IMGD-3000 Project 2

	Interactive Media & Game Development Worcester Polytechnic Institute	IMGD

IMGD-3000: Technical Game Development I
Project 2
Due: January 30, 2007 at 11:59pm

Objective: THIS PROJECT MAY BE DONE IN TEAMS OF TWO!
In this project, you will build on the work you accomplished on Project 1 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 create a user interface to display Hedi's state to the user, implement Goolie movement, implement "strafing," a.k.a. side-stepping, and allow the user to save and load the game. You will also implement code to load the game parameters from a configuration file.
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 1 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 1 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.
In addition, you should download the ZIP file for this project. Copy it to the directory where you will be doing your work, and unzip it. You will see several .cpp and .h files, as well as some Makefiles. I would suggest you start with this code, then add your code from Project 1 to it. It has lots of good starter code for you to use.
Compile and run your code-base before making any of the changes required for Project 2.

New Stuff:

You should flesh out the "Jaeger*" files, and (possibly) add some more (like maybe JaegerGoolie.*), based on the in-class exercises, as well as your team work.

You will create a user interface to display Hedi's state to the user. We will give you some code to assist you in this. You need to include elements showing:

Gold he is carrying,

Mushroom time/type,

Goolie time/tuple,

Status messages, and

The jellybean on the floor of the current cell, if any.

You will implement Goolie 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 allow the user to "strafe" a.k.a., step sideways, using <CTRL+LEFT_ARROW>/<CTRL+RIGHT_ARROW>.

You will implement code to load the game parameters from a configuration file. Here is a sample of what you might want to use as a format for 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.

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.

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 sound effects of some kind, e.g., when Goolies show up, when you throw a jellybean, etc.

Implement command-line options for "easy," "medium," and "difficult" levels of play. You may define what these are, but they must make sense.

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.
NOTE: For this project, you must also include a document stating what each person on your team did towards completing the project. This can be as simple as copying the list of deliverables (from above), and placing names next to each one. Or it can be more precise. If you feel you would like to express your views individually, send an email to the instructor.
Here is a list of some ideas that might help you when working in groups:

http://www.alice.org/bvw2001/tips.html

http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info.html

http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info2.html

http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info3.html

What to
Turn in: Submit everything you need to compile and run your program (source files, data files, etc.)
BEFORE YOU SUBMIT YOUR PROJECT, put everything in one directory on ccc.wpi.edu and make sure it compiles. Then tar (or zip) everything up into a single archive file.
The command to archive everything, assuming your code is in a directory "proj2", is:
tar cvf LastName_FirstName_proj2.tar proj2
or
zip -r LastName_FirstName_proj2.zip proj2

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.

Objective:	THIS PROJECT MAY BE DONE IN TEAMS OF TWO! In this project, you will build on the work you accomplished on Project 1 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 create a user interface to display Hedi's state to the user, implement Goolie movement, implement "strafing," a.k.a. side-stepping, and allow the user to save and load the game. You will also implement code to load the game parameters from a configuration file. 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 1 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 1 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. In addition, you should download the ZIP file for this project. Copy it to the directory where you will be doing your work, and unzip it. You will see several .cpp and .h files, as well as some Makefiles. I would suggest you start with this code, then add your code from Project 1 to it. It has lots of good starter code for you to use. Compile and run your code-base before making any of the changes required for Project 2.

New Stuff:	You should flesh out the "Jaeger" files, and (possibly) add some more (like maybe `JaegerGoolie.`), based on the in-class exercises, as well as your team work. You will create a user interface to display Hedi's state to the user. We will give you some code to assist you in this. You need to include elements showing: Gold he is carrying, Mushroom time/type, Goolie time/tuple, Status messages, and The jellybean on the floor of the current cell, if any. You will implement Goolie 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 allow the user to "strafe" a.k.a., step sideways, using <CTRL+LEFT_ARROW>/<CTRL+RIGHT_ARROW>. You will implement code to load the game parameters from a configuration file. Here is a sample of what you might want to use as a format for 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. 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. 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 sound effects of some kind, e.g., when Goolies show up, when you throw a jellybean, etc. Implement command-line options for "easy," "medium," and "difficult" levels of play. You may define what these are, but they must make sense.

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. NOTE: For this project, you must also include a document stating what each person on your team did towards completing the project. This can be as simple as copying the list of deliverables (from above), and placing names next to each one. Or it can be more precise. If you feel you would like to express your views individually, send an email to the instructor. Here is a list of some ideas that might help you when working in groups: http://www.alice.org/bvw2001/tips.html http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info.html http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info2.html http://web.cs.wpi.edu/~dcb/courses/CS3041/Group-info3.html

What to Turn in:	Submit everything you need to compile and run your program (source files, data files, etc.) BEFORE YOU SUBMIT YOUR PROJECT, put everything in one directory on ccc.wpi.edu and make sure it compiles. Then tar (or zip) everything up into a single archive file. The command to archive everything, assuming your code is in a directory "proj2", is: `tar cvf LastName_FirstName_proj2.tar proj2` or `zip -r LastName_FirstName_proj2.zip proj2`

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.

Back to course page.