Game Design the Wrong Way

A little meta-design here.

I’ve described (hopefully!) a number of tools that can be used to analyze design, and to help determine why games are fun, or not.

There’s two main ways you can use these tools.  You can use them to predict your gameplay, or you can use them to analyze your gameplay.  I call this predictive vs. reflective design.  These correspond to open loop systems vs. closed loop systems, as described in Managing the Design Factory.

I highly recommend you use reflective design, and avoid doing too much predictive design.

Many factors that impact gameplay are not apparent up-front.  Trying to quantify all of those factors before you start work is a difficult task at best.  Additionally, games are complex, chaotic systems that are notoriously hard to “get right” the first time.

This doesn’t mean that you shouldn’t do any up-front design.  At a high level, it’s worth trying to make sure that your design is vaguely right - make sure that everything has at least some level of a counter or balance point.

But, instead of spending a year writing documents, write a game.  Even if it doesn’t have every feature you think you’ll want, get it running and playable.  See if your basic assumptions are correct.  Make it work, make it fun.  Add things to make it more fun (or take them away!).  And, through this process, gather data.  Tons of data.  Log everything, store it in a database, and analyze the data.

And when you’ve got a real idea of how your game is being played, you can use the tools I’m describing to determine why it’s being played that way, and how to make it better.