Designer Notes #22: Amy Hennig – Part 2

In this episode, Soren Johnson interviews veteran game designer Amy Hennig, best known for her work on the Legacy of Kain and Uncharted series. They discuss what elements from film can’t work in games, how many hours she averaged per week working on the Uncharted series, and how to capture great acting performance for video games.

Games Discussed: The Uncharted series, The Last of Us

Designer Notes #21: Amy Hennig – Part 1

In this episode, Soren Johnson interviews veteran game designer Amy Hennig, best known for her work on the Legacy of Kain and Uncharted series. They discuss what happened in 1977, how to make a platformer about Michael Jordan, and whether women are now being scared away from game development the way she was from the film industry. In true adventure game fashion, we end on a cliffhanger!

Games Discussed: ELIZA, Sea Wolf, Combat, Dungeons and Dragons, Zork, Electrocop, Bard’s Tale 4, Desert Strike, Michael Jordan: Chaos in the Windy City, the Legacy of Kain series, Jak 3

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!

Designer Notes #20: Liz Ryerson

In this episode, Adam Saltsman interviews independent game developer Liz Ryerson, known for experimental games like Problem Attic. They discuss whether we should ever make players uncomfortable, why horror games have more freedom to try unconventional design, and whether Twitter is a game.

Games discussed: the Civilization series, Overland, Problem Attic, Train, Papers Please, PRY

Designer Notes #19: Louis Castle

In this episode, Soren interviews Westwood Studio co-founder Louis Castle. They discuss why early video game artists were also great at Etch-a-Sketch, why Dune 2 was not Dune 1, how Boom Blox was almost Angry Birds, and why narrative games can’t end on a negative.

Games discussed: Temple of Apshai, The Mars Saga, Command & Conquer, Monopoly, Dune 2, Eye of the Beholder, Blade Runner, Boom Blox, LMNO, The Battle for Middle-Earth

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

Designer Notes #18: Offworld Trading Company

In this episode, Bruce Geryk interviews Soren Johnson about his new economic RTS, Offworld Trading Company. They discuss how exploring a black map is one of gaming’s greatest hits, why the hardest part of designing Offworld was ending the game, and why Early Access games shouldn’t have QA. Also, listen to hear Soren correctly pronounce timbre!

Games Discussed: Offworld Trading Company, StarCraft, Age of Empires 2, Railroad Tycoon, M.U.L.E., Belter

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.

OTC Designer Notes #18: Adaptive Gameplay

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

We are most proud of Offworld because it makes the player think about each game differently, adapting to the events and environment of that specific match instead of using the same build order or pet tactic over and over again. The game encourages adaptation because so many key parts of the game are randomized each time:

  • Random MapsEach map is randomly generated, with different quantities of each resource available. To encourage interesting randomness, we associated each resource with specific terrain types (Carbon with Craters, Water with Lakebeds, Silicon with Sand, and so on), which determines how likely it is that resources might appear on a tile of that terrain type. Then, we limited these types of terrain to different sections of the map; if Sand fields are in the northwest while Lakebeds are in the southeast, then the Silicon and Water will be in different parts of the map. By preventing different resources types from being too close together, each potential founding location is defined by what resources are close and what resources are not. We also create a dead zone of resources near the middle of the map surrounding the Colony to encourage players to found near the edges of the map, making longer shipping lanes more necessary.
  • Black MarketThe black market typically has six to eight items for sale, and they are selected at the game’s start from a set of eighteen (not unlike the ten card stacks chosen at the beginning of a game of Dominion). As mentioned previously, they are chosen not purely randomly but with certain guarantees (for example, either an EMP or a Power Surge will always be available). Advanced players watch the black market carefully before deciding which HQ type to use. For example, Underground Nukes penalize Scavengers (who are so dependent on maintaining their Carbon supply) but barely affect Scientists (who can still put secondary buildings on top of Trace levels of a resource). Pirates and Magnetic Storms are dangerous for Scientists as they often ship expensive resources across the map; on the other hand, EMPs and Power Surges favor Scientists as they have protection against both. Circuit Overload is dangerous for Robotic players as they like to maintain a positive rate of Power. Expansive HQs are a good choice if Bribe Claim is not available because they will be the only ones with extra claims. Furthermore, the items change how each other can be used; Holograms are much more powerful in games without Spies than in games with them.
  • Random Prices – With the Random Prices option turned on (which is highly recommended for veterans), the starting price of resources also changes from game to game. Although half of the resources stay the same, a quarter of them are reduced by 50%, and a quarter of them are increased by 100%. This option was added once veteran players developed general starting strategies for most of the HQ types. For example, two Steel Mills and a Metal Mine on Iron is a typical Robotic opening; however, what if Iron starts high at $40 and Steel starts low at $30? Then, a Steel Mill is going to lose money by converting $40 of Iron into $15 of Steel (although the actual conversion should be a little better because of adjacency bonuses). The Robotic player can stick to the familiar strategy but might be better off looking for something else. Perhaps in this scenario, Power started higher and Aluminum lower? In that case, a Geothermal Plant would be much cheaper than normal and immediately produce some serious money. Basically, the best players will reevaluate all of their opening moves depending on the set of prices revealed at the beginning.
  • Random EventsDuring the game itself, random events occur that shift prices of resources significantly. Some events (Oxygen Surplus, Food Shortage, etc) will affect just one resource, driving the price either up or down; these events are the ones which can be created artificially with a Hacker Array, so players should always view them with a bit of suspicion (even if a Hacker Array is not visible as it can be hid with a Hologram). Other events affect multiple resources at once; for example, a Pipeline Leak will drive up the price of Food, Oxygen, and Fuel. Finally, Solar Flares and Dust Storms affect how buildings function; while the former boosts Solar Panels, the latter penalizes them but boosts Wind Turbines. Taken together, all these events ensure that players need to adapt to random circumstance during the game as well. For instance, a Silicon Shortage might suddenly make Glass Kilns unprofitable; should the player scrap them for something else, or just hold on until the market balances out again? The answer probably depends on many factors, such as the player’s stockpile of Silicon, the Colony’s demand for Glass, whether the player still needs Glass to upgrade, the cost of switching to new buildings, and so on. The random event, however, forces the player to consider the situation carefully.
  • Other Players The decisions made by other players are, of course, not actually random, but they definitely require the player to adapt. For example, the desirability of each HQ changes depending on the other founds. If other players found Scavenger, then perhaps the player should pick Scientific, which has good protection against sabotage. If everyone goes Scientific, then perhaps founding Robotic and building Power is a good move as Scientific players consume plenty of Power with their secondary buildings. Seeing many Robotic players means, of course, that life support resources will not be in such high demand. Besides the founds, players need to pay attention to what everyone else is building. Is everyone skipping Power? (If so, put down an early Geothermal Plant.) Did most players build Farms and not Reactors? (If so, do the opposite and build Reactors..) Are multiple Patent Labs and Optimization Centers up early? (If so, build Refineries as the price of Chemicals is about to rise.) Basically, watch what everyone else is doing to anticipate where the market is heading.

We hope that we’ve made a game that lives up to our ideal for strategy games — that the player should always be planning, always be reacting, always be thinking.

OTC Designer Notes #17: Stock Market

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

The hardest part of the game design to get right – and one that changed significantly only a few months before release – was the stock market. The system had both a thematic purpose (a modern economic game needs a stock market to reflect success) and a gameplay purpose (the system serves as a desperately needed victory condition for a game in which wiping out the opponent militarily is not an option). Basically, we needed a way to end the game that was more interesting than simply counting who made the most money.

Our initial idea involved buying out other players and actually acquiring their HQ as well as all of their claims and buildings. After a player had no more shares available on the open market, she would be vulnerable to a buyout, which any player could trigger by paying double value for all of the shares owned by other players. Thus, a player could defend himself by buying up his own stock or attack other players by buying up their stock, in preparation for a later buyout.

This system worked reasonably well except for two problems. First, players often felt that the game spiralled out of control following a buyout because they inherited a lot of new buildings all over the map that they didn’t have time to manage. Second, buyouts were all-or-nothing affairs; when two players were racing to buyout a third player, the winner would usually snowball forward and easily dominate the rest of the game (or, if we tried to balance out this effect by making buyouts too expensive, an even worse situation occurred in which players saved up their money instead, in hopes being able to afford the final buyout).

We solved both these problems with the subsidiary system, under which players no longer acquired all of the eliminated player’s buildings and claims but instead now owned shares of a new subsidiary, which is the eliminated player’s company run by a modified AI that focuses solely on making money (and avoids advanced options like sabotage, patents, auctions, and stocks). The subsidiary simply exists to distribute its profits to shareholders, according to the ownership percentage. This system is much easier for players to handle as they don’t need to manage their subsidiary’s buildings and also easily handles split ownership, avoiding the problems of the original all-or-nothing system.

Because subsidiaries enabled partial ownership of companies, we were able to add one more wrinkle to the system — the majority buyout, which occurs if the other players own six shares (meaning more than half) of a player’s stock. In a majority buyout, the targeted player is instantly eliminated and turned into a subsidiary. This feature prevents players from staying in the game far after the point it becomes obvious that they don’t have a chance; if a player’s rivals own six or more of his shares, his chances of winning are slim at best. Most importantly, the player is not left around with an opportunity to unbalance the game by, perhaps, using sabotage maliciously to keep a specific opponent from winning. If a player has clearly lost, the company should be run by the neutral, subsidiary AI as soon as possible.

One final important change to the stock system came very late, less than five months before we shipped the game. Some players asked for more transparency in how close players are to buyouts. Thus, we experimented with a system in which players could buyout an opponent’s self-owned stock one-by-one (for double cost). Stocks owned in one’s own company became the equivalent of hit points, and when a player ran out of stock, her game was over. The system led to some tense games in which players could easily see how close the game was to ending as they lost control of their own stock, one share at a time. For the first time, three-player games were playable because the two leading players could each end up with half of the last-place one. However, free-for-alls with more than three players suffered because players could team up against one specific player and buy one or two shares each, forcing him out of the game.

Next, we tried a middle ground. Players could buyout shares one at a time until only five shares remained; at that point, the remaining five shares have to be bought all together. This mechanic struck the right balance between making buyouts more transparent while also protecting players from being knocked out by the group. One final small change gave us our final stock system – during a buyout, players have to pay 20% extra for each share owned by a third party, which gives a bonus to players who invest in buying some of the first five shares. Many players didn’t even notice this final tweak, but it felt better; if a player buys the first five shares in an opponent, she is now best positioned to finish the buyout.

We are often asked how Offworld compares strategically to more conventional RTS games. Some parts of the game are so different that it is hard to even make comparisons; however, the development history of the game’s stock market is interesting because it ended up in a place that mirrors the most famous dynamic in RTS games – rush vs turtle vs boom. As a short explanation, these three strategies have a high-level rock/paper/scissors relationship. A rusher (who sacrifices economy for early military) will beat the boomer (who sacrifices defenses for a strong economy). The rusher, however, loses to the turtler (who builds defenses in preparation for an attack). Finally, the boomer beats the turtler by outpacing him economically by the end game.

Strategically, our stock system parallels rush/turtle/boom. Going for an early majority buyout of another player is akin to the rush, which is done by investing one’s money not in economic growth but in buying another player’s stock. This rush, however, can be beaten by a turtle strategy, which means buying up shares of one’s own stock, especially that all-important fifth share that prevents a majority buyout. However, the turtler will lose to a player planning to boom by investing as much money as possible in upgrading her HQ, expanding production, and usually building the first Offworld Market. Completing the circle, the boomer risks losing to the rusher who only needs to buy those first six shares to knock her out. Most games of Offworld have specific key moments when this strategic tension is clear – when a player buys his own fifth share and blocks a majority buyout attempt or when a player spends all her money to upgrade to the final HQ level but forgot to buy enough shares to defend herself. The original stock system did not have these dynamics, so it’s interesting to consider how we came upon the rush/turtle/boom mechanics of a traditional RTS, basically on accident.