Difference between revisions of "GAM670/DPS905 Project Requirements 20111"

From CDOT Wiki
Jump to: navigation, search
(Suggested Upgrades to the Base Code)
(Due Dates)
Line 80: Line 80:
 
|-
 
|-
 
|Proposal completed and members' roles selected
 
|Proposal completed and members' roles selected
|January 31
+
|February 1
 
|-
 
|-
 
|Phase 1 completed
 
|Phase 1 completed

Revision as of 11:15, 8 January 2011


GAM670/DPS905 | Weekly Schedule | Student List | Project Requirements | Teams and their Projects | Student Resources



Appointment Schedule

Team Name Date and Time
Tuesday January 18 10:00AM
Tuesday January 18 10:15AM
Tuesday January 18 10:30AM
Tuesday January 18 10:45AM
Tuesday January 18 11:00AM
Tuesday January 18 11:15AM


Due Dates

Proposed game and team members selected January 18
Proposal completed and members' roles selected February 1
Phase 1 completed February 22
Phase 2 completed - Presentation March 22
Approval meeting with instructor March 29
Phase 3 completed - Presentation April 12-14



Project Requirements

Your game involves a real-time audio-visual-haptic experience in a 3-D world using advanced game programming techniques to improve the performance and the appeal of your game. The user should experience force feedback through some form of controller in response to certain common actions in your game. Each member must contribute their own feature to the game development in a selected area of specialization. Each member should also contribute to the integration of a separate, unrelated feature developed by another team.

Phase 1

The first phase is an informal, written proposal of the features that your team wishes to implement in its final game. Your description should identify the basic aspects of these features as well as the refinements needed to produce a comprehensive implementation. This will require some research on your part, especially in the case of DPS905 students. Your proposal should be documented on the team project page of the course wiki under Proposal. Your proposal should identify the parts of the framework that you expect to modify extensively in your implementation after consultation with your instructor.

Each team member should have their own successfully compiled version of the base code in their own workspace in the branch sub-directory of their team's repository.

The source code for your copy of the base 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

Merge all of the team members' workspaces back to trunk so that the caption of the dialog box shows all of the names of the team members. See Merging your work back to trunk for detail

The purpose of this first phase of the project is twofold:

  • to define your final game in both scope and detail
  • to enable your instructor to identify some details that you will need to address in implementing the selected features

Your team should decide its own group to individual ratio for grading purposes and post the agreed 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.

Phase 2

The second phase releases a version of the framework that includes the new features that your team has incorporated. This phase includes a presentation that shows how your new features work within your own game.

Phase 3

The third phase presents your completed game with your team's new features and two new features of other teams incorporated. 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.


Suggested Upgrades to the Base Code

In this course, the base code serves as the common thread for sharing the feature work amongst all members of the class. The features added by the class should include as many as the students wish to see implemented in their own games. You are welcome to add features to the following list.

  • visibility determination
    • bounding volumes
    • spatial partitioning
      • octrees
      • BSP trees
      • portal systems
  • collision detection
    • plane collisions
    • oriented bounding boxes
    • sliding
  • lighting techniques
    • isotropic
      • Cook-Torrance
      • Oren-Nayar
    • anisotropic
      • Ward
      • Ashikhmin-Shirley
    • bump mapping
      • parallax
      • self-shadowing
    • environment cube maps
      • cube mapping
      • high dynamic range cube maps
    • high dynamic range lighting
      • simple
      • faked
      • tone mapping
  • texturing techniques
    • projective texturing
    • vertex texturing
      • displacement mapping
      • geometry images
  • audio techniques
  • comprehensive collada imports
  • quaternions
  • networked gameplay
  • noise
  • fluids
  • non-photo-realistic rendering
  • particle systems
  • terrain
    • terrain following
  • opengl 3.0
  • open audio
  • Direct3D10
    • porting the framework to DirectX10
  • Direct3D11
    • porting the framework to DirectX11
  • Direct2D
  • advanced force feedback
  • input techniques
    • XInput
    • Raw input
    • picking