Making Sense of Complexity

Games hide away a lot of complexity from the players. As game designers and developers, we have many sophisticated tools to handle the underlying complexity, from low level tools like programming languages, that abstract the computer platform into something digestible, to sophisticated tools such as full featured game engines (Unity3D, Unreal, etc...) that hide away a significant portion of the complexity involved in building a game.

But how complex is a given game? How big is a project given its feature set? How much effort is required to add a new feature? We'll take a look at an approach to understand the complexity space a game lives in to give us a better idea.

These are not idle questions for game professionals. Reality dictates that both independent developers and corporate game-smiths alike need to worry about them. An overly-ambitious project taken on by a team without the resources (in skills & expertise or in number of members) can end a small studio or an emerging indie career. Having a measure of the complexity of what wish to create can help us plan accordingly and recruit the help and support we need.

Let's take a look at  multiplayer by way of example. Many people have differing views on what the very word implies. Some feel it means a Quake-like FPS arena, while for others the first thing they'll think about are social clicking games. These may both be called multiplayer, but are clearly very different, so let’s break it down a little more.

A potential difference between the two is that for the FPS arena, the game is responsive in real time. When a Kuwaiti player fires their weapons, the amount of time the entire system must take before the virtual gun on a French player’s computer fires is limited. Beyond a certain threshold, the game breaks and no longer works. In comparison, Beetrootville's actions lack a significant real time constraint. So what if a player’s beetroot growth isn’t reconciled with another’s for days? This aspect is then one of the ways in which the complexity of a game can grow.  We could image a scale as below, where the complexity is lower on the left and higher on the right.

We can take a closer look at the different steps:

Valuable to consider is also where players will be playing from. Thinking about the previous domain, we can see that games in each of the above categories can be played without a computer, on the same computer or on different computers. This defines the next domain, and by thinking about it as orthogonal to the synchronicity domain, we can image the graph below:

As an example, we can image building an area control game in which players dispatch troops simultaneously throughout a graph of connected strongholds, and all decisions are accepted before being resolved (An online version of the Game Of Thrones Board game would be similar). Player should be able to play on their tablet. How complex will this game be? This can be seen at a glance by looking at our diagram:

An additional aspect to consider is how the information is shared between entities within the game. This can have a drastic impact on the complexity of a game. For example, a Facebook game will only have to share information between the player and their friends, a clearly defined and limited set. In contrast, EVE Online, will share the player’s actions globally.

This creates yet another dimension to consider when thinking about the complexity of a game. We can think of it as the set of people information has to be shared with:

It gets interesting here, as games do not necessarily have to take a consistent approach. Instance dungeons are a technique allowing a restricted environment to have no player number limitation (the shared wolrd), but drastically limit the number of players who can share the experience of the instance itself. Doing this reduces complexity when designing an area, as the maximum number of simultaneous players can be fixed, which simplifies the design task.

What we can realise by looking at the above diagram is that the 2D space we were working in has now become 3D. The complexity of a game is now represented as a volume in that space. Taking the Game of Thrones board game example, we can see the game as a cuboid:

Approaching the problem this way can help us visualise how increasing the complexity in a given domain will affect the total complexity. I make the point here that the total complexity of a given game is the product of all of its complexity domains. I'm hardly the first to make this realisation, and this idea is generalisable across things other than games. We can see echoes of it from the dawn of computers (See “The Tar Pit” in The Mythical Man Month).

We could assign numbers to each category in the different dimensions, but  it isn't clear what we would gain without basing them in real data. We're not trying to give a precise answer, but isntead to frame our thinking when building games and thinking about complexity in general.

Conclusion

we have described how games can have many dimensions of complexity, and that total complexity is not simply the sum of these. We ought to think instead about the product of the individual complexities in each domain as the total complexity of the final game. Thinking about a game in this way lets us answer the question "How complex is this project" with much more assurance that our answer is sensible, letting us predict the cost of increasing the complexity in a given domain during development.

It goes without syaing that we have barely scratched the surface of a game's potential complexity domains. That said, visualising the diagram gets trickier in more than three dimensions :-)

Others to consider are:

Firstly to realize that sometimes, the best move is not to play the complexity game at all. Many games have now started to do away with the complexity of language by replacing soken speech with unintelligible noises. Brothers: A Tale of Two Sons uses the environment, music and animation to convey meaning. This, rather than diminising the quality of the experience and emotional immersion, is used to great effect and improves it instead.

That last one may be a stanger to consider, but will helps us understand the effort required to shift from demo to publication. The difference in kind between the various play states explains the countless unfinished projects sitting on hard drives (mine included) across the world. Using the complexity dimension approach to visualise the effort required to complete a game, gives us a much better handle on the true amount of effort required. Not that should ever stop us, of course, but forewarned is forearmed.

So for your next project, why don't you ask yourself the following questions:

What do you think? How have you been handling and managing complexity in your games? How do you scope out projects? Is this the best thing since sliced bread? Is this lot of rubbish? Let us know!

Until then, Happy Gamedeving!

References:

Want to learn more about this kind of stuff? Want to learn more about game development? I've created an online course teaching game development using Unity3D that I think you'll like where I talk about this and a lot more besides.