Halma Game Deliverables

Phase 0 deliverable:

Phase 0 Deliverable consists of the following:

1. Single nicely-formatted page with: Team name, team logo, Team members, course, assignment title, date

This establishes the team and is essentially the cover sheet that you'll use for the remaining deliverables.

Phase 1 deliverable:

Phase 1 Deliverable consists of the following, presented exactly in the order shown below:

1. Cover sheet:  Team name, team logo, Team members, course, assignment title, date
2. Overview. A brief description of how you chose to architect your project: overview of the key objects/classes and their key methods.
3. Effort description. This documents in a fairly precise fashion, which teammate worked on what parts of the project and how that person performed. Start with an overall statement of how you split up the work in the phase, e.g., "We discussed our skills/interests and this is what came out <discuss>. Given this, we generally decided that Joe would lead on X, Suzy would lead on Y, and Pat would lead on Z". The heart is then a *detailed* table that shows the major tasks involved in that stage. You could use my bullets above as a starting point, but ultimately its up to each team to decide how to split up the work. The table has four columns: Task description, Assigned to, Percentage of effort, completion notes. How to fill this out:
   • Task description obviously outlines what the task is, with focus on functionalities expected in the outcome product.
   • Percentage of effort is the percentage of effort that this task took out of the total effort invested for this project phase. Obviously the sum of %effort across all tasks in the phase by all team members (i.e., the effort column as a whole) should total up to 100%. By totalling the effort for tasks done by any one person, one would get the percentage of effort invested by that person in this particular project phase; in an ideal team, that number would be 1/N percent, where N is the number on the team.
   • Tasks are assigned to ONE person on the team; it is that person's sole responsibility to see that the task gets done.
   • Completion notes document what actually happened. In the best case, it just says "completed and satisfactory". If the team member was not able to complete the task and another team member had to jump in, this is documented here. Describe what happened, and state what percentage of the task (task owner versus rescuer) performed.
4. Functionality checklist. This documents precisely the functionality that you completed for this phase. Hopefully, this is just a series of "100% working" checkmarks. Make this a table as well, with three columns: Functionality, %complete, notes. Here are the items in the "Functionality" column:
   • Graphical board display: Generates nicely-formatted GUI for your system, including the board, plus status and move entry areas
   • Board updating: GUI can receive updates to the board, display them smoothly, and includes move highlighting to chose from/to places of last-moved piece.
   • Move generator: Given a board and which player to move, it produces a correct and complete list of possible next moves, including jumps.
   • Win detector: Given a board and a player, correctly returns whether it is a winning (or losing!) board for that player.
   • A "move" method. Takes in a board and a move and returns either a new board (after making move), or an error report detailing a bad move.
   • Fully functional play mode: A Game object that plays a fully functional manual game, taking in moves from two human players in alternating sequence, showing the boards, reporting bad moves, and reporting win/loss.
   • Any extra/additional functionality that you innovated and think is worth highlighting.
5. Demos: Clearly labeled and annotated screenshots that very clearly demonstrated each of the above. In the best case, this is just a sequence of screenshots (labeled and annotated) of two humans playing your game, showing the board, some both good and erroneous moves, and ultimately a win by someone. Obviously, if your product is not able to play a coherent game, then you'll need to at least demo each of the pieces that you did get working. Let's hope it doesn't come to that...

Phase 2 deliverable:

Phase two deliverable consists of the following, presented exactly in the order shown below:

1. Cover sheet:  Team name, team logo, Team members, course, assignment title, date
2. Overview: Similar to phase 1, but now extended to focus on the creation of your intelligent Halma agent. Condense your description of the basics from Phase1 (labeling them as "Phase1" pieces), but leave them in so as to give a complete picture. Then add in (labeling as Phase 2) what objects/classes you added to upgrade your program into an intelligent system for playing Halma. Be sure to discuss the design of your utility function, i.e., what metrics it uses to determine the "goodness" of a board.
3. Effort Description. Exactly as for Phase 1, but now centered around your Phase2 tasks, as assigned to team members.
4. Functionality Checklist. Just as for Phase 1, but now has the following items for the Functionality column:
   • Utility function. Have a fully-functional utility function that, given a board, return some non-trivial (i.e. actually useful) measure of how strong that board is.
   • Minimax search. Is able to take a board, which player is moving, and some indication of how much to search (either #plies directly, or the time it has to move), and will return a move. At very least, it returns a legal move to make each and every time. At best, it returns a really *good* move to make!
   • Alpha-beta. Can be turned on or off (for testing purposes) in your call to minimax search. Implements the alpha-beta algorithm correctly. Has some way of reporting the pruning events, so that you can effectively debug/demo its efficacy.
   • Any extra/additional functionality that you think is worth highlighting.
5. Demos: Same thing as before, but focus it on your "intelligent" pieces. Some specifics to show would be:
   • Your unit testing for minimax: show some board, then start minimax on that board with some time limit, then show the resulting move plus all the stats: how many plies you went down, how many boards where generated/examined, and time taken.
   • Your alpha-beta being awesome. Using the same board as above, now show your minimax running with alpha-beta turned ON. One would hope to see the stats improve (more boards within same time...or less time for same number of boards), plus some indication of how many pruning events happened and on what ply/level.