The Making of Orbitron: Revolution

Orbitron: Revolution is a realtime 3d shoot em up game inspired by a myriad of the genre's classics. The basic concept is that the player takes control of a space craft and must defend a ring shaped space station from evil robot forces.

I had been working in video games since October 1996, starting at Radical Entertainment. Over the next 14 years I worked on a myriad of projects and ended up completing work as cinematics director on Dead Rising 2 at Blue Castle Games, later Capcom Vancouver. I had always wanted to get a small game of my own design off the ground and unfortunately was not given the opportunity at any of the larger studios I had worked for. I left Capcom Vancouver in November 2010, with the goal that I could finally play a part in building something, anything, of my own design. My plan was to complete a game on the visual and design front and then find a partner to do the programming, having an established core to work from.

The idea for what I wanted to create came from looking at a piece of artwork that I had modelled quite a long time ago that later became the basis for the Orbitron Ring. The model was a half circle outer space sports stadium for a whole other game concept I had been playing around with, one that would have been too complicated to follow through on. Originally, the sections that made up the design faced inward as opposed to outward and visually it was take on Halo and Killzone architecture, with strong 45 degree support struts, panels, and built in lights. Not being one to waste artwork, I took this original 3d model and tried to figure out a way of using it another way.

I'd been a fan of Pom Pom's Astro Tripper on PC and loved how the ship controlled and flipped around on a direction change. If you haven't played it, it was very much an old school, possibly Williams inspired, shmup with a modern take on controls and action. While that game was visually 3d with primarily 2d gameplay, it was also top down and with finite level sizes. I thought that I could make a similar game but in a side perspective and using a looped environment.

This quickly led me to thinking about the deluxe arcade version of Darius with its three screens showed you enemies from quite far away. While 16:9 is great it still isn't wide enough to capture such panoramic perspective, so my solution was to use the ring I had designed and flip it so it faced outward. The player would then be looking down the curvature of the ring, seeing more than they would otherwise if the environment was flat or curved inward. The environment being a loop would also mean that travelling in one direction for too long would put you back where you started, which was ideal. It is a self contained game location with no start and no end and could become a character unto itself.

Incidentally, this is why the game is constantly suggested to be a Defender clone when it was never intended or designed to be one. The environment design more or less forced the Defender environment loop into the game. As well, the shifting camera perspective is part and parcel in a game where the player has freedom of motion in both left and right directions.

Going into 3ds Max I set up the ring model using a 40 sided cylinder, and the original ring section as a guide. I then simply guessed at the scale required. Though, I had one rule for myself. The ring needed to have an actual North, West, South, and East as well as in-between sections at perfect 45 degrees hence the 40 sides, each at 9 degrees. This was done for simplicity sake of clean modelling and scene management in 3ds Max.

As soon as the ring design was cemented, I needed a reason to have the player move at all and came up with a number of ideas. Having enemies attacking the ring was one of the first ideas and it stuck. Though, originally I wanted to have all 40 parts of the middle strip of the ring attackable. This simply became too complicated to visualize and convey threat to the player so I settled on 4 clearly marked Sector Ports, taking a cue from Star Wars and a myriad of other sci-fi shmup concepts.

After this was settled on I started working on an enemy cast. I wanted each to have clear, fair, patterns. The ring attacking Driller was first in the cue due to the initial key design of the Sector Ports but it was actually one of the last to get fully modelled and textured.
The cast would include a classic arcade game looking lander (Drone), a Mario Bros. Boo like ghost (Scout), a Defender/Geometry Wars style splitting enemy (Atom), a fast, direct enemy like the red jets in GeoWars 2 (Fighter), a classic arcade game UFO like in Asteroids/Space Invaders that shot at you (Scanner), finally an enemy you needed to concentrate fire on like a bomb (Carrier) and then could be chained like barrels in Doom. Finally, taking another cue from Super Mario Bros, I wanted something large that rotated that would simply get in your way and force you to move up, down and around (Sword).

Visually the enemies needed to look like they are from the same family, designer, and factory but have very different silhouettes so they could be indentified easily during fast action. To this end, each enemy has a central beveled cylindrical power center. They also share 45 degree angular design, and most of them have floating "feet" or fins. They were also uniquely coloured, though I ran out of unique colours, and had a unique self illumination light pattern on them.

Not knowing where my poly counts should be for a game at a decent framerate I intentionally designed all assets to be as angular and low poly as I could get away with. The angles were meant to look intentionally part of the physical design, and not a product of a technical limitation.

The player ships were designed to be a hybrid of a racing vehicle you would see in Wipeout and a military ship from Homeworld. I previously worked on Homeworld: Cataclysm and while working on it I talked with and closely studied Aaron Kambietz and Rob Cunningham's artwork, which was inspired by the artist Chris Foss, among others. Inspired by that style from many years ago it led to the coloration, decaling, and stripes that the vehicles sport. Knowing too that the ships would be seen aggressively banking left and right they were designed to have a sexier top and bottom than side profile.

While I had done a lot of modelling in 3ds Max in the past I rarely did any serious texture mapping. For the first time I had to take a model, unwrap its UVs, and bring it into Photoshop Elements to get painted. Looking at tutorials all over the internet I created a Photoshop template that became the basis for every asset in the game. It was a very simple core setup with a model specific baked ambient occlusion at the top, a scratch layer, grime layer, panel layer, inset layer, panel line layer, and a underlying steel layer. The panels, insets, and lines were blended in Photoshop so I could just use simple white or black colour fills and the layer effects would automatically do the beveling work.

The biggest single piece of artwork in the game is actually the bay where the player select's their ship. The location is essentially valueless in terms of gameplay, however it was designed to serve as a flow bridge between what would be the front end UI and the game itself. It was put in only to add visual production value to the game and make everything seem bigger than it really is.

The overall look of the game was to be very much inspired by Psygnosis's games on Playstation 1. They had very graphic futuristic designs, corporate decaling, lots of lens flares, glows, and trail effects. I thought that this was the perfect game to lend that style to.
Long before the Orbitron: Revolution project ever started, I was interested in Microsoft's XNA community games initiative. Through that I had read about the Sunburn Engine by Synapse Gaming, which is beautiful lighting and shading editor for XNA. The renderer has since become more of a game engine and is currently rumoured to be moving into monogame territory and allowing the engine to be more platform flexible. I highly recommend taking a look at it.

http://www.synapsegaming.com/

What Sunburn Engine had basically allowed me to do was use Visual Studio to run one of the prepackaged samples and then overwrite the sample artwork with my own. So I wouldn't have a game but I could see what I built and textured on an actual Xbox and fly around it using the debug camera. I would take the assets I had built, place them dramatically in 3ds MAX and then export the file as a .fbx and view it in the Sunburn Editor.

The Sunburn shader system allowed for a diffuse map, specular map, normal map, emmisive map, and specularity control among other switches and dials. I made the most of what the renderer could do and each asset would use most of the shader features.

After being satisfied that I had a good template for a game did I hook up with a good friend of a friend to start assembling the game.

Starting with simple flying and shooting, then moving on to adding the enemies and their predesigned behavior it started to come together. Even though the game was intended to be a ring defense game at its core, we knew we wanted to give the player a bit more to choose from and this led to the inclusion of another game mode.

The first mode we designed and implemented was Countdown mode which is the 3 minute score attack mode. It was inspired by Pac-Man CE and Deadline in Geometry Wars 2. The mode gives the player a fixed time period and consistent enemy types but random positioning and the player has to make the most out of it.

While obvious before starting work, was that the mode, and game, needed a HUD to give the player information on enemy positions. Originally we wanted to do a 3d one that showed pixel enemies surrounding a simple colour coded rotating 3d version of the ring. It simply was too complicated to get right and was abandoned in a few days of having no luck with it. The next idea was to do an old school 2d radar.

We had considered making the radar not scroll like it does and instead move your screen space down the line. It was quickly abandoned as when the player approached the edges of the screen they may have been lost in TV safe frame. The solution was to keep you in the middle and have the enemies and ring scroll with you, much like Defender does.

Once the HUD went in and we could tell where the enemies were dropping we quickly found that constantly spawning enemies, with infinite player lives, was dull as dirt. To break the monotony we came up with the idea of breaking the mode into distinct Waves.

The moment the Waves went in it made the mode more psychologically engaging. Much like in Asteroids, the player simply has a burning desire to clear the screen and ring of all visible enemies. We started with a handful of enemies have the player clear them, then add more and more types, and so on until we pack the screen with stuff. It was basic, but the clear change with the addition of the Wave was a massive step to making Countdown into a fun mode to play.

The enemy spawns for Countdown were controlled in a few ways. We simply increased enemy types and numbers as the player went from one wave to another. However, there was a trick to the spawning that was a necessity for the mode. When enemies spawn in they originally started off in random directions. As a result, enemies that appeared farthest from the player would begin vectoring away from the player, increasing their distance away from the player. This created a very unfortunate situation where the player would clear out what was around him, and then have to resort to long time burning chase downs of stragglers.
To fix this issue we simply forced all enemies, upon spawning, to head toward the current location of the player. Having them come to you was a much more fun than you chasing them down and sped up the action significantly. We later found that there was a "bug" that got into the game as part of this. When you died the enemies would once again switch direction and travel toward you when you respawned. This "bug" actually made the game even better as the chase down time was once again cut down so the bug became part of the design.

While the new spawn and direction logic fixed the majority of the gameplay issues with the enemies there was still the chance that something could get by the player and they would need to chase them down. As part of the initial asset creation I had also build a piece of hardware called a Boost Gate.

These were designed to speed the player 90 degrees around the ring quite quickly. They were really the anti hyperspace gates from a game like Stargate. In that game it was random where you ended up and most of the time you simply died by dropping right on top on an enemy. We wanted something clear, understandable, desirable, and most of all fair when used. When accelerating after passing through the gate you become invincible and may destroy anything you happen to collide with. Also, upon slowing down you let loose a small powerwave that destroys enemies that happen to be in proximity. The gates worked fantastically well. We added in a nice post processed motion blur effect to accentuate the speed.

Simply shooting at enemies was all well and good, but the game required a more involved scoring system. We knew we needed a multiplier system. We went about designing this twice. Initially it worked more like Geometry Wars: Retro Evolved where there were multiplier thresholds. The player shoots 20 enemies and they were at 2x, 100 enemies 3x, 400 enemies 5x, etc. while functional you could say it didn't work and was confusing.
The solution was to do what a fighting game like Street Fighter does where each hit in a combo was counted as a multiplier increase and a long enough break in the combo chain dissolved the multiplier. It made a 1:1 correlation between shooting an enemy and getting a multiplier so it was very clean. In addition we had the voice and 3d models for the multiplier number appear on screen to reinforce the current level. We had though that after 100x Multiplier that it could keep going so we recorded the actress saying the words "Extra Multipler." In the end we made 100x the top as a clear ceiling.

To further the game mode and make the player move around more we added collectable Power Cells. They appeared and collected much like the enemy death spawning Geoms in Geo Wars 2. The player was to collect these items to try to build up to having enough to release a Power Shot. The Power Shot was designed from inception as a big blast that would do a full 360 degree of the ring, destroying anything in its way. It was our initial take on a Smart Bomb for a game like ours. The downside to a Power Shot was that if you later collided with it you would also be destroyed by it, creating a risk and reward for the ability.
Later, added the screen clearing Wavebomb out of necessity. We wanted to give the player something that they could use if there was no hope in out flying the enemies surrounding them and give them some air.

It was through suggestions during play testing that adding in a Turbo for your craft would be a good idea. We didn't want an ability that the player could rely on at all time or make the Boost Gates unimportant so we made it so that turbo could only be used if the player had some power collected via power cells. While using Turbo you would burn power you had collected and the players up/down control would be a little more limited.

One of the big features to Countdown Mode was the idea of creating a Replay Theater. Conceptually I thought that if the game was to become popular with the score attack crowd like Geometry Wars and Pac-Man CE were that the game would benefit from a way to see what it was a player did that got them a big score. We captured and saved the positions of near everything into a replay buffer and then gave the player the ability to play, pause, fast forward, and rewind their most recent play session. They could also change the view between the stock gameplay camera and 4 other view points. While the mode was difficult to create technically it was very satisfying to watch and use. At the very least it especially helped with creating marketing materials such as screenshots and captured footage.

The main game mode, Guardian, came together quite quickly but was actually very tricky to pull off properly. In the mode, the player had to protect the four sector ports, located around the ring every 90 degrees, from being destroyed by the enemy drillers.

Initially we thought that perhaps the Sector Ports would actually repair themselves slowly after they had been saved. This however made the mode go on forever. I wanted the mode to feel like a slowly sinking ship. The longer you could keep your head above water the higher your score and the longer your time in the stats screen. If it could go on forever what separates one player from another is simply time investment. Sooner or later people will get so good at the game that they could keep the ring alive forever and then the highest scores would be dictated solely by those with the most time to kill. That was the antithesis of game design based around a leaderboard.

Taking the repair out meant that sooner or later the health of the sectors would hit zero, however the problem was greater than that. The player could fly from a 90 degree point on the ring to the next 90 degree point in about 12 seconds give or take avoiding regular enemies. That meant that if Drillers were spawning in 12 second intervals it was possible to never have the ring get damaged. The player could simply fly from one port to the other killing Drillers as they went. The solution was to start them at 12 seconds, and then drop to 10, and finally to 8 seconds. At 8 seconds, even with Turbo, and Boost Gates the player would find it hard to keep up. Also, the deeper into the game you are, the more regular enemies spawn with the Driller, making travel even harder/slower. The design no longer became about feel, it became about mathematics.

Driller visibility was an issue as well. The player can see only about 20 degrees of the ring at once, and the HUD could get very busy. To fix this we had a Driller spawing in with a Posse. The Posse would first appear en masse around a Sector Port, forming a visually dense collection, and then the Driller would come in with a loud and unique sound effect. We also used a HUD Arrow Element and voice work to suggest where and which Sector Port was under attack.

In Guardian, the failure state was also set so that only 3 of the 4 sectors needed to be destroyed in order for the ring to explode and have a Game Over. This was done on purpose as if the failure state was all 4 then the player could simply sit by a single Sector Port, abandoning the other three.

In both game modes, We have the player respawn upon death outside the ship bay. This was purposeful penalizing for the player. In Countdown Mode it meant that if the spawns were getting farther out because you were flying around a lot you would have to need to travel. In Guardian it was a benefit and a curse as sometime you wanted to die so that you would respawn seconds later near a sector that was currently under attack (however you lose your current score mulitplier when you die). Many good Guardian players will keep Sectors A and D alive as death will have you spawn between them so you can be in a better place to defend either. It is still next to impossible to stop the sinking ship.

Both original game modes were intentionally designed away from the classic video game convention of giving the player finite lives. The thought was that both modes were already tied to an inevitability of time. Being destroyed and burning time waiting to respawn was penalty enough. It also cleaned up the ingame HUD, not having to track another in game statistic.

All particle effects were accomplished using Dynamic Particle System Framework or http://xnaparticles.com/

The beauty of DPSF was that it would render incredibly fast, have stock examples to pull from, and would also achieve additive translucency which Sunburn Engine could not do at the time (It does now). Every piece of additive rendering you see, such as the holographic shields infront of the ship bay and the boost gate holograph are actually single quad based particles positioned in code.

We had a pretty great playing and looking game but we started to seriously need real sound effects and music for it to play as being a high end Xbox Live Indie game, approaching Xbox Live Arcade Game quality.

For music I had played a good 200 hours of Geometry Wars 2 and seeing as though I had never gotten bored of the music in it I thought I would attempt to get Chris Chudley of Audio Antics to do the music. As luck would have it, (though this is very bad luck really) Bizarre was in the process of closing down and Chris was actually free to help work on the game. I simply emailed him, and told him what our needs were, and we quickly settled on getting music created.

The music for Countdown was done much like Chris' work on Geometry Wars: Retro Evolved 2 Deadline mode. In that game, and Orbitron: Revolution the music has distinct changes every 30 seconds. This is done so that the player can hear the music change and know where they are on the clock without having to look up at it. Important if the player is solely focused on the action on screen and not on the upper HUD.

For sound effects I had Paul Ruskay of Studio X come on over to my place to view the game. He suggested simply doing a captured video of the game to bring to the studio. When this was ready I then went to Studio X to show the game footage to the audio team there, and they asked me to make a master Excel list of every sound we thought we needed. Also they suggested a fantastic voice actress and singer would could do the voice work for the game. Over a period of a couple weeks they built sound effects and we did a little back and forth trying to get things right.

Close to release on Xbox we added a new game mode, called Extra Mode. The only reason why it is called that is because we didn't want to go back to audio record and have to pay our actress for another session. Instead, we dug through the sound files we had captured and found the old "Extra Multiplier" one. So we cut the clip in half and put the "Mode" part in from another recording. It was either that or have Extra Mode not have a voice declaration which would have been inconsistent.

Extra Mode was simply Countdown Mode without the timer or Waves and increasingly aggressive enemy spawns, but the player is only given a single life. In a way it was very similar to how the game started except that the single life added a very grave failure state.
The other audio problem we had was that we only ever have 4 music tracks. One for the Front End, one for Ship Select, one for Guardian Mode, and one for Countdown Mode. So Extra mode didn't have its own music track. The solution was to simply use Guardians music track over it.

Orbitron: Revolution uses a few features of Sunburn Engines fantastic realtime lighting tech. First of all, there is a mid range desaturated blue ambient light that effects near everything in the scene to give everything a space ambience. The models all had a baked in ambient occlusion in their diffuse channel, allowing flat ambient light to still look quite good. Sunburn also a shader effect that they term a normal map ambient occlusion so normal maps still show up in flat ambient light, which is a nice bonus.

Second is the sunlight which is a bright yellow direct light that casts realtime shadows. Only the Ring and the players ship actually cast shadows. The enemies however receive the shadows, not cast them, you only really notice if you look for it.

Because 1/2 the ring was bathed in light and the other half was blanketed in shadow we needed a way to make the shadow side look more interesting. What we did is put a point light inside of the player's ship and turned it on and ramped it up when he enters the shadow side. For both the red and blue ships it was colour coded as well. Originally we wanted this light to be casting shadows but the performance hit was unbearable but looked incredibly cool.

Sunburn Engine supplies HDR, Fog, and Bloom effects right out of the box. We tried the HDR and it looked ok but removed some of the colour saturation of the game. Fog was pointless in space so we disabled it. With the bloom, it took a very long time to find a pleasant balance where the game had a glowing luminance but was also pretty visible. It really came down to personal preference from tester to tester so we settled on the amount that we had. Personally I would have liked to have seen more bloom on the stations lights and less from the sun reflections on the ring itself.

Orbitron: Revolution was the first game I ever worked on where I had to create a UI/Front end. We wanted something that fit the subject matter, was clean and easy to understand, minimal but tech, and did a few things differently.

Placing the main game logo offset to the left, with the ring rotating on the right was the very first concept that I came up with and it worked pretty well. Then, placing the Main Menu options in the upper left corner was something I had never seen done before. On the visual side I used translucency, rasterlines, static, and glowing outlines. Unselected items would be translucent and monochrome with selected ones being filled and in colour. While it worked well, it didn't remain completely consistent when it came time to add in the "Milestones" via an update to the game later on.

The UI was done three times over. First was a rough in, trying to get a feel for it. The second time was full on production, completed front end. The third time was a complete redo of all of it due to needing a PC version that was pixel perfect at 1080p. I made the stupid mistake of doing a 720p FE instead of a full HD 1080p one. So I needed to go back, trace out the older material and redo it all at 1080p which took about a month of effort. The next stupid mistake was baking all of the typography into the Front End elements, meaning that the game cannot be localized to another language without stripping it all down again.

Two trailers were created for Orbitron: Revolution. The first was a requirement for entering Dream Build Play and would be the full reveal of the game to the world. I spent a month in 3ds Max and Premiere cranking away and animated sequence that would bookend the trailer. I also had to do all of the slates that appeared to show off features of the game. I simply used the actual in game models and set up the shading and lighting conditions as they were seen in the game. Then animated and rendered out each shot, as well as layers I could tweak for post production effects. In game footage was actually the PC version at 720p captured in Fraps. At the time both versions were absolutely identical so I didn't think that it was any kind of cheat at all.

Reveal Trailer.
http://youtu.be/8yO8HW0Dl8U?hd=1

The second trailer was the same setup as the first trailer. Pre-rendered sequences cut into captured gameplay. Once again, the trailer took about a month to create and I had learned a few nice effects to highlight text. It was also determined that we would not repeat much from the first trailer and instead highlight what was new.

Launch Trailer.
http://youtu.be/OGPce6P5BmU?hd=1

The out of pocket costs for the game was around $5000 total. This is of course not counting any salary draw or office overhead that was later required to finish up the game.
We entered Orbitron: Revolution into Microsoft's 2011 Dream Build Play competition. We were selected as a top 20 semi finalist out of more than 200 game entries! While we didn't get selected as a winner for any of the prizes it was still a fantastic opportunity and event to be part of.

After incorporating Firebase Industries, Orbitron: Revolution was released on December 1st 2011, a little over a year after I had started working on the game. The actual time it took to build the game was far less. At an 8 hour and 5 day work week I estimate the time to be closer to 7 or 8 months of development at the top end. No matter the time it was still the fastest I had seen a game come together from inception to completion.

Reaction to the game upon release was quite positive. Most of the reviewers who played it really enjoyed it. The extremely honest and critical Indie Gamer Chick had it as number 10 on her top 10 Xbox Live Indie Game Leaderboard for a short while before it was bumped off. We received positive press on Joystiq, Destructoid, Game Informer and Kotaku as well. Disappointingly we never were mentioned on larger sites such as IGN, Gamespot, or Giant Bomb even though the effort was made.

Unfortunately, sales expectations for the game were never met on Xbox Live Indie Games. Even in comparison to Radiangames' titles such as Crossfire or Ballistic we fell far short of what the posted sales for those games were. Orbitron: Revolution has struggled harder on PC. Having been declined from Steam twice by Valve, it is now sitting on Steam Greenlight at 1%. It has since been selected as an IndieFort Championship bundle game so there is hope for it finding a wider audience.

If you are interested in trying Orbitron: Revolution it can be purchased on Xbox through the Xbox Live Indie Games Marketplace. The PC version can be found on GamersGate, IndieVania, and ImpulseDriven / Gamestop. All versions are currently the same price at approximately $3.

Since release of Orbitron: Revolution we are hard at work on our follow up title at Firebase Industries, Arcadecraft which is a real time strategy arcade economics sim due for release in October 2012. You can follow Firebase Industries on Twitter @FirebaseIND and visit our webpage www.firebase.ca