Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Postmortem - Starcom: Nexus

    - Kevin Lin

  • 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:

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

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

    Hey planet, how's it going? Got any resources?

    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.

    My first attempt at an anomaly image.

    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.

    The scan/survey mechanic in action.

    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.

    An anomaly image after I'd gotten some practice


comments powered by Disqus