|
Due: Friday, May 10, 2013 (before 11:59pm)
|
Project Description
Now that you've completed the "required" game platform and proof of concept game in the first 3 projects, you are now free to leverage what you've done to build a game of your own choosing. Each team will propose a final game project to be done in the remainder of the semester. 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. Any game you build should demonstrate the full range of capabilities of the platform you have developed, as well as one major additional capability of your choosing (see below).
Be careful not to be too ambitious, you should have a better feel for what is reasonable to do now than you did at the beginning of the semester, but there's always a danger of biting off too much. Make sure your proposal has a fail-safe capability built in. That is, make sure there is a base game that isn't risky to implement that you start with, and augment from there, so you'll be sure to have something working. It is much, much more important to have a simpler game finished than a too ambitious game that doesn't work.
Because it is important that members of each team share a common vision for their game, and since I'm removing a lot of constraints on what it should be, we will entertain reorganizing of teams for this final project so long as everybody on all teams affected approves. You will need to work with Randy during the first week of the project period to get such reorganizations approved.
Requirements
- Each team must turn in a written proposal for their final game by
Tuesday, April 9 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 "levels" 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, who is on the team, 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.
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 9. 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. In addition, for this final project, you will need to make a 30-60 second long video trailer to show off your game and illustrate how it is played. You may use any tools you like to help in the production of this video.
The final submission must be made by Friday, May 10 at 11:59pm. All teams will demo their games during the 3 hours allocated for a final exam. Our class has the final exam on Saturday May 11 from 7-10pm in Pai 3.14. We plan to have game industry visitors play your games and give you feedback on them as they have done in the past.
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/01/13 by Don Fussell fussell@cs.utexas.edu