The Complexity Fallacy

Previously posted on the Frictional Games blog.

Brian Upton once told me the following anecdote about a game that he got pitched to him.

The game presented to him was a space sim where the player took on the role of a space pirate. A big part of the pitch was the virtual economy that the game had. It determined what sort of goods that planets needed, what the prices of various things would be and so forth. In turn this then determined the trading routes that ships would take and what sort of cargo you were most likely to find on them. This was a really complicated system and I guess they planned on devoting quite a bit of development time for it.

Sounds cool, right?

Problem was that none of this complexity was really apparent to the player. The only feedback that the player got from the whole system just boiled down to what sort of ships and cargo they would be encountering. From this meager data it was impossible for the player to get any sort of insight into underlying systems. If all of that system was replaced with a random number generator, the player wouldn't notice. So in essence, all of this complexity was a waste.

The reason something like this happens is quite easy to see when viewed through the lense of the SSM Framework. In this framework we divide the game into three separate spaces: system, story and a mental model. Something like the virtual economy would go into to the system space. But the problem is that these systems would never end up in the player's mental model. Understanding how this works is a fundamental, perhaps the single most important, part of the game design. The player doesn't play a game based on what happens in the computer, they play it based on what happens in their head. Any feature that doesn't have a mental representation might as well not exist.

Tynan Sylvester, who is currently working on the popular Rimworld, has a great article that addresses this very issue.

This is coming from a developer that is developing a hardcore simulation game. If it this sort of thinking applies to that genre then you can be sure that it applies to the entirety of game development.

Adding a feature is not about adding art and systems. It about is adding content that when played with will create a certain mental model in the player's head. In this sense, it's quite a bit like being a stage magician. Just like in games, the important thing in magic is not performing a hard trick, it is making the audience believe that you did one. In fact, many spectacular-seeming magic tricks have really boring explanations. But since the audience is never directly exposed to the method of implementation, it doesn't really matter. The only thing that matters is that the magician has a high chance of succeeding and what sort of reaction it gives the audience. Games works exactly like this too.

Most of the time, an increase in complexity is a bad thing. There is a higher chance of bugs, and it is less likely that you can maintain control of the system. This is why things like artificial neural networks doesn't have much use in games except for in very specific areas. While a neural net could accomplish a lot of cool things, robustness is more important. As a game developer you want to be able to intuit how a system works in order to properly use it in design. Go past a certain point of complexity and the output might as well be random. The KISS-approach is almost always the right one to take.

The simplest way of designing a system is, of course, not designing a system at all. It cannot get more simpler than zero. While this might sound a bit silly at first, it's a crucial part of game design. Last week I wrote about utilizing gaps of the imagination, which is really all about replacing something with nothing. The best way of understanding how to do this is to not see your features as concrete content, as complex machinery, but as experiences you want to evoke in the player. This is not just limited to fuzzy things like NPC emotions, but every single aspect of the game.

As I explained in the previous post, gaps have a lot of advantages over an explicit systemic implementation. Not only are they cheaper, but they are also more malleable and easier for the player to fit into their idiosyncratic view of the game and its virtual world. It is not always the solution, and sometimes the goal cannot be reached without having an actual system managing everything. The only way to make this decision is to look at games in the right way and understand that what matters is not the underlying machinery, but the mental states it gives rise to.

In games, if a tree falls and nobody hears it, it is a feature you should cut.