The following is a condensed and updated version of a post from the game's blog.
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.
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 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.
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 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.
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.
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.”