Prepare for unforeseen consequences
(Half Life: Episode Two)

Game Project

Group Assignments

While I strongly recommend team projects, the requirement for this course is the development of a project and that can be a team or individual effort. While there are considerations on both sides, the key reasons for developing the project as a team are both for development and design. The ability to spread the work is clearly important, but the ability to work together to grow and develop ideas is equally important.

The requirement that the game is a serious game means that there is agoal beyond entertainment. The most typical goals are education, training, health, exercise, or as a work of art. The education and training is normally a fairly traditional topic that one would normally attend a class or lecture to learn or could be taught in a apprenticeship or by trial and error. I will consider options that are more light-hearted. This last of these, art, is clearly still entertainment, but it opens the opportunity to for a game whose primary motivation is to create or invoke a specific emotion. While all games are intended to do that to some degree, the serious game does it to a degree that others do not. (See Past Games for games that have been developed in the past.)

Steps for building your game:

Deliverables

While the format of the deliverables is at the team's discretion, all of them need to be electronic and accessible form the web site.

  1. Working Game: You are to prepare the game for me to play. I do not want to compile it. You may assume that I have Python and Java installed and a Steam account or Half-Life 2 installed. If there are specific release requirements or other prerequisites required beyond that, please be explicit. You are to give me complete installation requirements and instructions. Of course, giving me a simple executable is best.
  2. Publicity Writeup: This is basically the concept document. It should give a 2-3 sentence description of your game, describe the purpose of the game, the genre, and the target audience. You should include the most salient features and game highlights. It should be in an attractive format and should be no more than a single page.
  3. Game Specification: This should be a complete description of your game as you envision it -- NOT as you implemented it. What would the game look like if you had all the time that you wanted? Be sure to identify the things that didn't get implemented. Included should be the back story, a description of the characters and game world, and a full description of each level and transisition. Explain what success and failure in the game means and what the user is learning as they play. (e.g., completing level 3 means that user has learned the nomenclature of algebra). For another version of a game design document, see Chris Taylor's.
  4. Development Documentation: There are lots of definitions of development and design specifications. What I am interested in is the documentation needed by someone who may take over this game and want to fix it or enahnce it. Identify the tools and systems needed. Describe enough of the structure, key modules and data structures so that the new developers can find their way around the system. Of particular interest are how they would add more levels, change the difficulty, capture scores, or change the graphics. If they want to add more content, how would they do it? This document will be significantly different for each project, but imagine that you are taking the course next year and want to enhance this game. What would you want to know?

Past Games

Fall 2006

This year all games were built from scratch. I think that all were written in Java.

Fall 2007

This year the entire class worked on Kidney Kids, a game to help adolescents with chronic kidney disease learn the skills needed for caring for themselves.

Spring 2009

This year all games were built from some basis.