This article originally appeared in Dev.Mag Issue 27, released in November 2008.

SpaceHack is one of two Game.Dev DreamBuildPlay 2008 entries. It eventually placed among the top 20finalists in the competition. The following is a discourse by one of the game’s two creators about the creation process and the story behind the game.

“SpaceHack is a Hack-and-Slash, Rogue-like top down shooter. In space.”

I have lost count of the number of times I have uttered that phrase in the past few weeks. Add the number of permutations (like adding SHMUP or mentioning Bullet-Hell if the person I’m talking to looks like a gamer) and I’m surprised I still feel enthusiastic about the game at all. I always forget to emphasise the random generation of everything aspect…

But, hand-in-hand with most of those explanations have come the smiles of people playing our game for the first time. Exclamations of surprise, “oh cool”s at the enemy shapes the generators create, screams of triumph and defeat. All of those blend together into one simple message: People are having fun with this; they’re enjoying something we feel isn’t done yet, so we have to be on the right path here.

Along with that enjoyment comes the interest. People take notice when your indie game runs on an Xbox 360. They take even more notice when you drop in choice phrases like “infinitely replayable” and “randomly generated story”. SpaceHack has opened a lot of doors locally, doors that I plan to keep wide open to the rest of the stuff that will emerge from Game.Dev. SpaceHack and Ultimate Quest are but the first of many. But I’m supposed to be talking about our game, so I’ll reign in the big picture stuff and start again.

SpaceHack began as two things: A racing game and random ship generator for a grandiose space opera in the vein of Starcontrol 2. I’ll look at the racing game first because it’s the least intuitive.

At some stage late in my university career (so we’re heading back to the scary days of late 2004 here, folks) I had an idea for a 2D racing game with a different control scheme: Instead of having a player steer a car via discrete full left/right and complete brake/accelerate binary key-presses (I feel that a controller’s analogue options make driving games much better), why not have a player control a car’s orientation on the road absolutely via the mouse? That would be an analogue turning system, providing much more control. If the player kept smoothly dragging the mouse in a direction, they’d corner accurately and responsively. If they jerked the mouse right or left quickly, the car would go into a drift and behave differently, leading to gameplay possibilities via the controls. The idea was to have angles that the car would “let go” of the road on, so drifting and spinning would be very important parts of the game.

I started prototyping the idea and quickly got a system going where the player’s car would be stationary on the screen and the entire map would rotate around the car according to the motions of the mouse. I ran into issues with the car physics though and my impetus quickly ran dry. Sarcastically I added a shooting capability and a few arbitrary targets and filed the prototype away as yet another of those rainy day projects that could take some work when the inspiration to do something new was lacking. I revisited it a few times over the next few months, adding a star-field for grins and at one point spending an enjoyable few hours coding Robotech-style missiles just to see if I could.

Everyone liked the missiles. That went into the book for later.

Around the same era I was spending non-digitally enabled time writing story ideas for a Starcon 2 style game down on actual physical paper. I was doing a lot of travelling due to my then girlfriend’s family (marriages were going down, people were hitting important age milestones, that sort of thing) so there was lots of sitting around in hairdressing salons and idly daydreaming about galactic civilisations, the rise of sentience and the stabilising effects of odd anomalies like the Earth’s moon, punctuated by obligatory “ooh”s and “aah”s at the latest sculpted and flower-adorned majestic head ornamentation.

Once people got used to the idea of being married and the rampant ageing had calmed down, I got back to my regular base of operations and decided that I hated doing art for games and this dramatic space opera would require far too much of it. So I started messing with algorithmic approaches to generating spaceships. Prototyping revealed that the simpler methods were best and people that saw the resulting collections of polys were amazingly quick to give them recognisable characteristics: Calling them squid- or crab-like as often as they observed that this particular one should belong to a race of robots.

Both the huge galactic story and the random generation prototypes promptly went into the Big Stack of Game Ideas™ and didn’t go anywhere for a while.

Now, I think it bears explaining that I am a Hack-and-Slash aficionado. I loved Rogue and ADOM. I have aMUD character with 4000 hours of existence. I played Diablo to death. Diablo II destroyed more hours of my life than I am ready to admit to yet. Darkstone, Fate, Sacred and eventually Titan Quest all scratched that itch. I’d always had ideas around a H&S of my own, but never any real base to build on until one day the racing game prototype stuck in my head during a Game.Dev organised DevLAN about procedural generation: Why not take that control scheme and build an action-heavy H&S designed to be played to completion in short sessions? Similar in execution to PlasmaWorm’s Strange Adventures in Infinite Space (play that game if you haven’t already done so).

That would serve as the germ concept that eventually became SpaceHack. Every once in a while I’d add to the game a little, driven by inspiration or a session of “what if the game was already done, what would it do?” mental masturbation. That’s how SpaceHack got its unique elements: Things like combining skills and items into items with branching upgrade trees to streamline the play experience but still give players that thrill of random drops and customisable upgrades with options to explore differently next game; or the weapon preview scene to show players exactly what a newly acquired item would do when either equipped or upgraded, that way it wouldn’t need huge and possibly ambiguous or, worse, confusing text descriptions that bothered me in other H&S games.

That was why I picked the concept as my entry into the first DreamBuildPlay competition in 2007. I wanted to make it a console game and the idea, then called Void Escape because I suck with names, really made sense in the console space – a platform devoid of a good H&S for me to play. DBP proved a perfect excuse to test out my ideas on procedural generation in a wider setting: The game would need randomly generated maps, events, enemies, weapons and there was even scope for a random story system; But as things turned out time was not kind to me… A design contract went a little south earlier in the year and meant that not only was I struggling to pay for food for a while, I was also limited to just under 4 weeks to finish Void Escape before the DBP deadline.

I cut features like crazy and used everything I’d already learned about .NET from my previous DirectX 9 work, but it wasn’t enough to get anything nearly complete out there. I slept roughly 14 out of 120 hours in that final crazy stretch before submission. Void Escape didn’t place anywhere, but it did lay the engine groundwork for a lot of what would eventually become SpaceHack.

That November when I started my company, Quarter Circle Forward, to formally take over from my previous contract-based consulting, DBP 2008 was on the company schedule as something we were going to do. Whoever “we” ended up being at that point. Ideas for the next competition entry constantly spiralled their way into my design file: A much expanded Monochrome with a film-Noir story and multiple endings; a good way to do RTS on console natively instead of porting mouse/keyboard issues; a bevy of puzzle game concepts that I hadn’t seen done anywhere else; numerous game mechanics inspired by or hinted at in other games I played during that period; etc.

The part of the file marked “Possible DBP” grew large. Thus it was that in May 2008, when my longtime friend and nearly-longtime house-mate Marc “Aequitas” Luck quit his job to live off his savings and finally make games, DreamBuildPlay was high on the list of what we talked about. We’d spent our varsity days designing mods and games that never saw the light of day (but would have been awesome had they done so), which meant that we already had a good understanding of how each other’s design sensibilities worked. Together we fleshed out the ideas already in the file and added even more: Aeq had a zombie-based survival mechanic that bore exploring; Monochrome became Ninja Noir, developed a combat system and started growing a storyline; the RTS concept turned into a space-based considered tactical system set in a hard Sci-Fi future where you’d have to rely on information that got to you as fast as light travelled, we called it Redshift and prototyped the time-lagged fog of war effect; Void Escape was talked about, but rarely did we consider it on the short list of games we’d like to make for DBP. It had already “been done”, in a way.

When the competition was announced in June 2008 and the theme completely failed to help us make what had become an increasingly hard decision as to which game to do, we ended up choosing Redshift. What better way to make a splash as a small studio than to finally make a workable console-based RTS? We began working, Aeq was tasked with learning about shaders and getting his teeth into XNA, while I built a map system that would index by time as well as position and start on the scene framework we’d need for the game.

Aeq made good progress. This was his first real game project (sure, he’d been to DevLANs before and produced the odd Game Maker prototype while there, but this was in a completely different league), so there was a lot for him to get up to speed on. 3D programming in particular, hence being set the mission to understand shaders – I’d worked with him at university before, so I knew he was up to the challenge. And up for it he was, pretty soon we were attempting to write shaders that would draw the smooth curves we’d need for unit prediction paths in the game – he’d supply the shader code and I’d work on the math.

A few weeks passed and we learned a lot, but made very poor progress. Redshift just didn’t feel like it was gaining any momentum at all. I was running into a lot of stupid issues with the engine (at one point I simply couldn’t get textured quads to render correctly at all, yay) and our forays into parametric line shaders proved only marginally reliable. It was time to re-evaluate the entry and see what we could get done realistically in the time we had. Void Escape and Monochrome started dominating our conversations, but most of the people we asked still liked the sound of Redshift. We were right back to where we’d started, unable to reach a decision…

After a rather bad day we gave ourselves a week to mess with Void Escape, see what kind of progress we made and pick our best shot at the contest that weekend. We never went back to Redshift after the first couple of days. Void Escape got renamed and just didn’t have the bottlenecks that Redshift’s design did, building on an already working (if horribly incomplete and limited) proto-system made all the difference in the world: Every time I wanted a specific type of functionality in the engine or scene system, I’d start working on coding it, only to find out that I’d already done it a year ago in that sleep-deprived death crunch. Plus I apparently still comment under pressure, so I wasn’t lost in the code at all. There were some glaring omissions, like a relative-to-parent positioning system for objects attached to other objects, but congratulating my previous self’s foresight became a habit as we got further into development.

Working with someone else on the project is what made SpaceHack possible. Aeq really proved himself in those short months: I started off handing him tasks with the idea that I’d take his outputs and integrate them into the game and engine myself, but after I spent nearly a week optimising some slowdowns with my quadtree implementation where I was too busy to really pay a lot of attention to his work and he ended up integrating the entire particle system by himself – quickly turning it into one of the fastest parts of the game – I levelled up my management skills and let him get on with what he needed to do. Our previous theoretical game design ramblings proved invaluable at this stage: He would get what I was going on about and not only figure out what I would need programmatically to get it done, he’d add his own understanding to that and produce stuff that could logically do more without getting dangerously stuck in feature creep.

Aeq understood SpaceHack from a player’s perspective instantly, we knew how the other spoke about games, which meant that there was (and still is) no design document for the game. We had a few dedicated design sessions to handle story or broad thrusts of enemy design, but in general most of the game evolved organically from the core concepts as they started coming to life. We’d discuss the game on the fly and things would just magically emerge as cool and functional after that… On top of the shader-heavy implementation code like the particle system (when he showed me 40 000 particles onscreen simultaneously all animating independently without any slowdown I freaked out a little) or the geometry instancing that we ended up doing to kill a hitch we were getting with enemy bullets (of which there are usually MANY), Aeq turned the preview system from theory into reality and handled all of the enemy and boss firing patterns while I worked on the random systems and eventually player items and story.

I think the only regret either of us has regarding the game is that we want there to be more of it! The random generation systems that populate the game-world with maps for the player to explore, put enemies in those maps and give the player a story to follow currently only have a fraction of the content we’d like them to have available. The version we submitted to DBP has over 80 boss and enemy behaviour segments (which the game combines in any order according to heuristically determined difficulty levels that depend on how well the player’s currently playing), roughly 30 story events (unfortunately only 1 major story arc though, the nanomachine one didn’t get done in time) and over 40 player items to find or unlock.

So while the generators can take all that content and produce a game that is already very replayable and different each time (it takes an average of 3 plays through the game to see everything that can happen and many more than that to get all the items at least once) we had to cut tons of ideas and neat things we wanted to do because we simply didn’t have time. Pretty much all of the gameplay in the DBP demo version of SpaceHack was done in the last two weeks as individual segments and is turned into a playable game on the fly as you’re playing it. We want another few months to first produce editors for each type of system (story, enemy, player item) and then build as many objects in each as we possibly can so that you’ll be able to fire up the full version of SpaceHack and play it a hundred times and get a different experience every time.

But there will always be missiles, because everyone likes missiles… Yes, there will be a PC version eventually. But first we need to figure out how a small studio doesn’t go bankrupt if you don’t have cool stuff to sell on eBay.