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 tolerant 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.

Designer Notes #58: Rob Daviau – Part 2

In this episode, Soren interviews board game designer Rob Daviau, best known for his work on Risk: Legacy and Pandemic: Legacy. They discuss the criteria for a good Legacy game, how to put just a little PvP in a game without overdoing it, and why he removed his phone number from his website.

Games discussed: Risk: Legacy, Pandemic: Legacy, XCOM 2, Seafall, Conspiracy, Stop Thief

https://www.idlethumbs.net/designernotes/episodes/rob-daviau-part-2

Designer Notes #57: Rob Daviau – Part 1

In this episode, Soren interviews board game designer Rob Daviau, best known for his work on Risk: Legacy and Pandemic: Legacy. They discuss bluffing his way through his first game job interview, how he designed Betrayal at House on the Hill without either starting or finishing it, and why Risk Legacy bombed in Germany.

Games discussed: Candy Land, Impossible Mission, Dungeons and Dragons, Trivial Pursuit, Scruples, Atlantis: Pathways to the Deep, Mountains of Madness, Pandemic: Legacy, Betrayal at House on the Hill, Risk 2210, Risk: Black Ops, Risk: Legacy

https://www.idlethumbs.net/designernotes/episodes/rob-daviau-part-1

Designer Notes 56: David Dunham

In this episode, Soren interviews independent game designer David Dunham, best known for his work on the narrative strategy games King of Dragon Pass and Six Ages. They are joined by writer and designer Meg Jayanth, best known for her work on 80 Days. The three discuss whether the advisors in Dragon Pass lie to the player, what Six Ages and 80 Days have in common, and whether the anthropomorphic ducks are ducks with human-level intelligence or humans who have been turned into ducks.

Games discussed: King of Dragon Pass, Pendragon, Fallen London, 80 Days, Six Ages, Sunless Sea, Castles, Hearthstone, Battle of the Bulge, Really Bad Chess, Drive on Moscow

https://www.idlethumbs.net/designernotes/episodes/david-dunham

I Shouldn’t Have to Write this Post

I have voted for a Democrat in ever election in my lifetime, and while I express my political view from time to time, it’s important to acknowledge that plenty of Republicans have served their country honorably in government. John McCain and Mitt Romney, for example, would both have been perfectly serviceable presidents. The country will always have a conservative party, and yet progress is still made because, each generation, what used to be an unthinkable progressive idea is now mainstream enough to be simply unchallenged by the GOP.

That context is necessary for the following statement: voting for Donald Trump is an unconscionable act.

I don’t need to list all of the ways he has beclowned our nation. Everyday, one just needs to read the news to see one more example of his cruelty, his ignorance, his incompetence, and his narcissism. Today’s violation is his ALL CAPS approval of his thugs running his opponent’s bus off the highway. Encouraging political violence is an unspeakably careless act for any politician, let alone the president. By itself, it would be enough of a reason to vote out any elected official, and I would vote against a Democrat who did the same. Consider that a president could do something this base, worse than anything Nixon ever did – who was a cartoon villain when I was young – and yet today will be forgotten in the unending waves of Trump’s crimes, failures, and corruptions.

Therefore, as the US is a two-party system, not voting for Joe Biden is also an unconscionable act. A second Trump term would mean that everything he has done was not just permitted or ignored but actually rewarded. I still have faith that America would recover, but every year undoing his damage is a year not feeding the hungry, not healing the sick, and not educating the ignorant.

Moreoever, all we have to do is vote. Our country has sometimes asked far too much from its citizens just for the right to vote, usually because of color or gender. Voter suppression may be the last refuge of minority rule, but Trump can still be easily beaten if every American just does his or her duty. All we have to do is vote.

The hard part is learning how to control Trump’s breed of American fascism because, no matter how many bad things one can say about Trump, the one thing that cannot be said about him is that he is not American. That fight, however, begins the day after Tuesday.

Designer Notes 55: Meg Jayanth

In this episode, Soren interviews independent game developer Meg Jayanth, the writer on 80 Days. They discuss how fan fiction is similar to modding, if 80 Days is a criticism of the Bioware companion system, and why it’s important to do your work.

Games discussed: SimTower, Grand Theft Auto, Savoir-Faire, All Roads, Choice Of Games, Samsara, 80 Days, Sunless Seas, Sunless Skies, Horizon Zero Dawn

https://www.idlethumbs.net/designernotes/episodes/meg-jayanth

Designer Notes 54: Jon Ingold – Part 2

In this episode, Soren interviews veteran game developer Jon Ingold, who co-founded inkle and is best known for his work in interactive fiction, including All Roads, 80 Days, and the Sorcery! series. They discuss how to get the player to trust the designer, why pursuing fairness can take away what is special about a game, and whether packing should be done in real-time.

Games discussed: Creature of Havoc, The Sorcery! series, XCOM: Enemy Unknown, 80 Days, Heaven’s Vault, The Last Express

https://www.idlethumbs.net/designernotes/episodes/jon-ingold-part-2