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

From CDOT Wiki
Jump to: navigation, search
(Created page with '{{GAM670/DPS905 Index | 20111}} <!--= Presentation Schedule = {| border="1" |- |Team Name |Date and Time |- |- |Team |Tuesday January 18 8:00AM |- |Slap Your Grandma |Tuesday De…')
 
 
(55 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
{{GAM670/DPS905 Index | 20111}}
 
{{GAM670/DPS905 Index | 20111}}
−
<!--= Presentation Schedule =
+
= Game Presentation Schedule =
 
{|  border="1"
 
{|  border="1"
 
|-
 
|-
Line 7: Line 7:
 
|-
 
|-
 
|-
 
|-
−
|Team
+
|Team Zombie
−
|Tuesday January 18 8:00AM
+
|Tuesday April 12 8:20AM
 
|-
 
|-
−
|Slap Your Grandma
+
|
−
|Tuesday December 7 8:15AM
+
|Tuesday April 12 8:50AM
 
|-
 
|-
−
|Team Zombie
+
|Team Guardian
−
|Tuesday December 7 8:30AM
+
|Tuesday April 12 9:20AM
 
|-
 
|-
 
|Team GG
 
|Team GG
−
|Tuesday  December 7 8:45AM
+
|Thursday April 14 8:20AM
 
|-
 
|-
−
|Cerebral Thought
+
|Team HSD
−
|Tuesday  December 7 9:00AM
+
|Thursday April 14 8:50AM
 
|-
 
|-
−
|Team Mutalisk
+
|Team Slap Your Grandma
−
|Tuesday  December 7 9:15AM
+
|Thursday April 14 9:20AM
 
|-
 
|-
−
|Copy Cat
+
|}
−
|Thursday December 9 8:00AM
+
<br />
 +
 
 +
= Presentation Schedule =
 +
{| border="1"
 
|-
 
|-
−
|
+
|Team Name
−
|Thursday December 9 8:15AM
+
|Date and Time
 +
|-
 +
|-
 +
|Team Guardian - Hasan, JP
 +
|Tuesday March 22 9:00AM
 +
|-
 +
|Team Zombie - Damian, Qing
 +
|Thursday March 24 8:00AM
 +
|-
 +
|Hic Sunt Dracones - David
 +
|Thursday March 24 9:15AM
 
|-
 
|-
−
|Double Tap
+
|Team GG - Brad
−
|Thursday December 9 8:30AM
+
|Tuesday March 29 8:00AM
 
|-
 
|-
−
| Hic Sunt Dracones
+
|Team GG - Randl
−
|Thursday December 9 8:45AM
+
|Tuesday  March 29 8:30AM
 
|-
 
|-
−
|SheetBrix Robotics
+
|Slap Your Grandma - Dan, Andrei, Sasha
−
|Thursday December 9 9:00AM
+
|Tuesday  March 29 9:00AM
 
|-
 
|-
−
|The 10th Floor
+
|Hic Sunt Dracones - Daniel, Jon, Kaitlyn
−
|Thursday December 9 9:15AM
+
|Thursday March 31 8:00AM
 
|-
 
|-
 
|}
 
|}
−
<br />-->
+
<br />
 +
 
 +
= Appointment Schedules =
 +
Initial Proposal
  
−
= Appointment Schedule =
 
 
{|  border="1"
 
{|  border="1"
 
|-
 
|-
Line 52: Line 67:
 
|Date and Time
 
|Date and Time
 
|-
 
|-
−
|
+
|Zombie
 
|Tuesday January 18 10:00AM
 
|Tuesday January 18 10:00AM
 
|-
 
|-
−
|
+
|Team GG
 
|Tuesday January 18 10:15AM
 
|Tuesday January 18 10:15AM
 
|-
 
|-
−
|
+
|Team Guardian
 
|Tuesday January 18 10:30AM
 
|Tuesday January 18 10:30AM
 
|-
 
|-
−
|
+
|Andrew Condinho
 
|Tuesday January 18 10:45AM
 
|Tuesday January 18 10:45AM
 
|-
 
|-
Line 69: Line 84:
 
|
 
|
 
|Tuesday January 18 11:15AM
 
|Tuesday January 18 11:15AM
 +
|-
 +
|Slap Your Grandma
 +
|Tuesday January 18 1:30PM
 +
|-
 +
|}
 +
Proposal Acceptance
 +
{|  border="1"
 +
|-
 +
|Team Name
 +
|Date and Time
 +
|-
 +
|Team GG
 +
|Tuesday February 1 10:00AM
 +
|-
 +
|Zombie
 +
|Tuesday February 1 10:15AM
 +
|-
 +
|Andrei Kopytov
 +
|Tuesday February 1 10:30AM
 +
|-
 +
|
 +
|Tuesday February 1 10:45AM
 +
|-
 +
|
 +
|Tuesday February 1 11:00AM
 +
|-
 +
|
 +
|Tuesday February 1 11:15AM
 +
|-
 +
|Slap Your Grandma
 +
|Tuesday February 1 1:30PM
 +
|-
 +
|}
 +
Project Review
 +
{|  border="1"
 +
|-
 +
|Team Name
 +
|Date and Time
 +
|-
 +
|Team GG
 +
|Tuesday February 22 10:00AM
 +
|-
 +
|Zombie
 +
|Tuesday February 22 10:15AM
 +
|-
 +
|
 +
|Tuesday February 22 10:30AM
 +
|-
 +
|
 +
|Tuesday February 22 10:45AM
 +
|-
 +
|
 +
|Tuesday February 22 11:00AM
 +
|-
 +
|
 +
|Tuesday February 22 11:15AM
 +
|-
 +
|Slap Your Grandma
 +
|Tuesday February 22 1:30PM
 
|-
 
|-
 
|}
 
|}
Line 76: Line 150:
 
{|  border="1"
 
{|  border="1"
 
|-
 
|-
−
|Proposal outline and team members selected
+
|Proposed game and team members selected
−
|September 21
+
|January 18
 
|-
 
|-
−
|Proposal completed and members roles selected
+
|Proposal completed and members' roles selected
−
|September 28
+
|February 1
 
|-
 
|-
−
|Member branches with updated 15-Controller sample ready
+
|Phase 2 draft and review
−
|September 30
+
|February 22
 
|-
 
|-
−
|Research into game requirements begins
+
|Phase 2 completed - Presentation
−
|September 30
+
|March 22
 
|-
 
|-
−
|Approval meeting with instructor
+
|Phase 3 completed - Presentation
−
|Weeks of October 3 and October 10
 
−
|-
 
−
|Draft game submission
 
−
|November 16
 
−
|-
 
−
|Project Review meeting with instructor
 
−
|Weeks of November 14 and November 21
 
−
|-
 
−
|Final game presentation
 
 
|April 12-14
 
|April 12-14
 
|}
 
|}
Line 105: Line 170:
 
= Project Requirements =
 
= 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.
+
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 ==
 
== 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.
+
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 to those features that are needed to implement your game design. Identifying the features and the required refinements will demand some research on your part. In the case of DPS905 students, the research should be deep and the description should identify the theory behind the required refinements.  
−
 
 
−
Submit the written proposal on your wiki team-page under '''Proposal''' and '''Map of the World of the Game'''.
 
  
−
Before continuing phase 1, please do the following
+
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. A draft of your proposal should be on the wiki before your meeting with the instructor and you should update your proposal after consultation with your instructor.
−
# Read [[Hints for Using SVN to collaborate on school projects]]
 
−
# Update your team's wiki page with your team's repository path information under '''Repo Path'''
 
−
# Create a directory with your seneca id under the branch sub-directory of your team's repository. This will be your home directory for development; for details see: [http://zenit.senecac.on.ca/wiki/index.php/Hints_for_Using_SVN_to_collaborate_on_school_projects#Directory_Structure Directory Structure]
 
−
# One of the team members should volunteer to export svn://zenit.senecac.on.ca/dpsgam/trunk/15-Controller into the trunk of your team's repository
 
−
#: For hints see [[Hints for Using SVN to collaborate on school projects#Start_the_project_by_continuing_an_existing_work | Start the project by continuing an existing work]]
 
  
−
Each team member should have their own successfully compiled version of the 15-Controller sample in their own workspace in the branch sub-directory of their team's repository.
+
In developing your game, you may start with the code that you used in the previous course or you may start with the base code for this course.  The base code for this course is an update version of the base code for the previous course.  In any event, each member should use the updated base code to develop the feature that they have selected and present the results of their work using the updated base code.  In other words, the update base code with the new features installed will serve as the source for other teams' access.  
−
Branch submission path: svn://zenit.senecac.on.ca/dps901_103rep??/branches/SenecaID/15C 
 
  
−
: ''Start doing the above by branching the 15-Controller into svn://zenit.senecac.on.ca/dps901_103rep??/branches/SenecaID/15C. See here for help: [http://zenit.senecac.on.ca/wiki/index.php/Hints_for_Using_SVN_to_collaborate_on_school_projects#Preparing_Branches.2Fworkspace_for_development Preparing Branches/workspace for development]''
+
Each team member should have their own successfully compiled version of the updated base code in their own workspace in the branch sub-directory of their team's repository.
  
−
 
+
The source code for each team member's copy of the base code should include the following updates:
−
The source code for the upgraded 15-Controller sample should include the following updates:
 
 
* add your own name to the caption for the dialog box
 
* add your own name to the caption for the dialog box
 
* change the window title to include the name of the team
 
* 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  [http://zenit.senecac.on.ca/wiki/index.php/Hints_for_Using_SVN_to_collaborate_on_school_projects#Merging_your_work_back_to_trunk Merging your work back to trunk] for details
−
Merge all of the team members' 15C workspaces back to trunk so that the caption of the dialog box shows all of the names of the team members. See  [http://zenit.senecac.on.ca/wiki/index.php/Hints_for_Using_SVN_to_collaborate_on_school_projects#Merging_your_work_back_to_trunk Merging your work back to trunk] for detail
 
−
 
 
  
 
The purpose of this first phase of the project is twofold:
 
The purpose of this first phase of the project 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 identify the features that your final game will include
−
* 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.
+
* to identify the features that each member of your team will incorporate
−
Your submission should enable your instructor to give you feedback and to discuss your proposal in some detail.
+
* to identify the features that your team is expecting to incorporate from the work of other teams.
  
 
Your team should decide its own group to individual ratio for grading purposes and post the agreed ratio on its project page.
 
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. This meeting should take place no later than week 6 of the semester, preferably earlier.
+
== Phase 2 ==
  
−
== Phase 2 ==
+
The second phase releases a version of the updated base code that includes the new features that your team members have incorporated.
  
−
The second phase releases a draft of your game without sound or input control. 
+
This phase includes a presentation that shows
 +
* how your new features work within
 +
** the updated base code
 +
** your own game
 +
* how to incorporate the new features in external code
  
−
This is your last opportunity to amend your proposal, modify your design and obtain your instructor's approval to any changes.
+
Your team will have one hour to make its presentation and each team member will have fifteen minutes to describe the feature that they implemented themselves
  
 
== Phase 3 ==
 
== 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.
+
The third phase presents your completed game with your team's new features and two new features that members of other teams developed.  
 +
 
 +
Your presentation includes
 +
* a demonstration of how the game plays
 +
* an explanation of the innovative aspects that your team members have implemented
 +
* an evaluation of the features that your team incorporated, including criticisms and suggested enhancements
 +
 
 +
Each team has 30 minutes to showcase its game.
 
<br />
 
<br />
 
<br />
 
<br />
 
<br />
 
<br />
  
−
= Some Suggested Upgrades to the Framework =
+
= Features that you could add to the Updated Base Code =
 +
 
 +
The base code serves as the common thread for sharing feature development amongst all members of the class.  Our objective is to add as many of the features that students wish to see implemented in their own games as possible.  We review this list at the start of the semester and you are welcome to expand detail or to add other features.
  
−
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.
+
* visibility determination
−
+
** view frustum
−
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.
+
** bounding volume construction
 +
*** principal component analysis
 +
***: covariance matrix
 +
*** bounding box construction
 +
*** bounding sphere construction
 +
*** bounding ellipsoid construction
 +
** bounding volume tests
 +
**: bounding sphere test
 +
**: bounding ellipsoid test
 +
**: bounding cylinder test
 +
**: bounding box test
 +
** spatial partitioning
 +
*** octrees
 +
*** BSP trees
 +
** portal systems
 +
**: portal clipping
 +
**: reduced view frustums
 +
* collision detection
 +
** plane collisions
 +
**: sphere and plane
 +
**: box and plane
 +
**: spatial partitioning
 +
** general sphere collisions
 +
** oriented bounding boxes
 +
** sliding
 +
** collisions with physics
 +
*** moving spheres
 +
*** moving boxes
 +
* 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
 +
* third-person camera techniques
 +
* 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
 +
* optimize coordinators for design unit creation and destruction
 +
** introduce standard template library
 +
** 0(1) removal of objects
 +
** provide external access to all objects in the scene coordinator
 +
* enable Streaming SIMD Extension 2 in Configuration Properties with optimized math calculations

Latest revision as of 07:19, 12 April 2011


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


Game Presentation Schedule

Team Name Date and Time
Team Zombie Tuesday April 12 8:20AM
Tuesday April 12 8:50AM
Team Guardian Tuesday April 12 9:20AM
Team GG Thursday April 14 8:20AM
Team HSD Thursday April 14 8:50AM
Team Slap Your Grandma Thursday April 14 9:20AM


Presentation Schedule

Team Name Date and Time
Team Guardian - Hasan, JP Tuesday March 22 9:00AM
Team Zombie - Damian, Qing Thursday March 24 8:00AM
Hic Sunt Dracones - David Thursday March 24 9:15AM
Team GG - Brad Tuesday March 29 8:00AM
Team GG - Randl Tuesday March 29 8:30AM
Slap Your Grandma - Dan, Andrei, Sasha Tuesday March 29 9:00AM
Hic Sunt Dracones - Daniel, Jon, Kaitlyn Thursday March 31 8:00AM


Appointment Schedules

Initial Proposal

Team Name Date and Time
Zombie Tuesday January 18 10:00AM
Team GG Tuesday January 18 10:15AM
Team Guardian Tuesday January 18 10:30AM
Andrew Condinho Tuesday January 18 10:45AM
Tuesday January 18 11:00AM
Tuesday January 18 11:15AM
Slap Your Grandma Tuesday January 18 1:30PM

Proposal Acceptance

Team Name Date and Time
Team GG Tuesday February 1 10:00AM
Zombie Tuesday February 1 10:15AM
Andrei Kopytov Tuesday February 1 10:30AM
Tuesday February 1 10:45AM
Tuesday February 1 11:00AM
Tuesday February 1 11:15AM
Slap Your Grandma Tuesday February 1 1:30PM

Project Review

Team Name Date and Time
Team GG Tuesday February 22 10:00AM
Zombie Tuesday February 22 10:15AM
Tuesday February 22 10:30AM
Tuesday February 22 10:45AM
Tuesday February 22 11:00AM
Tuesday February 22 11:15AM
Slap Your Grandma Tuesday February 22 1:30PM


Due Dates

Proposed game and team members selected January 18
Proposal completed and members' roles selected February 1
Phase 2 draft and review February 22
Phase 2 completed - Presentation March 22
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 to those features that are needed to implement your game design. Identifying the features and the required refinements will demand some research on your part. In the case of DPS905 students, the research should be deep and the description should identify the theory behind the required refinements.

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. A draft of your proposal should be on the wiki before your meeting with the instructor and you should update your proposal after consultation with your instructor.

In developing your game, you may start with the code that you used in the previous course or you may start with the base code for this course. The base code for this course is an update version of the base code for the previous course. In any event, each member should use the updated base code to develop the feature that they have selected and present the results of their work using the updated base code. In other words, the update base code with the new features installed will serve as the source for other teams' access.

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

The source code for each team member's 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 details

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

  • to identify the features that your final game will include
  • to identify the features that each member of your team will incorporate
  • to identify the features that your team is expecting to incorporate from the work of other teams.

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

Phase 2

The second phase releases a version of the updated base code that includes the new features that your team members have incorporated.

This phase includes a presentation that shows

  • how your new features work within
    • the updated base code
    • your own game
  • how to incorporate the new features in external code

Your team will have one hour to make its presentation and each team member will have fifteen minutes to describe the feature that they implemented themselves

Phase 3

The third phase presents your completed game with your team's new features and two new features that members of other teams developed.

Your presentation includes

  • a demonstration of how the game plays
  • an explanation of the innovative aspects that your team members have implemented
  • an evaluation of the features that your team incorporated, including criticisms and suggested enhancements

Each team has 30 minutes to showcase its game.


Features that you could add to the Updated Base Code

The base code serves as the common thread for sharing feature development amongst all members of the class. Our objective is to add as many of the features that students wish to see implemented in their own games as possible. We review this list at the start of the semester and you are welcome to expand detail or to add other features.

  • visibility determination
    • view frustum
    • bounding volume construction
      • principal component analysis
        covariance matrix
      • bounding box construction
      • bounding sphere construction
      • bounding ellipsoid construction
    • bounding volume tests
      bounding sphere test
      bounding ellipsoid test
      bounding cylinder test
      bounding box test
    • spatial partitioning
      • octrees
      • BSP trees
    • portal systems
      portal clipping
      reduced view frustums
  • collision detection
    • plane collisions
      sphere and plane
      box and plane
      spatial partitioning
    • general sphere collisions
    • oriented bounding boxes
    • sliding
    • collisions with physics
      • moving spheres
      • moving boxes
  • 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
  • third-person camera techniques
  • 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
  • optimize coordinators for design unit creation and destruction
    • introduce standard template library
    • 0(1) removal of objects
    • provide external access to all objects in the scene coordinator
  • enable Streaming SIMD Extension 2 in Configuration Properties with optimized math calculations
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=GAM670/DPS905_Project_Requirements_20111&oldid=62379"