Please note that I don't update this web site anymore. You can visit my new personal blog at

The Timeless Way Of Game Design

Thursday, June 16, 2005

A recent post by Gianfranco Berardi on creating a common language for game design lists some great resources. Among those resources are some attempts to create a pattern language for game design. I think pattern languages have done good things for the software world and I benefit from them regularly. Yet, I think a caution is in order.

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

Almost anyone who is familiar with software patterns knows that they were first introduced to our field of expertise by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in their seminal book Design Patterns. A lot of people also know that they got their inspiration from Christopher Alexander's The Timeless Way Of Building. In the process of converting Alexander's vision on architecture (the kind that creates buildings) to software development, however, I think we've lost something important.

A pattern language only helps communication if people know the language, but who is going to learn hundreds of patterns just to know what the other is talking about? Usually, discussion about game design goes pretty well without such a set of common patterns. The communication problem isn't big enough to warrant the effort of learning the patterns. The original Design Patterns contained only 23 patterns and of those only a handful are known well enough that you can always refer to them without explanation.

The main goal of design patterns isn't to facilitate communication, that's just a beneficial side-effect. The main goal is to provide proven solutions to common problems and to share those solutions. Before I founded Yellow Wood Studios, I was building web applications together with a partner. We both often used Martin Fowler's book Patterns Of Enterprise Application Architecture, yet I cannot remember a single time either of us referred to a pattern in the book assuming that the other one knew what we were talking about. Fowler's patterns got into our code, but not into our discussions.

Christopher Alexander's work isn't about pattern languages, though, it's about the timeless way of building.

It is a process which brings order out of nothing but ourselves; it cannot be attained, but it will happen of its own accord, if we will only let it.
The Timeless Way Of Building by Christopher Alexander

Where the software world applies individual patterns to individual problems, Christopher Alexander names only one problem and presents the entire pattern language as a tool for solving that one problem: finding and applying the timeless way of building. The pattern language isn't important of itself, the patterns within it even less so; it's all about creating structures and towns in such a way that they feel naturally alive.

Indeed this ageless character has nothing, in the end, to do with languages. The language, and the processes which stem from it, merely release the fundamental order which is native to us. They do not teach us, they only remind us of what we know already, and of what we shall discover time and time again, when we give up our ideas and opinions, and do exactly what emerges from ourselves.

How can we design games in a timeless way? Where do we find the quality without a name in our games? A pattern language for game design would be useful for sure, but I think we could do with a little less Gamma, et al. and with a little more Christopher Alexander.

Back to blog index


GBGames says:

When I was messing around with QBasic and hacking out an RPG (before I had Internet access and found out that everyone was trying to do this), I wrote code to handle loading and moving about the main map, towns, caves, and castles. I also had code in the towns to handle conversations in a dynamic way. It was fairly sophisticated, too, if messy. You could buy, sell, set flags, etc. At the time, I was just writing really cool code. After I was online, I found out that what I wrote was commonly called "scripting". "They do not teach us, they only remind us of what we know already..." This is precisely why language is important. We can't use, share, and discuss things if we can't label them. Being able to name something and have it defined helps us to remember what it is. A singleton, for instance, is fairly common, and people were writing them for years before someone codified it and named it. Now it is fairly trivial to implement since most of the thinking is already done for us. Instead of hacking out a possible solution to a barely understood problem, a programmer can be consciously aware about the drawbacks and benefits of using specific patterns. The how's and the why's are clearly defined, and clarity is important when trying to accomplish something. I think having such patterns available for game design and development would be incredibly useful. If I want a certain result, say a evocation of specific player feeling, rather than put some situations and controls together and hope for the best, I could probably look for an appropriate pattern to implement. Not to say that I think game development can be as simple as "drop in patterns, mix, bake". But codified game development doesn't need to be rigid. Patterns and language are incredibly powerful and are great for managing ideas and practices. They are named, and they define a solution to a defined set of problems. On the other hand, I haven't read Alexander's book, so I am not sure what the difference is between what he says and what the GoF say other than architecture vs code. Perhaps I am missing something that you know and understand, and so I am not capable of truly discussing it with you. When I learn what "Quality without a name" and "build in a timeless way" actually means, I'll probably be in a better position to talk about its merits to game design. But that's again why language is important. B-)

Thursday, June 16, 2005 5:46 PM

Joost Ronkes Agerbeek says:

It's absolutely true that there is merit in a GoF-like pattern language for game design and you describe those merits very well. However, my point is that Alexander's book has more to offer than the idea of pattern languages and I think we, as game designers, should take note of that. You will have to read The Timeless Way Of Building in order to find out what I'm talking about, though.

Friday, June 17, 2005 1:38 PM

Tell me what you think

Since I'm not updating this site anymore, I disabled comments. You can visit me at my new site: