Old World Designer Notes #9: Events

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

After finishing Civ 3, I spent a long period of time engaged with the community to learn what they did and didn’t like about the game, with an eye towards the patches and a potential sequel down the road. In the modding community, a common complaint was that our editor lacked something called “events” from Civ 2, which I learned meant a system for connecting triggers and effects that could give games a narrative arc. I didn’t immediately grasp the potential of such a system until I tried out the community scenarios. I remember two that stood out to me because my actions pushed the story forward – one recreated the journey to Moria in Fellowship of the Ring and the other was a retelling of Odysseus’s Mediterranean wanderings in The Odyssey. Neither was particularly replayable, but they both were interesting because they had functional stories built from only a layer of events sitting on top of the base game.

For awhile, I wasn’t sure what to do with this discovery because I didn’t have a clear vision for how events could make a Civ game better, but I did ensure that our Python layer for Civ 4 had both triggers (calls from C++ to stub Python functions) and effects (the stub functions could change the game state). This system led to many interesting Civ 4 mods and scenarios as well as allowing the team to write a series of events for Beyond the Sword, many of which focused on natural disasters. While these events were a first for the series, it also represented a bit of an evolutionary dead end as they were not carried forward into Civ 5.

Nonetheless, I believed that events could play an interesting role in 4X gaming, and indeed noticed that many other strategy games, including the Galactic Civilization series, the Crusader Kings series, and Stellaris, were using them more and more frequently. However, my biggest inspiration came from the most text-heavy genre of them all – interactive fiction. The genre was experiencing a renaissance in the UK, led by Inkle (80 Days, the Sorcery series) and Failbetter (Fallen London, Sunless Sea), and I began to quietly haunt the GDC Narrative Summit while also interviewing the writer/designers for my podcast to see what I could learn. I also finally found a physical copy of King of Dragon Pass, a cult hit from the 90s that was still unavailable online, perhaps akin to finding a disc of The Velvet Underground’s Loaded before mp3s. The game was a wild mix of traditional 4X strategy, clan management simulation, and dynamic narrative built around random events that triggered based on hidden factors and which had unknown effects (but which the player would slowly learn to anticipate).

I began to appreciate how important narrative could be in a video game, how it could pull players into a game world much more effectively than by simply making numbers go up, a trick that was perhaps starting to get old in 4X gaming. To be clear, I had no interest in writing a story with imaginary characters and a beginning, middle, and end (Who did I think I was? A writer?!?), and I was also fairly uncomfortable with opaque triggers and effects which kept players in the dark, forcing them to play by feel. Transparency is an important part of my design aesthetic, and while it could be violated for effect occasionally, I didn’t want to build an entire system around it.

Perhaps unsurprisingly, inspiration came to me via board games, specifically Tales of the Arabian Nights, a brilliant adventure game built around the ancient folktales of the Middle East. The game comes with a giant storybook of over 2,000 events (some by Paul Murphy, writer on Civ 3, in fact) which are randomly drawn from a deck of cards and then cross-referenced with the character’s location, the player’s decision, and the roll of a dice. Although another player would read the event to create suspense and hide the outcome of the choices, the exact mechanics of how the game chose each event was transparent by necessity as the players did the work of finding each event themselves. The readers would see how the events were constructed and what would have happened if the active character possessed a certain trait, so that they in turn would anticipate the range of possibilities on their own turn.

The game had an interesting system for linking events via loose connections based on skills, traits, or treasures the character picked up over the course of the game. A character might become Ensorcelled early in the game, have the result of a later event change based on being Ensorcelled, and finally have the opportunity to remove the trait with a further event. None of these events were necessarily going to happen during a single playthrough and, often, potential narrative arcs were left dangling without resolution. Nonetheless, when a cohesive series of randomly chosen events do come together to tell a real story, it’s a magical feeling. What appealed to me about this system was that it was robust; there was no intricate event tree that could fail if one node was changed or stopped working. Furthermore, loosely coupled events could be written by a large group of authors who could work in parallel without close coordination. One writer might add an event which results in your leader becoming a Drunk, and a different writer could add an event that requires the leader to be a Drunk (or, if so, forces the player to take a certain option), and these two writers have now created a little story without having discussed anything. Indeed, they could have been working years apart and perhaps not even know each other. I am very excited for the potential of community event packs which can co-exist with our 3,000+ events (and with each other) to create new narrative possibilities.

Thus, I had the basic blueprint for an event system – it would be a virtual deck of event cards which each had a potential trigger (such as meeting a new nation), a set of requirements (a childless leader), and possible effects (a foreign spouse). When a trigger occurs, the game finds all events in the deck valid for the current game state and then chooses one randomly based on the weight, probability, and priority values of each event. The backbone of the event system are the subjects, which are a set of game objects randomly chosen for each potential event. Subjects can be anything from a character to a city to a family and even to a law or technology. Each subject can have multiple tests to find the perfect one – an adult child of the leader who is NOT the heir but IS a bloodthirsty schemer is a good example of a very specific subject that might mean bad things for the current heir. Further, the system can test for relationships between subjects, such as two nations that are at war with each other, the religion of your spouse, or a character who is vengeful against another. The event options can affect any of the subjects and can also be unlocked based on the current ratings or traits of the leader.

There are many other wrinkles to the system – for example, it is possible to link subjects together for multi-step events such as a duel – but this basic architecture enabled the writing team, led by Leyla Johnson, to create a wide variety of events that fundamentally change the flow of the game. Dynamic random events disrupt the steady flow of a 4X game, which can often devolve into deciding which bucket should fill up and at what speed. Perhaps an event provides a sudden burst of Orders that allows the player to move enough units to defend a city that was just about to fall. Or, perhaps sending one of your children out to explore the world leads to the founding of a new world religion. Or, perhaps a severe combat injury means that Alexander will need to abandon the field and become the Learned instead. A common theme of Old World’s design is avoiding predictable and boring games where the same actions lead to the same results, and the event system is an important tool to ensure no two games are ever the same.

Designer Notes #59: Andy Schatz – Part 1

In this episode, Soren interviews independent game developer Andy Schatz, who founded Pocketwatch Games and is best known for his work on Monaco and Tooth and Tail. This episode was recorded March 23, 2018. They discuss how he tried to live out Ultima’s virtues, why no one was ever able to rip-off The Sims, and why we both hate click-the-stick.

Games discussed: Ultima series, Minecraft, Halo, X-COM, Star Trek: Hidden Evil, Whacked!, The Sims, GoldenEye: Rogue Agent, Wildlife Tycoon: Venture Africa, Wildlife Tycoon: Venture Arctic, Monaco, Geometry Wars


Old World Designer Notes #8: Opinion

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

One of the defining features of 4X games with an Eternal China Syndrome is that the conflict primarily comes from external sources, from barbarians and rival nations. With certain random maps or diplomatic situations, players can often be in a position where they are largely unchallenged, and without any other pressure, the game slowly slides into auto-pilot. Old World addresses this problem by adding internal pressure from families and religions, each of which have their own opinion of you, just like a foreign power.

Making internal opinions matter requires a pair of mechanics – how the opinion is determined and how it affects the game. Designing the latter was the easier task as family opinions could simply affect cities and units if they each had a specific family type. Thus, each new city would be assigned a family, and units produced by that city would also be attached to that family. Then, each city and unit could get various bonuses and penalties depending on the opinion of the family itself. Cites belonging to a friendly family have reduced Maintenance, units of an angry family have a combat penalty, and so on. Perhaps most importantly for family opinions thematically, an unhappy family has a chance of producing rebel units which are capable of capturing cities if not defeated.

Attaching units to a family was a much debated topic as doing so made it even more difficult to differentiate units of each nation and tribe. There are only so many team colors available, and using a secondary color for families was only partially effective. Thus, we added a distinctive banner shape for each of the ten family classes and also did not show the family of opposing nations to simplify the mix of colors. Communicating family type is still difficult, but without assigning units to families, it would be impossible for family opinion to affect units, which risked dulling the entire system.

The trickier question is what should determine family opinion. Some modifiers were easy to add – families prefer having more cities, like having their cities closer together, like having members in the royal succession, and dislike having cities with high discontent. However, to keep things understandable, we didn’t want to add too many modifiers, so we split them up between the different family classes, which also added to their flavor: Champions prefer having the largest army, Clerics dislike cities without a religion, Patrons like having cities with Wonders, etc. A diversity of family opinion modifiers also makes it more likely that each family will have a different opinion of you, which makes for more interesting gameplay as angry families could become jealous of pleased ones, fertile ground for the game’s dynamic events.

However, although families now had opinions with inputs and outputs, the system felt very abstract; it’s harder to relate to a family than to a specific character. Further, we had a separate problem that although characters had opinions of you, the opinions didn’t seem to matter all that much unless they were in the court. We addressed both problems by creating family heads whose opinions were directly applied to their family’s opinion – if the head had a +100 opinion of you, then his or her family’s opinion would be modified by +100. Now, if a player wanted to change relations with a family, all game systems that involved a character’s opinion could now apply; for example, the player could improve relations with a family by conducting an Influence mission with the family’s head. Conversely, the event system could give an option that might offend the family’s head which would then reduce the family’s opinion.

Another important vector for family opinion would be religion. Characters adopt religions local to their family’s cities, and once enough family members follow the same one, a family officially adopts that religion. After that happens, the religion’s opinion is applied directly to the family’s opinion, so now all missions and events affecting a religion could also potentially affect a family. I added religion to Civ 4 primarily to create a reason why one rival nation would like you and another one wouldn’t. Religion serves a similar purpose in Old World, except that it now applies to tribes and families as well. Religions also have heads that work similarly to the heads of families; the opinion of the head would be applied directly to the opinion of the religion, which would then be applied directly to the opinion of nations, tribes, and families that follow that religion. Thus, religion heads are very important characters that touch multiple levels of the world, a new way that a character’s opinion could matter.

I began to use a river network as a metaphor to describe how opinion flowed throughout the game. More specifically, opinion only ever flows in one direction, a fact I discovered when the game crashed after a character’s opinion boosted their religion’s opinion which then boosted their family’s opinion which then affected the original character and continued in an infinite loop. Thus, character opinion flows into nations, tribes, families, and religions, and religion opinion flows into nations, tribes, and families, but the opinions never flow in the opposite direction. Understanding this flow is key to learning who to favor and who to ignore, which is important for keeping families happy. Further, putting characters at the origin of the river keeps the opinion system inherently fluid and dynamic as fortune’s wheel has its way with the people of Old World.

Old World Designer Notes #7: Characters

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

Veterans of Civ communities will recognize the acronym ICS (Infinite City Sleaze) as it has haunted the series since the beginning. However, there is another acronym that is less recognized but just as big a problem and, frankly, a lot harder to solve – ECS, which stands for Eternal China Syndrome. The term refers to the tendency of nations that have gotten over the hump of early expansion to maintain a level of internal stability that is both ahistorical and, more importantly, not much fun. (Of course, students of Chinese history will know that the term is an exaggeration of the country’s actual internal stability.) Most of the pressure applied to the player in Civ comes from external sources, meaning other nations, and the internal pressures (including unhappiness) are really just different flavors of taxes. Furthermore, although new abilities and powers are unlocked throughout the game (via laws or techs or Wonders), they are accretive, meaning that they are only given to the player, never taken away. Strategy games are built from players adapting to their current situation and making difficult decisions along the way, but in most 4X games, these decisions are front-loaded to the initial exploration and expansion phases. Once stability sets in, the path ahead for the player becomes very predictable, which is an important reason why 4X games become such slogs – the path to the victory (or defeat) gets more and more predictable the longer a game continues.

Characters were not introduced to Old World to alleviate ECS; they were added simply because more and more games (Crusader Kings being the obvious example) were adding characters in meaningful ways and, in doing so, appealing to larger and larger audiences. Turns out that people like playing games that are about people, and a game that lasts 6,000 years is more about gods than humans. The benefits of adding characters to Old World could be spun out into multiple new articles, but to some extent, the lessons learned are not particularly interesting as the benefits were largely free, a simple result of human empathy and vengeance, of our sympathy and our avarice. Adding flesh-and-blood humans to a game is somewhat akin to adding realistic physics; it adds instant depth, but the depth is going to be the same across all games that do a good job representing the human condition. I’ll do my best to avoid getting carried away here and not end up quoting Anna Karenina and simply move on to how adding real characters improves the core 4X gameplay.

Simply put, characters add a dynamism to Old World that prevents it from reaching ECS, the usual fate of most 4X games. The most obvious way characters disrupt the game’s stability is via diplomacy. Simply having foreign leaders actually change – from death or abdication or even deposition – over the course of the game makes a huge difference. Perhaps you have a great relationship with Phillip of Greece but not so much with his heir, Alexander, because you offended him at a dinner years before? The latter’s eventual ascension (unless, say, some unfortunate accident might come to pass) will mean that your diplomatic status with Greece could go from good to bad. The amazing thing about this outcome is that it flows completely naturally from having real characters who age and die; players aren’t shocked when relations change and, indeed, expect them to change.

It is hard to articulate how significant a departure this is from a tension that has always bedeviled Civ games – that players expect diplomacy to be predictable, but predictable diplomacy inevitably becomes boring. Players will frequently rant over “unpredictable” or “random” AI leaders who suddenly go from being a friend to an enemy. These shifts are necessary for games to not slowly calcify from their earliest diplomatic states, but there are few ways to make these changes thematically palatable when the leaders never change. Civ games have experimented with all sorts of opinion modifiers that give a reason why a leader might change their opinion of you, but the most natural reason is that there is now simply a new leader who has a new set of relationships, memories, and opinions.

However, the biggest gains for dynamism are not external (like diplomacy) but internal, changing how your own nation works. As mentioned previously, one problem with unlocking powers over the course of a 4X game is that they tend to be accretive, a nation slowly adds new and better abilities over the course of the game. Players don’t like losing their powers, and Civ has only dabbled with this, such as the Civ 4 civics system where a player might give up one power but only to unlock a better one. When powers are accretive, designers have to be careful not to make them too strong, or else they could dominate. Give the player a giant hammer too early, and the rest of the game is a nail.

Instead, what if powers were attached to leaders via their unique archetypes, and these powers disappear when the leader dies? Then, the powers can change how the game works significantly but not permanently – for example, Builder leaders can add new Urban tiles to cities, Orators can hire Tribal troops as Mercenaries with Legitimacy, Heroes can Launch Offensives to allow units to attack twice, and Tactician Leaders can Stun their targets as Generals. Each of these powers fundamentally changes how the game feels, but attaching them to the Leader’s archetype means that each power is mutually exclusive and will be active less than 10% of the time. (There are ten archetypes, and young leaders don’t always even have archetypes.) Further, because these powers are attached to characters, players don’t have complete control over when these powers are turned on and off. If they were attached to Laws, for example, players might abuse the ability to switch between them whenever desired. Instead, players have some, but not total, control over the archetype of their heirs and have to navigate the natural flow of their dynasty. They can still make long-term plans for when their current Builder leader is succeeded by his Hero daughter, but they can’t pick the same pattern, game after game.

Perhaps the best thing about all of these new dynamic elements that flow from characters is that they are simply a natural extension of human nature and regular lifespans, of which all players bring an understanding to the game. For example, if a game spanning 6,000 years tried to implement our archetype system, it would need to tie itself into knots justifying why these powers are constantly changing, why the player doesn’t always have control of them, and why they are all available and viable at both the beginning and the end of the game. A game’s theme has its own gravity which puts limits on where the design can reach, and games about people provide natural affordances for an environment that is constantly changing, always a good thing for a strategy game.

Old World Designer Notes #6: Citizens and Specialists

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

The first Civilization game was like a game design thunderbolt, sent from the heavens and marking everything it touched. Although the game does have antecedents, it is not unreasonable to split a history of digital strategy games into those made before Civ and those made afterwards. Working to extend the franchise across multiple games was an intimidating task because the original cast such a large shadow. “Whatever I do,” thought many a Civ designer, including myself, “I better not screw this thing up!” It took many iterations of the game before designers realized that there wasn’t a single magic number or formula inside the game without which the whole thing would unravel. Indeed, the basic thematic gameplay of Civ has been remarkably resilient across six major iterations with countless interesting detours, cul-de-sacs, and dead ends. Almost every aspect of the original has been taken apart and put back together again, and the franchise keeps on ticking, easily the longest-thriving strategy franchise of all time.

With that preamble done and due praise given, it is all the more remarkable that one bad game mechanic has been preserved from version to version, tweaked perhaps, adjusted at times, but still as clumsy, fiddly, and unnecessary in 2021 as it was in 1991 – the system of placing citizens on tiles. In Civilization, each tile inside a city’s territory is completely useless without placing a citizen on that tile. This is not a particularly interesting or engaging choice – it is usually obvious which tiles are optimal, and the player can at best get maybe a little extra growth or production or money if they spend some time micromanaging the tiles. Indeed, “micromanaging” is perhaps too generous a term – tweaking or fiddling or even futzing with them is more accurate. There is no in-game cost to moving each citizen in each of your cities every turn to eek out a tiny 1% efficiency gain; the only cost is the player’s time and patience. Within the overall design, citizen management is completely unrivaled for the least amount of benefit for the most amount of time spent (which is a simple shorthand for being the least amount of fun).

One can tell that Civ’s designers have never been enthralled with the system. Even in the original, the citizen system is buried deep away within the opaque and intimidating city screen. (A fellow Civ developer once quipped to me that the best feature of the original city screen is that it disappeared almost anywhere you clicked on it.) One could finish (and win) an entire game of Civ without ever engaging with or even understanding it. In later versions, the designers encouraged the player to use the city governors to set “priorities” that determined how the AI would place the citizens for you – a telltale sign of poor game design is the inevitable addition of an AI to play the game for you.

Furthermore, if the system was bad for casual players, it was actually worse for the hardcore. By Civ 3, veterans had mastered the art of rearranging citizens each turn to avoid wasting a drop of growth or production. If a Warrior cost 10 hammers, and a city produced 7 hammers a turn, then 4 hammers would get wasted every turn the city produced a Warrior (because 7 + 7 = 14, and the 4 extra hammers were thrown away). Thus, the optimal player would remember to visit their city every turn to switch the citizens around to alternate between 7 hammers and 3 hammers with more growth or money. Civ 4’s citizen management code minimized this type of micromanagement; instead of throwing away the extra hammers, the game applied them to the next item being produced. Of course, new forms of micromanagement sprung up in different places, all in the service of a system which had never delivered much enjoyment in the first place.

I was already not a fan of citizens by the time of Civ 4, and the earliest members of the Frankenstein testing group may remember an odd version of the game where there was no citizen placement. Instead, cities got yields from all tiles within their borders and higher yields still if the tiles had improvements like Mines and Farms. The change removed the awkwardness of citizen placement, but it couldn’t work without other major changes to the game. The rest of Civ’s basic plumbing (how cities grow, how units are produced, where money comes from, etc.) was built to work with the citizen system, and so it could not just be removed without causing the rest of the game to break. At a minimum, Civ 4 would need a resource stockpile system so that, for example, cities full of mines would send all the excess output to an iron stockpile instead of spitting out a new unit each turn.

However, designing Old World meant that I definitely would get a chance to build the system from scratch – this time without putting citizens on tiles! Because rural improvements like farms and mines always contributed to the national stockpile, I didn’t need to worry about a city that was overloaded with a specific type of improvement. I just needed to make sure the improvements couldn’t be built so quickly that the math became exponential. The Orders system helped out here in multiple ways. First, although players could perhaps build a ton of Workers to mass produce improvements, they might not have the Orders necessary to keep them all working, especially if wars flare up, either with tribes or other nations. Further, because the number of moves in an average turn of Old World is more consistent than in Civ (with more Orders than units early and less Orders than units later), the game has less early “dead” turns with little activity. Thus, the total number of turns in a game of Old World is much fewer than in a game of Civ, making exponential math much less dangerous. Finally, although we experimented with having cities produce improvements directly on the map, we found that tying them to Workers, which build them by spending one Order a turn over multiple turns, both made guns-or-butter work and also delayed improvement construction enough to prevent a runaway economy.

On the other hand, one original piece of logic behind citizen tile placement was that it required cities to maintain a balance between improvements and growth – building more improvements than citizens had no value because no one was there to work the new Mines and Farms. This part of the system had merit to it; balancing multiple vectors that limit each other is solid game design. I felt we could recreate this dynamic without the fussiness of citizen management by allowing cities to upgrade citizens into permanent specialists for an improvement that exists on a specific tile. We would maintain the basic idea behind citizen tile placement (put an unused citizen onto a specific tile) but as a permanent decision with a one-time cost. In other words, the player makes an intentional choice to boost a tile’s output with a citizen, but because the choice is not reversible, the micromanagement is now gone.

The tricky part was determining how MUCH a specialist should boost an improvement. Initially, I thought that we should largely duplicate the basic economy of Civ, so that an empty improvement would barely produce anything, but it was hard to get the game to scale well that way. The player would start with so little production early on that we had to lower the costs of everything, which became a big problem later on when players turned the corner and started producing far more than they could spend. The system would only work with inflating prices, which would add a heavy dose of black box complexity.

Instead, we increased base improvement production and reduced the boost from specialists to either 50% or 100%. This change got the math right for empty improvements but now specialists were no longer worth the investment (when compared with just adding new improvements). We added some Science output to each specialist (which is a good thematic match), but it still wasn’t quite enough to make specialists worth producing.

I used this opportunity to fix a couple other problems with the design. Players had complained that cities were too similar to each other, which was certainly a problem with yields coming less from the terrain itself, as with Civ. Thus, we attached four important city yields to each of the four core rural specialists – Farmers would produce Growth, Miners produce Training, Stonecutters produce Civics, and Woodcutters produce Science. (Cutting down trees produces Science because of, um, paper? Not all at because I had an extra yield in search of an extra specialist.) Now, cities would be differentiated by their specialists which were a result of their improvements which would largely be determined by their terrain, getting us back to how terrain leads to city specialization in Civ. It took some time to isolate the positive features of citizen placement and then port them back into Old World, but it’s nice to know that maybe citizens did serve a purpose back in 1991 after all.

Old World Designer Notes #5: Yields

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

Old World has a lot of different currencies (referred to in-game as “yields”), which represent things very concrete (Iron), somewhat vague (Orders), and VERY abstract (Civics). All of these yields are produced differently, are used for different purposes, and are stored (or not) in a few different ways. There are 13 distinct yields in Old World, a lot more than in most 4X games (although perhaps coincidentally equal to the exact number of resources in Offworld Trading Company). Indeed, the game used to have three more – Horses, Happiness, and Inspiration – so clearly we weren’t afraid of multiple currencies! Why so many?

To start, we needed some new yields because we adopted resource stockpiles, which are a transparent way to differentiate unit and improvement production. We believe strategy games are most fun when the player is adapting their play to the map, and having a variety of yields produced from rural improvements (in our class, the classic Age of Empires quartet of Food, Iron, Stone, and Wood) gives players lots of reasons to adapt their plans. Maybe a player normally trains Archers by spending Wood but starts one game a long distance from any forests, so adapting to a new strategy would be best. Further, just as Orders make each move more interesting, giving a yield stockpile cost to actions that were free before, like building a Temple with Stone or training a Swordsman with Iron, makes them also more interesting, giving the player a reason to choose different options depending on the current situation.

In contrast, Civ has relied on a much more abstract model that shifts around from game to game. In Civs 1 & 2, resources like Iron and Stone were turned into generic “production” which just determines how fast anything can be built. Civs 3 & 4 made resources national booleans which turned certain units on or off (no Chariots without Horses). Civs 5 & 6 went further by allowing only X units per resource. (Only Gathering Storm added a true stockpile.) These systems avoided a stockpile model because it felt too awkward in a game about all of world history. Old World can get away with just Food, Iron, Stone, and Wood because they will all be relevant throughout the game. Civ needs to make Iron and Copper and Horses matter but also Saltpeter and Oil and Rubber. Keeping the list from exploding (and minimizing obsolete entries) was certainly a fear I had as a designer.

However, for Old World, the question arises of what should happen if the player has an empty stockpile. If they only have Stone and nothing else, have we taken away the player’s agency by limiting them to a fraction of their build choices? The solution was adopting the free market system from Offworld Trading Company, which gives players the flexibility to buy and sell their stockpiles as needed although often at the cost of inefficiency. Indeed, the system is much closer to the market of Age of Empires, which always maintained a buy price twice as high as the sell price to represent this inefficiency. Collapsing these two prices into one was a key moment in the design of Offworld that made the game so fluid, but the priority in Old World was making market an option only when necessary, so we discouraged its overuse with separate buy and sell prices. Once the market system prevented the game from stalling out, stockpiles could become the core of the economy, so that almost everything would cost something, from 20 Wood for a Farm to 1800 Stone for The Hagia Sophia. (An important exception was Workers, who have no cost, so that a downward spiraling economy could still be saved by switching to producing Workers who can even harvest outside of their territory.)

The next question about yields was what cities should produce themselves. Some yields didn’t need huge revisions (Science, Money, and Maintenance still work like they mostly always have), but others required more work. Culture started out exactly as it had been since Civ 3 by determining how fast borders would grow. This mechanic was eventually dropped to make border growth completely driven by player actions, and a new one replaced it as the primary role of Culture. I’ve often found that players enjoy discrete, chunky levels more than bars that fill up indefinitely, so I defined four successive Culture levels that a city would go through – Weak, Developing, Strong, and Legendary – with each requiring significantly more Culture to attain than the last. The next step was to attach effects to these different levels so that Culture would matter. A simple one was assigning more Victory Points to higher levels of Culture, which was a great way to show that a small highly cultured nation could be as valuable as a large uncultured one. Making all types of production hurrying require Developing Culture was an effective way to differentiate newly founded cities from your cultured core.

I also gave each Wonder a specific Culture prerequisite (for example, The Pantheon requires Legendary Culture), which creates an orthogonal way to progress outside of the tech tree. I had never liked having Wonders on the tech tree – they clog up the nodes with unlocks that are definitely less valuable than a new unit or improvement. Taking them off the tree also allowed a random subset of Wonders to be available each game, a great feature if we ever double the number of Wonders but don’t want to overwhelm the player. Seeing how well Culture worked for Wonders inspired us to try the same thing with most of the urban improvements, so that while you may only need Citizenship to unlock Courthouses, you will need a Strong city for a Ministry, and a Legendary city for a Palace. This hybrid approach allowed us to add new improvements to the game without having to add a bunch of new techs which would just unlock better versions of an improvement you already had. Attaching unique units to higher-level improvements also got these units off of the tech tree and onto this orthogonal path. A cultured Greece could build Hoplites without ever unlocking Spearmen as a completely alternate path through the game.

Discontent, on the other hand, was a necessary evil that I often had to remind myself was actually necessary as no one ever said that the best part of Old World is the Discontent. Ultimately, the game needs some way to push back on the player to keep positive feedback loops from snowballing too much. (Maintenance, unit consumption, and law upkeep all exist to keep inflation in check, for example.) Further, the era would not feel right without some sense of anger at the ruler; simply put, the bread-and-circuses need a reason to exist. The event system would be a lot harder to write without options to either please or upset the people.

However, I wanted to be careful to avoid one dynamic I’ve seen over and over with other 4X games; I didn’t want Discontent to just be an inevitable side effect of Growth, of larger cities and more citizens. Thus, Discontent is largely disconnected from how fast your cities grow, so players are not tempted to manipulate their Growth to keep their cities happy. Hurrying production with citizens would no longer be a bizarre path to making people happier. Finally, just like Culture, Discontent levels up each time the bar fills, with each level having a higher set of negative modifiers, each step a powerful motivator. I might let my leader become Cowardly to placate a mob, especially if Discontent drops a level or two.

I also wanted to differentiate cities more by splitting “production” into Growth, Civics, and Training. Growth is functionally similar to Food in previous Civs as it determines the rate a City produces new citizens (although it is also the production yield for civilian units like Settlers and Scouts). Civics and Training, however, come from splitting the old production/shields/hammers of Civ into two different yields – Training, which is used for military units, and Civics, which is used for specialists (upgraded citizens attached to tile improvements) and projects (akin to city-based improvements in Civ). By making city Growth separate from the global Food stockpile and differentiating Training and Civics, we enabled more options for city specialization, making military powerhouse cities specializing in Training more distinct from those able to crank out the Settlers with Growth.

To make this system work, of course, we would need many ways to focus on one yield over another, ideally based on adapting to the map. Thus, Growth comes from Farmer specialists, Training from Miners, and Civics from Stonecutters, so cities which specialize in various improvements (which the game encourages via adjacency bonuses and governor traits) will naturally end up specializing in one of these three yields. Many of the Families also add a significant amount of Growth, Training, or Civics to their cities as do the Discipline, Courage, and Charisma ratings of the governors.

As the stockpile of physical yields was successful and being inspired by the stockpiling of Science and Culture in Through the Ages, I decided to stockpile Civics and Training as well, which answered the question of what should happen with a city’s yields when not being used for production. Unused Growth went into making more citizens, so it felt strange that unused Civics and Training would just disappear. I didn’t necessarily know what the Training and Civics would be used for but was confident that we would figure something out along the way. Some uses were pretty obvious, such as laws and theologies for Civics and unit promotions and upgrades for Training, but other uses became clear when we needed to solve other problems. Wonders felt more grand, more of an accomplishment, once they required Civics, a yield which could NOT be bought on the open market. Training became the limitation making Force March a powerful tool but also one which could only be used occasionally. Tying governors and generals to Civics and Training solved the problem of how often we should prompt the player to fill an empty slot; because of the cost, adding one wasn’t an automatic decision that players would be frustrated to miss. Both yields were also useful for differentiating mission costs – asking Persia for a truce would cost Civics while asking the Gauls would cost Training.

Finally, our event system became quite powerful over the course of development, and the number of currencies gave us the knobs necessary to write 3,000 distinct events. Maybe the player would choose between Money and Training, between Stone and Science, between Growth and Orders, or between Culture and Discontent. These choices could even be between nations – send Carthage X Science per turn if they send back Y Training in return. From the code’s perspective, these yields are simply different flavors of the same thing (each one is just a separate entry in yield.xml), but they feel like a choice between apples and oranges, which is ideal because that forces players to make decisions with their gut instead of with their calculator.

Old World Designer Notes #4: The Technology Deck

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

The technology tree was one of the great innovations of the original Civilization, without echoes in Empire or other proto-4X games. (Interestingly, the closest parallel is probably the technology card discounts in the Avalon Hill Civilization board game, which Sid has always maintained was not a big influence on him. Bruce Shelley certainly would have been familiar with it, and a great piece of Civ trivia is that the artist of the original Avalon Hill technology cards, released a decade before Sid’s Civilization, was none other than Brian Reynold’s uncle!) The tech tree was a perfect bit of game design, especially if the goal was clarity. It was always abundantly clear how to discover Gunpowder if you wanted to build Musketeers.

Of course, every piece of game design is a set of trade-offs, and one of the trade-offs that the traditional tech tree made in the name of clarity was determinism. As everyone knew the path to Gunpowder, it was very easy to remember the exact order of the ten techs which led to Gunpowder so that the player could get to it as early as possible. If this strategy turned out to be optimal, then a veteran player would find themselves making the same choices, game after game after game. Indeed, many versions of Civ made this even easier for the player by allowing them to target a specific tech and then highlighting the right choice each time it came up.

In fact, Sid anticipated this problem from the beginning as the technologies presented to the player in Civ 1 were a random subset of the ones available. However, because this version had no in-game UI and because the tech tree itself was so new, players didn’t give this randomness much thought, especially when it was dropped quietly in later versions. Giving players a random subset of tech choices did solve the basic problem but was perhaps an inelegant way of addressing it. The ideal solution would force players to make difficult choices while also being transparent about why the player couldn’t choose from all the valid options.

The answer came from borrowing mechanics from deck-building board games, first popularized by Dominion in 2008, which made shuffling, drawing, and discarding cards an important part of gameplay. For Old World, each tech would be represented by a card, and the player would choose a tech by taking four cards from the current draw pile, choosing one, and discarding the rest. The discarded techs would not be seen by the player again until the next time they would be shuffled through the deck, guaranteeing difficult decisions. Deciding between Forestry and Labor Force becomes more meaningful because the technology that you don’t pick will not be available until it passes through the discard pile, gets shuffled into the next draw pile, and is eventually drawn back into your hand, which could require researching 3 or 4 other techs first. The player can follow the path of each card through the different piles to know exactly when it might next be available and what the odds are of drawing it. Thus, there is no longer a golden path through the tech tree, each individual choice is more meaningful because of discarding, and the whole system is completely transparent to the player.

As is often the case with new game systems, making one change often opens up new possibilities that didn’t make sense beforehand. Turning techs into cards is a good example of this phenomenon because once we had the card metaphor, we could shuffle other cards into the deck which were NOT technologies but could still be unlocked the same way techs would be. Thus, we added “bonus” cards to our tech system, which could be researched just like regular techs but would provide a one-time bonus instead, like a free Settler, a Great Scientist, or a boost of Stone. The bonus cards would only be available once for the player, so they would be, using the terminology of deck-builders, trashed instead of discarded because we didn’t want to clog up the deck with bonus cards for players who preferred to focus on just standard technologies. These cards added a nice apples-to-oranges comparison for players to make – take the short-term bonus (a free archer right now) or the long-term option (unlock Lumbermills to produce Wood to build multiple Archers). Strategy games benefit a great deal from borrowing mechanical metaphors from physical board games – not only do many players already bring an understanding of the system with them but the physical roots of the mechanics also make them inherently easier to explain on the interface.

Old World Designer Notes #3: One Unit per Tile

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

The big change that always gets mentioned when going from Civ 4 to Civ 5 is one-unit-per-tile (1UPT), which is interesting as 1UPT is purely a mechanical – as opposed to thematic – change. (The introduction of religion in Civ 4 or city states in Civ 5 would be examples of thematic changes.) The change was intended not to make the role of combat different in the game but to make it more interesting. Jon Shafer, Civ 5’s lead designer, was inspired by turn-based games, such as Panzer General which were laser-focused on combat mechanics and benefited from the visual transparency of no stacking.

(Many of these tactical games also used hexes – clearly superior to squares from a tactical perspective – which helped the series finally adopt them. I had considered hexes for Civ 4 but held back from a long-held prejudice inside Firaxis that hexes would scare off mainstream gamers. Indeed, many have commented that Civ 5 finally made hexes safe for video games. I was content to move Civ 4 back to a top-down chess-board grid and away from the visually misleading isometric squares of Civs 2-3, where horizontal and vertical distances were separated by a factor of two.)

Generally speaking, opinions were divided over (although largely in favor of) the success of one-unit-per-tile. Most felt that 1UPT did increase tactical depth but many others began complaining about the “carpet-of-doom” which dulled potential depth by filling the world with so many units that simple movement became difficult. The term carpet-of-doom is an ironic reference to the “stacks-of-doom” of Civ 4 where an AI could invade with 20+ units stacked on a single tile. Few people called for the return of stacks-of-doom, but critics pointed out that carpets-of-doom were just as bad.

I watched the debate with interest, glad perhaps that it wasn’t my problem to solve this time. I felt that Jon had made the right choice with a radical change to the combat system – each new Civ needs to give itself a fundamental reason to exist – and I also wasn’t surprised that it was not necessarily an easy process. From my own experience, I felt that the main issue with 1UPT in Civ 5 was limited unit mobility and a lack of space between cities for maneuvering. Tactics-focused games like Panzer General tended to have a preset number of units which were chosen to fit the size of the map, a design luxury not available in a 500-turn 4X game where a dedicated player could have hundreds of units by the end of the game.

Although I saw that Civ 5’s 1UPT had become the mainstream conception of a tile-based 4X game, Old World actually went through roughly a year of development WITH stacked units. Early on, the simplest way to prototype the game was to maintain a strict 1UPT rule (as stacking has the major downside of making the UI much more complicated). However, I knew that at some point we would need to experiment with stacking to at least allow military and civilian units to share the same tile. (Civ 5 & 6 both allowed a military and a civilian unit to share the same tile, and everyone in the world considered that a good thing, a rare moment for game development!) So, when I added the code to allow multiple units per tile, I decided to try to find a happy medium between encouraging 1UPT in practice while allowing stacks when necessary for managing large armies.

My theory was that if stacking was possible but also potentially very dangerous, Old World would have the benefits of both systems. Thus, our movement system allowed infinite stacking, but the cost would be that, when attacked, every unit in the stack would be damaged just as if it was the primary defender in non-1UPT Civ games. There would be no “top unit” which would shield the units underneath it from damage. This system fit very well with the lack of defensive retaliation in Old World – attacking a tile only damaged the unit on the tile, so attacking a stack meant damaging every unit in the stack.

In practice, the system worked great. Players generally kept one unit on a tile, both to avoid suffering extra damage as a defending stack and to maximize the number of tiles covered by Zones-of-Control. Plus, players often faced an interesting decision during combat when deciding whether to stack an extra unit onto a tile to get a second attack, especially if they needed the extra attack to kill the defender. Doing so would be very tempting, but the cost would be exposing stacked units to multiple hits per attack during the enemy’s turn. Tempting players to make an impulsive decision for a short-term gain but at the risk of a bigger loss later is solid game design. I had cracked the problem of how to combine the tactics of 1UPT with the convenience of stacking. I was very pleased with myself!

The only problem was that I seemed to be the only one who was pleased. The rest of the team ranged from tolerance of the system to subdued hostility. In due course, another mutinous mod appeared (see the section on Orders). I agreed to give it a try, and to my surprise, I sort of seemed to prefer the simplicity of 1UPT. Unlike the rest of my writing on Old World’s design, I’m not sure I can quite articulate why 1UPT worked better than the stacking system I had implemented. I can still explain what was great about giving the players a reason to stack and a reason not to. Look at the interesting decisions! Marvel at the trade-offs! (I am reminded of Sid joking that the way to respond to negative feedback is to explain to players that “You just didn’t know you were having fun!”) In reality, I had bumbled into the best system for Old World with some strong encouragement from the team.

The simplest explanation for why 1UPT works in Old World is that it‘s actually a perfect fit for the game’s unusual combat system, which splits combat resolution across multiple turns by requiring multiple attacks to kill a unit and minimizing retaliation damage from the defender. Allowing a strong defender to damage an attacker significantly was never going to work with this system because doing so is akin to giving the defender a free attack on the attacker’s turn (and without spending an Order). Defenders always tend to be at an inherent advantage, both in real life and in strategy games, so anything that boosted their advantage even more would be a mistake. At its best, the lack of retaliation damage pushes players to go on offense, to take risks, to take an active role in combat, which is inherently more fun. A game where you take an active role killing enemies is much more engaging than one where the AI annihilates itself against your stationary defenders.

Because Old World expects combat to last multiple turns, allowing the player to overload a combat front with extra attacks (via stacking) was sapping away an important part of our unique combat system. Counter-attacks (and retreats) are meant to happen during the other player’s turn, and giving the player more opportunities to focus fire via stacking to kill a unit short-circuited that dynamic. 1UPT has multiple other advantages over stacking (including a cleaner UI, more cohesive fronts, and simpler combat rules), and we never looked back after re-implementing it.

In many ways, the Orders system, limited city sites, and one-unit-per-tile all need to be viewed as part of a single holistic system where each part buttresses the other. The enforced distances between city sites ensure that there is enough space between each city for a battle to be fought, instead of ICS-style cities inconveniently clogging up the battle lines. The Orders system prevents 1UPT traffic jams because the game allows a unit to make multiple moves with a single click and to covertly stack on another unit as long as it’s not the final destination. (Civs 5 & 6 do the same thing by allowing units to pass through each other, but because they are still limited to one move per turn, the feature is of limited use.) 1UPT, on the other hand, helps balance some of the extremities of the Orders system by making it more difficult to kill a unit via stacking. Each system cannot be viewed in a vacuum, and debates over the costs and benefits of each need to be made within the context of the game as a whole.

Old World Designer Notes #2: City Sites

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

One challenge that has haunted all Civilization games since the beginning is Infinite City Sleaze (ICS). In the original version, one player discovered that the optimum strategy was to cover every fourth tile on the board with a city, a mind-numbingly boring strategy that was always the best choice. Most players did not go that far, but they usually realized that more cities was always better, and because the game had very loose rules for city placement, squeezing cities into every possible crack became a typical strategy. Every Civ after the second tried a different strategy to stop ICS – Civ 3 used corruption and waste to make extra cities less valuable, Civ 4 used maintenance to make new cities an economic drain, Civ 5 used global unhappiness to make a large empire harder to manage, and so on. None of these systems were any fun and weren’t intended to be so; they were mechanics put in place to keep the players from ruining the game for themselves by founding too many cities just because it was simply the most effective strategy.

The issue is not that the player shouldn’t have a large empire, meaning one that covers a large portion of the map. Instead, the issue is that the player benefits from packing more cities into the same number of tiles and so bends their strategy to squeeze in as many cities as possible. In an empire-building game, more territory should be good, but more cities just for the sake of more cities simply adds busywork and frustration. Ultimately, there is no actual solution to this dilemma as all of the attempted fixes just slow the player down in unpleasant ways but the same truth remains – more cities are still always better. Indeed, it becomes a little perverse to try to reverse this dynamic; why make a game about building an empire where the player is punished for building an empire?

The answer, frankly, has been around for almost as long as the 4X genre. Master of Orion, the first sci-fi successor to Civ, does not have an ICS problem because the player is strictly limited to the number of planets on the map. The gameplay is simply better without putting artificial brakes on the player for fear of them ruining the game for themselves. Limiting city counts has many gameplay benefits, such as more predictable victory point thresholds based on cities, better balanced per-city bonuses, more consistent city value weights for the AI, and a generous minimum distance between cities to allow breathing room for one-unit-per-tile combat. Endless Legend adopted the same system in a tile-based game by slicing the world up into a series of territories, with only one city possible in each one. I actually tried a similar system while prototyping Civilization 3 but didn’t feel comfortable that we were predetermining what the borders of a city would be before actually founding the city. I wanted city borders to still grow organically based on player choice, even at the risk of still enabling ICS.

For Old World, we finally found a happy medium between a limited city count and dynamic border growth. City sites are placed on the map at game start, but the actual territory of each city is based on decisions the player makes. Namely, building an urban improvement and producing a specialist on any tile extend the city borders in all six directions. Further, a few buildings (Hamlets, Shrines, and Monasteries) are notable because they are urban improvements which can be built anywhere, giving the player a number of ways to extend a city’s border in a specific direction.

Thus, city borders always extend out from the initial city site but only based on decisions made by the player. The range-based culture growth of Civs 34 and the random tiles of Civs 56 got the job done but generally were disconnected from the player’s actions. The core hook of a 4X is long-term planning, and putting border growth in the player’s hands is a perfect fit. We had gone with the Civ 56 random tile system for a long time, but players were generally unhappy with it until we gave them full control. The algorithm could never consistently find the tile they actually wanted for their city, which was perhaps a good thing because it wouldn’t be a strategy game if it was always clear what next tile would be best. (The old border growth algorithm is still inside the code as it gets used for events and with the Borders Boost tech card.)

It is also worth noting that although a city’s territory is built dynamically, unlike being predetermined as in Endless Legend, each tile is still associated with a specific city, opening up new gameplay options not available in games without territories. For example, a Governor can have a trait like Delver which affects all Mines and Quarries in the city’s borders. Further, tying tiles to cities is an important tool for the family system – the Artisans, for example, only care about pillaged tiles in their own territory, highlighting their sometimes myopic perspective.  Finally, because tribal settlements also block most city sites, taking them for expansion becomes a dramatic moment in the game, part of a multi-turn plan instead of simply plopping down a new city every time a Settler is built.

I was well aware that the city sites of Old World would be a controversial feature. City placement is one of the great puzzles that players love to debate and analyze – the Civ community has a tradition of posting “dot maps” to compare different potential city arrangements for each random map, but sometimes in game development, it’s necessary to abandon a positive feature that players enjoy for the overall good of the design. Old World has a much sturdier core – and far fewer annoying anti-expansion mechanics – because of city sites.

Old World Designer Notes #1: Orders

The following is an excerpt from the Designer Notes for Old World. The game, a historical 4X set in classical antiquity, released on July 1, 2021, and is available for purchase here.

I’m not sure where the idea that every game piece should be able to move exactly once per turn first originated. I suspect it came from hex-based tabletop wargames before video games even existed, but it became the default state for many games, largely unquestioned. Empire and then Civilization itself both followed this pattern, which then extended to all their 4X descendants. The problem with every-unit-moves (EUM) in 4X games is that it only creates the illusion of tactical and strategic decision making. (I am taking the prerogative to coin an acronym for this to draw attention to the fact that employing EUM is an intentional design choice, just like using one-unit-per-tile is a choice.) Each turn, the player is evaluating the most effective single move for each of their units, which is often a very straightforward and often even boring decision, without any tradeoffs, with no reason to NOT take an action. In Civilization, there is never a reason not to build another mine or not to take another shot with an archer. These decisions quickly become rote as the number of units in the game grows. Players ask to automate their Workers because they no longer want to make these boring decisions but are still aware that they are going to perform worse if they don’t at least do something with their Workers each turn. Much has been made about Civ being a game of guns-or-butter, but that choice only really happens during city production. With EUM, once the units are built, it’s guns-AND-butter.

The Orders system of Old World came from an unlikely place, the so-called “social games” of Facebook circa-2010, which seemed to be taking over gaming for one strange little moment. (Indeed, for a brief period of time, three former Civilization designers – Bruce Shelley, Brian Reynolds, and myself – were all working at Zynga, and Sid Meier himself was building a version of Civ for Facebook.) One specific design mechanic stuck out to me from this era, which I first noticed in Brian’s FrontierVille – the “energy” system that was built to give players a limited number of actions each time they logged in, with of course the option to buy more if they got impatient.

I wasn’t particularly interested in the microtransaction side of the mechanic – as I discovered at EA and Zynga, it takes a very different designer than myself to master the dark arts of mixing business and design required for free-to-play games – but I was interested in how energy systems could multiply the strategic possibilities for older genres with a only a small amount of additional complexity. (Of course, ideas like this always have multiple sources, and perhaps also in the back of my mind was my favorite wargame from my childhood, Eric Lee Smith’s The Civil War, which used an interesting alternating initiative system that did not follow the EUM default.)

I hoped that taking a standard 4X game and overlaying an Orders system on top of it would instantly make the game more interesting, so our first step with Old World was to make the game work in multiplayer to see if this was true. We discovered we were onto something special immediately; not only were we making actual guns-or-butter decisions every turn, but the strategic space was blown open so wide that it felt like a completely fresh experience. Every tactical situation now had hundreds of possible approaches based on which units the players wanted to spend their orders moving. Courageous flanking gambits were now possible as were tactical retreats to better terrain. Is it better to spend all your Orders to get your best units in the right location to maximize their damage, or is it better to spread the Orders out to hit the enemy from more positions? Or, is it better to have the discipline during a war to reserve some Orders to spend on Workers to make sure your economy doesn’t fall behind. We discovered in MP that the victorious teams were often not the ones spending the most Orders on military victories but those who didn’t neglect their economy (and especially those who connected their front line to their core via Roads to reduce Orders from moving troops).

The early prototypes tried a number of crazy ideas – there was a turnless mode where every unit had an individual cooldown timer after attacking, there was a version where Orders could be bought just like Food or Iron (and which can still be seen in the game via Coin Debasement), and there was a mode where stockpiling Orders between turns was an important mechanic. Each of these systems was hotly debated, and other base assumptions from 4X design were modified – for example, units now have an absurdly large visibility radius to ensure that they can actually see their own potential movement range (and also so that enemies moving from far away are less likely to look like magically transporting units).

However, the most contentious question by far was whether units should have unlimited movement – in other words, if the only limitation on whether a unit could continue moving was if there were still Orders left to use. With enough Orders, a single unit could theoretically cross the entire map in one turn. I don’t like to add extra rules to a game unless absolutely necessary as each rule in a game adds an extra burden on the player, and “every move costs one Order” without any other restrictions was a very simple rule to describe to players. Further, I was convinced that allowing any one unit a perhaps ridiculous movement range was not actually a problem for game balance; a player could move one unit perhaps thirty times in one turn but only by suffering the huge opportunity cost of not moving any other units.

The team, however, felt quite differently, sometimes vehemently. After months of debate, a mutinous internal mod suddenly appeared that put a hard cap of three moves per turn on each unit. I agreed to give it a fair shake, and although I tried to keep an open mind, I absolutely hated it; we had discovered gameplay magic with the Orders system but were afraid to let it loose. However, I had to admit that perhaps I was pushing the game outside of the comfort zone of most players. At the very least, giving units a soft movement cap would help guide players who would be confused why they could just keep moving their Scout over and over and over again; unlimited Orders certainly increased the risk that players would spend their Orders in the wrong place without considering all their other Units.

Thus, we adopted a fatigue system where most units got three moves each turn but could extend their range by spending 100 Training once on a “Force March” and then double Orders per move thereafter. My fear was that we were adding complexity that would be mandatory to understand to play the game, but I trusted the response the team had to completely unlimited Orders. As a bonus, fatigue gave me one more knob to turn for nations and traits and promotions. (Roman units, for example, could get +1 fatigue to represent their military discipline.) Nonetheless, the promise of the Orders system was still intact, and the variety of moves available to players each turn, especially if they unlock unlimited movement with a Force March, is almost impossible to calculate.