Starcom: Nexus Postmortem, an Indie Dev Journey

The following is a condensed and updated version of a post from the game's blog.  

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” in the late 90's, 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.

My first game: PlanetDefender

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.

Screen from an emulated version of the 1971 Star Trek

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

Starflight: my earliest inspiration

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.

My second Flash game: Starcom

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.

My third Flash game and first attempt at an indie commercial product

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

Two tasks down, 8000 to go.

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:

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.

A planet from the original Flash game.

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.

Starflight: Amazing for its time, but the planet interactions are tedious and dated by modern standards.

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

One week after entering Early Access the game had sold over 1500 copies and grossed a little over $20,000.

First three months of Early Access

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 12^th 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.

Early access launch vs Full launch

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:

As of writing, a little under six months after entering full release, the lifetime results for the game so far are:

The net result has been that the game has so far earned me a bit over $8000 per month of development (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.

Starcom: Nexus is now available on Steam.