Open main menu

CDOT Wiki β

Changes

GAM670/DPS905 Project Requirements 20111

3,611 bytes added, 07:19, 12 April 2011
no edit summary
{{GAM670/DPS905 Index | 20111}}
<!--= Game Presentation Schedule =
{| border="1"
|-
|-
|-
|TeamZombie|Tuesday January 18 April 12 8:00AM20AM
|-
|Slap Your Grandma|Tuesday December 7 April 12 8:15AM50AM
|-
|Team ZombieGuardian|Tuesday December 7 8April 12 9:30AM20AM
|-
|Team GG
|Tuesday December 7 Thursday April 14 8:20AM|-|Team HSD|Thursday April 14 8:45AM50AM|-|Team Slap Your Grandma|Thursday April 14 9:20AM|-|}<br /> = Presentation Schedule ={| border="1"
|-
|Cerebral ThoughtTeam Name|Tuesday December 7 9:00AMDate and Time
|-
|Team Mutalisk
|Tuesday December 7 9:15AM
|-
|Copy CatTeam Guardian - Hasan, JP|Thursday December Tuesday March 22 9 8:00AM
|-
|Team Zombie - Damian, Qing|Thursday December March 24 8:00AM|-|Hic Sunt Dracones - David|Thursday March 24 9 8:15AM
|-
|Double TapTeam GG - Brad|Thursday December 9 Tuesday March 29 8:30AM00AM
|-
| Hic Sunt DraconesTeam GG - Randl|Thursday December 9 Tuesday March 29 8:45AM30AM
|-
|SheetBrix RoboticsSlap Your Grandma - Dan, Andrei, Sasha|Thursday December 9 Tuesday March 29 9:00AM
|-
|The 10th FloorHic Sunt Dracones - Daniel, Jon, Kaitlyn|Thursday December 9 9March 31 8:15AM00AM
|-
|}
<br />--> = Appointment Schedules =Initial Proposal
= Appointment Schedule =
{| border="1"
|-
|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: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
|-
|}
|-
|Proposal completed and members' roles selected
|January 31February 1
|-
|Phase 1 completed2 draft and review
|February 22
|-
|Phase 2 completed - Presentation
|March 22
|-
|Approval meeting with instructor
|March 29
|-
|Phase 3 completed - Presentation
= 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 appealof your game. The user experiences 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 or areas of their choosingspecialization. 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 intends wishes to implementin its final game. Your description should identify the basic aspects of the these features as well as the refinements to those features that are needed to produce a comprehensive implementationimplement your game design. Your proposal should be documented Identifying the features and the required refinements will demand some research on your part. In the team project page case of DPS905 students, the research should be deep and the course wiki under '''Proposal'''. Your proposal description should identify the parts of theory behind the framework that you expect to modify in your implementationrequired refinements.
Each Your proposal should be documented on the team member project page of the course wiki under '''Proposal'''. Your proposal should have their own successfully compiled version identify the parts of the starting sample framework that you expect to modify extensively in their own workspace in the branch sub-directory your implementation. A draft of their team's repository.Branch submission path: svn://zenit.senecac.your proposal should be onthe wiki before your meeting with the instructor and you should update your proposal after consultation with your instructor.ca/dps901_103rep??/branches/SenecaID/15C
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 starting sample 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' 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 detaildetails
The purpose of this first phase of the project is twofold:
* to define identify the features that your final game in both scope and detailwill include* to enable identify the features that each member of your instructor team will incorporate* to identify some of the details features that you will need your team is expecting to handle in implementing incorporate from the selected featureswork 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 must arrange == Phase 2 == The second phase releases a time and date to meet with your instructor to discuss version of the proposal and to commit the different responsibilities of updated base code that includes the new features that your team membershave incorporated.
== Phase 2 ==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
The second phase releases a version of the framework that includes the new features that your Your team has incorporated. This phase includes a will have one hour to make its presentation and each team member will have fifteen minutes to describe the feature that shows how your new features work within your own game.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 incorporateddeveloped.  Your presentation includes * a demonstration of how the game plays along with * 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 no more than 20 30 minutes to showcase its game.
<br />
<br />
<br />
= Some Suggested Upgrades Features that you could add to the Framework 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 * 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 fallback position for the design of your game. There are numerous opportunities to refactor different parts depending upon what your game requires plane**: box and what your personal interests areplane**: 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. Decisions 0* open audio* Direct3D10** porting the framework to focus on certain parts should reflect DirectX10* Direct3D11** porting the areas with which you wish framework 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.DirectX11* Direct2D* advanced force feedback* input techniques** XInput** Raw input** picking * optimize coordinators for design unit creation and destructionEach team will ** introduce its own upgrades standard template library** 0(1) removal of objects** provide external access to all objects in 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.scene coordinator* enable Streaming SIMD Extension 2 in Configuration Properties with optimized math calculations