IMGD-3000 Project 3

	Interactive Media & Game Development Worcester Polytechnic Institute	IMGD

IMGD-3000: Technical Game Development I
Project 3
Due: February 6, 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 2 in pursuit of optimising the game "Jäger: The Hunt for Crazy Gert's Gold!".
You will implement two acceleration methods for rendering the labyrinth.
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. If you have not completed the work required in Project 2, this is the time to do so. Once you have your Project 2 code working, you will alter your code as follows:

Change the JaegerDrawMaze function in the file JaegerDraw.cpp to look like this.

Add the following two lines to the file JaegerGlobals.cpp:
int JaegerDrawMethod = DRAW_ALL; int JaegerDrawRadius = 10000; // In cm.
and the following lines to the file JaegerGlobals.h:
extern int JaegerDrawMethod; extern int JaegerDrawRadius;

Add the following four lines to the file JaegerConstants.h:
// Constants for JaegerDrawMethod. const int DRAW_ALL = 0; const int DRAW_RADIUS = 1; const int DRAW_VISIBLE = 2;

Add entries to your config file for choosing which method to use for drawing the labyrinth (i.e., just set the global variable JaegerDrawMethod to be one of the constants you defined above), and for setting the draw radius.

Compile and run your code-base before making any of the changes required for Project 3.

New Stuff: One of the main complaints about using/playing Jaeger has been the speed at which the rendering takes place. The main source of this problem is the fact that OpenGL will try to draw everything it is told to, and a large labyrinth creates a large number of textured polygons. In this project, you will implement two different approaches to improving response time using "interest management" techniques.
In the new JaegerDrawMaze function, there are two case clauses that you need to flesh out.

For the DRAW_RADIUS case, you should only draw those cells who are at least partially within a radius of JaegerDrawRadius of Hedi.

For the DRAW_VISIBLE case, you should only draw those cells that are "potentially visible" from Hedi's current cell. That is, if Hedi is standing in a "vertical" cell, both cells to the North and South of him would need to be rendered, in addition to the cell he is standing in. So, Hedi can see straight ahead (both North and South, to continue the example from above) until a wall is encountered. Also, if an opening to the left or right exists down this hallway, he can potentially see one cell "deeper" (i.e., further off to the East/West) from the hallway.

Regardless of the method, pseudo code for the actual drawing will be something like:
if( This_Cell_Needs_To_Be_Drawn ) { glPushMatrix( ); glTranslated( col * CellSide, 0.0, row * CellSide ); JaegerDrawCell( GertMaze->GetCell( row, col ) ); glPopMatrix( ); }
At the end of this project, you should have a fully working version of the game that draws much faster.

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 "proj3", is:
tar cvf LastName_FirstName_proj3.tar proj3
or
zip -r LastName_FirstName_proj3.zip 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.

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 optimising the game "Jäger: The Hunt for Crazy Gert's Gold!". You will implement two acceleration methods for rendering the labyrinth. 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. If you have not completed the work required in Project 2, this is the time to do so. Once you have your Project 2 code working, you will alter your code as follows: Change the `JaegerDrawMaze` function in the file `JaegerDraw.cpp` to look like this. Add the following two lines to the file `JaegerGlobals.cpp`: `int JaegerDrawMethod = DRAW_ALL; int JaegerDrawRadius = 10000; // In cm.` and the following lines to the file `JaegerGlobals.h`: `extern int JaegerDrawMethod; extern int JaegerDrawRadius;` Add the following four lines to the file `JaegerConstants.h`: `// Constants for JaegerDrawMethod. const int DRAW_ALL = 0; const int DRAW_RADIUS = 1; const int DRAW_VISIBLE = 2;` Add entries to your config file for choosing which method to use for drawing the labyrinth (i.e., just set the global variable `JaegerDrawMethod` to be one of the constants you defined above), and for setting the draw radius. Compile and run your code-base before making any of the changes required for Project 3.

New Stuff:	One of the main complaints about using/playing Jaeger has been the speed at which the rendering takes place. The main source of this problem is the fact that OpenGL will try to draw everything it is told to, and a large labyrinth creates a large number of textured polygons. In this project, you will implement two different approaches to improving response time using "interest management" techniques. In the new `JaegerDrawMaze` function, there are two `case` clauses that you need to flesh out. For the `DRAW_RADIUS` case, you should only draw those cells who are at least partially within a radius of `JaegerDrawRadius` of Hedi. For the `DRAW_VISIBLE` case, you should only draw those cells that are "potentially visible" from Hedi's current cell. That is, if Hedi is standing in a "vertical" cell, both cells to the North and South of him would need to be rendered, in addition to the cell he is standing in. So, Hedi can see straight ahead (both North and South, to continue the example from above) until a wall is encountered. Also, if an opening to the left or right exists down this hallway, he can potentially see one cell "deeper" (i.e., further off to the East/West) from the hallway. Regardless of the method, pseudo code for the actual drawing will be something like: `if( This_Cell_Needs_To_Be_Drawn ) { glPushMatrix( ); glTranslated( col * CellSide, 0.0, row * CellSide ); JaegerDrawCell( GertMaze->GetCell( row, col ) ); glPopMatrix( ); }` At the end of this project, you should have a fully working version of the game that draws much faster.

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 "proj3", is: `tar cvf LastName_FirstName_proj3.tar proj3` or `zip -r LastName_FirstName_proj3.zip 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.

Back to course page.