words

Warped Drive Mid-Mortem

8/11/2016

That's how it starts. It ends 427 commits and 357 days later with an original, unfinished, and very hard to play video game. I say "ends," but that's not entirely true. The game is over half-way done, I just haven't had the drive to get back in there and finish it up. I'm missing the drive because I've concluded that, despite my intentions, the end result of those 427 commits falls short of the "fun and compelling" mark.

What follows is the chronicle of Warped Drive, the most "complete," and most ambitious game I've worked on yet. I've titled this a "mid-mortem" in the hopes that one day I'll be proud of the last binary release. No, this post is more a cathartic log of how I got here.

Best Intentions

The innocuous looking IM above was sent to my siblings, all 4 of them. I had idly chatted about the idea a week or so prior, and some of us had time to kill, so we thought it would be fun to try. Unlike a future struggle with logo design, Harmonic Order (our studio) got named and a logo very quickly.

We went with the bottom-left one.

After a short discussion, we converged on one theme that the whole team was interested in: hacking. We broke for a few days so that each of us had the chance to come up with two or three pitches. We soon had three front-runners:

After a little back and forth about which was our favorite, the infected-starship game (now titled Warped Drive) became the front-runner. Brains were stormed as we came up with suitable game mechanics and tweaks to plot and setting. The pilot became a network engineer, and would be able to switch between meatspace and cyberspace. Meatspace gameplay would be centered on finding oxygen and accessing airgapped networks, and cyberspace would be centered on the anti-virus combat.

During this discussion, I wrote an "Appendix" to our design doc (a small essay, really) in which I outlined the perils of feature creep. It contained this ominous section:

This early in the design process, we have to be disciplined in what we seek to make. We need to pick things that can challenge us, but not overwhelm us. The more we pack in now, the less ‘room’ we’ll have to add features as the game development goes on. I’m not saying we should discard every original idea that we have as “too much work,” but we should pick our battles.

I was worried at the time that I was being too harsh with the readers of that mini-essay, that I'd scare my own siblings away from wanting to help. Now I look back and wish I had taken this cautious approach not just at the beginning of this project, but for the whole laborious process. But we're not to the regret yet, that comes later in the story.

Prototypical Hesitance

Our game design doc now had some important mechanics and a setting. What it did not have was a core gameplay loop. Switching between meatspace and cyberspace to manage your oxygen supply was a secondary gameplay loop. We didn't even have the genre of the core gameplay! Cyberspace and hacking have been presented as many different metaphors, from basic ASCII puzzles to graphically-intensive first person shooters. One of the earliest ideas the team had discussed took the "space" in "cyberspace" quite literally: server racks were solar systems, with individual machines being planets or moons. Software was represented as space stations or space ships, depending on their relative size. This appealed to us, as vehicles are always easier to model than humanoids.

At this point, instead of coming up with core gameplay on paper, I wanted to start prototyping. It had been over a year since I had messed around in Unity, so I was dying to dive back in and see how it had improved. Getting back into it was great! Unity had much better performance and more free stuff, like the Image Effects library. The very first commits of the repository were of a first prototype with "cyberspace-as-space flight sim" gameplay. The player zoomed around a little space scene. Since I now had to design the visuals of this space scene, I started thinking about how to represent cyberspace on a starship in the future.

Early tech demo of a cyberspaceship flying around a station circling the moon of gas giant with binary jet streams at the poles

The visual design now had a formula: cosmic shapes and patterns presented with the neon and pixels of cyberspace. The focus of the hacking gameplay was still unclear: is the player a one-man virus-busting starfighter? My limited knowledge of information security knew that using this conceptual base was a bad fit for the world of cyber-security, with its levels of complexity.

And Now For a Completely Different Genre

Our idea of the goal of cyberspace combat was limited to "clean viruses off of fancy sci-fi computers." We had no real idea of how to frame and present this idea. The tech demo was based on the idea that our sysadmin hero flys a single virtual antivirus cyberspace ship around, blasting individual viruses. After some thinking, this didn't sit right with me. The scope seemed too small. Sysadmins have to purge whole systems of malicious programs while worrying about the larger network. Yes, the space setting was a good fit for action/space flight gameplay, but I consciously rejected the idea that the gameplay was restricted to those categories. But if not that, what genre should the gameplay fit into? Puzzle? Platformer?

After a lot of thought, I settled on Strategy. The sysadmin acts as a general, sending their anti-virus software into battle after battle to win the overall war. The core gameplay would be: create anti-virus units with available resources, anti-virus units remove viruses off of machine, move to next machine, repeat until the whole network is clean. I thought I had some good mechanics too: individual antivirus scripts (units) would require CPU cores (resources) to deploy, and your choice of scripts was constrained by RAM (loadout). Unfortunately, I didn't take to heart my own careful warning that feature creep can kill a project. Choosing to write a strategy game, while perhaps the right choice for some reasons, was the wrong choice for ensuring your game is fully completed on a timeline of months.

Let's Get Down To Business

I sketched out a 'vertical slice' of the game:

  1. A main menu with new game and load game buttons
  2. A 2D meatspace map with the ability for the hero network engineer to collect oxygen
  3. A cyberspace overworld with combat level selection
  4. A cyberspace "workshop" for "programming" anti-virus units
  5. A cyberspace combat level
To cut down on development costs, meatspace would be done in 2D, and cyberspace models would be created from spaceship meshes and primitives. And so I started coding. Quite a lot of coding. And prototyping. And modelling.

Virus Prototypes: bomber, torpedo, tank (left to right)

A month goes by and the vertical slice is coming along nicely: players can start a new game, load an old game, and transition through meatspace into cyberspace. The cyberspace workshop for units is scaffolded and three combat levels are done. A few weeks later, and there are three different enemy unit types, and three different antivirus unit types. My own playtesting seems pretty fun- viruses blow up, computers are conquered, and levels are winnable, even though they are pathetically easy.

UV Mapping the Tank mesh

Things seem really good! I start spending time on lore and plot. The New Game screen is written to provide the backstory: the player signs up to be a crewmember on a "Wormway Construction Starship" that lasts 10 subjective years and 25 Earth years. I start sketching out the plotline - as the player disinfects systems, they will learn more and more about the virus mastermind, before journeying in meatspace to find a stowaway AI core in the cargo hold. I add a Database object into combat levels that can be scanned to reveal lore documents, to give both a collectable and another outlet for more gamesetting information.

I add a few new combat mechanics as well - a key and door system to gate movement between nodes in combat, and an "artillery" object that fires missiles that can cross nodes and applies minimum damage to viruses (and is utterly overpowered.) An ability is added for the player to "interrupt" combat, freezing time. I theorize it should work to give players additional time to strategize.

Final design for the cyberspace overworld

Your Own Cassandra

Around this time I get really concerned about the core gameplay: it feels entirely deterministic. Most levels can be beat by just one tactic: spamming units. Actual strategic choices are few and far between, and most fall within the question of attempting to attack a well defended position for a larger reward vs taking a lightly defended position for a lesser reward. This is problematic: better level design will help shake things up, but I need more mechanics to play with or my "strategy" game will be a joke. To address these issues, I come up with a simple level mechanic and a much more complicated systemic mechanic.

The simple addition is to add a very badly needed enemy respawner. This makes the low-level unit spam approach much harder, but I make a mental note to use it sparingly so as to allow spamming to be viable for some of the levels.

The new virus-spawning miniboss hovering above an infected server

The second addition is much more novel - I eliminate hit points and replace it with a one-hit-kill percentage-based-dodge system. Each unit has a chance-to-kill when attacking and a chance-to-dodge when being hit by an attack. Exceptionally strong units have extra "lives." Buffs and debuffs for these two percentages for support units round out the mechanic. This new system is implemented quickly and adds some much-needed randomness to the gameplay.

I add one last mechanic to the game to enhance the player's agency and give more strategic depth: sysadmin abilities, on a cooldown. They have immediate effect, like banishing virus units for a time, but have a slight chance to backfire. The "freeze time" pause introduced earlier in development now becomes invaluable as a way for the player to stop and think about these abilities, or stop the mayhem to trigger one. Only four or five are planned, and are intended to be rewarded to the player after cleaning every level in a world.

Inordinately happy with the new mechanics, I get the game into a playtestable shape.

How do I do anything?

It's now February, five months in. At this point the player can complete 6+ cyberspace levels, the virus can fight back and reinfect computers (upping the difficulty), and all 6 antivirus unit types are available. I eagerly show it to playtesters, asking for any and all feedback.

These controls feel weird.
It's very...interesting.
I have no idea what I'm doing.

While all of the feedback was supportive, and phrased nicely, I knew I had a problem. Playtesters had a really hard time figuring out the control scheme. They didn't know what they were looking at, and they didn't know how to play the game. It wasn't their fault: they were all gamers, used to all manner of genres and control schemes. They had problems with this game, right in front of them.

Playtesters can't figure out how to pan and zoom. Playtesters create units, watch them die, and then sit back, baffled as to what to do next. In retrospect, it's easy to see why: I've succeeded in making gameplay that is novel but I've framed it in a way that it is utterly alien to even accomplished gamers. I have a strategy game with no fixed-height sidescrolling overview and no resource mining. I have units that cannot be grouped with a click-and-drag, cannot be put into formation, and cannot receive new orders once spawned. Battlefield fronts are presented as 3D but are effectively a 2D plane. Abilities aren't in a center-aligned row, they're off in the corner. Number keys don't trigger abilities, they spawn units.

I start on a tutorial to try and fix this glaring error in my game design. Progress slows to a crawl. There's a lot to explain to a user, the use of keyboard-only bindings is complicating everything, and I'm having a having a hard time communicating the big picture.

Not Fun Anymore

It's now March. I'm still working on Warped Drive but not at the same pace as I was. I know I must finish the tutorial levels or no-one will ever figure out how to play the combat levels without me there to hold their hand. Tutorials are a real pain to code. The "easy" way is to just label the UI and have big button prompts, but that always feels ham-handed. Good tutorials have a kind of light story, walking players through steps. The problem is that both the easy and the hard way require a bunch of tedious code to handle all sorts of things: what if the player clicks this button first? What if they can't figure this part out? Questions on how to implement it quickly grow out of control.

I periodically take a break from the tutorial code to make larger, more complex levels. Even after all the redesign, I still can't shake a sinking feeling about the core gameplay. Antivirus combat is still pretty predictable; the challenge is almost never how to finish the level, it's more a question of when. This lack of challenge is even more egregious given that the oxygen time limit mechanic is still in full force! Players still have a ticking clock to play against, and winning a level is never exciting. That's the real sucker punch. The game isn't exciting. I could fully finish out all the other features, upgrades, and lore, and I'd still have paint-by-numbers core gameplay.

I'm pretty discouraged at this point. Faced with the twin problems of an unteachable UI and a core gameplay loop that feels deterministic, I mentally surrender. Solutions for these twin problems that don't involve months more work are nonexistent after days of brainstorming. After the mental surrender, the drive to grind out commits every day fades. I go a week with no commits to the repository, reassuring myself that it's just a little break. Two weeks after that I am no longer deluding myself: active work on Warped Drive is on hiatus.

426 commits with 45 commits in one week
Look at all those commits!

Continue?

Things aren't looking good for Warped Drive. I don't have as much free time to work on it as I did back when development was in full swing, and I have yet to find silver bullets to fix the issues it has. At this point, I intend to wrap up development by adding in placeholder levels and literally adding big labels that say "Incomplete" for features that weren't finished. To fix the tutorial problem I may include a static image dense with instructions on the first few levels.

What did I learn from all this? I learned that venturing too far into new territory can leave people lost. A game with too many novel features has too much to explain. Creating an environment that isn't in the physical realm throws out all the rules we've experienced as humans, and presenting a game unlike any other disconnects gamers from their accumulated knowledge of how games work. Perhaps if I had used a standard RTS view, it would have been easier for playtesters to understand. Conversely, if instead of viruses I had spaceships and solar systems, the novel UI and mechanics may have been easier to grok. Lastly, I learned that core gameplay (especially with new and unproven mechanics) needs to be engaging. It's not enough to approach it early, get a working rough draft, and call it good enough. This, in retrospect, was harder a lesson to learn, as it's such a monumental mistake, and an obvious one. Warped Drive isn't my first game, but I'll be sure to apply this lesson with every game after it.

In the end, I'm glad I got to have the learning experience from this failure. One day I'll finish a game, but today is not that day.

If you want to browse the code, check out the GitHub repo, and if you're interested in playing the game, check out the Warped Drive website.

If pictures of the final result are good enough, a gallery of screenshots is below:

-Alex