My Start
My career as an indie game developer got off to a late start.
I spent most of my professional life as a web developer, initially as a general purpose “webmaster” before specializing in UI during the dot-com era, then switching to server and database development. It wasn’t until I was in my mid-thirties that I decided to try my hand at game development.
I had a couple of ideas for games, but with no game-specific development experience I decided to start small with a fairly basic “tower-defense” game called PlanetDefender. I built it with Adobe Flash, simultaneously learning ActionScript as well as general principles of game design. It took maybe a month or two in my spare time. I was very happy with how it turned out, despite not being my “dream game.”
Most aspiring game developers have a dream game: the game in their head that’s just itching to get out and is invariably too ambitious for their skills.
Mine was in a venerable genre that doesn’t actually have a name: 2D space exploration action-adventure where your ship essentially is your character.
This genre can trace its roots back to the very popular and very unofficial Star Trek games of the 1970s (and possibly even earlier with influences from Spacewar!, arguably the first video game ever).
But my primary inspiration was a game called Starflight.
Starflight was one of the first entrants in the genre to fully realize its potential by combining RPG elements with a procedural sandbox universe. Incredibly advanced for its time, it inspired numerous others include Star Control II, Escape Velocity, and many others. It had multiple alien races with unique ships and dialogues who varied their disposition toward you depending on your actions. It had a galaxy of nearly a thousand planets, most of which you could land on and explore. It had an engaging story that unfolded through exploration.
I wanted to create a game like that: a vast open universe of exploration with aliens to meet and battle, and stories and mysteries to uncover. Unfortunately, one tower defense game under my belt wasn’t quite enough experience to make that a reality.
But I still wanted to try to make a simplified version of that vision.
My initial attempt was relatively modest in scope, but still a big step up from the tower defense space game: it had fast-paced combat with multiple weapons and upgrades, a simple story line and some light RPG elements including ship upgrades. There were no alien races you could talk to, the planets were simply window dressing and the whole game could be finished in about an hour or two. But I was immensely proud of the accomplishment and like PlanetDefender, it was fairly popular among the Flash gaming community.
Since the dominant form of making money from Flash games was ads and sponsorships, which usually paid pennies per thousand plays, neither of these first two games made a substantial amount of money relative to how long they took me to develop. Which was fine because this was still a hobby for me.
At this point I felt I had enough experience to attempt to make a game with the goal of doing it professionally.
After my last web dev contract wrapped up, I set myself on the task of developing my third game: a multiplayer real-time roguelike dungeon crawler called Lost Crypts. It was loosely inspired by the standup arcade Gauntlet that had eaten hundreds of my quarters as a kid, but with rogue-like procedural dungeons.
It took a little over six months to develop and I spent $1000 on art and music. Players generally enjoyed it, but my attempts to make money from it failed utterly. At the time, my understanding of both game marketing and free to play monetization were quite limited. I told myself and others that it was successful as a learning project and portfolio piece, which is true, but privately I felt I was failing as an indie developer. My games had made a lot of people happy and I don’t think people should be valued based on how much money they make, but realistically I couldn’t afford to continue as an indie dev making less than minimum wage. And Lost Crypts didn’t even recoup its external costs.
So I returned to contract work to pay the bills. During that time a few players tracked me down to ask if I had any plans to make a sequel to my space RPG.
In the era of Flash gaming, a developer released a game and if it was popular it would end up being re-hosted on numerous websites. I had the foresight to have each game “ping” my webserver when a player started a new game so I could have a count of gameplays, but there was no way to connect with the many players who might be interested in my next game. Which was a mistake I would later regret, once I learned the importance of marketing in game development. This might seem obvious in hindsight, but since my first two Flash games reached hundreds of thousands of players with no marketing effort on my part, I sort of assumed that if you made a good fun game people would find out about it somehow.
Better late than never, I set up a mailing list so players who visited my website could let me know they wanted a sequel and say what features they thought it should have. A few hundred interested players found the list, bringing with them the hope that there might actually be a market for an ambitious game like the one I’d originally envisioned.
The Meandering Road to Release
By this point, it was clear that I needed a new engine for the project: the writing was on the wall and Flash’s days were numbered. So I switched to Unity, which seemed like the most reasonable option at the time.
According to my task tracker, the first two chores I completed while working on the game were “Install Unity” and “Spacegame tutorial parts 1-8,” both marked as done on April 5, 2014.
Over the next few months I worked part time between contracts at a slow but consistent pace until I had a playable demo: the controls and combat worked similarly to the Flash version. Unity’s lighting and particle effects made everything seem much more polished.
At this point players would certainly recognize the seed of Starcom: Nexus.
But it was very far from a complete game. The RPG elements were still superficial and without them it was just a top-down shooter with boring pauses between the action. I could definitely see how to recreate a prettier version of the Starcom Flash game, but I was having trouble visualizing a path to “epic open world RPG of space exploration” that I dreamed of.
After being rejected from showcasing the game at a game festival, I became discouraged. I went back to full-time freelancing and put the game on hold. I didn’t touch it again for almost two years.
In 2016 during a lull of contract work, I started on it again. A few ideas, once implemented, started to fill in the gaps in game play: I implemented a discovery system where players could get “research points” by finding new things. I added a Research Tree where players could spend those points to get faster engines, new weapons, etc. I created a system where players could build their ship from modules, increasing the feeling that the ship was their own.
And I started to fill in the game’s content with visually interesting things to find, conversations with various characters and lots of pretty planets. I wrote and re-wrote a backstory to tie everything together.
By March 2018 I’d made significant progress but was getting concerned about the fact that I’d spent several thousand hours and several thousand dollars with no clear sense as to when it would be done. With no roadmap, deadlines, or stakeholders it seemed like I could go on forever and never release the game.
I think this pattern was driven by a fear of failure. As long as I kept it in “experimental pre-alpha side project mode” I never had to confront the possibility of putting my hard work out there and failing completely. With the previous disappointment of Lost Crypts, I was afraid that another commercial dud would effectively be the market telling me: “You’re so bad at this, you don’t even know how bad you are.”
I needed to commit to a decision: Either a) admit to myself that this was just a hobby and return to focusing primarily on contracting work, or b) approach it as a business with the potential to be something that players would love and provide a real return on its development cost.
If I went with the second choice, I decided that it was not necessary that the project be 100% profitable in terms of recouping all external costs as well as the full opportunity cost. Instead I decided to analyze the chances that it could pay all external costs plus a living wage for the remaining development time, while ignoring sunk costs (a “bygones principle” analysis). This was an admittedly low bar, but perhaps not unreasonably low: If I reached it while simultaneously building a base of happy players, it increased the likelihood that I could continue with a sequel reaching true profitability.
As a starting point, I had a spreadsheet of games released in recent years that were in the same nameless genre as mine. Using established heuristics, I verified that there were a fair number of titles produced by solo devs and small teams that seem to have sales at least at the level I was targeting. But with caveats: Survivorship bias made it difficult to locate the games similar to mine that had launched and were never seen again. There was no “starflight-like” tag to easily identify the also-rans.
Also at this point the industry was well into the so-called “Indiepocalypse”: every week a new story would appear on my radar of a developer who had spent years on a game only to sell a few hundred copies (or worse).
To minimize the worst-case scenario risk, I committed to three things:
- Get a playable beta of the game in front of real, potential customers by mid-Summer 2018 to verify I wasn’t way off course;
- Generate market proof by releasing a version for sale within 12 months (e.g., Early Access), which meant by early 2019;
- Make a serious effort to better understand how to market the game.
Design Issues
Before this story plunges ahead into beta and beyond where you’ll learn the outcome of my quest, I’m going to rewind a bit and talk about one of the many reasons it took so long to get from “Unity Space Game Tutorial” to “Playable Beta.”
I had made a fun Flash game that was basically Asteroids with some RPG-lite elements. I also had ambitions of an open-world PC RPG that could evoke feelings of exploring a large and rich universe full of wonders. Actually combining those two concepts in a way that produces fun and coherent game mechanics is harder than it sounds.
Compiling a list of the major design decisions I had to visit and revisit would take longer than I am prepared to spend on this postmortem.
Rather, I’m going to tell the story of a single illustrative feature: what I call “The Planet Problem.”
The Planet Problem
In the original Flash game, planets were just decorative landmarks near where the player might encounter enemies. They looked pretty, helped orient the player, and generally made space seem less empty, but they had absolutely zero game play effect.
One of my high priorities for Starcom: Nexus was to add some kind of interaction to planets. I imagined them like treasure chests in RPGs: having defeated whatever menace was guarding it, the player would be treated to the reward of discovering what was in the box.
As I mentioned earlier, a major source of inspiration in the game’s overall design was Starflight, which had a very sophisticated planet exploration mechanic for its time. The player would pick a point to land, send a rover down (accompanied by an impressive 3D landing animation) and drive around a 2D map collecting resources and avoiding dangers.
It was a great mechanic for a game released in 1986, but hasn’t aged well. Essentially it boils down to turn-based Pac Man without the maze. Forcing the player to engage in a mini-game that is less fun than the actual game they are playing isn’t a great reward.
What I wanted was something fairly quick: a sense of anticipation and mystery, some agency, then concluding with the potential of a reward.
My first playable prototype of this mechanic was a targeting mini-game. The player right-clicked on a planet, then scanned it. If the scan revealed “anomalies” the player could target them with their lander. If they hit, they received the anomaly’s reward:
It was sort of fun, but only for the first half dozen times. Targeting the anomaly had some skill due to the rotation of the planet, but if you missed with any frequency at all, the whole thing felt frustratingly tedious. If you mastered the targeting, it was just a time sink.
I experimented with several modifications, but it quickly became clear that no variation was going to be fun for hundreds of repetitions throughout the game.
One of the most difficult decisions in game development is tossing a feature after investing a lot of time and energy into implementing it. But sometimes a game mechanic just doesn’t work.
So with some regret I simplified the interaction. The player scanned the planet and was informed if there was something there or not. If there was, they could send a lander down to investigate, no mini-game at all. I also simplified the UI by removing the separate scan window: the player just flew to the planet and pressed a key or controller button.
At this point, all anomalies consisted of a title, an image, static text and resource reward. There was a sense of mystery and the potential for reward. I could tell it would be more fun than my first attempt, and the fun could be scaled up with more variety of anomalies.
The next question became: “how much variation can you have with static text and one of eight possible resource rewards?”
Based on a mechanic I encountered in the game Out There, I added multiple choice options to some of the anomalies, giving more variety and a greater sense of player control to the surveys. I also added the potential for penalties, like the loss of crew.
Next I made it so that some of the choices could open up into a second set of choices, based on the first. Finally, I noticed that anomalies were starting to look more and more like multiple-choice dialogue trees, which I had already implemented for NPC conversations. So I scrapped the anomaly data model and turned all anomalies into “conversations with a planet.”
Because the dialogue system supports scripting via Lua, and I’d already created API hooks into the game logic, this opened up infinite possibilities for the complexity of anomalies.
For example:
- A giant stone structure with a control room inside. If the player activates the controls, a nearby warp gateway becomes accessible.
- Aliens with a disabled ship. The player can offer to help if they have sufficient resources.
- A rogue trading outpost which requires a password to enter (which the player can learn from conversations with another race). Once inside, the player can trade resources or purchase unique items.
- An underwater labyrinth. If the player sends a crew member down, they must navigate through a Colossal Cave-style labyrinth in a limited number of moves before their oxygen runs out.
To help distinguish the anomalies, I started creating images for them using a 3D environment modeling tool called Vue and then editing them in Photoshop. My first attempts to create distinct environments for the anomalies were not very good: they looked like the pre-rendered backgrounds from 90’s adventure games. To conceal the low-quality of images, I created a shader that added static and video scanline effects, simulating an image transmitted from the surface (nevermind why humanity switches back to CRTs in the future.) and reduced the display size of the images to 400×400 pixels.
With practice, I learned how to improve the quality of my anomaly images, so I was able to scale up the image display, but I kept the shader effect because it made the images seem more alive.
My improvement in creating anomaly images resulted in better-looking encounters, but at the expense of taking more time. While I found the process a relaxing break from other areas of game development, I’m a bit of a perfectionist which led to spending lots of time polishing the results.
Combined with writing the anomaly text, and writing the custom logic in Lua, meant that each anomaly took several hours to create on average. I couldn’t repeat many of the anomalies without breaking the immersion of exploration and a star system with no anomalies feels empty and disappointing. There are roughly 200 unique anomalies in the game and they all took at least a few hours to create including image, writing, custom logic and testing.
The Feedback Cycle
Not every element in the game required as much time as the Planet Problem, but almost every major feature took multiple attempts to get right. So Starcom: Nexus didn’t start its first round of beta testing with actual players until early August 2018, after the equivalent of a fulltime year of development.
Beta testers were randomly selected from the game’s mailing list which had been very gradually accumulating subscribers and were about as “in market” as I could expect. If a significant portion of them didn’t like the core gameplay, I had a serious problem.
Initially, I started with small test rounds of a dozen or so players with the goal of identifying the big problems, gradually increasing as Early Access launch approached.
Qualitative Feedback
Qualitative feedback is a player’s subjective impressions of the game. It’s what they consciously report liking and not liking in the game. It could be given in person, email, responses in discussion forum, etc.
For the closed beta tests I implemented an in-game system where players could submit feedback any time by pressing F8, which paused the game and brought up a dialogue where they could put in their thoughts along with a rating for how they were enjoying the game. This was an interface I copied from Subnautica. A reminder was subtly, but constantly visible in the lower corner of the screen throughout the closed beta and Early Access, as well as one of the possible tips that could appear during game loads.
There are a number of advantages of this system:
- The ability to give feedback any time allows me to captures impressions that players may forget by the end of their session.
- The anonymity of the system makes players less likely to feel that they have to soften their criticisms or they must say something good if they’re saying something bad.
- I can easily collate feedback based on the game’s version from the database.
The only significant disadvantage is that it doesn’t prompt players to give their gestalts impression of the whole game as an experience. Some players might elect to give it at some point, but many did not. To help with this I encouraged players to submit their impressions via other channels like the Steam forums.
The qualitative feedback was overall very positive and helpful: players professed to really like the game play and had suggestions on how to make it better.
Analytics Data
Player feedback was probably the most important source of data on what needed fixing, but to reinforce and validate that feedback I also collected anonymous event data to ask statistical questions like “how long does it take the median player to finish the game?” or “what percentage of players who start the first mission finish it?”
It also helped assuage the notion that perhaps players were merely being polite: e.g., having been given access to the beta, they felt obligated to give some kind of positive feedback.
But combined with analytics there was a strong case that some players were really enjoying the game. In the first limited round of beta tests, half of players stopped playing very early on (within two minutes) for reasons I wasn’t immediately able to figure out. But of those who made it past the first few minutes, almost all finished the available content. While it was conceivable that a player might launch a game and give some quick impressions to be polite, the fact that a good chunk of testers played to the “end” was an encouraging sign.
A pleasant surprise was that the game was longer than I thought: I could play through the current content in 20 minutes, so I had guessed new players might take 30 to 45 minutes. Real players averaged 90 minutes. With a goal of at least 4 hours of gameplay for Early Access, I wasn’t as far away as I feared.
Observational Data
Analytics data tells you what players are doing and qualitative feedback tells you what they are feeling. Combined they give you a lot of insight into what is and isn’t working. But observation fills in gaps that you might be missing. For example players may wonder aloud what would happen if they did “x.” Players who aren’t sufficiently engaged may quit in boredom just before something interesting happens.
As a specific example, I mentioned earlier that a non-trivial percentage of players stopped playing very quickly, within a few minutes. Was the game’s performance bad? Did they just not like the genre? Neither the players nor the data were telling me.
I speculated that they missed the instruction that they should head toward a specific objective, so I made the objective indicator brighter and flashing. This change cut the number of players who failed to make it to their first objective in half, from 13% to 7%.
It wasn’t until I observed a player in a live session that I realized some players thought they were supposed to follow the ship that had given them their orders, and had their eyes fixed on it, ignoring the glowing, flashing arrow in the corner of the screen. Worse, once the player was sufficiently far from the objective, it was removed from the radar.
I added a relatively minor change to have the first officer gently remind the player, if they continued in the wrong direction. I also extended the radar range for mission objectives. These changes cut the early drop-out rate from 7% to 5%.
These fixes to the first half hour of the game were huge: consider 1000 players starting the game. A 13% drop out at the beginning of the game is an immediate 130 players whose opinion will be mediocre at best. They will likely return it and/or leave a negative review. It’s hard to connect minor improvements in the early experience with the overall response to the game, but I strongly suspect they have a more than trivial effect. As an aside, Steam reports the game’s median playtime of 9 hours to be “above average” (although they do not say what the average actually is).
Over the next several months I repeated a loop: release a build, email a batch of fresh testers, gather feedback and analytics, implement the changes that players either asked for or I inferred were needed, create new content, and repeat. By late October things felt good enough that I could launch in 2018 before the Winter Sale, so I announced a release date of December 12.
Marketing
I am probably not unique among indie devs in that marketing is not my favorite game dev activity. I’d much rather just spend my time working on the game than try to talk about it at all.
But all my research has consistently pointed at one conclusion: the success of a game on Steam depends almost entirely on reaching its market before launch. Using Steam review counts as a proxy for sales, review score as a proxy for quality, and pre-launch followers as a proxy for market awareness, the rank correlation between quality and sales is 0.25 (weak) and the correlation between pre-launch awareness and sales is 0.86 (strong).
As mentioned previously, when I decided to commit to Starcom: Nexus as a serious endeavor, I also committed to start taking marketing seriously.
I started a marketing journal. I made a list of games in the same “space” as mine, either released or upcoming, and read their reviews. I made a list of YouTube streamers and journalists who had covered those games. I tweeted often. I posted videos and images to relevant Reddit subs.
One aspect of the game that was a problem from a marketing perspective was the lack of clearly identifiable “hooks.” As I mentioned earlier, the genre doesn’t even really have a name. When prospective players asked in the discussion forum what other game it was like, there was no consistent answer.
The game’s best feature was really hard to communicate in a short clip, GIF or marketing blurb: the sense of exploring a mysterious open universe. In a post-launch player survey in which players checked-off their favorite parts of the game, exploration was the most selected. When players talked about their favorite aspects of the game, it was usually a response to something that was hard to convey visually, like discovering that by aligning a pair of mass accelerators, they could be transported to a hidden star system. The event itself was not spectacular—it was the delight in discovering something unexpected.
I tried to convey the exploration elements by showing planet surveys, alien dialogues and space artifacts, but my trailer ended up focusing mainly on the most eye-catching aspects of game play: enemies exploding in fireworks of particles and pretty space settings.
In the aforementioned player survey, I also asked how people learned about the game. Here’s what players said:
- 79% saw it on Steam
- 12% saw a YouTube or Twitch streamer play it
- 6% played the original Flash game
- 3% saw it somewhere else
Because I didn’t post the survey until after full launch, it probably underestimates the number of players who learned about it from the original Flash game, since I think they were more likely to have been on the mailing list and bought it in Early Access. But it does underscore the importance of the Steam algorithm working as a multiplier of your marketing efforts.
Note that I say “multiplier”: it has been consistently observed in data and anecdotes that 95% of games which launch with little to no public awareness vanish into obscurity, buried in the avalanche of other titles released that week. Games that achieve sufficient traction are shown more prominently by Steam’s algorithm.
Entering Early Access
Early Access (EA) is a program where players can buy a game they’re interested in while it’s still in development, like a paid beta. They know the game isn’t complete, but are willing to take the risk for the opportunity to experience it first and to influence its development. Not every game that enters Early Access makes it out: some are abandoned soon after launch as developers realize that there was nowhere near as much demand for their vision as they had hoped. Others languish for years before enthusiasm flickers out. But contrary to reputation, quite a few games do use the program as it was intended and emerge with a better quality game as a result of a high intensity beta. Subnautica is probably the most well-known example, going on to be one of the best-selling games on Steam, but there are plenty of others: Rimworld, Dead Cells and Slay the Spire are a few examples.
From a sales and marketing standpoint, entry into Early Access needs to be taken seriously. For almost all games on Steam, EA or otherwise, their launch week shapes their entire return. Almost all games’ first year sales are a single digit multiple of their first week, generally clustering around 3 to 6 times. E.g., a game that sells 100 copies in the first week could expect to sell 300 to 600 copies in the first year.
From my analysis of visible Steam data, many EA games receive some kind of bump when graduating to full release (sometimes even a big one) but if a game hasn’t found some footing in the market at the start, it will almost certainly fail.
I had personally committed, both to myself and players, not to abandon Starcom: Nexus during Early Access.
But my savings were not inexhaustible. By this point I’d spent 3800 hours over the equivalent of 16+ full time months and roughly $10,000 of my own money. This is excluding the larger cost of, you know, living. I’d been working 60 to 70 hours a week for several months. Combined with the uncertainty about how the game would fare, this was producing a large amount of stress.
There is a scarcity of hard data to predict a launch success, particularly for EA titles. One analysis done by Jake Birkett estimates that during its first week, a game will sell 0.5 copies for each player who has wishlisted it before launch. But this was a limited survey and there was a range of results: from 0.14 to 1.8. Moreover, the games surveyed had mostly been released at a time when Steam was seeing fewer releases per month.
I felt a worst-case scenario would be the game selling only 400 copies in the first week. Combined with a pessimistic tail model, that could be as low as $30,000 lifetime, and that’s before Valve took their revenue share. If it did that poorly, my plan was to do an aggressive but abbreviated Early Access and start sending out my resume in a few months. I did not believe this was a likely outcome, but it was a possibility that had been magnified in my anxiety-wracked mind, which had begun contemplating “even worse than worst-case” scenarios.
A slightly more optimistic model was 800 copies the first week. With a reasonable tail and a moderate bump on graduation, this could justify the “bygones” decision I’d made, at least in the sense that I would have made more than a living wage from the time of that decision to the time of full graduation. Which is a very forgiving criteria, but also excludes the value of an established audience for future games. In this scenario my plan was to spend 6-9 months in EA and after launch evaluate the possibility of a sequel.
At the most optimistic end, I estimated as high as 2000 copies in the first week was possible based on wishlists and followers.
After nearly 4000 hours of development, I pushed the launch button that officially triggered the game’s entrance into Early Access.
After an incredibly stressful first day, it became clear that the worse-case scenario wasn’t going to happen: the game sold over 500 copies in the first 24 hours. The sales rate dropped rapidly after the initial rush, but I had expected that. Like the first week making up a significant percentage of annual sales, the first 48 hours usually make up a majority of the first week sales.
One week after entering Early Access the game had sold over 1500 copies and grossed a little over $20,000.
At this point, I’d like to draw attention to a convention in indie PC game development: when developers publicly talk about gross revenue, we are not usually referring to the money we receive before expenses, which is the standard accounting definition of gross revenue. We are referring to the money Valve (or another distributor) receives. Why? I don’t know, probably because it sounds more impressive. But that amount never appears in my bank account. It’s like including part of your boss’s salary when someone asks how much you make. So when I say the game grossed $20,000, I mean that Valve collected $20,000. After various deductions like VAT, returns and Valve’s revenue share, Wx3 Labs LLC (which is just me) grossed around $12,000. Which still sounds pretty good for one week, except that a) I had spent $10,000 in development and b) sales drop off a LOT after the first week.
Even though I had only net $2000 in profit for my 16 months of labor so far, this was a good start and I could at least hold off work on my resume for the moment and focus on finishing the game.
Early Access Development
The beta testing paid off in the sense that nothing went catastrophically wrong on launch. Players were in general very happy: the first few dozen player reviews were all positive, and after 100 reviews it had a score of 94% positive.
But it was still obviously a work in progress. After several patches to hot-fix a few potentially serious bugs, I started work on the first post-release milestone, adding features and content to extend the game from a polished beta to a full game.
I tried my best to be accessible to the players via multiple channels: I checked the Steam discussion forums every day, was always logged into Discord and read the “F8” feedback logs regularly. And, as painful as it was, I read every single negative review on Steam.
Listening to players’ pain points gave me the best insight on where the game needed work. At the same time, I had to resist the temptation to pivot the overall design based on the strongly expressed opinion of a handful of players.
Over the next ten months the game grew. From a few dozen star systems to over 150. The median time for players to complete the game increased from six hours to well over twenty. I added features that players asked for like attacks drones and quick-saves. Towards the end I added an element that I had conceived of and teased in the very first piece of concept art: a mysterious Dyson sphere that the player could enter.
The game continued to be well-received and saw spikes in customers with sales and Steam events, but after the post-launch cliff, average revenue continued to slowly drift downward: it looked like the game was experiencing a fairly typical Steam release life cycle. There was plenty more I could do on the game, but the longer I spent the less overall return I would see, and the less budget I would have for my next project.
I also wanted to make sure that the game graduated from Early Access before I was too burned out to properly support it. The game had a beginning, middle and end. The core features were all in, tested and well-polished. In the Steam Store description I had pitched a 6-12 month Early Access period and that was rapidly running out.
So in late October I announced a December 12th release date, exactly one year after the initial launch.
Graduation Day
In the lead-up to the game’s graduation from Early Access, I had frozen development to ensure that the first version non-EA players experienced was as bug-free as possible. There was plenty for me to do: market outreach to potential streamers, more analysis on the analytics data and even starting preparatory work for the next project by improving my 3D modeling and texturing skills.
I also spent a lot of time trying to guess what would happen when I pushed the “launch button” for the second and final time.
By this point, the game was doing “great” by indie game dev standards but just “okay” by the standards of someone trying to start a business:
After one year in early access it had sold 6500 copies and grossed $98,000. After Valve’s cut, VAT, and other deductions that left $60,000.
During Early Access I had spent another $10,000 in external costs for a total of roughly $20,000. That left $40,000 in net revenue. Divided over the entire development lifecycle so far, that worked out to $16,000 per year. That’s more than US minimum wage but just barely, and not even close to a living wage.
But there was the fact that unless graduating from Early Access actually caused sales to drop to zero, the game had expectations of earnings that would continue to come in over its lifetime, albeit at an ever-diminishing rate. My ballpark guess was that with zero graduation boost, the lifetime return would work out to around $32,000 net per year of development after external costs, before taxes. That’s for the full development lifetime, including both the “pre-commit” time when I had yet to really analyze the prospects for the game, plus some amount of post-graduation support.
On top of the financial return, I had gained a lot of skills, both in technical and design areas, as well as a much better understanding of the business aspects. I had a base of several thousand players with a positive experience who might be interested in a sequel.
And there was the hope, expectation even, that graduating from Early Access would produce a measurable sales boost.
Conventional wisdom among devs is that you only get one launch and you should treat entry into Early Access like it’s your only shot. Anecdotally, some indie developers have reported little visibility boost on graduation, but others have seen a significant increase in sales.
During pre-EA market research, I had been tracking a large cohort of Steam games that launched around the same time as mine. Some of those were also Early Access titles and a dozen of those had graduated by this point. Most of those showed a spike in review counts after graduation that suggested a healthy increase in sales, in some cases apparently matching or exceeding the EA launch over a slightly longer time period. A few of the titles, however, showed no increase at all around the time of their graduation. And again, review counts are only a rough proxy for sales. Guessing from limited data (which was something I did a lot of while wearing my indie market analyst hat) I thought there was a good chance the game would sell at least 30% of its initial launch numbers in the few weeks after graduation.
In my marketing journal, the day before full launch I wrote: “My best guess is that first month of graduation will sell between 700 and 3000 copies, but that’s a wide range.”
A few hours later, apparently gripped with pessimism, I added: “I have now convinced myself after looking at Steam that it will get no boost above a normal sale.”
Those late fears turned out not be realized. Quite the opposite: initial sales were well above my projections. In the first 24 hours of full release Starcom: Nexus sold over 1000 copies, and another 1000 in the next 24. Numbers began dropping rapidly after that, but after a week the game had grossed almost as much as the entire year of Early Access. That sounds a lot bit better than it really is because of how front-heavy game sales are, but it was still fantastic.
So I was wrong in my graduation predictions. It’s the kind of wrong I’m delighted to be, but it was still wrong and it would be helpful to understand why.
Looking back, there were several major causes:
- In my examination of recent Early Access graduates, I think I had subconsciously “rounded down” some of the graduation ratios (ratios of graduation week review counts to launch review counts), possibly in a sub-conscious attempt to avoid severe disappointment.
- A number of graduates had their graduation review counts spread across a wider time frame. I.e., while most launches have the bulk of their first reviews in the first week, many EA graduates saw the reviews spread over 2-3 weeks.
- During Early Access I consistently had around 1 review for around every 30 copies sold. After graduation, that ratio changed to about 1 review for every 40-45 copies sold. If that shift holds true for other Early Access titles, it would explain a good chunk of my underestimation.
As of writing, a little under four months after entering full release, the lifetime results for the game so far are:
- Steam gross revenue: ~$400,000
- Copies sold: 24,000
- External development expenses (music, art, licenses, etc): $25,000
- Total development time: equivalent to 30 full time months
The net result has been that the game has so far earned me a bit over $7000 per month of development time after all expenses, before income tax. That result from creating the game I’ve always dreamed of making is a feeling I can’t describe. I am tremendously fortunate to have had this opportunity.
What Went Wrong
No game postmortem would be complete without a list of things that the developer would have done differently.
Overall, I think there were very few significant missteps. Some things that I might do differently in the future were still the correct decisions at the time, I think. For example, the game has minimal procedural generation because I wanted to focus on a crafted experience as I learned what worked and what didn’t. But maybe in a sequel I’d try to create a game with more replay value and greater universe variation.
But there were a few regretted decisions that I think other developers could avoid:
Dialogue Structure
I used a third-party tool to author the game’s many dialogues. This sped things up enormously, but created a problem: multiple missions are managed by a few characters. The open world nature of the game meant that players could interweave missions in unpredictable ways.
If multiple missions depended on one character, players would sometimes find particular plotlines blocked until they completed a task, at which point suddenly several missions would progress all at once. For example there was a rare sleeping sickness that the player’s ship could be infected by, but a character they need to talk to for the cure might be pre-occupied with an imminent invasion of sentient goo.
There was no good way with the tool to inject conversation topics into a dialogue tree, nor to link to specific nodes of another conversation. The overall plot of the game (and budget) was not conducive to having one character for every mission. So either I had to have a really huge conversation tree that covered every mission in the game with a cascade of conditions to determine priority, or use this “queue” system where conversations would wait in line for their turn with the character.
I think a better system would be one where a scripting system could inject and remove topics from a character’s tree. Their intro would depended on whatever the highest priority mission was at the moment, but once inside a character’s tree the player could always ask about any active missions. A side benefit would be allowing the tree to detect which branches had new topics.
Content Creation
Most of the content creation was done in Unity, which is both a game engine and editor. In general, this allowed for superfast prototyping and iteration. But there are some limitations in this regard:
- Unity becomes progressively slower the larger the project. Part of this is due to compilation times, which can be mitigated with packages and assemblies. But the largest part seems to be with Unity serializing everything. It’s not slow by project compilation standards, but it’s slow enough to act as a drag on iteration.
- Unity content can be managed with source control, but its format is somewhat opaque. I’ve noticed that Unity will often make changes to asset files for non-obvious reasons. When I go to submit a change in Git, there are suddenly fifty prefabs who have decided that their m_Mesh objectReference or whatever has changed from 99772313 to 129203923 or something, despite me not having changed anything.
- It’s difficult to support modding. Technically, I could provide some API for modders to create assetbundles to import into the game, but a) that’s going to be a challenging workflow if they don’t have the original project (which I couldn’t distribute if I wanted to because of 3rd party plugins and assets), and b) it’s unclear how Unity’s licensing tier system applies and might require every modder have an expensive Pro license.
Mission Log
Missions underwent several design and technical revisions throughout development. There wasn’t even a mission log for players to track what they were supposed to be doing for the first two closed beta rounds. This wasn’t a huge problem because the game was still fairly short at that point, but the lack of building a solution early on made the eventual mission log feel bolted-on and less than ideal. In a player survey gauging interest in a possible sequel, I asked players, “What parts of the game do you think most need improvement?” The mission log was the most frequently chosen option, with half of players checking it.
The Save Problem
One decision I didn’t really confront until late in development was how to handle compatibility between saves and game updates. This is a really easy situation to find yourself in when you a) don’t have any players, and b) your game isn’t very long. Which is the starting state for all games, and it can seem like a low priority when you aren’t even sure how you are going to get players or how to make your game long.
It’s also a problem that only applies to the category of games that have large and complex save states, like open world RPGs.
In Starcom: Nexus, there are a lot of persistent interactions: planets to be explored, characters to talk with, mission lines to progress, etc. The universe is fully open, meaning the player can wander almost anywhere at any point. If they point their ship in the right direction and fly long enough, they can enter star systems and meet aliens that most players don’t encounter until very late in the game.
With each save, the game stores all the persistent objects in the universe: the stars, planets, ships, etc. and any information that can change. As I developed the game, the universe changed. I added sectors where there weren’t any before. I gave planet anomalies more choices, characters different dialogue options, and so forth.
There really wasn’t a simple way to port saves forward. Even if I hypothetically implemented one, it would compound QA enormously. Besides the additional testing load, if a player reported a bug, I’d need to determine whether it was a bug in the version they started playing in, or any of the subsequent versions they’d upgraded to.
After researching what bigger, more successful games had done, I decided to follow the strategy of Divinity: Original Sin 2, a hugely popular RPG that also went through Early Access. Which was to not try to implement save compatibility and have content updates require a new game.
During Early Access, there was a period of “opt-in” where new content was available to players on a beta branch. After suitable testing, the build was moved to the default branch but the older branch was preserved so players could switch over to it if they were half-way through their play (Steam does not offer the option of letting players opt-out of default branch changes).
This generally worked “okay,” but if I do a similar game in the future I would like to see if I can find a way that does not break saves with new content.
Conclusion
This postmortem has turned out to be longer than I originally planned, thank you for having the patience to read through it.
To aspiring indie devs reading this: I hope that it has some helpful guidance. I would like to caution that most developers who eventually find success do not do so with their first game (Remember, Starcom: Nexus was my second attempt at a commercial release, and fourth overall game).
To the game’s players, I’d like to thank you sincerely and deeply for allowing me to bring my dream to life.
End Note:
I began writing this in December and had it mostly finished before COVID-19 upended everyone’s lives. If you are stuck inside somewhere I hope that it was an entertaining diversion and that you are staying safe and healthy.