GAM666/DPS901 Project requirements 20103

GAM666/DPS901 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources

Due Dates

Proposal outline and team members selected	September 21
Proposal completed and members roles selected	September 28
Research into game requirements begins	September 29
Approval meeting with instructor	Weeks of October 3 and October 10
Draft game submission and project review	November 16
Final game presentation	December 7

Project Requirements

Your game involves a real-time audio-visual experience in some sort of 3-D world. The user must be able to control at least some aspects of the game with a controller, and there must be some use of sound, both in the background and in response to some action in your game. The user should have control over which display devices, resolution and input devices are used at any time during the game. Your game may however offer only a subset of the available resolutions and input devices. Finally, your design code must differ significantly from the samples presented in class and you must identify the unique elements of your code in your submissions. Each game is a team effort. The structure of each team is up to the team members. Each member must contribute their own work in a selected area or areas of their choosing. All members should contribute to the design part of the assignment.

Phase 1

The first phase is a 200-300 word informal, written proposal of what you intend to implement in your game: what you imagine your game doing. Your description should identify the objects in your game and include one or more illustrations of your design. The illustrations may be hand-drawn and scanned. Included in your illustrations should be a map of what you envisage the 3D world of your game will look like, with 3-dimensional coordinates of all of the major points in the world. Your map should include all of the "actors" (moving objects) in the world. You should identify the coordinates as realistically as possible, being aware that you may need to scale them up or down as you implement your design in code.

As part of the submission each team member should provide a link on the team's project page to their own successfully compiled version of the 15-Controller sample. Each member should have their own copy of this sample in their own branch of the team's repository. The source code should include the following updates:

• add your own name to the caption for the dialog box
• change the window title to include the name of the team

You can obtain a copy of this sample from the dpsgam course repository.

The purpose of this first phase is twofold:

• to define your game in both scope and detail and thereby to give your instructor some idea of your design: whether what you intend is too simple, too complex or about right
• to ensure your instructor that you are ready to work with your own branch of your team's repository and ready to start modifying the framework to suit your team's design.

Your submission should enable your instructor to give you feedback and to discuss your proposal in some detail.

Your team should decide its own group to individual ratio for grading purposes and post the ratio on its project page.

Your team must arrange a time and date to meet with your instructor to discuss the proposal and to commit the different responsibilities of the team members. This meeting should take place no later than week 6 of the semester, preferably earlier.

Phase 2

The second phase releases a draft of your game without sound or input control.

This is your last opportunity to amend your proposal, modify your design and obtain your instructor's approval to any changes.

Phase 3

The third phase presents your completed game with sound and input control to the class. Your presentation includes a demonstration of how the game plays along with an explanation of the innovative aspects that your team members have implemented. Each team has no more than 20 minutes to showcase its game.

Some Suggested Upgrades to the Framework

The Framework in its final stage consists of 12,000 source lines of code. The Framework is only a starting point and fallback position for the design of your game. There are numerous opportunities to refactor different parts depending upon what your game requires and what your personal interests are. Decisions to focus on certain parts should reflect the areas with which you wish to become more familiar. Listed below are some areas that you should consider in deciding where to devote your energy. If you wish to add items to this list, consult your instructor.

Each team will introduce its own upgrades to the Framework. The nature of these upgrades will vary from team to team. Each team member is responsible for a thorough understanding of at least one particular upgrade.

Two upgrades are mandatory, while some are challenging:

• mandatory upgrades are in bold
• challenging upgrades are followed by an *

Modeling (Design Component)

1. game play logic
2. import a model script

Design Units (Scene Component)

1. design new objects for the scene
2. create billboards – clouds, smoke, vapor trails
3. add stock objects (requires changes to GraphicsCard Component also)
4. detect collisions between objects in a scene *

Viewpoints (Viewing Component)

1. comprehensive camera motion

3D Graphics (GraphicsCard Component)

1. improve texturing
2. introduce fog, emissive light
3. create new graphics representation for new objects in the scene
4. implement an OpenGL 3.0 version *
5. use Direct2D for fonts *
6. replace Direct3D9 with Direct3D10 *
7. replace Direct3D9 with Direct3D11 *

Sound (SoundCard Component)

1. sound effects on buffers and optimizing performance
2. replace DirectMusic with DirectSound only
3. replace DirectMusic and DirectSound with Xaudio2 *
4. create an Open Audio version *

User Interface (Input and UserDialog Components)

1. improve controller input and user dialog
2. action mapping *
3. replace DirectInput with Xinput *

Framework (Cross-Component)

1. context – implement a database
2. save the current state of the model to a file and restore from a file
3. performance optimizations *