Below is the design document for Woebot Chapter 1 a short game we’re developing with the intention of walking you, dear reader, through the entire design and implementation process.

A quick diatribe:

This document covers an agile process (read: not-waterfall) focused on making your software design as robust and as easy to maintain as possible *after* you’ve already got a great game design.

If you don’t happen to be writing articles about it, authoring one of these should only take maybe a week to do (and save at least three times that in refactoring/maintenance down the road). Most of the OOAD tutorials I’ve read don’t involve writing video games, so I thought this might be a fun way to learn about it.

The methodology we cover here is meant augment the development process for an individual developer, or a very small tightly knit team. Don’t make the people you work with have long drawn out meetings about this kind of stuff! That’s just cruel, and it’s a big waste of time since the decisions any developer makes during the design process can be very, very subjective.

Ok, on to the document!

Project:

Woebot Chapter 1 – Ascent into the ridiculous world of the pretty much extinct humans

Synopsis:

Woebot is a short game about a small slightly depressed robot who has decided that the cure to his depression is to leave the underground home of his peers to live with humans on the surface. Unfortunately the road to the surface is full of peril, and the robots haven’t seen a human in over a thousand years!

Features:

For details on the method we used to define our features and how we’ll use them see: Step 1: In which we figure out what our software is going to do

• (Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
• (Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
• (Woebot-F003): The game shall provide a choice of weapons to the player at the start of the game, which can be improved as the player collects power ups.
• (Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
• (Woebot-F005): The game shall contain narrative elements explaining the back story for the relationship between robot and human. (e.g. The robot civilization decided to sunder themselves from the humans over a thousand of years ago, and why that happened).
• (Woebot-F006): The game shall provide a simple narrative ending leaving the door open for sequels while providing clear completion to the goals of the game.

Use Case Diagram:

For details on the method we used to define our use case diagram and how we’ll use it see:
Step 2: In which we figure out how our software is going to be used
Step 3: In which we discover that our feature list sucks

Systems to develop:

For details on the method we used to define our systems and how we’ll use them see: Step 4: In which we transform big software problems into smaller more manageable ones

Risk Analysis:

For details on the method we used to perform risk analysis see:

For details on the method we used to define our use case diagram and how we’ll use it see: Step 5: In which we build a tower from things we should be worried about.

Use Cases:

Domain Analysis / Class Diagrams:

Appendix A- Level Design:

Appendix B- Baddies:

Appendix C- Concept Art / Sketches:

Most of this stuff happens on paper – so there’s a fair bit I still need to scan in.