Teams

Information

Useful Links

Tentative Schedule

Sprint 1: Documents and Prototype: During this sprint, you will complete your GDD and create a prototype for your game. Your prototype can be either electronic (GameMaker, XNA, Unity, etc) or paper (boardgame, table top game) as long as it properly demonstractes your core game mechanic. You will also, as you finalize sections of the GDD, use dotProject to input the tasks (testable requirements from your GDD).

Sprint 2: Finalize TDD & Implementation: During this sprint, you will complete the dotProject scheduling of your entire project, insuring that each testable requirement from the TDD has been input into the dotProject file as a task/milestone. SVN access will not be granted to your team until the GDD and the dotProject tasks have been finalized.

NOTE: this does not mean that you cannot change things - it means you must have your GDD requirements fully documented in dotProject. You can, if needed, change the GDD - however, please remember, anything you change in the GDD must also be changed to match in the dotProject tasks.

Once you have finalized your documentation, your team will be granted SVN access and you may begin implementing your game. Remember, you cannot use any of your prototype code.

Sprint 3: Implementation and Alpha Release: During this sprint, you will continue the implementation of your game, with the set goal of having an alpha ready playtest game at the end of the sprint. You must have at least one level complete, 3 animated characters with all capabilities fully coded, basic AI, and a basic HUD working for the playtest. At the end of this sprint, we will be playtesting your games as a class so you can incorporate your playtesting feedback into your implementation cycles.

Sprint 4: Implementation: This is the last complete dev cycle for your game. At this time, you must finish coding your game, including incorporating any changes suggested by playtesting that you can get to work in the time allotted. Remember, you have a documentation aspect to this cycle that must be completed - you must aggregate your results from playtesting and determine what you are going to change. This documentation must be complete prior by the end of March.

Sprint 5: Implementation and Beta Release: During this sprint, you will complete the dev on your game. At the end of the sprint, you will have a viable beta release. You must have completed the level requirements (2 levels, one indoor, one outdoor), the player, the AI, HUD, and the menu system. You must also have the cutscene in your game and functioning from both a trigger in the game (it can just be the start of the game) and from the menu system. Super extra points for building a system that will allow me, after the first viewing of a cutscene to be able to skip it from then on (probably do not want to use a browser cache for that, however). At the end of the sprint, we will do presentations in class on your games along with a brief demo session.

Sprint 6: Cleanup and Polish: You are now in a code and feature freeze, meaning that you cannot add new code/features to your game. You should, during this sprint, take the time to clean up your repository, code, webspace, unity folders, etc. You should also finish any outstanding code that you have left to write (it should just be tweaks here and there, no major code at all). You also need to close out any tasks in dotProject, being sure to correctly label tasks you did not complete. Clean up models, textures, audio, etc to make your game as polished as you possibly can, without breaking the game.