Design Document 1.0
After losing the thread I started writing a complete design document for AT. It used two days of work but now it seems to merit version number 1.0. It has 24 pages, everything handwritten. Designing on the computer does not work for me. I need the possibility of fast sketching and the no-way-to-delete style of a biro. It is much more natural this way and keeps the design juices flowing.
Core Features
First I had to decide which core features to include. There were a lot of candidates so it used some time ordering them by Must, Should and Can. After this I reasoned about their dependencies. Features which serve as base for other features became more important. More independent features went down on the priority list. This is useful for scaling the project focus. For instance if I run out of time there's always a possibility to kick out a low priority feature.
Then I subdivided each feature into its parts. For instance the very basic feature "fly through vertical 2D mission and complete task" was divided into what can be in a mission (background, enemies, obstacles, etc.) and which tasks there can be (kill end boss, rescue people, destroy targets, etc.).
Screens
I figured out the needed screens according to the planned features and linked them together as they will be accessible in the game:
After fleshing out the screens each of them became defined by its parts and how they will be laid out on the screen. With code reuse in mind I filtered out shared parts like the back button or the common background image. That's a common OOD practise, nothing new here to tell you. Important was the imagination of the player navigating through the screens using the buttons and switches. The first draft won't be the final version except for experienced GUI designers. So keep change in mind while designing.
Content and Procedural Generation
Some of the content may be procedurally generated. I used the same method as for prioritizing the core features:
- list all the parts of the game which are candidates for procedural generation
- order them by complexity, need and predefinition (already known algorithm)
It's always a consideration of algorithm development/testing versus handcrafted content. Rule of thumb:
Generate heavily used content procedurally which is not primary used for defining the fun in the game.
For example making conversations purely procedural is tough work. The generated chat may not meet your (and more important: the gamers) expectations.
Schedule
Finally I wanted to know when all these details come to live in a sellable game to pay the first bills. So I defined what has to be done for the alpha version, beta version and release. Alpha contains just test graphics (like shown here) and only the must-have core features are available. Beta has all should-have features, graphics have to be nominal (speak: does not blame the artist). Optional features, graphics polishing, balancing and play-testing are the last steps for making the game releasable.
These commonly known phases where divided into their basic tasks which have to be completed. The time for each task was estimated and written down in a rough schedule:
Shock!!! The release date is sometime in fall 2010! My finances don't allow such a long development time - starvation seems inevitable. Time to scale the whole thing down a bit. Finally there is additional work to do like advertising, research, blogging or maintaining this website which is not included in this schedule. And everybody who knows deadlines knows that most of them aren't met.
First Truth
Yesterday I've finished the shop screen alpha version according to the design document's specifications. The schedule states 1 day of work, finally I needed 3 days. Scaling the schedule according to this would delay the AT release to 2012. A bad year to release something when you believe in Roland Emmerich's movie :)
Cheers!
Thomas