Mandible Games

We've spent time talking about Anno 2070's subtle shifts in complexity. We've spent time talking about Gyromancer, SquareLogic, and FF13's attempt to unearth new game mechanics by removing complexity. But we haven't talked about adding complexity, and we haven't talked about explicitly moving complexity.

So let's talk about that.

Starcraft 2 and Supreme Commander

You could just as easily compare Starcraft 1 and Total Annihilation, but I'm sticking with these because it'll be easier to find screenshots. (And no, we're not going to talk about Supreme Commander 2. That game didn't exist.)

Starcraft 2 and Supreme Commander, on first glance, occupy the same genre. They're both real-time strategy games, where the player is given control over a base filled with resource gatherers and production structures, has to construct an army, and is told to go blow up the bad guys.

It's the same genre, but the two games differ drastically after that.

A race in Starcraft 2 consists of 13 to 15 units and 15 to 18 buildings. Most buildings have orders they can be given, either to produce units or to produce upgrades for units. The units themselves almost all have a gimmick – sometimes a passive gimmick like the Observer's cloaking field and cloak detection, sometimes an active gimmick like the Marine's stimpack. Combat in Starcraft 2 is mathematically simple, without any worries about ballistics or dodging. A fired shot will always hit and always do a predictable amount of damage, albeit with a little travel time. However, the complexity of the units make combat fast-paced and difficult to perfect.

Supreme Commander takes a dramatically different approach, with almost fifty units and fifty buildings per faction. Production buildings build units just like Starcraft's, but control over your utility buildings is limited to a simple on/off switch. The vast majority of units have no gimmick, either passive or active, and while there are technically "fifty units" the majority of them are simple upgrades on previous units – like the "Conservator T1 Interceptor" vs the "Swift Wind T2 Combat Fighter" vs the "Corona T3 Air Superiority Fighter". In Supreme Commander, there's no reason to build the older models of aircraft – you'd always want to build the new, higher-tech version.

First, there's a moving of complexity. In Starcraft, you upgrade units by researching upgrades at your various structures. In Supreme Commander, you upgrade units by building a new factory, then producing upgraded units. The result is that, while Supreme Commander has two classes of "thing" – buildings and units – Starcraft 2 has three classes of "thing", adding upgrades into the mix. Supreme Commander simplified the basic concepts available in the game by adding far more types of unit.

Ironically, despite having well over three times as many units as Starcraft 2, Supreme Commander's units are, overall, much simpler. Most of Supreme Commander's units do three things: they move, they shoot, and they die. In the meantime, Starcraft's units can do all sorts of things, from kamikaze explosions to directed area-of-effect attacks to mind control to teleportation.

Supreme Commander's base-building is significantly more complicated. Structures in Starcraft are largely passive, acting as large lumps of hit points that let you build things. Supreme Commander leans much more heavily on active buildings with weaponry, giving you an entire range of close-range and long-range defensive buildings, as well as a small number of ultra-long-range artillery buildings. To supplement this, Supreme Commander provides a range of defensive shield buildings that can protect nearby units and structures from incoming fire. Finally, Supreme Commander's energy-generation buildings also act as augmentations for nearby structures, doing anything from reducing resource consumption to increasing fire rate.

To compensate for this dramatic increase in complexity, Supreme Commander's bases are far easier to automate. While Starcraft's factories require manual intervention for every single unit, Supreme Commander's factories can be set to automatically construct units without the user being involved. This is a good thing because Supreme Commander armies are far far larger. Starcraft limits the player to an army of 200 "food", and the vast majority of units take one or more food – some reaching up to eight food per unit. Endgame armies frequently number around 50-75 actual units. Supreme Commander, by default, limits you to 500 units, but this is more of a computer performance limit than a game balance limit.

So, the Complexity Roundup so far:

Starcraft has more complicated units, more base management, and more complex upgrades to deal with.

Supreme Commander has more complicated base layout and far more units, but once your base is laid out, it mostly manages itself.

From what I can tell, the goal with Supreme Commander was this: Make the player spend effort only on things that are actively improving their position. Building a larger base is worth spending time on. Keeping your base running is not. Changing your production is worth spending time on. Mass-producing units one at a time, by hand, is not. Your base is meant to run itself while you're away. So what do you do during those times you're "away"?

The intention, I think, was to set the player up as . . . well, as a Supreme Commander. (They're not subtle.) You have hundreds of units and you order them all around constantly. The trailers showed the player doing pincer attacks, feints, all sorts of clever military maneuvers.

Unfortunately, this doesn't work out well in a modern real-time strategy game. In real warfare, many of these clever military maneuvers worked due to limited information, bad communication, and extremely slow units. It's easy to do a pincer maneuver when the enemy is nearly incapable of relaying orders from one side of their formation to the other, and it's easy to do a pincer maneuver when the enemy is unable to look into thick brush. It's a whole lot harder when the enemy has a circle of visibility around their units roughly equal to yours and when the enemy can retreat at the same speed as you can attack.

And "far more units" isn't really a source of complexity in itself. When your units do individual important things, it certainly can be – if you're familiar with the game, imagine trying to efficiently manage a 1000-food Starcraft 2 army – but in the world of Supreme Commander, more units simply means a larger blob of death that gets moved around the map as a sort of conceptual amorphous accumulation of power.

Supreme Commander tried to move a large amount of Starcraft's base management and micromanagement complexity into largescale strategic positioning . . . but it turns out that really doesn't work well in the RTS genre. The end effect is to take a complicated game and just make it simpler, and that's one of many reasons Supreme Commander was unsuccessful.

But with that in mind, I can talk about a more successful example.

World of Warcraft raids vs God of War boss fights

I'm not going to even pretend that one of these was inspired by the other. We all know that's not true. But they make for an excellent study on how you can get dramatically different gameplay by moving complexity around.

For the sake of this discussion, let's just ignore the whole multiplayer thing. Assume your World of Warcraft pals are simply AI bots, and the boss lives or dies based on your success at your role in the fight.

World of Warcraft characters are very complicated. Even standing in one place trying to maximize damage on a single target, you're generally juggling half a dozen abilities or more, each of which has to be used properly in order to do your job right. Many of your abilities interact with each other in complicated and nonobvious ways and have to be activated in the right patterns. If you start having to move, or deal with large groups of enemies, or target-switch often, it gets far more complicated.

Conversely, controlling Kratos, God of War's main character, is quite simple. Maximizing damage is a matter of mashing a single button repeatedly, and your alternative attacks vary in only a few simple ways – usually recovery time or area damage. Kratos has no complex interacting moves. The only interesting thing Kratos does in terms of combat techniques is his combo moves, triggered by pressing the buttons in certain patterns – but Kratos has only a small number of these combos, and they are both completely predictable and easy to trigger.

Kratos is, fundamentally, much simpler to control than a World of Warcraft character. Basic understanding of Kratos's abilities takes minutes at most, and expert control takes perhaps a few hours.

Simplifying his control scheme opens up a lot of space for complexity in other places. Namely, bosses.

Much has been said of the complexity of World of Warcraft bosses, and in a sense, this is accurate. The most difficult boss fights tend to take a month or two for the best groups to kill. But this isn't a particularly even comparison. Warcraft bosses are intended to be tough to kill, while God of War bosses are intended to be relatively easy to kill. Challenging, yes, but doable. We're going to compare Warcraft bosses that are roughly the same difficulty as God of War bosses.

When making this comparison, the Warcraft bosses start looking simplistic at best.

Complicated bosses might do something every fifteen or even ten seconds – simple bosses will often have thirty-second-long periods of time where you're simply standing there whaling on the boss. Some bosses, such as the semi-infamous Patchwerk, have literally no gimmicks. They stand there and beat on you, you stand there and beat on it, if you survive long enough to kill it within the time limit, you win. Meanwhile, the God of War bosses tend to require a response every five seconds or so, at most. There's simply no time to get complacent and no time to rest – the boss will be smacking you if you let it.

Modern Warcraft bosses will usually have two or three basic attack patterns – "run away when he does this", "don't stand in fire", "get ready to cast a lot of healing spells", but all of these are telegraphed with a clear indicator and several seconds of spare response time. The God of War bosses often give you one second's worth of notice, at best, and frequently require that you quickly and accurately recognize the boss's movement and respond in the correct manner out of several options.

World of Warcraft has chosen to put a large amount of the gameplay complexity into the character. Once you understand your character – and that can take a phenomenally long time – most of the bosses end up being relatively similar. God of War, conversely, has chosen to put a large amount of the gameplay complexity into the boss. Each encounter is dramatically different, but your character is relatively simple and easy to deal with.

Proper complexity budgeting isn't just about putting complexity in the spots you want complexity to be – it's also about taking complexity out of the spots you don't want. If Kratos had a complicated control scheme it would take away from the real goal of the game: beating the shit out of horrifying monsters the size of a house. But if World of Warcraft had a simple control scheme, then the process of creating new bosses would be far more complicated and expensive, possibly resulting in huge budget issues. You can't get away with strictly removing complexity because that results in a dull game, but likewise you have to stay below an upper threshold, or your game is impenetrable and unplayable.

I could probably go on with more examples for months, but this has gone on easily long enough by now. I'd like for you readers to analyze a few games based on complexity. Take a look at what a game explicitly avoided adding, or what a game added that was unnecessary. Compare two games in seemingly the same genre but with different behavior.

I've found this to be a surprisingly powerful tool for analyzing game design, and I've already modified some of my game plans by reconsidering where I'm putting complexity. If you find anything interesting using it, let me know!

This is part two of this increasingly enormous writeup on complexity. I recommend reading Part One before we get started.

The concept behind this megapost really started about two years ago, when I played a pair of games that made unexpected but excellent design choices. Later, I found a third. In each case, the game removed an uninteresting mechanic that had become a staple of the genre, and in doing so, unearthed some new interesting mechanics that had gone unnoticed.

Just to warn you: two of these games don't really succeed. That's what happens when you try experimental things. But they're all intriguing games, and they all open up areas of game design that I think are worth analysis.

First off: Gyromancer.

Gyromancer is, at its core, a big-budget version of Puzzle Quest. Puzzle Quest is, itself, Bejeweled with an RPG grafted on. In the case of Gyromancer it's Bejeweled Twist, with a pile of surprisingly pretty art and a plotline that's . . . well, it's a plotline. We'll just go with that.

Most of the complexity of Gyromancer (yeah, we're back to complexity, you saw that coming) is tied up in your abilities, your opponent's abilities, and the effect of gems on the board. All of these have to be dealt with rather carefully. Spells can morph the board rapidly and only somewhat predictably, your opponent does quite a lot of damage when he attacks, and many of your abilities interact in complex ways.

And on top of this, you have to play Bejeweled.

Bejeweled Twist, at that, which is a more complicated variant – instead of the relatively simple block-swapping mechanic, you have to rotate a square of four blocks. It's a little harder to understand the side effects of a move and a little tougher to come up with long-term plans. Now, I'm sure Bejeweled experts will have no trouble with the mechanic, but I am not a Bejeweled expert, and I had trouble with it. The game has a lot of mechanics piled on top of each other and it was almost too much to handle.

I say "almost" because the developers made one little concession to crummy players like me. See, your cursor lights up when it's held over a valid rotation. This means that you figure out incorrect moves before you click and screw up. This also means that if you can't find the valid move, you can just skim over the entire board watching for your cursor to light up in order to find it.

In other words, they took out some of the complexity of "find possible next moves", and they moved that complexity into "choose the right ability or move to make". Being a Bejeweled expert is no longer as necessary, and training your eyes to detect valid Bejeweled moves isn't as needed. Instead, you can devote that time to choosing the right move to make.

But imagine what would have happened if they'd gone even further. Instead of telling you whether a chosen move is valid, they could simply show all valid moves. They could have removed all the difficulty of finding a move and simply left the player to figure out the best move. Even less player effort in the brute-force scanning, freeing up time and effort for the interesting decisions! I'm not going to claim this would have been a better game – I suspect I'm not the target audience – but it would have been a game I personally found more interesting. If I'd wanted to play Bejeweled, I would have played Bejeweled, but really I was most interested in the new mechanics, which Bejeweled masked.

Next up, we've got SquareLogic.

SquareLogic can be best described as Sudoku on acid. Sudoku takes place in a 9×9 grid, further divided into nine 3×3 boxes. You must fill each box with a number from 1 through 9. You can't use the same number twice in a row, or twice in a column, or twice in a 3×3 box.

SquareLogic, on the other hand, goes from 4×4 through 9×9. You're roughly limited to the same count of numbers – a 4×4 grid will take numbers 1 through 4, a 9×9 grid will take 1 through 9 – and you're still subject to the row/column restrictions. But it gets far weirder from there. First, while SquareLogic does have subcontainers, they aren't necessarily square. They might be rectangles. They might be strange bendy shapes. Worse, these containers don't care about uniqueness. They care about other things. For example, you might have a 24x container, which means that the product of the numbers within the container must be 24. Maybe that's 1*2*3*4. Maybe that's 1*1*4*6. You might think it could be 2*2*2*3, but you'd be wrong – remember, you can't have the same number duplicated in a row or a column, and there's no way to lay out 2*2*2*3 such that no two 2's share a row or column. But 1*1*4*6 would fit in an S-shape, with the two 1's on opposite ends.

That's not all, though! SquareLogic doesn't tell you where the containers are. You're given one square in each container, and the rest of the container locations have to be derived logically. Sometimes that's easy: if the container is "12x", you know it needs to be at least two squares large. Sometimes that's tougher, though: is "12x" two, three, or four squares?

And then, just when you feel confident in that, SquareLogic throws double-board puzzles at you. Two boards, the same solution on each board, but different containers. You'll have to solve them simultaneously to win, as neither board has enough detail to get a full solution.

All of this could easily become overwhelming. In fact, just the busywork could be overwhelming – Sudoku-style games require that you keep track of which numbers have been used in which rows or columns. But SquareLogic, after throwing an enormous amount of complexity in your face, quietly shuffles much of the busywork away and takes care of it for you. Each box contains, greyed-out and in small type, all possible numbers that could fit there. You can eliminate numbers manually by right-clicking them. But if you make a decision and place a number in its final location, SquareLogic instantly clears all instances of that number from that row and column, as you can guarantee the number won't show up in any other similar places. The busywork is boring, and the computer can do it, so why shouldn't it?

SquareLogic helps in other ways. If you mouseover a container, it will list all possibilities. Mousing over 12x will show 3*4, 1*2*6, 1*3*4, 2*2*3, 1*1*3*4, and 1*2*2*3. If you've determined that your 12x container is only three squares large, it will restrict that down to 1*2*6, 1*3*4, and 2*2*3. If you've shown that none of the squares can contain a 3, it will cross out 1*3*4 and 2*2*3, leaving you with just 1*2*6. Sure, you could do it by hand, but does anyone want to spend their life trying to factor numbers?

(Especially the larger numbers – multiplication containers can easily reach the thousands, as 6*7*8*9 = 3024. I don't want to factor 3024. That's why I own a computer.)

The end result is a horrendously complicated, but surprisingly manageable, puzzle. When you get stuck, it's usually because you missed something clever, not because you misclicked or forgot to cross out an option. Since the game keeps track of all the little mental details for you, your brainspace is available for the far more interesting logical derivation.

But it's worth noting what SquareLogic didn't automate. SquareLogic will never actually choose a number for you, even if you've eliminated all alternatives. SquareLogic will happily tell you that there's only one possibility for a container, but it will never narrow down the elements in that container without your explicit input. The automation is solely limited to removing row/column conflicts and informing you about container possibilities. If you go too far, you end up writing a game that plays itself. SquareLogic went further than most do, but not too much further, opting to stay back and leave the fun bits up to the player.

Last, though with unarguably the highest budget of any of these games: Final Fantasy 13, and specifically, FF13's combat system.

(Before I continue: no, it hasn't escaped my attention that all of these games either involve squares or are made by Square. I promise this is a coincidence.)

From Final Fantasy 1 all the way through Final Fantasy 10, the most fundamental assumptions of Final Fantasy's combat system remained unchanged. You controlled a party of characters, from one to four at a time. Each character had a number of abilities, generally including Attack, Magic, Item, and a special gimmicky thing. Each character attacked in some order – generally determined by the character's speed – and used a single command at a time to damage the enemies, heal friendlies, or cast helpful (or harmful) spells. The enemies did the same, interspersed with your units.

There were many variations, of course. Some games used an "active time battle" system where characters attacked somewhat in realtime, although this was essentially a realtime wrapper around a turnbased game. For a while, every Final Fantasy game came up with a new way to gain magic, from Espers to Materia to Guardian Forces to the Sphere Grid. In FF7, your characters' spells were highly customizable before battle. In FF10, your characters could be swapped out at a moment's notice in a fight. FF8 let you buff your characters by "attaching" spells to them. It got complicated. But the fundamental design didn't change – one character took their turn and did something, the next character took their turn and did something.

FF11 broke the pattern by virtue of a genre change. FF11 was a massively multiplayer game, where you controlled a single character, and your party fought as a cohesive, realtime group. The gameplay didn't surprise anyone, at least after the MMO layout was announced – MMOs don't work with the old Final Fantasy method. But FF11 heavily influenced FF12. In many ways, FF12 felt like a single-player MMO. Instead of controlling a party, you directed a party – you wrote general-purpose scripts to automate what you intended, then gave direct commands to your characters when you needed to override their behavior.

Which taught us some very curious things. It turns out that the old Final Fantasy combat style is, fundamentally, very repetitive. Classic Final Fantasy combat consists of three things: healing, buffing, and attacking. First, make sure nobody's about to die. Then, cast the spells that make your characters vastly better. Finally, kill the bad guys. Most of this can be automated. In fact, the only part that takes any thought is "attacking", as various monsters require different attack spells. For example, robots are vulnerable to lightning, so if you're fighting robots, hit them with lightning. That's all the thought you need to put into it, though – after you've figured that bit out, it tends to be quite formulaic.

When FF12 automated all the basic bits, they were able to use that freed-up gamespace and make the bosses more complicated.

Now, FF12 didn't do a great job of it, because in order to play the game efficiently you basically had to be a programmer. Your characters had little automated scripts that you had to design. If you weren't good at that kind of process design, you sucked at the game. But FF13 took this to another level altogether.

In FF13, you didn't really control your characters at all. Instead of telling them what to do, you told them how to behave. For example, you'd tell one character "be a healer", and that character would start lobbing heal spells around to keep everyone else alive. You'd tell another character "cast buffs", and that character would automatically choose appropriate buffs and keep your party fully augmented. At the same time, FF12 took the old three-role Final Fantasy system and split it into a whopping six roles. The "buff" role was joined by a "debuff" role. They picked up a fully functional tank role, able to absorb firepower and take minimal amounts of damage. And, in a rather uncommon twist, "damage the bad guys" was split into two separate roles – a Ravager that gradually knocked the enemy off-balance, and a Commando that did enormous amounts of damage, but only once the enemy was off-balance.

Now, you did have direct control over one character, but to be honest, most of the time you just mashed the "do whatever you would normally do" button. The AI was smart enough to prioritize buffs intelligently and it understood which debuffs worked on the enemy. The tank would do a good job of keeping damage contained, the healer would distribute healing spells appropriately, and the various damage roles would quickly figure out the right spells to use and . . . well . . . use them. Instead of spamming Lightning on the robots, you watched while your characters spammed Lightning on the robots.

And as you'd expect, this opened room for more complicated bosses. Bosses in FF13 are truly deadly – a few turns of the wrong actions will often result in a party wipe and a game-over. Your characters will respond quickly, and do an amazing job of efficient damage mitigation and recovery, leaving the only real in-battle decision to a moment-by-moment choice between party roles, deciding on the fly which combination of roles will prevent your party from dying and kill the boss.

Which is, in many ways, where FF13 fails. You simply don't have enough choices. I'm all for automating the repetitive parts, but it turns out that the Final Fantasy combat model is repetitive parts. When you take away all the repetition, and don't replace it with something new, you're left without a game. In the case of Final Fantasy, the "game" becomes recognizing the right response to half a dozen boss abilities. When boss does this, you mash Tank button. When boss does this, you have time to rebuff. When boss does this, you can go back to kill mode.

The problem is that the roles are very, very specialized. If you need a tank character – and you often do – that's a full third of your party's functionality tied up. If you need a healer as well, that's another third. That leaves you with one character left to do damage, and that's only if you don't need buffing or debuffing. The game stops being about fighting the monster and starts being about juggling role timings.

Which is admittedly an interesting mechanic. Perhaps not one that stands on its own, but one that could be used as part of a much better game. And a mechanic that simply wouldn't have been uncovered without automating all the boring parts of combat.

So, what's the conclusion to all this?

I've talked about three games that got rid of large parts of their complexity. In the case of SquareLogic, I think it was a clear win. In the case of Gyromancer and FF13, I think it was a bit more dubious as a game, but quite valuable as research. The real lesson is that removing obvious sources of complexity does not always result in a better game, but it does usually result in learning more about your game and finding unexpected deposits of fun deep inside your game's emergent behavior. Even if you don't want to do it in your final release, it may be worth trying it out as an experiment, just to see what you discover.

And that neatly segues into our third entry, in which I'll compare pairs of games to see how differences in complexity layout can result in vastly different gameplay. I'll see you again next time. :)

I've been spending a lot of time thinking about complexity.

I've also been spending a lot of time playing Anno 2070.

Let's start with Anno 2070.

The game industry is fickle and deadly. Franchises appear out of nowhere, make it big, and instantly fall on their own sword, only to be resurrected in a sort of grisly undead state years later when some publisher realizes they still own the rights. The surviving franchises are either mutated out of recognition within a few years or exploited beyond all sanity. The Anno franchise is an exception. Anno 1602 was released way back in 1998, and it's been followed by four major sequels, two spinoffs, and an expansion pack. Despite this 13-year history, the core game mechanics are unchanged since the very beginning, which makes it absolutely perfect for this discussion.

Unfortunately, I've only played the most recent two games. I'm sure I could say a lot of fascinating things about the entire series of five games, and maybe someday I will, but that's not today. So, instead of talking about the Anno series as a whole, I'm going to talk about the changes between Anno 1404 (known in the US as Dawn of Discovery) and Anno 2070.

Anno is a citybuilding game. There's combat in it, but very little – the core game mechanic is about building a really big city with a whole lot of people and industry. Now, in most games, you'd expect that a city would need a lot of workers in order to run factories and farms. Anno doesn't work that way. Production buildings work whether or not you have people, but they cost money to run. Houses, meanwhile, do only three important things. First, they unlock new technologies and new buildings, based on your population type and your population count. Second, they give you money in taxes, which is needed to keep your cashflow positive and your production functional. Third, they consume the output of those aforementioned production buildings. Playing Anno isn't about balancing Residential, Commercial, and Industrial zones, then watching people move in, it's about building a ton of houses and then trying to keep them fed when they start demanding eighty tons of pasta every minute. And you're the one in charge of the pasta.

(All goods in Anno are measured in tons. This makes perfect sense when talking about wood, coal, or oil, less sense when talking about pasta or glass, and very little sense when talking about diamonds, lobster, or marzipan. You get used to it.)

For a game that's all about production quantities and production chains, Anno 1404 provides very few tools to keep an overview on your industry. In fact, until midway through the game, the only way to count your buildings is to do it manually. To make matters worse, Anno 1404's tech trees can be complicated and interdependent, and figuring out the proper building quantities requires that the player either do a lot of math by hand or use tools.

For example: To run a a wine press at full capacity requires three vineyards, one barrel cooperage, 2/3 of a lumberjack hut, half an iron smelter, half an ore mine, and half a charcoal burner's hut. An Optician's Workshop at full capacity requires 3/4 of a quartz quarry, 3/4 of a copper smelter, 3/4 of a copper mine, and half a charcoal burner's hut. A Redsmith's Workshop requires 1.5 candlemaker's workshops, 2 apiaries, 1.5 hemp plantations, 3/4 of a copper smelter, 3/4 of a copper mine, and 2 charcoal burner's huts. Now: If you want four wine presses, five optician's workshops, and three redsmith's workshops, what buildings do you need?

The answer is "I have no bloody idea, let me alt-tab out to check my Excel spreadsheet".

Even worse than that, however, is the fact that the game doesn't tell you these ratios. I had to look them up. The early tutorial gives you some of the basic ratios – "you will need two hemp plantations for every weaver's hut" – but the complicated stuff has to be determined either by trial and error or by looking it up on a wiki.

Anno 2070's solution to this is . . . incomplete, but an improvement. First, the very first buildings you can construct in Anno 2070 give you access to an easy building-counting station. Apparently they decided that counting buildings manually was boring.

I'm going to pause here, because that last line is the crux of this entire entry. They decided that counting buildings manually was boring. Got a boring mechanic? Take it out! We don't want that here! Every time you get the player to stop doing something that's boring, the player will have more time and more intellect available for things that are interesting. Counting sucks -> get rid of counting.

But they didn't think that calculating building numbers was boring. Now, it's obvious I disagree with this assessment, but I strongly suspect this was an intentional choice of theirs. You can't spend 13 years developing a franchise based around an accidental game mechanic. They also don't seem to think that production numbers are something they need to show. It'd be easy enough for them to do so. As it is, a chunk of the Anno community spends time figuring out the actual production numbers, which the rest of the community embeds into utility programs and the like.

Counting isn't the only interface improvement in Anno 2070. I've mentioned "production buildings", but really there are two important and unique kinds of production buildings – factories and farms. Factories take up a fixed area of land. Farms include a farmhouse, which takes up a small area, and then some number of farm plots – frequently larger than the farmhouse, and always more numerous – which have to be near the farmhouse. Through sheer bulk, the farm plots end up dominating your industry in terms of size, and you spend a good deal of the game time trying to lay out farm plots efficiently.

In Anno 1404, this is somewhat difficult. Farmhouses have a circular zone that you can place plots within, and there's a bit of latitude in how far outside that zone the plots are allowed to go. However, if your farm plots go too far outside the farmhouse radius, they'll produce slightly less efficiently. Remember the mess up there about building production quantities? Imagine if a few of your hemp workshops were running at 90% efficiency. Yeah. You don't want that. To make it even more complicated, some of your farms need to be within range of a water-producing building, which has its own circular radius. To make it even more complicated, you get further bonuses by having overlapping water-producing buildings.

Anno 2070 simplifies things considerably. First, there's no longer such a thing as a water-producing building. Second, while the farm plots still have to be placed nearby, and while the latitude still exists, farm plots placed "close enough" count 100%. Always. You can still be clever and place plots slightly outside the circular range . . . and now that's totally okay! There's no downside! It's just a little extra flexibility you have with placement.

The important thing to realize about complexity is that it's not simply a matter of increasing or reducing complexity. We're not talking about making a decision between Cow Clicker and Paradox Interactive's insane wargame simulators. This is all a matter of moving complexity. I'm going to use the term "complexity budget" – you have only so much space for complexity (both in your game design, and in your poor player's brain) and you have to spend it wisely. Anno 2070 took some of the complexity out of farm placement, which meant they had complexity to spare, which meant they had complexity to spend. And spend it they did!

Anno 1404 has several farm variations. The most common farm is the one that has four 3×4 plots. Later, you find a farm with eight 2×3 plots, as well as the behemoth Cattle Farm that has five 4×4 plots. But that's as weird as it gets – with the exception of the eight 2×3 plot building, every farm has between three and five plots, sized between 3×3 and 4×4.

Anno 2070 goes absolutely insane with farm layouts. Early buildings have a mere two 3×4 plots. The Fruit Plantation has eight 3×3 plots. The Corn Farm requires nine 3×6 plots. 3×6? What the hell is 3×6? And nine of them? Meanwhile, the behemoth Dairy Farm has seven 5×5 plots, making it by far the largest and most irritating structure in the game.

This, right here, is what I mean by the complexity budget. Anno 1404 spent a bunch of complexity on the difficulty of placing farm plots correctly. Anno 2070 threw away that complexity and replaced it with the difficulty of aligning farm plots in efficient patterns. 2070's Dairy Farm would simply be a nightmare to deal with in the world of 1404. With 2070 logic, it's certainly challenging, but it's nowhere near as horrifying as it could be. Moving the complexity out of one area of the game allows you to move it into another area without actually making the game more difficult to deal with – and if you're clever, you've moved it into a more fun location.

2070 moves complexity around in a few other directions as well, though I'm going to go over these quickly. Compared to 1404's Patricians, 2070's Executives are easy to keep happy. The Patricians gain a whopping six new demands at the end of the game, while the Executives only acquire two. But while 1404 has two population types – one complicated type with four stages, one simpler type with two – 2070 has three population types, two with four stages and one with two. The end result is that you spend far less time clawing your way up through the final stage and far more time watching your population upgrade. If 2070's four-stage populations had the complexity of 1404's four-stage population it would just be intimidating.

Finally, 2070 does have a replacement for 1404's water mechanic, but it's a simpler island-wide mechanic. Instead of overlapping circular water radiuses, you can change the ecology of the entire island, anywhere from a polluted hellhole into a glorious green paradise. It's a heavier-weight mechanic – instead of being a little localized effect on certain farms that you can ignore if you don't care, it's something you can and probably will put a significant amount of effort into – but it also has big and, more importantly, predictable results. It's not quite as complicated and minmaxable as 1404's mechanic but it's a lot easier to understand and has simpler ramifications through your supply chain. Anno 2070's water mechanic is made a running theme of the story and set, with a large amount of documentation explaining exactly how it works, while 1404's water mechanic is so undocumented and unintuitive that it's considered by some people to be an exploit – the developers have never fixed it through several major patches and an entire expansion pack.

So. Summary: 2070 takes 1404 and makes incremental improvements to it. They moved complexity out of some mechanics (counting buildings, finicky farm plot placement, water, complex population end requirements) and were able to use that space to add new mechanics (complicated farms, ecology, third population type). The game doesn't feel any more complicated than it did before, but most people seem to feel it's more interesting. Without removing the old things, it may simply have felt overwhelming.

Right now, I think this entry has gone on long enough by far. But we're not done with this subject – oh no, we have quite a lot further to go. We'll be posting more later.