Interactive Media & Game Development Worcester Polytechnic Institute	IMGD

Objective:	THIS PROJECT SHOULD BE DONE IN YOUR PROJECT TEAMS! In this project, you will set up the basic structure of your game "Jäger: The Hunt for Crazy Gert's Gold!": implementing simple first-person character movement allowing the player to pick up coins allowing the player to throw, drop, and eat Gummies allowing the player to pick mushrooms In addition, you will write code to generate a random maze for the player to explore. 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 put together your Jaeger development framework. A sample runable version of a sub-set of the functionality is available here; play it to see how it works! Use the WASD keys to move around the default labyrinth, and the mouse to look around. Using the knowledge you gained from Project 1, put together a simple first-person walk-around experience.
New Stuff:	You will need to implement the controls for moving, throwing, dropping, eating, and picking up of the various elements, using the keys defined below: wasd: Movement r, g, b (lower case): Throw a colored Gummy. The Gummy should collide with the environment. R, G, B (upper case): Drop a colored Gummy. The Gummy should collide with the environment. p: Pick up a nearby mushroom being looked at. The mushroom should disappear. e: Eat a nearby dropped Gummy being looked at. The Gummy should disappear. Mouse: Look around/point to objects. Objects (Gummies/Mushrooms) should only be interactable if they are looked at. Maybe give them a highlight? Thrown Gummies ar projected forward, while dropped Gummies fall straight down. Coins should be picked up when the player collides with them. They should disappear after being collected. You will need to write the code to generate a random labyrinth layout, based on the following rules: Each cell in the m x n maze should be assigned a cell type. Two cells may adjoin only if the adjoining sides are both openings or both walls. A cell side that abutts the edge of the maze must be a wall. A fully filled maze is only valid if there is a path from every filled cell to every other filled cell. At least 50% of all cells must be filled (some algorithms leave unreachable sub-sections of the grid). Cycles in the maze are okay. Use a random number generator seed to initialize the generation of the labyrinth. At the end of this project, you should have the solid basis for adding more game functionality.
Attacking the Problem:	This problem has as much to do with Unity as it does with coming up with a "good" algorithm to generate a proper labyrinth. So, independent of Unity, you should be able to come up with code to do this. Since time is short, you should try splitting up the work, so one person may work on generating the maze, while the other is getting the basic functionality/control working. Use the Unity forums for help, as well as talking to the TA. He has built a version of the full game, and can help point you in the right direction.
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 for all your projects. 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 how you altered the source files, and which art assets you created.
Submission:	All documents are to be submitted electronically via turnin by 11:59pm (Midnight) on the day the assignment is due. Build a web player executable for your modified game: Select Demo scene File > Build Settings > Web Player > Build Test the web executable by clicking on the .html file in the folder created by the build command. If the TA tries to run your demo and it does not run, you will fail this assignment. He will give you one chance to correct it. Copy all of the scripts (not art assets, if any) that you created or modified to the folder created by the build command above. You can organize these into subfolders if you wish. Do NOT try to zip up the complete Unity demo, including all the art assets, because the file will be too big for turnin! Prepare a plain text file, README.txt, in which you briefly describe the changes and extensions you have made to the demo code. Be specific about which classes and methods you have modified or added, and what you were trying to achieve. Add the README.txt file to the web folder. Zip the web folder. Thus we can play the game to see what it does and look at your scripts to see what you've done. When you are ready to submit, zip everything up into a single archive file. Name the file Lastname1Lastname2_proj2.zip. You will use the 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 proj2.
Academic Honesty:	Taking credit for work you did not do or getting unauthorized help on assigments or exams is cheating. If you are in doubt, ask the instructor first! Cheating is a serious offense, punishable by an automatic NR for the course. 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.