This came out from email discussions with
about the need to stop and think about design. I thought it be nice to post it here, since it gives a nice history of how I worked on Monkey.
I wrote a first draft of the game (version 1), which was based upon D6s. Went to playtest it with my mate Ginger Matt and immeadilty he exposed the central rule mechanic as the nonsense it was right at the start of the game – so we didn’t even start it was so broken. (but damn it looked sexy on paper).
Re wrote it (version 2),which saw dice replaced with cards, and despite more abortive playtesting,which turned into more discussions about the concepts and mechanics, found there was still problems. People agreed there was a germ of a good game but just didn’t get how it all comes together.
Then and only then just when I was about to jack it in did I take a step back and think about DESIGN. Immediately I stopped working on the writing and stripped back the game to the bare essentials. After a bit of thought and discussions the yin-yang card mechanic came about, which I think really is the ‘sexy’ part of the game rules that fits in with the Chinese setting to a tee. This eventually lead to version 3. This actually got my playtesters interested, were as before I only got silence (since the game as as presented was a confusing mismash of ideas. From this I wrote version 3.6 which was an attempt to get the game in its entirity, if only quick notes and headings for some chapters. Overall theres been been 3 versions of the game with about 4-6 rewrites of each.
About six months ago I started working on my Final draft which is the what I’ve been getting everyone excited about ,because it finally is a game , Not just an essay about an potential game.
I’ve learnt the hard way that having a clear design of your game is vital. Not only does it speed up the writing process, because you are less tempted to just launch into a rambling train of thought that then requires multiple revisions to sort out, by having chapters and concepts before you to work in a modular manner, but it also helps during playtest. My early ‘playtests’ broke down quickly because not only did I not have vital concepts and rules properly explained in the playtest rules, but I didn’t even have a clear idea of whats going on. My last playtest was a roaring success not only because the rules are in better shape, but the design and what the rules intend to do is clearer in my head.
You’ld think as a software developer all this would be obvious 😉