In Part 1, you were required to adhere to a somewhat specific specification, albeit with lots of room for research and creativity in the system that you designed, implemented, and evaluated. In Part 2, you are given considerably more leeway in how you expand, improve, and otherwise alter, the scheduler/simulator of Part 1. Nonetheless, some teams might still be be trying to successfully complete Part 1 specifications.
It is relevant in what follows to state that of the 100% of the team project grade for the course, Part 1 counts 65%, and Part 2 counts 35%, to reflect the greater time required for Part 1 and the greater risks in Part 2.
A team’s focus in Part 2 can be on one or more of the following.
- In the case where a team did not get their Part 1 working at correctness standards and evaluation requirements, that team can keep working on the code that they produced on Part 1. If this is all that the team does, and does it successfully, a 65%/100% is probably the highest grade that the team is looking at for their total team grade (assuming high scores in other project aspects of Part 1, like intermediate updates and individual updates), but that’s probably going to lead to a passing grade and doesn’t keep you from graduating! Work in this option 1 — getting your Part 1 up to spec — will not be the basis of any Part 2 team intermediate updates, so a focus only on this option will probably prevent you from maxing the 65%/100% total team grade.
- Assuming that a team satisfies the Part 1 correctness standards and evaluation criteria, the team can improve upon their own project code, perhaps replacing a computationally expensive search that really limits the number and quality of schedules derived (e.g., a beam search) with a less expensive search that still yields schedules of acceptable quality and deeper depths, and does so much faster (e.g., a depth-bounded heuristic depth first search), and then repeat experimental evaluations. If you were only to do 2, perhaps in conjunction with 1, this could lead up to a total team grade of 75%-80% of 100% of the total team grade (65% for Part 1, and 10%-15% for the lessons learned work that does not extend the part 1 specification), (assuming high scores in other aspects of Part 1, like intermediate updates and individual updates). But this self-improvement, lessons learned could be significant for purposes of advancing the project in other ways (see below — you might be a more attractive participant in a game that was created by another team). Work on this option 2 — improvement to Part 1 based on lessons learned can be the basis of Part 2 intermediate team updates.
- Ideally, a team will be at a point already, or they can quickly get to a point by finishing/improving upon Part1 quickly, where they can start expanding the Part 1 specification in at least one of several ways. Gamifying the simulation and machine learning are two broad ways that we’ve discussed, and that are listed in the Part 2 ideas page. Its likely and intended that this option 3 — expanding the Part 1 spec into other functionality — will be the focus of most of the Part 2 intermediate team updates.
Knowledge sharing guidelines will also change in Part 2. Free revealing played a role in Part 1, and that will continue in Part 2, but additionally you can participate in knowledge brokering with other teams. A team can release, with agreement from all team members, its Part 1 code in totality (free revealing) and other teams can use all or part of it in their Part 2 designs and implementations, even to the exclusion of their own Part 1 code. Thus, there is also the potential for a soft ‘reset’ for a team that uses another team’s code. If team X uses another team’s released code, then X must cite that reuse when referencing it in class and must declare the reuse to Doug at a minimum (an honor code requirement), but no points are given to X for that reuse per se. In contrast, the other team, call it Y, will get significant points for the reuse by others of its code. The better documented your team’s code, and the better your code evaluates along performance dimensions (and the team shares this too), the better chance that your code will be reused by others.
Its possible that you will use another team’s released code if you did not do well in Part 1, and/or you think another team’s code will be a better jumping off point for Part 2, and/or if you see advantages to one code base when jointly developing Part 2 enhancements with one or more other teams. You might also ask whether it would be advantageous to “start over” on Part 2 and leave your Part 1 alone, rather than further achieve complete correctness, satisfactory evaluation, and lessons learned. Whether this is a good option or not depends on how far away you are from a best-possible score in Part 1, and how far you will get in Part 2 enhancements when building on another project. Talk to Doug and Jesse if you want feedback in deciding.
In addition to code sharing through free revealing, knowledge brokering possibilities abound. If, for example, there are several teams interested in implementing a game and associated game manager, they can cooperate on the creation of the game manager, a communication protocol between players and the manager, round robin infrastructure, etc, splitting the development responsibilities as they see fit. The more teams involved in a joint effort, say a gamification, the more functionality I would expect for the same grade, ranging from a basic “bookkeeping” game manager to one that does user modeling through machine learning and other forms of game manager intelligence.
Whether through across-team knowledge brokering or not, the development efforts in Part 2 can again be free revealed, so that other teams, can for example, take part in a coopetion in a game created by another team.
Similar guidelines on knowledge brokering and free revealing apply to other Part 2 areas as well, such as machine learning of macros, learning search preferences through reinforcement learning, and the like.