A common perception about gameplay systems is that their complexity is a product of how many moving parts they have. Even if you feel that a simple game can be engaging and that there are plenty of boring complex games, you may also describe mechanically minimalist games as simple and games packed with mechanical levers and pulleys as complex. But there is another way to look at it. In Katie Salen and Eric Zimmerman's 2003 game design book Rules of Play, the authors explore the question of what makes a system complex. They devise a thought experiment in which there are two office buildings, each with mail that needs delivering to the opposite building, and tell us that we must program a system that has the messengers deliver those items as efficiently as possible. There's only really one answer, and it's a simple one: we have a messenger take mail from building A, run it across to building B, pick up the mail at building B, carry it back to building A, repeat infinitely.
But then Salen and Zimmerman shake things up. In a second iteration of their thought experiment, they have us design a courier network with ten messengers who must service fifty buildings. The loss condition is that any one building will be waiting too long for its post. Those buildings are not equally spaced apart either, and we can't guarantee that they're all sending the same volume of mail. We could tackle the problem by trying to portion out one messenger for every five buildings, but then our system wouldn't account for there being greater distances between some buildings than others, wouldn't adapt to some buildings sending more letters and parcels than others, and couldn't get mail from one side of the city to the other. If we want fast delivery over long distances and the ability to process the letters in bulk, we should build new features into the system like having our workers meet up to exchange letters, maybe we should get them to visit certain buildings more regularly than others, or we could have the routes of the couriers overlap.
Notice that in the move from two buildings to fifty buildings, nothing changed about the rules of the scenario. The goal is still to deliver letters promptly, and buildings, messengers, and letters function exactly as they did in the earlier version of the experiment. However, when the writers scaled up the problem, we had to do more than scale up the solution to meet it. The new system we blueprinted was not just the previous one with more moving parts; it had to have entirely new features, which is Salen and Zimmerman's point. Echoing the view of journalist Jeremy Campbell, the authors say it's these emergent, interacting features which make a system complex.
This knowledge is relevant for us as people who play games because it allows us to identify complex gameplay systems, but it has particular relevance for those of us who play strategy titles, management sims, and puzzle games. In most action games and some puzzle or strategy games, we interact only with pre-built systems, but there are plenty of experiences in the management, puzzle, and tactics genres that have us designing our own systems to solve problems. The systems we build in these games all break down into either physical systems, abstract systems, or a mixture of the two. For example, the transport lines in Cities in Motion, the factories in Satisfactory, and the physical structures of Bridge Constructor all qualify as physical systems. But the timetables for the inmates in Prison Architect, the programming for our processor in TIS-100, and the trade economy in Stellaris are all examples of abstract systems.
We can think of systems construction games as a discrete genre and may wish to further split it into subgenres based on whether the games have us constructing physical or abstract systems. Within these genres, and in every systems construction game I've mentioned so far, we can architect the kind of complex systems Salen and Zimmerman describe in their book. In Bridge Constructor, we can weld together individual beams to make a support that takes more load than those beams could hold individually because the girders work together to distribute weight; that's an example of complexity in a physical system. In TIS-100, you might change the kind of operation one code module does based on the input it gets from another module; that's an example of complexity in an abstract system. But there's one game, more than any other, that Salen and Zimmerman's thought experiment reminds me of.
2015's Mini Metro is a minimalist puzzle strategy game from Dinosaur Polo Club. If you take our courier thought experiment and you replace the buildings with stations, the messengers with trains, and the letters with passengers, you've more or less got Mini Metro. There are various ways it differs from the game in Rules of Play, however.
1. Just as different letters may be addressed to different buildings in the delivery thought experiment, in Mini Metro, different passengers want to reach different stations. However, to keep the challenge from being positively headache-inducing, Dinosaur Polo Club makes it so that passengers often don't need to arrive at a single station on the map, we just need to shuttle them to a certain type of station. We must deposit triangular passengers at triangular stations, circular passengers belong at circular stations, and so on.
2. Mini Metro has an explicit scoring scheme. Passengers will spawn at stations over time, and every passenger delivered to their destination merits you one point.
3. Mini Metro also has a more complex loss condition. If a station ever ends up with seven or more passengers on it, a timer will start counting down and will keep elapsing as long as the station is over its limit. If that timer reaches zero, the session is over.
4. Our trains/messengers can't move wherever they want. They can only travel along lines we've laid down, and we have a limited number of lines.
5. Mini Metro adds more stations over time, and at fixed intervals, awards you more trains, as well as the opportunity to create more routes for those trains, tunnels which let your burrow your lines under bodies of water, and other features.
As is common in the format, games of Mini Metro start simple and increase in complexity as they go. To understand how we get to those complexities, we have to remember that, in games, we tend not just to have goals but also subgoals. So, in Planetside, the goal might be to out-kill the opposing team, but a subgoal of that would be making sure we're reloading regularly. In Amnesia: The Dark Descent, our goal might be to escape the stage intact, but setting ourselves the subgoal of not running out of lantern fuel would be a way to help us do that.
In Mini Metro, our goals are to deliver eager citygoers to their destinations and to ensure that stations don't collapse under the weight of commuters. If we want to carry out those tasks efficiently, we should set ourselves the subgoals of making sure that each station has a train regularly passing through it and that carriages don't become full. Typically, when we lose, it's because of a failure to achieve one or both of these subgoals. If stations are not constantly evacuated of passengers, they back up, which triggers the game over timer, and if stations are overcrowded, you're likely to find that even when trains arrive at them, those trains will fill to bursting. When trains are at capacity, they won't be able to pick up passengers from stations which only makes the problem worse. The complexities we ingrain in our system must be designed to keep us on top of these two subgoals. So what emergent features do we build into our system as the scenario scales up and why?
1. Loops. When your train reaches the last station on the line, the line should pipe them back around to the first terminal again. With a loop in place, the distance any one train must travel to reach any one station is the length of the line; without a loop, a train may have to journey as far as two lengths of the line to reach the same station again. With a loop, the next station a train reaches will always be the one it's neglected for the longest; without a loop, it's possible that the next station a train reaches is one it's recently visited.
2. Stations shared between lines. Just as we can have the messengers trade post, we can have our trains trade passengers at stations. It is particularly important that we build this capability into our system because of the existence of unique stations. Sometimes only one instance of a certain station type will spawn on the map, but passengers who wish to reach that station will pop up all over the city. As it would be disastrously inefficient to stretch all our lines across the metropolis to transport people to every unique station, our only choice is to pass passengers from lines without that unique station onto a route or routes that have it. Handing off passengers from one line to another can also be a way to get commuters from a line without a square station to one that can accommodate them. As square stations are rarer than circular and triangular ones, you'll occasionally need to do this.
Often, the optimal solution is to have all your stations converge on a single point that you can use as a hub. Where possible, you want that transfer station to be in the centre of the map so that you're not stretching lines beyond their limits to reach it, and ideally, you want the station they meet at to be a square. In a perfect world, lines might connect at a unique station, the rarest type, but those tend to pop up closer to the edges of the map precisely to stop you doing this.
3. Alternating station types on a line. This strategy is best explained with an example. Imagine that we have a line that runs through three circular stations in a row. A station will never produce a passenger the same shape as it. Why would a triangular passenger, for example, try to hitch a ride at a triangular station? They're already at their destination. We can know, based on this rule, that our three circular stations will only output triangular, square, and unique-shaped passengers. A train moving along this line may pick up some square, triangular, and unique passengers at the first station, which it won't drop off at the second station as the passengers don't match the station shape. At the second station, it may pick up more of the same, which it can't drop off at the third station because that's still not a triangle, square, or unique.
Our train is liable to exit this chain of three stations stuffed wall-to-wall with passengers, violating our subgoal of retaining open space in carriages. By comparison, imagine our locomotive went through a circle station, then a triangle station, then a square station, in that order. Any triangular or square passengers picked up at the first station would be deposited at the second or third station, and any square passengers picked up at the second station would also be dropped off at the third station. On average, our train will exit the second route setup with far more passenger slots left in it than if it had gone through the first. So, we alternate station types wherever we can.
4. Non-overlapping lines. This one is about as easy to grasp as they come. If railroads overlap then when a train travels across that overlap, it will slow down. You don't want carriages taking longer to reach stations than they have to.
___
Knowing these strategies, there's a couple of interesting observations we can make. Firstly, Mini Metro explicitly teaches us its rules and what tools we can use to build systems in it but challenges us by having us figure out what complexities we should implement in those systems to get ahead. Most systems construction games use this general scheme. To return to our earlier examples, Bridge Constructor lets us erect beams but doesn't tell us that we can cluster beams in certain patterns to better reinforce our bridges. TIS-100 teaches us about how to implement input, output, and conditional functions, but doesn't tell us how we might use them together to process data between modules.
The second observation we can make about Mini Metro is that not only can we bring components of our system together to create complexities, we can combine those complexities to make new complexities. To reiterate some of our strategies, we want non-overlapping lines, loops, and our routes to converge on a square station. We can put the above aims together to create an ideal pattern for our rail network: It should look like the petals of a flower growing off of a square station in the centre of the map. Now that we know this strategy, Mini Metro would appear to be solved. In fact, through this mindset, all systems construction games could be beaten by learning the correct complexities to implement and putting them into practice. I'm not going to say it's wrong for a game to reward that approach, but if the challenge of a game is only to uncover and memorise a set of strategies, then it's limiting its depth and longevity.
Many games develop their difficulty over time by teaching us a lot of ideal actions and tactics to use but making it difficult, or in certain situations, non-advantageous to execute on them. In a systems construction game, this means the design putting up a lot of walls in our way when we try to embed the complexities in our systems that we want to. Let's run back down our list of strategies and look at how the game can sabotage each one.
1. Loops. When we have a lot of solid ground to work on, running a loop across it is highly doable, but often we have to route our networks across bodies of water. Every time we do this and include a loop in the line, we use at least two tunnels: one for the train to go out over the river or sea and another for it to make the return journey. Tunnels are in short supply, so you have to ration them, meaning you often don't have enough of them to complete circuits across bodies of water and must resort to non-looping lines.
2. Stations shared between lines. The risk you run by implementing this strategy is that those cross-line stations buckle under the pressure of extra passengers. They not only have to accommodate all the regular commuters that show up at any spot on the map, they then have all these additional travellers crammed into them as those people disembark from one line and wait for the train to appear on another. The strategy in which we connect all lines to a single station is a countermeasure which aims to keep this potential overflow of passengers contained. This is a more attainable goal if we can use the "interchange" power-up on that shared station, increasing its capacity and the speed at which it can load and unload passengers, a move which will have all lines moving faster. Still, sometimes that powerup doesn't spawn, and there's no way to eliminate the pressure on shared stations entirely.
3. Alternating station types on a line. The game can make it hard or impossible to use this strategy by spawning a lot of circle stations in close proximity to each other. You can't run your metro through a square or triangle if there are no squares or triangles nearby.
4. Non-overlapping lines. If a designer is smart, they can make it so that rolling with one strategy prevents us from implementing another.
Choice is a critical element of meaningful play, and in Mini Metro, we frequently have to make choices about the layout of our rail networks. If you're looping lines, overlapping them, and having them connect back to the same hubs then, at some point, you're likely going to run one line across another as they encroach on each other's space. The game dumping a cluster of circles in one area also nudges you to twist your lines into pretzels searching for other shapes to thread in between those circles. In both cases, you will see a slowdown of your trains as tracks run across tracks.
___
When the game trips us up with these tricks, we can't think of our objective as just being to build the "correct" features into our system; the play has been lent depth through us often having to decide when implementing a feature is worth it and when it's not. We may also have to choose which complexities we prioritise. There are trade-offs, calculations we must make about which are the best tactics, and there is risk/reward based on which strategies we choose. All strategy games must have these elements if they want players to keep thinking of original solutions to problems and coming back to play. For maximum depth, they must have us not just devising a complex strategy or system for the whole experience, but revising it on a per-level or per-session basis.
Before we leave this topic behind, let's dispel a few misconceptions about complexity in games. Firstly, complexity does not equal depth. Under Salen and Zimmerman's specific definition of complexity, this means that just because a system might have emergent features in it or a game may push us to implement such features in our games, that doesn't guarantee that those features are going to be meaningful to us. The dynamics in our Mini Metro subway are meaningful to us because they're each unique and have a clear and substantial effect on the larger game state, but when features of a system are too similar, or their impacts are nebulous, the player is going to struggle to care about them. Additionally, if the player can succeed without paying attention to many of the elements in a system, what the design has is not depth but clutter. Secondly, there's this little bit of logic:
Premise 1: Our video game is themed around a real-world system that's complex.
Premise 2: Our video game or a system within it is complex.
Conclusion: Our video game is an accurate simulation of that real-world system and its complexities.
The problem with this line of thought is that while you might be right that both these systems are complex, the complexities in system A are not necessarily the same ones as in system B. So, in our Mini Metro example, our subways are complicated, real rail systems are complicated, but that doesn't mean that they're complicated in the same manner or to the same extent. For one thing, in Mini Metro, the tube map you're building is identical in layout to the railway it represents, but in the real world, stations and train lines aren't laid out in the same patterns they are on maps. Those maps are orthogonal diagrams designed not to be geographically accurate but to make transit systems easy to navigate for commuters. Compare the London tube map to this engineers' diagram. You can wrap your head around the orthogonal map far more easily than the engineers' diagram. There are countless other differences, including real rail networks generally having more lines or the engineering of trains and tracks being a factor in efficiency.
Lastly, it's important to keep in mind that when analysing a game or any system, that we don't have to use Salen and Zimmerman's definition of complexity. The researchers say that complexity can be identified not by whether a system has a multitude of moving parts but by a system evolving interacting features to cope with a problem. However, there are plenty of other conceptions of "complexity". In certain contexts, we might define it as a system having a large collection of elements, or having many properties that an observer can see, or something else entirely. In situations where terms have multiple definitions, there's often a tendency to try and discover which one is the "real" one, but I think this often erodes our descriptive ability rather than improves it. There are myriad meanings of "complexity", and we can use different lenses on the games we analyse at different times to achieve different insights.
To recap, Rules of Play claims that when problems are scaled up, we can't absentmindedly scale up our solutions to meet them. Instead, we have to add new interlocking features to our systems, and at the point we do, we can call our system "complex". This is relevant both in the context of the systems which make up games and the systems that we sometimes build to play them. The systems we construct can be physical or abstract, but the games typically run us through three steps: 1. The designers tell us what elements we can build into our systems, 2. We learn for ourselves what complexities we can build into them, 3. The game tries to disrupt our implementation of those complexities. However, just because a game system is complex does not mean it is realistic or deep. Nor do we have to adopt Salen and Zimmerman's concept of "complexity" in any given scenario. Thanks for reading.
Sources
1. Salen, K. & Zimmerman, E. (2004). Rules of Play: Game Design Fundamentals. MIT Press (p. 152-154).
Log in to comment