US 12C — Computer Games as Art, Culture, and Technology

Game Project Time Line

This quarter the game development project will cover almost the entire quarter.

1. April 9 Lab: Form teams of four (three is acceptable) and brainstrom ideas. Teams can implement games in either Java+Ucigame or Second Life. Team members do not need to be enrolled in the same lab, but they must be able to attend a lab hour together.
2. April 16 Lab: Email to Eric a short statement, comprising:
   • Names of team members
   • Team name
   • Lab period team is attending
   • Sentence or two description of game
   • Technology platform
3. April 23 Lab: Prepare a draft of the game design document.
   • The draft should be 5 to 10 pages long, and should include parts of each of the design document's four sections, especially including the Schedule and Personnel section.
   • Upload the draft to the EEE Dropbox Design Doc Draft (only one team member should upload per team). No paper copy will be turned in.
   • Your draft can be a Word document (.doc, not .docx), a PDF file, or a zip of a folder containing an HTML file and all images needed.
   • The draft is due at 6:00 pm on Wednesday, April 23.
   • The draft will count 20% of the Design Document score.
4. April 29 Lecture: Pitch your game design to the class
   • Each team will give a three minute "pitch" of their game idea to the class, during the 11:00-12:20 lecture period.
   • It is not required or expected for a team to have PowerPoints or overheads. However, they are permitted: up to three overheads (in PowerPoint, Word, or PDF format) can be uploaded to the EEE Dropbox Pitch Overheads before 10:00 am on 4/29. (Teams will not be permitted to bring laptops up to the podium or to run code.)
   • The pitch will count 10% of the Design Document score.
5. May 7 Lab: Show TA your almost complete game design document. It will probably be 20 to 30 pages long.
6. May 8 Lecture: Turn in complete game design document. It will be 20 to 30 pages long and will include a well-written overview, game specs, technical specs and schedule & personnel. This assignment will be graded according to the following rubric: http://www.conceptlab.com/uci/us12c/us12c-designdoc-final-rubric1.html.
   • Your final file can be a Word document (.doc, not .docx), a PDF file, or a zip of a folder containing an HTML file and all images needed.
   • Upload the final design document to the EEE Dropbox "Design Doc Final" (only one team member should upload per team). This electronic version is required.
   • Each team will also send a copy of the completed Design Document to TurnItIn.com. Log in using the name you used for previous quarters (your @uci.edu email address). Upload your paper for the class US12 Games, assignment Paper 5 - Design Doc. Your paper must be submitted before 11:05 a.m. on Thursday, May 8.
   • Print out a hardcopy (one per team) of your final design document and turn that in at the start of lecture on May 8.
   • Also print out the email containing the feedback and grade for your design document draft. You will need to submit this as hardcopy with your final design document. Staple together both versions of the design document, with the final version on top and the draft (with feedback email) underneath.
   • The EEE submission and hardcopy are due at 11:00 am on Thursday, May 8th. Documents submitted after 11:00 am will be considered late.
   • The final version of the design document will count 80% of the Design Document score.
7. May 14 Lab: Demo prototype of game
8. May 21 Lab: Demo prototype of game
9. May 28 Lab: Demo prototype of game
10. June 3 and June 5 lectures: Demo almost-completed games for class
11. June 4 Lab: Demo almost-completed games and work on presentations
12. Sunday evening, June 8: Completed game due

How To Turn In Your Work

Playable Prototype

You will create a working, although probably incomplete, version of your game, which you will then demo in lecture on June 3 or June 5 for five to ten minutes. Bring a laptop with your game ready to run on it.

This prototype and demonstration will not be graded, but not providing one or participating in the demonstration will hurt your grade.

Final Version

In addition to the game, you will write a brief report, one or two pages long. The report should be in a file called Report.doc (not .docx) or Report.pdf. It should include the following:

• The name of the game.
• The name of the team members.
• A brief tutorial on how to play the game. This is important — make sure we know how to access all aspects of your game. Particular instructions are needed for starting the game, for accessing mult-player aspects (if applicable), and for accessing all paths through the game (e.g. win and lose conditions).
• Description of any known bugs or missing art.
• Any special instructions that are needed to play the game, including technology you used.
• A detailed listing of any art, sound, music, or code that was copied from or is substantially based on other sources or was made by anyone not on the team. Name the sources.
• A breakdown of which parts of the game were created by which team members.

To turn in your team's final game:

1. Complete the game by midnight at the end of Sunday, June 8.
2. Put your Report, all game code (source and executable) and assets into a zip (not rar) file. If you are using Ucigame, include the ucigame.jar file you have been using; if you are not using Ucigame, use extra care to provide an executable game we can run.
3. Upload your zip file to the US 12C EEE dropbox called Game Project (any one team member can do this).

Design Document Structure

Each team will write a Game Design Document, following the structure described below.

The Design Document is a critical factor in determining the success of your efforts to create a computer game. With commercial games, it is often created over a period of many months, and is a "living" document, updated as the game is developed. For this course, your Design Document will probably describe a larger and more complex game than you will be able to implement by finals week. That's perfectly OK, but you should indicate clearly what parts you plan to accomplish.

Your Design Document should have four major components: the Overview, the Game Specification, the Technical Specification, and the Schedule. In addition, an essential component of your document is careful proofreading. Look for misspelled wrods, awkward grammer, needless repetitions, unstated assumptions, vague assertions, needless repetitions, and omissions important features. Every member of the team should have carefully read the document before it is considered final.

Overview (Executive Summary)

The goal of this section is to give the reader, in no more than two pages, a clear understanding of what your game is all about. This means not only an overview of the background story, but also a description of game play, important rules, art, and technical platform.

Game Specification

The Game Spec section serves as a "rule book" for the game. It describes the types of interactions the player can have with the game. It should be fairly easy for a writer to turn the Game Specs into a manual that could be included with the game. The nature of the Game Specs is somewhat dependent on the type of game being developed. I'll give examples and descriptions for four genres of games, top-down shooters (TDS), driving sims (DS), first-person shooters (FPS), and role-playing games (RPG).

• Rules and mechanics. This is often an extensive section, and may need to be divided into subsections. For any type of game, explain how the game ends or is finished. TDS: How ships/tanks/units move, the types of weapons they have, how damage or hit points are calculated. DS: The physics of the world, how the car / vehicle is controlled, race rules, information about brakes, tracks, surfaces, parts, etc. FPS: How damage or hit points are calculated, how the protagonist moves, types of weapons and their capabilities. RPG: Rules for creating characters, their stats, skills, special powers. How inventory, buying/selling works.
• Artwork and user interface. For all types of games, show screen shots, sketches, prototypes, samples. Describe the overall "look and feel" of the game. FPS: Often tries to "shoot" for the sense of having no user interface. But there always is one, right?
• Gameplay and balance. What can the player(s) do? See? Hear? How does he or she interact with the game world? How are weapons or other tools acquired, used, lost? What are the puzzles that have to be solved? Does left click mean something different than right click? What kind of physics model, if any, is being used? Describe how the game is designed so that whatever options the user chooses, the game is still interesting and playable.
• Music and sound. Even the simplest music and most rudimentary sound effects add immensely to the pleasure and "immersiveness" of playing a game. It may be hard to describe the music and sound you plan to have, but you should describe where the music and sound will come from.
• Background story. DS: Often sketchy or non-existent. TDS, FPS: Typically fairly simple. RPG: Usually quite complex, with many side-stories. Should integrate closely with the artwork, the characters, and the levels.
• Characters. This section might be integrated with examples and sketches of artwork. Discuss both the characters the player can play, if any, and the NPCs the player will encounter. TDS: Spaceships, asteroids. DS: Other racers, pace car, police. FPS: Usually a variety of monsters, aliens, and bad guys. RPG: Every NPC should be described, his/her/its background, skills, powers, possessions. useful knowledge. For important characters, this should be a "character bible."
• Levels. These are the phases of the games. They have a variety of names: TDS: Levels. DS: Locations, tracks. FPS: Missions. RPG: Quests. Describe the story, goals, interactions, etc. of several levels. If your levels have puzzles or secrets, describe those. For some games, a storyboard is an extremely useful way of communicating the action in a level. Briefly describe several levels, if appropriate, and give a large amount of detail about a single one you plan to implement this quarter.
• Scripts. There are several kinds of scripts: lines for voice actors to speak, text for text-based interfaces, and programming scripts for controlling the action and behavior of some objects or characters. (If you have all three of these, you may want to break them out into separate sections.) TDS: Typically little. DS: Some, e.g. bridge and traffic light controls. Before and after race sequences. FPS: Interactions with monsters, guards, minor non-adversarial characters. RPG: Extensive. Ideally, the exact text of dialogs will be presented in the Design Document.
• Cut scenes. If you plan to have non-interactive sections of the game, at the beginning, the middle, or the end, describe these in detail.
• Artificial Intelligence. How do NPC's, enemies, and followers behave?

Technical Specs

In "real life" the Technical Specs are hundreds of pages long. They take all the rules from the Game Specs and make them specific, unambiguous, and implementable. When writing the Technical Specs, think through implications, exceptions, exact limits. For instance, if the the Game Specs say "The player will be able to make the car move faster by pressing the up arrow key," the Technical Specs should elaborate: "Each press of the up arrow key causes the car's speed to be multiplied by 1.01, up to a maximum of 500 and down to a minimum of -100 (reverse)." For this example, you'd need to explain also exactly how the user shifts between forward and reverse.

The Technical Specs should also discuss or include:

• Programming languages, including compiler and emulator, if necessary.
• Libraries that will be used.
• Any code or engines to be used. If you plan to use a game engine, describe it and explain what its interface (to the rest of the system) is.
• Target hardware and Operating System.
• Data Structures, or better, interfaces of ADTs and classes. A list of all (C++/Java) classes and their interfaces is appropriate in this section.
• Exact algorithms. If an NPC "knows" how to walk back and forth between to positions, avoiding a large rock in between, discuss the AI algorithm (or script) that will be used.
• Back-up and version control plans. We don't want to lose 40 hours of work in tenth week, do we?

Schedule and Personnel

It's important that each member of the team have a clear set of responsibilities, and a clear time-line for various tasks.

You should include the following:

• Deliverables as of the end of seventh week, Friday, May 16.
• Deliverables as of the middle of tenth week, Wednesday, June 4.
• Deliverables as of the end, period, Sunday, June 8 (was Wednesday, June 11).

As far as possible, state the deliverables by team member. Structure the sequence of your deliverables so that core art and gameplay comes first, and extra features, levels, characters, puzzles, AI, etc., are scheduled later. You should plan on having a playable mini-version of your game by May 23.

For each team member, state the role(s) he or she will play in the project, and what contributions he or she will make to the final game. Also include a statement from each team member about what he or she needs to learn in the remainder of the course.