Here's the first version of the Evolution: Fitness design document.
The design paradigm for the game is that it has very few rules that creates a complexity that is interesting. A sub-set of the design paradigm is that the rules of Moving, Mutating affords for direct interaction with the gamestate (:moving a piece directly) while the rule of Breeding affect the conditions for automatic interaction where the game will act, the player controls the interaction indirectly by setting up conditions for it. It could be interesting to create a game where the player only could indirectly act with the game, - where he only could affect the conditions for interaction and the game would do the actual interaction.
I had a hard time figuring out what kind of format I should document it, but eventually decided to do it as a game-manual without flavour text or gameplay-examples. I've written it and read it through once (maybe twice) and corrected it. It's very raw. Remember: the purpose of this exercise isn't to present you with a finished product, but to document the process.
(It raised the issue of iterations: when is an iteration done? when is each phase of the iteration (design -> test -> evaluation) done? Right now all phases takes place in my head; I decribe a design, visualize a playthrough and evaluate the playthrough, so the only way I can define iterations as discreet entities is by being meta-reflective about my mental activity).
(Note to self: parts, whole, level of zoom).
Some things are readily apparent with the document. This is not a satisfying way to describe the game, - it's very abstract and it takes a trained designer to actually understand what is happening. I'm thinking about writing some playthrough-examples to example the game and will also add graphics as I move along (a picture seriously is worth a thousand words).
Feel free to download the design document, comment on it, test it and elaborate on it.
If you want to send me a commented version, send it to email@example.com.
All feedback is appreciated.