Interactive Media & Game Development Worcester Polytechnic Institute	IMGD

Objective:	THIS PROJECT MAY BE DONE IN TEAMS OF TWO! In this project, you will build on the work you accomplished on Project 2 in pursuit of completing the game "Jäger: The Hunt for Crazy Gert's Gold!". You will create the remaining data structures that will make up the rest of game. You will implement Ghoulie movement, and a way to exit the game. There are two parts to this project: a "Preparation" part, and a "New Stuff" part.
Preparation:	The aim of this preparation part is for you to get your Project 2 into a usable form. You and your teammate should decide on a code-base to start from. If one of you failed to get part of Project 2 working, or if you prefer to use one person's implementation over the other's, then this is when you should make this decision. You may combine any parts of one teammate's code with the other; all the code does not have to come from the same teammate. Compile and run your code-base before making any of the changes required for Project 3.
New Stuff:	You should flesh out the Jaeger files, and (possibly) add some more, based on the in-class exercises. You will implement Ghoulie movement, during regular play, good-mushroom play, and bad-mushroom play. Read the original project description for what these mean. You will implement code to appease a given Ghoulie by throwing jellybeans in the proper color sequence. You will implement code to display an "Exit" from the maze. This should be some marked trigger in the cell where Hedi spawns, so he can find his way back following dropped jellybeans. The trigger should exit the game. At the end of this project, you should have a fully working version of the game!
Extra Credit:	These options may be implemented for extra credit: Add effects of some kind, e.g., when Ghoulies show up, when you throw a jellybean, etc. Implement config-file options for "easy," "medium," and "difficult" levels of play. You may define what these are, but they must make sense. You will implement code to load the game parameters from the C4 configuration file. Here is a list of some of the things you should think about reading from this file. This is just a sample, and may contain information that your implementation does not need, or that you have chosen to do a different way. You will find, however, that once you have the ability to load parameters from a config file, instead of hard-coding things, this can speed development and testing greatly. You will implement code to allow the user to save and load the game. This means you will need to save the whole state of the game, or at least whatever you need to return to the same place. The file you save to need not be specified by the user; just use a default name, like "jaeger_save.txt". You may want to read this default name from the config file. There is help for this on the C4 Wiki.
Documentation:	You must create adequate documentation, both internal and external, along with your project. The best way to produce internal documentation is by including inline comments. The preferred way to do this is to write the comments as you code. Get in the habit of writing comments as you type in your code. A good rule of thumb is that all code that does something non-trivial should have comments describing what you are doing. This is as much for others who might have to maintain your code, as for you (imagine you have to go back and maintain code you have not looked at for six months -- this WILL happen to you in the future!). I use these file and function (method) headers, in my code. Please adopt these (or the official CS ones) for all your projects. The file header should be used for both ".h" and ".cpp" (or ".c") files. Create external documentation for your program and submit it along with the project. The documentation does not have to be unnecessarily long, but should explain briefly what each part of your program does, and how your filenames tie in. Most importantly, tell the TA how to compile your program.
What to Turn in:	All documents are to be submitted electronically via turnin by 11:59 pm on the day the assignment is due. Make sure to include a README file as well, listing the names of your team members, and a short description of what each person did. Only one of you needs to turn in the project for both team members. When you are ready to submit, zip everything up into a single archive file. Name the file LastnameFirstname_proj3.zip. You will use the new Web-based "Turnin" facility to submit your work. Information about submitting can be found here: http://web.cs.wpi.edu/~kfisler/turnin.html. Choose one of your team members to submit the document. Your WPI user ID should be used to login, and you should have been emailed a password. The Turnin assignment ID is proj3.
Academic Honesty:	Remember the policy on Academic Honesty: You may discuss the project with others, but you are to do your own work. The official WPI statement for Academic Honesty can be accessed HERE.