·
Pitch: Due October 27, 2006, in class
The concept paper is the most rudimentary step in game development, and the idea here is to lay out in written form a simple picture of what you intend to be doing. Your project should be a significant step up in complexity from your Arcade Game, and as the size of your group increases, my expectations will increase accordingly. The grading of the final project will be focused more heavily on the non-triviality of your game, and the overall experience (game play) than was the Arcade Game, so you will probably want your design to take this into account.
We will be looking for a brief discussion on all of the points listed below (1-2 pages).
· What's the basic idea of the game?
· What will the game look and feel be like?
· What is the primary play mode and what will it be like to play the game.
· Game Genre: Strategy, First Person, ...
· Single Player vs. Multi-player
· Will it be a single development effort vs. group – we highly recommend three person teams.
· What is special about the game -- what are its most interesting features?
· If it is a group project, a preliminary statement of how the work will be divided among the members.
· What assets might you need from the art groups.
Every group must hand in a concept paper on November 2 – no late days. All members of a group must contribute to a concept paper. The hope is that following pitch day, groups will form and the concept paper will be written.
In the gaming industry design documents are used to lay out all the details of the game so that the project can be developed in a group environment with minimal problems. In essence the design document should allow a reader with no prior knowledge about your game to completely envision how the final product will look, feel, and work. It is quite typical for industry design documents to fill over a hundred pages. For this assignment, however, each group needs to hand in a single 15-25 page paper.
Your group's concept paper should serve as a foundation for this assignment, but the design document should be verbose enough so that only implementation details are left unspecified. Among the topics you should include (if appropriate) are:
o The title
o A complete version of the game's story line.
o Any background information that will be provided to the user.
o The game's selling points (e.g. graphics, action, plot)
o A description of the primary modes of game play
o For each mode:
· A list of the resources, how the are created and consumed.
· The user interface.
· Whether there is positive or negative feedback.
· How you will balance the game play
o A transition diagram for how the player moves between the primary game modes.
o A description of all entities that will be in the game and how they behave.
o An inventory of artwork and how it will be used
o A description of all interactions in the game (e.g. which objects collide, which cause damage to the player)
o A statement of how the work will be divided among the group members.
o A schedule for your future work on the project.
Your full, compilable/buildable source code must be turned in. Otherwise, there are no other technical documents required.
Your software (source and executable) with a list of features that run and those that don’t. It should at least turn over even it there are implemented features that don’t work yet. Include a schedule for completing the project.
Your software combined with your (revised) design document and your self-evaluation of the project (the form for this will be handed out later). Included in the alpha release must be a good screen shot of the game that we can use for advertising the game showcase.
The criteria for the final game will be similar to that of the Arcade Game, but with higher expectations. The grade will also be a combination of the overall project (a team grade) and an individual grade for your contribution to the team.