CMSC 23800/53800
Course Project
Spring 2014

Overview

The course project is to design and implement a game. You will work in groups of around five students and will be expected to make frequent, but informal, presentations about your project in class. This page will include links to various documentation, code, and game assets that you may find helpful for your projects.

The default project is to implement a racing game and we will provide some support for that version of the project. Your group may also choose to design and implement a different type of game, subject to the following requirements:

1. your game should be both playable by a single player or multiplayer (i.e., at least two players)
2. to satisfy requirement #1, your game should have AI players (it might have other AI agents too)
3. it should include some form of simulation

Milestones

It is important that you work steadily on your project throughout the term. The help you gage your progress, here is a list of project milestones with target dates. There will also be regular group presentations, which are listed below.

Milestone 0: group formation (April 8)

By Tuesday of the second week, you should have formed your groups. You should also start thinking about breaking up the project into parts and assigning responsibilities.

Milestone 1: design document (April 15)

An important part of any large software project is a document that lays out the architecture of the application. For the first project milestone, each group should produce a design document that covers (at least) the following issues:

• project name and members
• an overview of the gameplay; i.e., controls, graphics, scoring, etc.
• major architectural components of the project (e.g., graphics engine, AI agents, networking, ...).
• for each of the architectural components, describe its responsibilities and sketch its interface.
• describe the interactions between components.
• assign roles to the group members.
• coding style: naming conventions, source code organization, documentation conventions, etc.

You should view this document as a living document that will be refined as the term progresses.

Milestone 2: revised design document (April 24)

By Thursday of 4th week, you should have a revised and fairly complete design document. You should also have started to prototype the core components, such as the physics engine, of your game. Getting a basic engine up and running early will provide a useful tool for developing the other parts of the project.

Presentations

Over the course of the term, there will be four to five group presentations (including final demos).

Presentation 1: Game design (Thursday; April 17)

Groups will describe their game and their architecture.

Presentation 2: Status report (Tuesday; April 29)

Groups will describe the current status of their project; any issues that they have encountered; and give preliminary gameplay demos.

Presentation 3: Status report (Thursday; May 8)

Groups will describe the current status of their project; any issues that they have encountered; and give preliminary gameplay demos.

Presentation 4: Status report (Thursday; May 22)

Groups will describe the current status of their project; any issues that they have encountered; and give preliminary gameplay demos.

Final Presentation (Thursday; June 5)

Groups will give final demos of their games.

Specifications

For groups that choose the default project, we will provide some assets to get you started.

• The track-file format (Version 2.0).

And here are some tracks that you can use in your game.

• oval.trk — A simple, hand-generated, oval track.

• barbell.trk — A medium sized track generated using a script.

• wide-barbell.trk — A wider version of barbell.trk (20 units vs. 12) with four lanes (instead of 3).