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.
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:
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.
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!
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.