With Game in a Day round the corner, I thought I'd do a quick post on Game Documentation. If you plan your game beforehand, and have necessary reference material while you are coding it, then you are more likely to succeed. It is very noticeable for me that when I do some form of documentation beforehand, I'm more efficient in my use of time; something that is important when entering a schedule. Of course, its not just Game in a Day contests that run on a schedule, only a few lucky Developers have a free hand on when a game can be completed. Some are lucky enough to have a good working relationship with their publishers to extend deadlines, but deadlines still exist for the majority of us in some form or another.

For those of us on BYOND, its more of a casual thing. But that doesn't mean planning isn't essential! Preparation before hand helps keep you in line and ensures you always have something to work on in order to finish development. I myself am guilty many a time of not producing documentation before hand, and struggle sometimes when I look at it in a year or twos time and try to figure out what's going on. So for this post, I'm going to go through ideas for 3 forms of documentation:

1) Pre-planning
2) Coding Reference
3) Development Analysis

Now for Game in a day, your game probably won't be complicated enough to require references during coding, and you can do your post-development Analysis later after people have tried the game. For now, lets start at the logical step of pre-planning.

1) Pre-planning

Now when you start to make a game, you need to decide first off what your game is going to be, and what you intend the player to do. That's obvious right? Now think about all the different sections of the game you have to make in order to form that game. How long do you think its going to take to complete it? Set a loose time frame you think it will take. Write or type this down, and no changing it! So lets take an example. Last year I made a game called "SET UP!", here is a possible quick pre-planning documentation I might have set last year:

---

Game Name: Set Up
Game Style: Minotaur puzzle clone
Theme: Game in a day "Noir" theme

Player Goal in game: The player starts in the middle of a maze. They have the goal of reaching an exit on one of the sides. In the way is a "Minotaur" styled enemy which attempts to capture the player. Along the way there are additional goals such as collecting items and leading another game character out of the maze.

Storyline: The player is an investigator in trouble with the Mafia. The Mafia is attempting to kill and frame the player. The player has to exit the building without being killed, and as additional goals find evidence to bring the Mafia to justice, and find players love interest and get her to safety.

Alternative features: The game will feature a randomised maze upon completion of the default map. This will continue until the player is defeated, in which it will return to the default map. The game will get harder with each successful completion with less walls to trap the Minotaur character. The player will also receive a specialised endgame story relating to completed goals.

Items used in game:

Player: The player character can move up down left and right.
Minotaur (Mafia): The enemy character can move 1 square towards the player character, and an additional move towards the player if the direction is different to the first move.
Follower (Lucy Lu): The following character will remain stationary until the player character has stepped next to it. It will then follow the player behind.
Pick ups (Evidence): Items that can be picked up. One is set in place, and another spawns randomly when the first is picked up.

Timeframe for development:

I intend to develop the game within the 24 hour "Game in a day" Limit. In order to do that, I will split its development between different stages. First I will produce the icons to be used in the game for roughly one hour. After that, I will code in the necessary system to interact with the characters and develop the random map generation. I assume this will take more than an hour, possibly 2 or 3 to fully complete. Along with this, I intend to test it at interval stages to ensure the game is solid and working as intended. Finally, I will work on the style and script the game will include, and documentation to help the player understand how to play the game. I assume this will take an hour to perfect. Altogether, I intend to finish the game and package it for release and submission within a 5-6 hour time frame, allowing for any problems along the way.

---

And there we go. It would take me awhile to get this down of course, but now I have a written plan on what I intend to do. If I then edit this document, then I won't be doing myself any favours. This is the plan at the time, and its quite well possible that it'll change before I have finished. Knowing what problems you'll come across and allocating time for it is something you get with experience, don't worry too much about the specifics of the time frame! If you are making a Game in a Day, then still worry about what you have planned will be completed within the time limit! If you look at it after writing it and think "Am I really going to be able to do this is the time I have set for it?" and the answer is no, then look at it again, what have you set out that makes the development time more complicated. One of the things that I might have decided if I were to cut it down, would be to create some basic pre-laid mazes for players to go through, which would either be randomly selected or done one after another in a list. This might have saved me time with creating random generated mazes that required testing to ensure a fair and staged generation.

2) Coding Reference

For Game in a Day, that is all the documentation you want to be worrying about with during the contest. If however, your planning on a longer game, you might wish to work on reference material while you are developing. I use referencing via Excel a heck of a lot for Wargames and Wargames 2. This is because the games are so big, and have staged and branched development and include lots of lists for pre-made data. Both games are "building games" to a degree, with research as a hub to open new items for the player to use. Units form the basis for combat between players, and include variables to differentiate between them. This can look very ugly or un-readable in a tree or list formation, that is where using reference material comes in. Rather than searching for minutes to find one or two values, I can easily see the entire games variables and values in one go. This speeds up development time when you are editing or creating new features in your games, and an absolute must in larger games which sees a lot of development and alteration.

3) Development Analysis

Finally, lets look at Development Analysis. Now when you have your completed game, released, played by the masses, its time you reviewed what you've done. Yes, you have probably done this in school sometimes and you might not have enjoyed it! But its a simple and easy method of realistic looking at what you've done and comparing it to what you set out to do. Now for my example above, I wrote this today, not at the time! But it did include my rough notes that were in my head (and is better off written down) when I was developing it. Now it is a year old, people have played on it and Iain has done a write up here, I can review myself:

http://files.byondhome.com/IainPeregrine/giad_2008/ results.html

Here is what Iain had to say "SET UP is, like most GiaD games, single player. The player controls Sharp Simon, an investigator who has crossed the mob. But why sit around and listen to my rehash of the story, when Acebloke has provided a lively interactive version? Helpfile present, no bugs or oddities found, and the interface is easy to use. The first map is always the same, and gameplay is deterministic, so once you've won it once you know how to win it every time. However, a random map is generated after the first win, so there is always a new challenge (though I suspect some of those randomly generated levels may be unwinable). My only complaints are with the rebooting at the end of the game, and that the entry was somewhat limited in scope."

Well with those comments I was pretty chuffed! Iain did however point out one or two issues, and this is where I do my own analysis. Comparing my game to what I thought out before coding it, I think that I followed it well. The games goals were implemented as I made it out to be, and my original vision I believe did get represented in the final product; everything looked the way I wanted it to feel, everything ran the way I wanted to feel. Now I don't remember how long I took to develop it in the end, but I did have some problems, namely with the random generator. There were moments where complete boxes would appear, or areas would be formed in which the player would be trapped and unable to leave. I attempted to deal with this situation, but as I found out afterwards by people who played it, Iains observation that an un-winnable situation could occur is true, and I was unable to completely account for being stuck in a box at generation, and made no effort during development to account for placement of the Mafia characters route towards the player to allow for a definite winnable situation every time.

There are also two other issues, that of the repetativeness of the first stage. At the time I thought it wasn't too bad, but when I play it myself, I get slightly irritated by attempting to do the default stage everytime I lose, or even everytime I start up the game. The most obvious change that I can think of, if the game were ever to be updated would be to change this, and allow for some form of easy access to a randomly generated map, as well as improving the generation process itself. The rebooting is an annoying feature which isn't required, the game easily accounts for rewriting a map on completion, and could easily be made to soft reset. Finally, the scope is limited in the sense that while there are two additional objectives to just finding the exit, this might have been improved without the necessity to complete the default stage every time one loses. Arguably more goals, or a larger map could be created in order to offer more complexity, but the game itself is set and has few possibilities for expansion without greatly increasing the games size and content.

Overall however, I think I did pretty well. So to finish off I'll recap my analysis in a form of a document similar to the one I laid out before:

---

Post Development Review of: Set Up
Game Style: Minotaur puzzle clone
Theme: Game in a day "Noir" theme

Comparison to plan laid out: Overall the game development went well. I believe that the vision and plan I laid out before was evident in the final product. I was happy with the state the game was in for the time produced to make it. It was not too hard and I enjoyed myself making it.

Time scale: My time scale plan was roughly on time. Problems in the Random generation was the largest issue and took the longest time. Game was completed within the 24 hour deadline as per the "Game in a Day" rules. Spent rest of time playing it!

What went wrong: Issues with the Random generation still persists, along with other generation issues such as whether a generated map has a chance of success or not. Game was perhaps too easy or too simple, with little to grow on further through the game other than harder random generated maps. Rebooting at lose would result in having to do the default game again, making it repetitive and distracting from playing the more fun generated maps.

What I would change: Ensure a way of skipping the default map, or produce more. Concepts for expansion could include larger maps, better map generation that changes with difficulty, adding new forms of map terrain such as flip doors that acts as re-positional walls common to puzzle games of similar nature and new forms or alterations of goals. A intro and/or endgame graphic could complete the look and feel of the game, polishing it off.

What I would do next time: Next time I do a project such as the "Game in a Day", I would look towards continuing a form of random generated game play to ensure replayability, and also look into a more complicated and staged version to enhance a players "progression" from an easy start to a harder endgame. A "finish" result, which the player can take away with would also be a bonus.

---

And there we have it, typically unintentionally long for me. The first line said quick post but that obviously wasn't the case! Using documentation can bring real change to the way you work. If you feel like you can never finish a project with what you intended, this is the best course of action to take. I'm interested in your thoughts of this post, whether you like it or not and whether or not you've taken any of this on to use yourself. If people find this useful, then I'm open to doing other posts on development in future!