Main
Lectures
Assignments
Groups
Requirements
Showcase

About:
  Schedule
  Staff
  Roster
  FAQ

Resources:
  XNA Help
  Demos
  Lab Accounts
  CVS

Links:
  CL³
  CSUGLab
  CMS
  GDIAC

Communications Lab 4
The Milestone Document and Functional Spec

Due: Tuesday, February 19 at 11:59pm

The focus of today's lab is to develop the milestone document and functional specs for your game. These were first detailed in Lecture 5. You will submit the results from this communication lab to CVS by Tuesday. We will read your drafts and talk to you about them at the next communication lab, which is simply a follow-up on this one. You will then submit your final collection of milestones and function spec as part of Assignment 3 on Saturday, February 23.

The Milestone Document

Typically the timeline for developing software, games or otherwise, is divided into what are called 'milestones'. Milestones are important markers that signify the completion of crucial tasks in the development cycle. The development team creates a Milestone Document, detailing the specifics of each milestone. A typical set of milestones for game development include:

• Project Kickoff
• Design and Functional Specification Draft
• First Production Milestone, Second Production Milestone, etc.
• Code Complete
• Content Complete
• Zero Bugs
• Release

Each milestone should be described specifically in the timeline, and typically has the following:

• A title
• A short description
• A due date
• Production dates
• A test for acceptance
• A risk assessment
• Deliverables
• Contributors

For this class, the Milestone Document will not be quite as detailed as one in the industry. Given the iterative nature of game development, we’d like the Milestone Document to be somewhat broad and flexible. It will list broad tasks for the entire semester, and conform to the schedule below:

Additionally, every two weeks starting with the completion of the Gameplay Prototype for Thursday, February 28, we would like each group to provide us with a very detailed two-week breakdown of tasks leading to the next boldface milestone. By very detailed; we mean down to an allocation of all hours of each team member. Recall that each group member is committed to 10 hrs/wk of work on the project. This means that for each two-week period, t he project leader has 20 hours of work to allocate to each member of the team. Your two-week breakdowns must account of all of those hours. We will talk more about these breakdowns when Walker returns from GDC.

Clarification: The two-week breakdowns are not due with this assignment. We will talk about them next week.

The Functional Specification

In addition to the milestone document, we want you to start working on your functional specification for your game. Your game code will change a lot, so this will not be final, even when you turn it in for Assignment 3 on February 23. We expect you to keep revising this over the course of the semester. We just want you to start working on this early so that we can give you some feedback while it will do some good.

The function specification is an outline of the system architecture of your game. It should be designed so that your programmers can split up and work independently without having to look over everyone else's shoulders to see what they are doing. It also allows programmers to write code without having to wait for others to finish.

There are many ways to write up a formal specification, but right now we are going to stick with an "informal" formal specification to get you started. You can revise this and make it more formal over the course of the semester for your final submission in May. The format will be pretty much the one that the programmers were assigned for Lab 4. That is, your specification should contain the following:

Identify major subsystems in the game

For this part of the class, a subsystem is just a significant part of the game that a single programmer could work on in isolation, provided that the programmer has an API of the other subsystems. For example, AI is a subsystem that can be programmed distinct from the rest of the code. While it needs to know the methods of the enemy units, it does not need access to their source code.

It is important to identify subsystems because they are the ways in which you can divide up work among your group members. Therefore, you should identify a minimum of three different subsystems.

Identify how the subsystems interact with one another

Provide a high-level (bullet points are fine) overview of what type of information needs to be passed between the subsystems. For example, if you had networking, the UI subsystem needs to send the IP address to the network subsystem in order for it to connect with the server.

Design interfaces for the subsystems

Design interfaces (methods and properties) for these communication points only. Do not make interfaces for anything inside a subsystem that is not exposed. For example, if you had a networking layer, you do not need to identify every single class used in networking. Likewise, in the simulation subsystem (e.g part of the code that occurs in the Update() method that is specific to the game, but which may or may not include physics or other general purpose libraries), you do not need to outline the classes for every enemy or terrain obstacle. You should only expose the functionality needed to communicate between the systems.

As a general rule, each subsystem should have only one interface. However, if any subsystem needs to pass complex information to another system (e.g. AI subsystem passes a movement path to the simulation/update subsystem), you may need to present a class for that. However, you do not need to construct a class for anything that you can commonly find in an object oriented programming language (e.g. Points and Rectangles).

You do not need to include the programming analysis that was in programming Lab 4. However, you should keep this exercise in mind as you revise your specification over the course of the semester.

Today's Lab

Today's communication lab will consist of the following:

• Jerry will talk about the milestone document
• Walker will talk about the functional spec
• Each group will begin work on the Milestone Document
• During this time, Jerry and Walker will talk to each group about their Concept Document drafts

Right now, in generating your Milestone draft, we do not want you to work on organizing by deadlines. Instead, begin by just generating a list of all the tasks you know you are going to have to do to complete this project, including the sub-tasks necessary to complete the larger tasks. After you have gotten the list of tasks and sub-tasks to a place where everyone is satisfied that, as of now, the list is exhaustive, then you can begin to match those tasks with the calendar.

When you reach this point, an important consideration will be structure. How will you organize this information so that the information you are trying to convey (what is going to get done, by whom, when, etc.._ is transparent to your audience. As with the Game Concept Document - and just about any other document you will write for a professional audience - the Milestone Document needs to be skimmable. That is, a very quick glance at even the first page should reveal to the reader how information is organized in the document. Do not make your reader work anymore than they already have to.

One final note: you can think of the level of detail that a Milestone Document should include as the level of detail that the team leader would be able to understand. Anything more detailed than that belongs only in the two-week breakdowns.

Submission

For this communication lab, you have two files to submit. The first file is the your Milestone Document, which should be titled Milestones. The second file should be an outline of your functional specification and should be titled FunctionalSpec. These files may either be a text file (txt), a Microsoft Word file (doc), or a PDF file (pdf).

Due Tuesday February 19, 2008 at 11:59pm