Great Dane Games

Great Dane Games

Great Dane Games - all things gamerelated

This weblog is the digital playground for Anders Højsted. I'm a philosopher, indie gamedeveloper, writer & all-round renaissance man.

Evolution: Fitness 0.1

Game DesignPosted by Anders Højsted Fri, November 06, 2009 10:23
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

All feedback is appreciated.


  • Comments(2)

Fill in only if you are not real

The following XHTML tags are allowed: <b>, <br/>, <em>, <i>, <strong>, <u>. CSS styles and Javascript are not permitted.
Posted by Anders Højsted Fri, November 06, 2009 12:47

Thanks for the feedback :)

I very much like the sprawl idea, - it makes the game a lot more dynamic, but makes it a lot harder to predict more then 1-2 moves into the future, so it looses the strategic element of Chess and upgrades the tactic element. I'll have to look into a balance or an "on/off" option for this feature.

The ally-option is a bit harder to implement. The simplest solution would be to make it possible for different species to co-exist in the same field if the players was allied, - this will make possible for you to migrate across other players space. Will look into it.

If it possible to rate the different rules on complexity & length of playsession, I might make a beginners, intermediate & expert rules option in the rules, so the players can pick the rule set that fits their skill and purpose of playing the best. Right now I'll just integrate the ideas in the next design document and credit you off course.

Somewhere along I'll make a playtest with the different potential versions of the game to se which functions the best.


Posted by Dave Mariner Fri, November 06, 2009 11:43

Hi Anders,

Firstly I have to deeply disagree with part of your blog posting. The bit where you say that it takes a trained designer to understand what's happening - I personally think that you get the aspects of the gameplay across quite nicely with this :-).

A question - is the play area constrained, or can it sprawl? Are there any ways that you can incorporate more geographical features into the setup phase, so the players can choose / are forced to make archipelagos etc?

An additional layer that I think would really add to the game would be if you had the ability to ally yourself with other players within the game - have some kind of cross-breeding mechanics (or "inter species erotica, in "Clerks" terms ;-) ). My assumption would be that, especially with an expanding habitat rather a fixed board (you extend out the habitat within the play phase rather than in the setup phase), it would lead to a far more tactical and varied approach to the gameplay.

With regards to iterations, that's simple. Iterations are timeboxed. You set yourself a deadline - most ppl I know run 2 week iterations, but YMMV. You then breakdown your objectives in terms of tasks, and define (once you've broken them down) what you consider the "done" criteria for a task. If you're really process-oriented (difficult if you're working solo, but still a good idea), then you estimate how long you think each task will take to do, and only commit to those tasks you believe you can get done by your *fixed* deadline.

At the end of the iteration, only those tasks that have met your "done" are "done", and you can then calculate how much stuff you can get done in your iteration cycle.

Then rinse, and repeat.

All in all - I think this is a great start - best of luck with it!