A Story Continues

Continuing from my last post, I had finally got it into my head that I could make a browser based game. The question became how should I do it?

 I approached my friend R about my idea, and she was very encouraging. Her main piece of advice was to write up as much as I could about what I wanted to build before I started coding. This is pretty sensible advice for any software project, not just games. So I set about writing up as much as I could. This process was happening in parallel with me evaluating various tools that I could use, but I'll talk about tool evaluation later.

I started using Google Docs since I chould easily share the documents with R and get her feedback. As the documents got longer and more detailed it became clear that one lond document was becoming difficult to manage. It might have been OK, if I could get linking inside the document to work, but that broke everytime I regenerated the table of contents, and you need to regenerate the TOC each time you add a new section. It was also difficult to look at two places of the document at the same time and finding the part you want in a very long document was irritating as well. The other problem I was facing was that a design document isn't very liniar. One long document is fine when you are trying to tell a story but when you are trying to describe lots and lots of inconnected ideas that liniar form becomes a burden. 

It occured to me that I was trying to use google docs like a Wiki. For me a game design is a lot of small ideas connected to eachoter in different ways. My game features a mini-economy where base resources must be produced, and converted into other resources before use. This meant that I needed to descibe the resources, the methods of production, the methods of transportation, trade. It became much simpler for me to make a series of short documents littered with links to the related documents. Wiki's are perfect for that task. I did some shopping around because I hoped to find a website that would host a wiki that was free for personal use but could also be made private. I didn't find anything that met my needs and budget. Cost was a limiting factor. Since I am just starting and doing this in my spare time I didn't want to lay out a monthly fee out of pocket. In the end I put MediaWiki (the software that runs Wikipedia) on my home computer. That let me make a private wiki that cost me nothing to operate. It did take up some of my time learning to install and configure MediaWiki but that was a one time cost. 

 It didn't take to long to chop up the Google Docs into Wiki pages. It became a lot easier to maintain the document in Wiki format since it is designed for editing small chunks at a time. I could also make links to non-existent pages and later use the Wanted Pages tool to find pieces of the document that I indtended to write later. 

I was able to open up access to the Wiki to R and some select friends, and using the Talk: feature of the wiki we were able to dicuss various parts of the design on pages that were parallel to the concepts we were discussing. Recent changes was also useful for identifiying what parts others were making comments on. 

The main downside is that it seems hard for someone else to absorb the whole design since there is no way to read it beging to end like a traditional document. Someone who browses through the design might miss out on reading parts of it. On the otherhand they don't have to read the whole thing if they don't want to. They can just read the relavant parts and skip over things that they don't need to know right now. 

I don't see switching away from the wiki for this project, and I suspect that I will probably use a wiki for future projects as well. I think that for collaborative design, it offers some very compelling features. I think in a small office environment, most of the issues involved in running it on your own desktop computer go away so if I manage to grow what I am doing into a company, I'll probably stick with the Wiki then too. 

To be continued again.