CIS 4002: Advanced Projects in Game Design

Assignment 5
Game Script/Wiki

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:

Wikidot
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.
Assembla
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.

Wiki Content

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 information.

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 span producer.
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 this reason.
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 online.
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.

Submission

Due Saturday, September 25th at 11:59 pm through CMS.

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