Game Design Technology: The Holy Grail of Fun4 min read

Game Design Technology: The Holy Grail of Fun

The best game design possible.

A design technology for game design.

Aka the holy grail of game design.

Aka the ultimate formula to make the best game design possible.

Aka where to get excellent game ideas from and how to translate them into a plan.

Aka how to find motivation and meaning for creating and finishing a project.

Aka how to make a project both a profitable and a critical success, guaranteed.

Aka the ultimate game designer's guide.

Foreword#

The holy grail of game design: a best, guaranteed method to design a great game. I used to wonder if such a thing exists.

Having played many games in my life, modded them and designed entire games myself, I had noticed patterns and concepts that made for a better game. Things that could break a game in some cases or make it extremely good in others. Certain ideas, certain ways of thinking, that a designer could take into account when facing a design decision on a particular project, in a particular situation.

I knew this stuff intuitively for a long time, but I didn't have a proper way to explain it. In other words, I didn't have a solid method for explaining the things I knew about game design in a short, clear way that also explained the underlying reasons why it works. Then I discovered Nonviolent Communication, something entirely outside the realm of game development. It helped me trace the root causes of why things work the way I had figured out, and it let me explain them directly without needing more words than necessary.

Turns out there is indeed a holy grail of game design. It is not one single thing, but a collection of things that interact with one another: a few parts glued together by a certain mindset, some special tools and a little bit of experimental research and development. It is still one cohesive, guaranteed method, but don't expect it to be easy. Developing a game design is a very difficult task, comparable to space rocket engineering in some ways, especially mentally. A single project demands that the designer keeps track of an immense number of tiny details, and each one of them can blow up the whole thing if the designer is careless. It is doable, but hard.

I call this method a Design Technology. It's best understood as a mindset plus step-by-step tools and methods for approaching a task, in this case game design. Like the scientific method, it gives you the same reliable result every time, as long as you actually use it properly. With it, you should never need to doubt your game design again.

About this edition#

I started writing this book a long time ago and never finished it. Back then I simply poured everything I had in my brain into one document as it came to me: the ideas, the warnings, the mistakes I'd seen, all of it. The ideas were the important part. The structure, the order and the polish never came, because finishing it would have meant re-reading everything, reorganizing it and rewriting it.

Since then I've written a series of articles that worked out many of the parts the original only had headings for: infinite metagames, multiplicative content, what a game designer actually does, scope, competition and more. Some of those articles also changed my mind about things the original said. Wherever the two disagree, this edition follows the newer thinking.

So this is the finished book. The original's ideas, reorganized, completed and revised.

The book is free to read online. There is also an offline edition you can buy, which is the same book packaged for reading without a connection. Buying it is how you can support me if this book helped you. The ideas themselves are free, though. Copy them, teach them, use them as a source for your own courses or videos, build games on them and make money with what this book gives you. That's what it's for. I'd appreciate a mention if you do. It would mean a lot to me.

I'm not going to give you a number of years of experience to convince you I know what I'm talking about. That kind of number doesn't prove anything. If you want to see what I've designed with this method, my designs are all here: Reactorcore's game design portfolio. Judge the method by what it produces, and better yet, by what it produces when you use it yourself.

One more thing. I'm assuming that whoever reads this already has a burning, passionate reason of their own to learn game design, so I'm not going to open with my own story. It's at the end of the book, in Growing as a Designer, in case you picked this up without a reason of your own yet.

Contents