Lessons of game design

If you’re searching UML, Design Patterns or suchlike, you’re wrong here – this time I’ll try to cover some principles of puzzle design to general software from the point of the user:

Scott Kim, a well known Puzzle creator has written a great paper on Puzzle design called “The Puzzlemaker’s Survival Kit” (sorry, no link available).

He goes through principles, case studies and the design process of puzzle and game design. Some of these guides can (IMHO) applied to software design in general.

How? I think, puzzles in games and features in general software aren’t that different. Here the first principle of puzzle design written by Scott Kim:

He also writes:

bq.A puzzle is a problem that is fun to solve!
What makes puzzles different from problems is that they are fun to solve. A good puzzle is guaranteed to have a solution that is neither too easy nor too hard to find.

If we map puzzle to real world problem I want/have to solve we should design our software to allow this as easy as possible and powerful as needed. So, our software should enable the user to solve a problem with joy!

I wouldn’t limit “fun” to games – I think we could build software that every problem is fun to solve because the software helps us and doesn’t step in the way. It depends only on our imagination and our willing to invest a lot of time to build software that is fun to use. (Although game puzzles may be more fun to solve, but not as rewarding).

…neither too easy nor too hard… is another interesting phrase. Doesn’t that map directly to the power of any feature included into a piece of software? Conclusion: don’t treat your users as complete dumbs, design your features right – not too complex, but with enough power to perform a specific kind of task.

Scott Kim explains how to construct puzzles in games, let’s see if we can map these to software in general.

Think small.

Interesting, huh? Think small as advice! Isn’t that the same as Apples Think different – just take the iPod Shuffle or the Mac Mini? A lot of people try to get more and more features into a piece of software (Think big), but these systems tend to be overly complex and unusable (at least for me).

See how far you can get with the smallest number of features.

This is one of the most thrilling and adorable advices I’ve ever read! Don’t build battalions of special cases. Extract, refine and rewrite until you’ve got a truly elegant solution for the problems you want to solve. The web, meaning HTTP, follows exactly this advice. They striped out every special case and build a solid foundation for thousands of web applications by not disturbing or limiting the possibilities. See Axioms of Web architecture for more.

Many, if not all, of the brightest minds of history gave this advice – starting from Da Vinci Simplicity is the ultimate sophistication., Hoare The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay., Dijkstra Simplicity and elegance are unpopular because thy require hard work and discipline to achieve and education to be appreciated. or Simplicity is prerequisite for reliability.… .

Start with a tutorial.

Definitively a game design advice, or not? Eclipse, GMail and many more start with a tutorial – maybe we should think of including a quick and simple introduction into any given piece of software?

Make puzzles easy to author.

Construction puzzles need to be as easy and fun to author as they are
to solve.

This is a very underestimated advice in general software. Why do we think that we are the great masterminds and know every single case our users want to do with the software? There is no possible way for doing that with any given real world problem!

Open up your software and let users create features the need through an API, scripting capabilities or whatever.
Design these interfaces so, that no existing code has to be read to use the API, Interface or Scripting capabilities. Make it easy to build new functionality and don’t even try to lock in the user!

Even Microsoft allows users to build their own little programs within their office suite.

Another big advantage: You might use that feature yourself to build new features and customizations… .


Do it! Any feature you find “hard to use” is for the user simply unusable – your user doesn’t invest month or years learning (like you building) the software!

User interfaces which you – as the creator – find “super easy” are usually “just right” for your users.

[I’ve written this in a rush, so please excuse some weird phrases and formulations.]

The imagination of nature is far, far greater than the imagination of man.
— Richard Feynman