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.

This Old World

My next game, Old World, releases on Early Access tomorrow (May 5th) on the Epic Games Store. This might come as a bit of a surprise to some as we have not been discussing the game very often, but that is changing quickly! Old World is a 4X strategy game set in the Mediterranean during Classical Antiquity. Each turn is a year, and your leader is mortal and will eventually die – passing on the crown to the next in line.

I discuss the major new features here on the Mohawk blog: https://www.mohawkgames.com/2020/04/14/old-world-first-post/

For example, here is a description of the Orders system:

Orders are a resource used to issue commands across your nation. Instead of moving every unit every turn, as is traditional in 4X games, each unit can be moved as many times as desired, until the player runs out of Orders. There are many other ways to spend this resource: Combat, Construction, Events, Diplomacy, and so on. 

You can find more information on the game in these interviews:

  • Rock, Paper, Shotgun: In the end, after a few more hours of “one more turn” (it’s taken that much from Civ, at least), I could only conclude that Old World is entirely its own thing. And I like it very much.
  • PolygonThe build I’ve been playing is certainly not the finished article, but it’s engrossing and fun, and I love its attempt to bring more story elements to grand strategy.
  • PC GamerBut once I started amassing soldiers I would run out of orders without moving half my units, and realized how much more tactical I was going to have to be.
  • I also discussed the game with Dirk Knemeyer and David Heron on the latest Game Design Round Table podcast

Check out our game webpage, mohawkgames.com/oldworld, for more info and important links, including our press kit and Discord server.

We will be streaming Old World from the official Mohawk Games Twitch channel on release day starting at 10AM ET. Hope to see you there!

Offworld Trading Company – Jupiter’s Forge

Offworld Trading Company‘s first expansion pack – Jupiter’s Forge – was released today. Buy it here on Steam.

Jupiter’s Forge, the first expansion pack to Offworld Trading Company, is our chance to see just how flexible free-market game mechanics can be. During development of Offworld, we discovered that the core gameplay was remarkably robust because the buy/sell mechanic auto-balances the game. Thus, the game should be just as fun even if the map, the HQs, and even the resource tree changed significantly.

Reworking the resource tree would be the most significant change as everything in the game is downstream from how the resources interact. We knew this change should not be minor, so we looked for a location in the solar system that could flip the water tree, which led us to Io, a moon without water but with sulfur oxide ice and a steady stream of hydrogen ions from the neighboring planet. Here, instead of splitting water into oxygen and fuel (hydrogen), the player would melt the ice for oxygen, collect hydrogen from Jupiter’s radiation, and combine them into water. Life support becomes much more challenging when the player can’t just extract water straight from the ground.

Io has a few other wrinkles that mix up the familiar formula from Mars. The day is much longer – 42 hours! – with an additional two-hour eclipse when Jupiter blocks the sun. From the Ceres DLC, we are borrowing diminishing resources (which drop high and medium tiles to low over time) and cave terrain (which gives mining access to all adjacent tiles). Because Io has no atmosphere, wind turbines are not buildable, so players must rely on geothermal plants, solar panels, and nuclear energy. Io also has liquid basalt lakes, on which players can build basalt platforms that produce iron, silicon, and uranium. (Further, scientists can use these resources as inputs for their buildings.) Finally, Io has an assortment of random event new to Offworld – radiation storms, sulfur frosts, landslides, and tremors. The Patent Lab on Io has some new options as well: Nuclear Engine (use uranium as fuel), Geothermal Borehole (all buildings adjacent to geothermal tiles produce power), and Synthetic Meat (farms are permanently boosted).

We also knew that we wanted to encourage new ways of approaching the game by adding two new HQs to the game. The Penrose Collective (colloquially known as the Nomads) are scrappy survivors, emphasizing flexibility and adaptation by allowing the player to actually return claims back to the colony to grab new locations. If aluminum crashes, return you aluminum tiles and get into something more profitable. The Nomads also are able to place two HQs on the map, which reduces their shipping costs and makes moving claims around easier. Finally, the Nomads use silicon instead of steel as their primary resource, making them a good choice for maps rich in the former resource.

The Diadem Trust (known as the Elites) are thematically the rich kids of Io, focusing on special versions of all the advanced buildings. Their Pleasure Dome produces double the revenue (but consumes chemicals); their Patent Lab can license patents from other players; their Optimization Center grants free claim for each fully upgraded resource; and their Hacker Array can create a shortage and a surplus simultaneously. Finally, they can build three Space Elevators instead of the typical two. (Oh, did we mention that Io has a Space Elevator instead of an Offworld Market?) Thus, the Elites are difficult to stop if they make it deep into the game (although that itself can be a challenge as they have few early bonuses).

We hope players find Jupiter’s Forge to be a fresh experience that makes them rethink their old strategies from the base game.

Offworld Trading Company GDC Postmortem

I am going to be speaking at GDC this year on the design and development of Offworld Trading Company. I’ve included the description below and a few sample slides. Hope to see you in SF – my favorite week of the year!

‘Offworld Trading Company’: An RTS Without Guns

Speaker: Soren Johnson  |  CEO, Mohawk Games
Location:  Room 3016, West Hall
Date:  Wednesday, March 1
Time:  5:00pm – 6:00pm
Format: Session
Track: Design

For ‘Offworld Trading Company’, Mohawk Games set out to make a new type of real-time strategy game, one that focused on economics instead of combat. Following this initial vision led Mohawk Games to shed other standard tropes of the genre, such as unit selection, on the way to creating a unique gameplay experience, one that de-emphasized micro dexterity challenges in favor of macro high-level strategy while still hewing to the standard half-hour RTS format. This postmortem details the twist and turns of Offworld’s design process, from conception to prototyping to Early Access to final release.


Despite the increasing quantity of games released each year, there are still huge areas of unexplored territory for new gameplay, even within established genres such as the RTS. The development of ‘Offworld Trading Company’ serves as an example on how to find these hidden kingdoms.

Intended Audience

This talk will be of interest to developers interested in the details of how design decisions were made while pioneering a new type of real-time strategy game. Developers interested in open development should also benefit as the talk will give positives and negatives from Mohawk’s Early Access experience.

Offworld Trading Company Podcast Roundup

I’ve been meaning to write this posts for months, but it always seemed like there was just one more podcast coming out to delay the complete list. However, I think we are now safely past the podcast saturation point, so if you want to hear me go on and on about Offworld for about eight hours, today’s your lucky day!

Offworld Trading Company Early Access Postmortem

The most common problem in the games industry is waste – wasted time, wasted effort, and wasted money on design ideas that aren’t actually fun in practice. Often, this discovery is not made until shortly before shipping when the game is finally played outside of the development team. Basic assumptions about how the game should be played might be wrong, and a community more dedicated to winning can easily find holes in the balance. No one knows a game both better and worse than the development team, which understands why every decision was made but is also blind to how the game appears to new players.

At Mohawk, we believe that games need outside feedback as soon as possible. I saw this first-hand with Civilization 3 and 4; the former had no external feedback before shipping and thus had numerous gameplay and balance issues that would have been easy to fix if we had simply known about them. In contrast, we recruited a private external testing group from the community to play Civilization 4 over 18 months before we shipped. The logistics of managing this group – with NDAs, physical copy protection, and bi-weekly patches – were a nightmare but much of what went right with the game can be traced to feedback from this group, which kept us on the right track.

Thus, as soon as I heard that Valve was starting an Early Access program, I knew we wanted to take part with Offworld Trading Company. Getting good feedback from players before release is a logistical challenge, especially for a game with a major multiplayer component, and Early Access would solve that problem for us, a small indie team making a very unusual RTS without combat. We were worried about the potential marketing impact of Early Access on our final release launch, but we still went for it, assuming that the increase in quality from early feedback would outweigh the cost.

What Went Right

1 – Learning About the Game

Feedback is important because it is the best way to learn about a game – finding out how people actually play instead of how the team imagines they are going to. Offworld was on Early Access for 14 months – approximately half of the project – and we learned many things that we would have never discovered internally. A great example was player dissatisfaction with scanning the map before founding an HQ; this feedback led directly to the development of the Reveal Map option that completely changes how the game begin.

We discovered this issue during the first competitive tournament as the scanning system quickly became a point of contention. The players argued that if a map had a founding location which was superior to all others, the game would be won simply by whoever discovered that founding location first. These players were concerned primarily with a sense of fairness, which was a reasonable concern for the hardcore community because founding location is so important for high-level play in Offworld.

The solution was to start with the map fully revealed and then let players choose where to found, with a debt auction determining who gets to found first. (A counter starts at $200K debt and then goes down in real-time so that players who found earlier start the game with more debt, essentially “buying” their founding location on credit.) This option worked perfectly for our most competitive players and quickly became the de facto standard for online play.

However, the important point is that we made this change a full year before we shipped Offworld, so we had plenty of time to test and balance the mode, write AI for it, and decide how to introduce it to the player. If we did not have Early Access – even if we only had a small private beta – we would not have discovered this important issue until it was too late. There is no better argument for Early Access than learning about a problem while there is still plenty of time to fix it.

2 – Live Experimentation

One crucial aspect to doing Early Access right is figuring out how to update the game while also keeping it playable. A good example of how this can go wrong is the Corpse and Hound update from Darkest Dungeon (see Tyler Sigman’s 2016 GDC postmortem) which put the developers at odds with a vocal portion of their community. This type of conflict is paradoxical – the point of Early Access is to be able to change the game for a live audience and yet players can punish developers for doing exactly that.

We were very careful about how we rolled out changes while also maintaining the position that the point of Early Access was live experimentation, so we would be fearless in that regard. We took a number of steps to meet these two conflicting goals. First, we released major updates slowly so that casual players would not experience random bugs during normal play. Then, to get feedback on our most recent changes, we created a Steam branch entitled “next_version” which we updated multiple times per week. (This branch was password protected, but we shared the password publicly so that it was essentially an ongoing opt-in patch for our hardcore community.) We felt free to make any changes we wanted to on this branch; if players were upset by a change, they could always just switch back to the main version. Our core community knew that we wanted to hear feedback about this version, so they were excited to jump onto the branch, see what was new, and let us know how they felt about it. Most importantly, they were never blindsided by a change because the next_version branch was constantly updated.

However, when we made potentially controversial changes, we would attach them to game options that the player could disable. For example, our stock system underwent many significant iterations, with some of the changes being more popular than others. In one patch, we added two major features – Destroy Buyout (a player’s buildings are destroyed on a buyout) and Majority Buyout (a player is eliminated when more than half of his or her stock is owned by rivals) – but both were options that the could be turned on or off. Thus, players who hated the changes could play without them while we keep experimenting. To ensure that we would learn enough about these new features, we hosted a community tournament after releasing the patch which specified that both options must be turned on. Knowing that an upcoming tournament would use these rules encouraged our players to practice with them in preparation, which produced meaningful feedback for us. (In this case, Majority Buyout became a standard rule while Destroy Buyout did not, being replaced in the long-term by the Subsidiary system.) Being able to experiment rapidly and without fear was a major factor in taking advantage of Early Access to improve the game’s design.

3 – Building the Community

A vibrant community is important for the long-term health of a game, especially one with a strong multiplayer component. One of the great advantages of Early Access was that we were able to build that community before launch. Although players still find each other on forums, we found that the best place for a community to form is on Twitch. We discovered our best players early by seeing them play on streams, usually ones involving multiplayer games.

We encouraged that growth by hosting Twitch tournaments, meaning that after we organized the brackets, players were required to stream their games. (Because some players were not capable of streaming, other players jumped in to stream the games as observers.) Players and viewers would jump from match to match as the tournaments progressed, forming bonds with each other in the process.

Long-term, our community became an important part of our development process. For example, when working on the AI, I would ask players to do their best on the Daily Challenge (a random map based on a new seed each day) and post their videos or replays online. I would watch to find the biggest holes in the AI’s performance, write some code to fix things, push a build to next_version on Steam, and then ask players to try again. The impact of this rapid iteration cannot be overstated. The quality of a game is determined by how many time that game can go through the design, code, play, and listen feedback loop. With Civ 4, the best we could do was bi-weekly; with Offworld, that loop could be daily.

Finally, building a strong community during Early Access paid off handsomely at launch because we had already primed an active group of players. On their own, they organized a 24-hour marathon of veteran players streaming the game for newcomers interested in the game. Two of our best players – Zultar and Cubit – wrote comprehensive strategy guides that we included as free DLC. Many YouTube videos were already online for players who wanted to see the game; according to Steam Spy, these videos averaged over 200K views per day during the first week. Our final release launch sales were just as strong as our Early Access launch sales, and much of the reason was having an active community already in place.

What Went Wrong

1 – Constantly Shipping

Over the 14 months of Early Access, we shipped ten major updates to the game along with a number of hotfixes, which absolutely took its toll on the development team. Each update had to go through a round of QA, with bugs being assigned to developers who had to interrupt their normal development flow to ensure the update was polished and ready. Some of these bugs were critical, but others were of subjective importance. The QA team was trying their best to be thorough, but during active development, not every bug needs to be fixed, especially for systems that are currently just placeholders. I gave each team member the right to make a judgment call on which bugs to ignore, but the process itself absolutely took time away from more important, long-term tasks.

Also, being on Early Access for half of the game’s development cycle meant that we couldn’t include half-baked features with just debug text and programmer art. This type of prototyping is an important way to make progress while a feature is experimental so that polish would be a waste of resources. Sometimes, we would lock away features that we knew were not ready for a general audience by enabling them only in special developer builds, which helped mitigate the problem. Regardless of the Early Access label, the general Steam audience is simply not ready to see just how ugly games can be during development.

2 – Steam Reviews

Although Steam tags user reviews written before release with a special “Early Access Review” designation, these reviews still count against the game’s positive review percentage. We had generally positive reviews, but – as our current percentage is just two point shy of the 80% threshold for the Very Positive status – it is hard not to imagine that we would be in a higher category of we weren’t saddled with user reviews written 14 months before release. (Our Executive Producer at Stardock, Derek Paxton, took the time to respond to every old negative Steam user review that had a specific complaint addressed in the release version, and we did see a number change their review.)

On a personal level, negative Steam reviews took a not insignificant toll on my own personal morale, and the same is probably true for the rest of the team. It’s hard to read over and over again that the game doesn’t have enough content, has crummy voicework, is missing a tutorial, and so on – as the team is working to fix those issues. Even with an imaginary, unlimited budget, one has a finite amount of energy to invest in a project, and premature yet permanent ratings can drain that energy surprisingly quickly.

3 – Press Apathy

One common argument against Early Access is that “you only get one launch” – meaning that a game’s Early Access launch is, in truth, it’s only launch. We certainly experienced a surge of interest in Offworld when it first launched in early 2015; our game was the new shiny object, so we were able to organize a media blast by revealing the first screenshots a couple weeks before the Early Access release, resulting in exclusive stories and interviews on Gamespot, Polygon, IGN, VentureBeat, and more. Shortly after release, videos appeared from popular YouTube personalities like Sips, Quill, Arumba, and Northernlion while huge audience watched streams from Trump and Day[9].

This wave of media interest led to very strong sales during our first few weeks on Steam even though we launched at $40, making Offworld one of the highest-priced games on Early Access. (At launch, only Galactic Civilizations III – also published by Stardock – was more expensive.) 14 months later, however, we had a much harder time getting press attention for the game’s real launch; most of the websites who wrote about the Early Access launch told us explicitly that since we had been on Steam for so long, they didn’t find us newsworthy. We could expect reviews but little else.

Fortunately, our reviews were strong (82 on OpenCritic, including a glowing review from Rock, Paper, Shotgun), the game had been on over 200K wishlists, and forums activity around the game was high, so we ended up selling nearly the exact same number of copies during our second launch as compared with our first (two-week sales of 23,607 vs. 23,457, respectively). Thus, we proved that a game can have a second launch although we certainly felt like we had significant headwinds from a lack of mainstream press interest.

We are not entirely sure how we were able to sell so well the second time without a strong media push. I’d like to think that the tradeoff we knowingly made by going on Early Access – sacrificing a traditional media buildup for the benefit of early feedback to make a higher-quality game – paid off in the long run although that is, of course, impossible to prove. Indeed, it’s still possible that we may have sold more copies without Early Access if we had paired our media announcement blast with our polished release version, but we’ll never know for sure.

What We Would Do Differently

Without question, we would be willing to put our next game up on Early Access as well. However, we will certainly approach the process differently. First, we would try harder to sell our game independently before going up on Early Access. Many games do this (Factorio, for example, sold over 100K copies before launching on Steam), and we sold Offworld with a “Founders program” on our own site but without actually showing any screenshots or video of the game. Users were buying the game blind, and predictably, we sold the game to just a handful of dedicated players. We were worried about releasing images while the game was full of prototype art (and inevitably seeing those images stick around forever online), but developing a game publicly before going up on Steam has huge advantages.

The pre-Steam audience is more mature and more forgiving of the inevitable bumps of game development; they know upfront that they are buying into something speculative. During our Founders program, we uploaded builds without running it through QA at all (although we often ran a test game internally) because we knew this group would tolerate a few hours downtime if we released a bugged version. We had the freedom to develop without worrying about a temporary mistake landing on our permanent record via negative user reviews. Next time, we would accept the downside of showing prototype art publicly to allow us to stay off of Steam longer; if we are getting sufficient feedback while selling the game independently, we would delay our Early Access launch as long as possible.

When we do launch on Early Access again, however, we would do a few other things differently. We would actually drop QA from the process entirely (at least during the long period after the initial launch and before final release) and instead develop a build process that fits the needs of the development team, which should always be thinking long-term and not worrying about a bug list too early, as well as the Early Access audience, which both wants the game to work yet also to see frequent updates.

One possibility is to run a build automatically every Monday morning which is then uploaded to Steam without testing. This build would be sent to a branch similar to next_version (although this time, the branch would be public and not password protected), which our more dedicated players would try out right away. If there are any problems during the week, we can manually update that branch. By the following Monday, if next_version was stable, we would promote it to the main branch for general consumption. Hopefully, this development process would allow the team to work unhindered while also making sure that the players are experiencing a current version of the game. Indeed, one major problems of releasing monthly updates is that, even after a single week, players might be playing a game already outdated by various new features or balance changes, which makes their feedback – which is the whole point of Early Access – no longer relevant. (Note that some Early Access teams argue that major, themed updates produce the best sales, but we are assuming that sales figures should not be a priority during active development.)

What Steam Should Do Differently

Most of the problems with Early Access result from differing expectations between developers and consumers. Developers want Steam to provide a safe place to build a game while also exposing the game to a large enough audience to get worthwhile feedback. Consumers, on the other hand, want to play a game early and, hopefully, for a low price as well. (However, we heard many times from players that they didn’t even realize they were buying a game on Early Access or what that designation even meant!) We have a few suggestions for improving the role Steam Early Access plays in game development.

1 – Allow unlisted pages

The biggest benefit of being on Steam during early development is not the exposure but the infrastructure: build distribution and branching, access to the Steamworks library, free community support features, and online sales through a trusted store. All of these tools were major problems for independent developers ten years ago and are now easily solved via Steam. However, Valve takes an all-or-nothing approach to Early Access; launch will put the game on the front page of Steam whether the developers want it there or not. During our Founders program, we sold Steam keys directly through our website, but Valve has become increasingly resistant to allow developers to sell Steam keys without their games actually being for sale on Steam.

This policy is forcing some independent developers to other options for their first online sales. (Adam Saltsman launched Overland’s “First Access” on itch.io for this very reason, and they are even limiting the number of keys available for public sale.) Most developers would prefer to stick with Steam (as it has the most mature infrastructure) but are afraid of risking their reputation by launching too early. The answer is to allow developers to sell games on Steam with unlisted store pages, meaning the page is only available via a direct link and does not show up in any advertisements, ranked lists, discovery queues, curator collections, or any other method for exposing the game to the average Steam consumer. This option would allow developers to start selling their fledgling games slowly while still benefiting from Steam’s infrastructure.

2 – Unscored user reviews

User reviews are a staple of online commerce, and Valve was wise to implement them, even with the potential chaos inherent with giving customers the power to judge a game anonymously. However, what exact purpose does a review serve when stating that an Early Access game is not ready? The game’s presence on Early Access is an explicit statement that the game is not ready! More importantly, the existence of scored user reviews argues that Early Access games should be judged and evaluated the way the normal games are, which is simply not true. If the team is serious about iterative development, Early Access games can and should take wild swings in quality during development; the fear of negative user reviews encourages developer to sit comfortably on local maximas. Removing scores (meaning thumbs-up or thumbs-down) from user reviews should send a message that Early Access games are not ready for a final evaluation; the goal is not to trick people by removing scores but to sell to less people, the ones who are onboard with experiencing an unfinished product.

3 – No sales, No refunds

Implicit in the argument against user reviews is the belief that Early Access would be healthier if the games sold to less players overall but also to ones who are more dedicated. Turning off the developer’s ability to reduce the price of a game to drive sales and turning off the consumer’s ability to test out a game knowing that a refund is possible should both drive down game sales, especially among the more casual audience looking for either a bargain or a de facto demo. A Subnautica developer spoke to their view on driving sales during Early Access:

Subnautica is a game that is still very much in development, and we don’t need to bring in a large influx of players right now. When the sale price is lowered by a large margin, it tends to attract a group of people who are less willing and dedicated to giving the game a real chance. You end up with players who just tossed it on the pile of other games they are buying, mainly because it was a great deal, and many of those people either never end up playing it or end up playing it for a short amount of time and posting a negative review because they likely didn’t research it.

One potential alternative that would provide some flexibility in driving sales but without bringing in players not ready for Early Access would be to allow two ways to buy the game – a pre-order option and a play-now option. The latter could be slightly more expensive, which should keep away players who are looking for a deal, while the former provides a nice way for consumers who trust a developer to support them.

Ultimately, Early Access development would be healthier with a slower and steadier influx of players, growing the old-fashioned way by word-of-mouth. We want a special type of consumer, one who is excited about seeing behind the curtain, contributing critical feedback, and seeing the game evolve. We have met these types of players over and over again online; they inspire us with their passion and patience while we work hard to build the best game possible for them. These players are priceless, and Early Access would be the best place to find them if Steam is willing to do the work to guide player expectations.

OTC Designer Notes #19: Special Thanks

The following is an excerpt from the Designer Notes for Offworld Trading Company. The game, an economic RTS set on Mars, released on April 28, 2016, and is available for purchase here. (A Game Almanac, which includes the full Designer Notes, is available as free DLC.)

Offworld Trading Company was not an easy game to make, perhaps most especially because people needed to believe that it would work in the first place. Thus, I need to thank Brad Wardell, Derek Paxton, Brian Clair, and everyone else at Stardock for believing that an economic RTS would actually be fun.

I also need to thank the team for taking the leap with me and working so hard to build the game. Dorian Newcomb, my business partner, was the game’s official Art Director and unofficial Producer, making sure that life on Mars looks amazing and that everyone was working in sync. Jason Winokur was the first programmer to join us, and he handled the graphics, supported modding, and generally made sure our project was in great shape. Dave Wagner implemented multiplayer, replays, saved games, leaderboards, and all the other details needed for a modern game. Jim Alley created all of our interface art as well as our great logo. Josh Hardy, after being lured away from the Star Control team, made our building, colony, and HQ models as well as our effects. Joel Bowers implemented the scenario system and then built the tutorials on top of them.

Zack Fowler implemented our terrain system and built the map editor on top of it. Tommy Truong helped us finish, animating our buildings and HQs. Mark Cromer made our sound effects and helped with audio design. Christopher Tin composed an amazing soundtrack that scales with the player’s progress. Kirby Runyon created 32 maps by hand, based on real locations on Mars. Andy Hull added some nice polish to our character popups (and invented the giant check for losing). Erik Ehoff made some key early concept art the helped to define the game’s look. Shentloc, our localization team, did an amazing job to help us ship in nine languages. (Ten if you count British aluminium!)

I’d like to thank my wife Leyla who, perhaps unexpectedly, fell in love with the game and sunk 1,000 hours into it, her very first RTS; her excitement and encouragement helped me keep going during the rough times. Finally, I want to thank the fans that provided us with amazing feedback and support during the pre-release phase; the game would have been much different (and certainly worse) without them. I specifically want to acknowledge the contributions of the following players: Zultar, Cubit, PBHead, Gameslayer, Blues, Blackmagic, Death Tacticus, Indczn, Kingmorgan, Jaiwera, YerAnd, GalacticWino, Roler, TheSpinCycle, Veivi, UltraPope, Dermas, Heisenberg, Showcasemike, and Sir Rogers.
Offworld would still just be an idea in my head without the amazing team we have at Mohawk, and I will forever be in their debt for believing in the game and committing to making it great. I think we will all remember that year when we were playing the game internally as one of the best of our careers — iterating on it constantly based on daily games while slowly becoming aware that we were making something truly unique. Actually finishing the game was very hard work, so I am very proud of what we created. I hope the game will mean as much to you.