Due: Saturday, September 25th at 11:59 pm
The Game Script (or Game Bible) is an internal document to be used a reference
for the entire development team. It records all design decisions, is kept up-to-date,
and should be able to answer any non-technical question about the game.
As a living reference document that has authorship shared by several people,
the Game Script is especially well-suited to the Wiki format. For this
class, every group will create a Wiki for their Game Script, and keep it
updated throughout the semester.
Choosing a Wiki Service
You are free to use any wiki service you like. Here are some options that have
been used in previous semesters:
This used to be the defacto wiki site for this course. It supports
all the standard features, has forum support (which you may want to
use as a bug list or task list internally), allows file uploads, and good
administrative controls. Unfortunately, it is moving to a paid model,
and free services are much more restrictive than they used to be.
This is another excellent service. It is one-stop shopping in that it
provides your Wiki, SVN for version control, and a bug tracker to
coordinate development. I use this service for many of my own projects.
It is also primarily a paid service, though the free service works
as long as your disk-space requirements are not too large.
- Google Sites
Google Sites is not as full-featured as many other Wiki services.
However, it does benefit from being free and easy to use. Use it
only if you cannot find anything else better. On the other hand,
it is an excellent choice for your website
- Your Own Wiki Server
If you feel confident enough, you can always set up your own wiki
server. The group Pandora's Sphere,
which contained two of your current TAs, did this last year. If
you choose this route, the requirement is that the Wiki server must
remain up and running until graduation weekend.
We are always looking for alternate wiki services. If you find anything
better than the options listed above, please let us know.
You wiki is not static content; the content should change and grow
over the course of the semester. Right now, you should just set
up the "skeleton" of your wiki. That means, you should have a
front page with a basic navigation menu, connecting to content
pages (which may or may not exist yet). As a general rule, the
accepted form is to have a sidebar menu with hierarchical
options (e.g. a link to a top-level page, and links to subpages
that fill in more detail). See the examples below for more
How you structure your wiki is up to you. However, there are several
highlevel features that we recommend that you have on your wiki.
- Overview and Design Philosophy
This is essentially your concept document rehashed. However,
you are allowed to go into more detail, as this is an internal
document for your group and not a sales document for a short-attention
- Game Mechanics
This is where you describe your verbs, resources, and challenges --
the types of things that we focused on in the development of the
nondigitial prototype. If you want to put the nondigital prototype
online, that is a plus. However, this part of the wiki should
describe the mechanics of the computer game, not the prototype.
- Architecture Specification
When you do complete your architecture specification (not due yet)
you should put in on the wiki for all your programmers to see.
- Game Art
Eventually, your artist may feel like he/she is working in isolation.
The wiki is how the artist communicates with the programmers. Post
concept and character art on the wiki, and do it early. Do not worry
if the art in the game changes; the wiki is internal only for just
- Game Audio
As with the artist, the musician needs to keep the group aware of the
game audio. Make sure that you have a wiki that can post sound
files so that you can post music on the wiki. You may want to separate
game music from sound effects within your wiki.
- User Interface
User interface is directly related to art. This is where you should
post screen mockups of your various game modes. The exercise in the
communication lab is intended to get you started on this, so that you have something to put in your wiki.
- Level Editor
If you do make a level editor (highly recommended) then you need to
train people how to use it. This is another great use for a wiki;
create a short tutorial on how to use the level editor and put it
- Game Levels
Once your software is done, it will be time to create content, and
content means game levels. Making random levels is a bad idea;
you should have a natural difficulty progression as the player moves
through the game. Use your wiki to outline the primary challenges
in each level.
These are what we consider to be the most important part of the wiki.
But as we discussed in class, there are other things that you may wish
to add to the wiki as well. For example, you may want to add a background
story or game-related fiction.
Examples from Previous Semesters
It is not necessary for you to open up your wiki to the public. However,
if you do, then you will probably appear in this assignment in future
semesters! Here are some example wikis from previous semesters. Not all
of the are completed; you should just use them as a general guide for
how you construct your wiki skeleton.
Of these examples, ChronoBot
has one of the most extensive wikis, and is a good model for how to do
your own. Flight of the Munchkins
has very little content, but is an excellent skeleton.
Due Saturday, September 25th at 11:59 pm
The primary goal of this assignment is to choose a wiki format and start
to set it up. If your wiki is not publically readable, then you need to
make sure that the instructor has access. This may involve giving the staff
a user name and password. If you use any of the recommended sites
above (Wikidot, Assembla, Google Sites), the instructor has an account
and just needs to be invited to your wiki.
You should submit a text file wiki.txt
This file should contain the URL of your wiki, as well as information that the
staff needs to know in order to administer your wiki (e.g. user name and password).
You do not need to submit anything else.
It is important that you continue to keep your game wiki up to date after this
assignment is due. While we will give you feedback on your wiki for this
assignment, we will not give you an actual grade on it just yet. That is
because we cannot grade this document until the semester is done. We will
be paying attention to how much work went into the wiki over the semester
when we assign you a grade in the final document portfolio