Assigned: Tuesday, April 10, 2012
Game Project 2:
Your own game
Due: Thursday, May 10, 2012 (before 11:59pm)
Project DescriptionNow that you've completed the "required" game in the first 3 projects, you've developed a technology platform that you can leverage to build a game of your own choosing, and you've gotten a feel for how long it takes to get various game-related tasks done. Accordingly, we're going to let each team pick their own game for the final project. There is not particular constraint on what type of game it can be, but we urge you to pick something that builds on what you've done in some way to allow you to finish something substantial. Starting from scratch, as you know doubt have learned, is a pretty expensive task, and one that is unlikely to lead to an interesting finished product in the time you have. That said, improvements to your game engine structure to support new capabilities going forward may make good sense, so feel free to change and improve the system you've already built while getting as much leverage as you can from your previous work.
Your game project will be broken up into a series of milestones given as separate assignments, these will be due weekly as before, starting with the proposal on Tuesday April 17. Each subsequent Tuesday until project end, you will need to turn in an update report with demo, as before. These reports will include the same elements as in your previous projects. At the end of the project, you'll turn in a working game artifact on Linux, again as before, along with a final report, readme, and, separately, evaluations of each team member.
- Each team must turn in a written proposal for their final game by Tuesday, April 17 at 11:59pm. Only one copy of this proposal should be turned in. This must include a description of your game as a game, including what the "level"s will be, what the game's objectives will be (what is the player trying to do to win?), how the controls and interaction will look, whether it is single or multiplayer or both, what new capabilities and/or architectural changes to your current code will be needed, and how the work is divided among your team members.
We will need to accept your proposal before you can assume that your proposed game is your project. However, we anticipate that any non-accepted proposals will be acceptable with some limited modifications to make the workload tractable or to make the extensions sufficiently challenging, so you can safely start basic work on your game before you hear from us.
- Your game should incorporate one or more significant extensions to the capabilities you have after completing the first project. Examples include the addition of one or more animated characters, the addition of AI capabilities at the overall game level or at lower tactical levels such as control of automated characters, new graphics special effects that are not trivially implementable in Ogre3d out of the box, more advanced physics simulation than was done in project 1, or significantly enhanced gameplay, controls, camera, etc.
As part of your writeup, be sure to highlight what you consider to be your significant extensions to current capabilities. These need not be from the list above, but they are subject to approval.
- You should strive to make sure that this one is really a game, that is playable and winnable without being excessively difficult due to crude gameplay elements or excessively easy due to poor design. As with previous projects, this requirement is intended to ensure you spend at least some of your time thinking about gameplay and implementing and tuning it rather than devoting all of your efforts to making a bag of special effects that is in no interesting sense a game. As before, it does not mean that we'll be grading you on the quality of your game design beyond these basic requirements.
As for the other assignments, your primary grading criterion is to turn in a working game on time. As you progress in the project, you may need to scale up or down your original plans. Prepare a strategy for that in your proposal, as we've recommended before. And remember that a good game is always better than a technology demo as a final project artifact, so if you have to sacrifice some glitz for playability, do it.
Last modified: 04/11/12 by Don Fussell firstname.lastname@example.org