Back to Programming Project landing page
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, you might still be be trying to successfully complete Part 1 specifications.
Your focus in Part 2 can be on one or more of the following.
- In the case where you did not get your Part 1 working or evaluated, you can keep working on the code for Part 1. But you should do more, because the bulk of this option alone won’t contribute much to your Part 2 grade!
- Assuming that you satisfy the Part 1 correctness standards and evaluation criteria, you can improve on your 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 option 2, perhaps in conjunction with 1. This self-improvement, lessons learned could be significant for purposes of advancing the project in other ways too.
- Ideally, you will be at a point already, or you can quickly get to a point where you 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 Part 2.
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 others. You can release Part 1 code in totality (free revealing) and others 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 someone who uses another’s code. If you use another’s released code, then you must cite that reuse when referencing it and must declare the reuse in your final deliverable (an honor code requirement). The person’s whose code is reused will get significant points for the reuse by others of their code. The better documented your code, and the better your code evaluates along performance dimensions, the better chance that your code will be reused by others.
Its possible that you will use another student’s released code if you did not do well in Part 1, and/or you think another student’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 students. 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 if you want feedback in deciding.
In addition to code sharing through free revealing, knowledge brokering possibilities abound. If, for example, there are several students 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 knowledge brokering or not, the development efforts in Part 2 can again be free revealed, so that other students, can for example, take part in a coopetion in a game created by another student.
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.
Project Part 2 Deliverables
You will submit the following to Brightspace (see Schedule for due date). The primary narrative of project Part 2 will be in the form of Powerpoint slides and a video presentation using those slides. You will also be submitting your well-documented, beautiful code.
- file 1 (a zip file):
- Powerpoint slides accompanying the video
a text file containing a video LINK (e.g., a private link on Youtube or a link to a Zoom recording).- The bulk of your part 2 grade will be based on the video and slides. The video should focus on improvements/additions/changes/expansions that you have done since Part 1
- Make sure that Doug (doug.h.fisher@gmail.com if on Youtube) can view the video without having to ask.
- A reasonable time upperbound for the video is 15 minutes, and/but you should include all that you regard as important about your Part 2 work. These can be improvements/additions/expansions to functionality based on at least one of the three broad Part 2 ideas (e.g., gamification, machine learning, and world modeling) or some other area that we have discussed, and/or remediating your Part 1 work (as explained in the Part 2 overview).
- Summaries of experimental studies, including explanations of selected cases, graphs and tables
- Remember that well-thought figures can be worth a “1000 words”. At a minimum you might include an architectural design of your system, to include parts of the system that still implement basic Part 1 functionality. But in any case, give a comprehensible overview.
- Citations to outside sources that you used (e.g., on transforms and resources, algorithmic variations), to include references to other teams.
- Powerpoint slides accompanying the video
- file 2 (a zip file): well-documented and well formatted code, include a READ ME file with clear and detailed directions for running your code and that identifies the file that contains the game_scheduler function, and any other important top-level functions. You will also be graded on the documentation and format of the entirety of Part 1 and Part 2 code.