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:

• Syncless games share no state between clients. At this point we can't really call them multiplayer games. This doesn't stop the meta-game from being multiplayer. For example, players will often try to beat each other's high scores on an arcade racing games, even though the game itself does not share state.
• Async games share information between players is shared asynchronously. A player’s choices effect other player's worlds after some indeterminate time. Many Facebook games belong to this category, as does our Beetrootville example above. 
• Locking async games may be played asynchronously, but the game state will not be changed by more than one player at any time. Essentially, we mean games that have turns. For example a mobile Tic Tac Toe or Scrabble game. Traditional board games (Go, Chess, Awale...) almost always belong here.
• Synchronous games allow players to change game state simultaneously, making their decisions at the same time. A digital version of  Rock, Paper Scissors will be synchronous, but this puts no restrictions on the time required to make a decision or how fast the game state has to be shared with other players. Diplomacy (the board game with simultaneous turn resolution) is a good example.
• Realtime games have the addition of a time limit on how quickly the game state has to be shared. This often implies a time limit on how quickly players have to act. Numerous examples abound: Counter Strike, Musical Chairs, Guild Wars or Starcraft.

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:

• The language of the game [none, one language, many languages]
• The AI [None, pathfinding, Strong AI]
• Permanence of the game world [transient, instances, fully persistent]
• The play state [Debug build, private demo, public demo, published]

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 are the major dimensions of complexity in your game?
• Which dimension adds most value to the player’s experience?
• Which dimensions could be reduced with the least effect on player experience?
• Which dimension could be increased to most improve the player experience?
• Can alternative solutions be found to satisfy the player's needs instead of raising the complexity?
• How many domains does the game cover?

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:

• Unity 4.x Game Development by Example Beginner’s Guide (Ryan Henson Creighton, 2013) - inspired the article with its Multiplayer Ladder
• Brothers: A tale of two sons, by Starbreeze Studios 2013
• The Mythical Man Month (Fred Brooks, 1995)

 

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.