This incredibly detailed postmortem, written by Resogun lead programmer Harry Krueger, offers a look behind a huge number of technical and creative decisions behind the popular shooter.
Written by Harry Krueger, lead programmer on RESOGUN at Housemarque.
RESOGUN is a fast-paced, explosive horizontal shoot 'em up that was released alongside the PS4's launch in November 2013. It was developed by Housemarque, a company that has been around for 20 years now, and published by Sony XDev Europe.
RESOGUN was in development for a total of about 20 months or so, with an additional 12 months added to develop the two expansions for the game: Heroes and Defenders. The core team was 12 members strong, with frequent support from our R&D and art departments, so in total about 20 people total worked on the original version of the game.
Voxels are essentially 3D pixels, and are quite literally the building blocks of the RESOGUN universe. At Housemarque, we've been making arcade-style games for a while now by marrying timeless gameplay values with cutting-edge tech. During the time of RESOGUN's inception, we were considering ideas for our next big game and voxels seemed like a natural way to express this "neo-retro" design philosophy. We quickly came up with a few concepts to utilize this aesthetic approach: one of them was a shoot 'em up, another morphed into an unreleased mobile game, and a few more never made it out of concept phase.
The name "RESOGUN" was coined by Petteri "Petsku" Putkonen, one of our guys at the time. The "RESO-" prefix touches upon the concept of high " RESOlution", and the "-GUN" postfix was added since -- being a shoot 'em up -- we predicted you'd occasionally be shooting things.
The pre-production process was rather simple: Before we started development we made a concept video of the game, featuring a rough estimate of what the visuals and gameplay would be like. I remember when Harri Tikkanen, our creative director, first showed the video to me; being a huge shoot 'em up fan I instantly recognized this as my dream project, and I insisted I'd work on the game if we went ahead with it. A few months later, development started.
Image taken from the concept video.
In the beginning we were fairly platform-agnostic. At the time we had PS3 and PS Vita dev-kits in house, so we used those as a reference for potential platforms. When considering possible multi-platform development though, the weakest platform always becomes the lead. In the context of our early development, this meant that RESOGUN was initially targeting PS Vita hardware, and all the technical possibilities and limitations that came with that.
We started implementing the game using the Super Stardust Delta engine. Since both games shared a similar design approach (being shoot 'em ups mapped onto a 3D surface), we were able to utilize many of the existing sub-systems and start working on the base version of RESOGUN immediately.
Preliminary concept art for an early version of the game.
Aesthetically, we started out on a somewhat lighter note. Initially we were planning on having brighter colors, blue skies, and a more naturalistic tone, to represent environments that we thought would be the human habitats. The first level we prototyped had a huge tree in the background, and the humans were in small huts. We eventually shifted away from this and went for a darker tone.
For the gameplay, we knew from the start that we wanted a horizontal, fast-paced, skill-based shoot 'em up. We've been largely inspired by classic arcade games, and we wanted to do our part in keeping that arcade spirit alive. Our goal was to achieve that "one more go" feeling, and create a game that's easy to pick up and hard to master. "Depth without complexity" was a mantra we followed; allow the main game to be simple to pick up and play, but create some layers of depth for those looking for that extra challenge.
Adding some humans for the player to save worked well with this approach. Much like Defender and Datastorm (two of our key inspirations), introducing this extra gameplay layer of saving the humans created an interesting tension for the player, as they needed to balance their "shoot and survive" abilities with a clear secondary goal. We adopted the human-saving mechanic from our very early prototypes, and the humans ended up largely defining RESOGUN's identity.
Another thing we knew early on was that RESOGUN's gameplay would take place on a cylinder. When having a horizontal looping playfield in a purely 2D environment, some kind of minimap is essential to communicate the extended surroundings to the player. Mapping RESOGUN's gameplay to a cylinder eliminated the need for a minimap, as the player can always see around the bend and plan ahead. This helped instantly create intuitive gameplay, and from a visual standpoint the cylinder also made RESOGUN stand out even during early prototyping stages.
Image from an early prototype version.
One other key aspect of RESOGUN was of course the use of voxels. Due to our technical constraints at time, early versions of the game merely simulated the voxel look through carefully constructed meshes and particle effects. Originally we had also envisioned the voxels playing a larger, more direct role in the gameplay. We intended to have the player pick up and manipulate voxel objects, and maybe shoot them towards the enemies. During very early prototyping we realized that this careful voxel management would conflict with the intense arcade action we were shooting for, so we quickly abandoned the idea.
In hindsight, it's actually really hard to differentiate between the development of "the prototype" and "the game." You can easily hack together a working prototype in a couple of weeks, and then proceed to spend two years continuously refining and polishing it to perfection. With RESOGUN, we aimed to create something unique from the start, so we attempted to innovate from very early stages of development, which led to a lot of different iterations.
When looking at a finished game, everything often feels effortless and naturally integrated into the final product. However, reaching the end result is usually a process of "natural selection" where countless features are eliminated and very few make it into the final cut. At Housemarque, we subscribe to the common game development notion that it's better to iterate and fail quickly. We try to test simple versions of ideas immediately, and then let the game decide: If it works, we keep and refine it, and if it doesn't we discard it and move on.
Below are some of the many ideas we tried for RESOGUN that didn't make it into the final version:
The Tower: We knew from the beginning that we'd require some kind of "drop off point" for the humans. Initially we experimented with a tower-building mechanic, which would collect humans and grow over time. One version had the player collecting all the humans at the tower, and the humans would then run around on a treadmill to generate power ups for you. Outside of feeling a bit abusive towards the humans, as a gameplay mechanic it also felt unnecessarily complicated and hard to communicate.
The Weapon Shop: By killing enemies and saving humans throughout the level, the player would collect "orbs" which functioned as an in-game currency. At the end of each phase, the weapon shop would descend onto the playfield and allow you to exchange your orbs for weapon power-ups. Although the actual implementation was great (it even allowed you to preview items before purchasing), it severely affected the pacing of the game: just as the intensity was ramping up and the player was getting into the zone, we were pulling them out of it and asking them to decide on weapons purchases. Unacceptable.
The weapon shop was one of many ideas we tried but ultimately abandoned.
The Weapon "Options": For the weapons, we also tried having some Gradius-style "options" (helper ships that assist you by shooting alongside your main weapon) which sported a variety of different weapons. The Options didn't work that well with the relatively confined shooting gameplay we were going for, so we went with traditional power-ups instead.
The World Map: We were originally planning to have 10 levels in the game, and had an ambitious plan to incorporate a world map to connect them with each other, hoping to lend the game more cohesion and structure. In between levels the player would get thrown onto this world map, where they'd select the next level from multiple routes. It was unnecessarily complicated, and we ended up discarding it because, once more, it affected the intensity and flow of the experience.
One of the many concept renders for the "World Map" we tested.
The Humans: We had lots of different iterations over the humans. Originally we had humans that would be easily killed by enemies' bullets, and eventually even by the player. Later we iterated over humans with an extra glow or ring around them, to indicate what kind of power up they'd give you. We even tried having special "scientist" humans that award you with power-ups, while the "normal" humans wouldn't.
All of this was once again difficult to communicate and hard to keep track of during gameplay. Initially humans would also spawn from their own "huts", which we would burn to the ground before releasing them. We shifted away from this and trapped them as prisoners in "human chambers" instead, where they'd always be visible to the player.
Originally we had humans escape from their burning houses.
360-Degree Shooting: This is an interesting one. When we got the first prototype of RESOGUN running we naturally tried 360-degree shooting as well, just like Super Stardust HD had. Shooting in 360 degrees generally allows the player more freedom, and this encouraged a more passive play-style that basically transformed the player into a "moving turret": you'd move to a safe location, shoot around, move somewhere else, shoot around, and so on.
By limiting the player to shoot only horizontally, we also forced them to move a lot more; this meant making more decisions and taking more risks, which ultimately created more gameplay. We eventually revisited 360-degree shooting (as a separate "challenge") for our free expansion called Challengers.
Many of the aforementioned flaws in our early designs were highlighted during some of our frequent test sessions. We'd invite people from outside the company to test the game with new eyes, and we'd pay close attention to their initial reactions and feedback. This often helped us gain a fresh perspective on things; as a developer it's easy to get used to how everything works, and even the most obscure features start feeling intuitive after a while. Although these test sessions didn't strictly guide our design process, they often helped us understand when we were over-complicating things.
Establishing a unique visual style for the game also involved lots of iteration. We weren't happy with the bright, more colorful tone we initially targeted, as it lacked a certain "edge" and made gameplay difficult to read. So we eventually shifted to a darker tone, and decided the level environments would now belong to the "Sentients" (our enemies in game) rather than the humans. This also lent itself well to a clear contrast between bright gameplay and dark background elements, which directly helped the game's readability.
Refined concept art from the later stages of development.
After about a year of development, our planned release schedule seemed to largely coincide with the launch window Sony was planning for the PS4. This was the first time when the idea of a PS4 exclusive came up. Transitioning to a different platform at such a late stage represented a moderate risk, but after several talks with Sony everyone agreed that RESOGUN would benefit greatly from becoming a PS4 exclusive and harnessing the extra power we'd get from such a machine.
Although we received devkits fairly late (roughly eight months before the PS4's launch), we were already largely aware of the possibilities the PS4 would allow through features like compute shaders and 8GB of unified GDDR5 memory, so we started working within these lifted constraints immediately.
A target render put together during our transition to the PS4.
The design of the core game remained largely undistracted by this transition -- after all, gameplay always comes first. The decision to keep the game focused in scope also meant we could throw all of this newly found processing power at making the core gameplay much more satisfying and rewarding, and create a truly rich sensory experience while maintaining our original 1080p/60 target.
Needless to say, switching to the PS4 was a hugely positive transition for the project. We needed to re-think practically everything related to the game's tech and presentation, as we now had the power to abandon many of our early compromises and push the game to its full potential. Being freed of the shackles of potential cross-platform (and cross-generation!) development meant that we could confidently "look ahead" and not have to compromise on our vision. We had more options than before, but expectations were also much higher; we now needed to deliver a true "next gen" experience that would stand alongside other giants during launch.
Voxels were obviously a huge part of the game, and with the PS4 we had a chance to explore their utilization anew. Before, we needed to combine traditional polygonal meshes and effects to merely approximate the "voxel look"; now we could use actual voxels to construct (and blow up) everything and create a much more visually cohesive experience.
All of this sounded great of course, but we still needed to somehow put all this into the game...
Working on one single platform meant we could now standardize our export procedure and streamline our asset generation pipeline.
Generating voxelized assets for RESOGUN involved two separate systems: one for the static voxel levels, and another for the entities (humans, enemies, player ships etc.) Having two separate exporting procedures for these allowed for more control and optimization.
For the levels, we created custom Maya tools for generating and exporting them. As a first pass, we would build an asset in Maya using traditional mesh tools. A custom "voxelizer" tool would then process this by raytracing the structure, and generate a "hollow" voxelized cube mesh from it. Meshes were left hollow because aside from the redundancy of generating the inner cubes (they'd be very hard to edit), it also significantly helped with Maya performance.
Our voxel level generation process.
Once the hollow cube mesh was generated, our artists could then edit the surface cubes and define material attributes per-vertex. The material of the "inner" cubes (which are exposed during gameplay after e.g. an explosion chips away the surface) would be decided during the export phase using a separate attribute.
Aside from the surface and inner cubes, we also needed to create "indestructible frames" inside the level objects, so that we could maintain some structure and readability during gameplay. To create these, we used our same "voxelizer" tool, which built voxels at specific locations inside our modeled mesh. The voxelizer tool also defined the "density" (how far apart) these inner frames would be. We would then mark this generated frame as "indestructible" and the export process would combine these with our final asset.
Level generation steps.
Each level could be composed of multiple objects, each with their own materials and properties. During export, all of the objects composing the scene would be mapped to a large 3D grid, and then exported as a custom 3D texture. This process was used to generate the two key assets for each level: one for the "centerpiece" (which had a maximum size of 512^3), and another for the outer "gameplay ring," which was exported as a 128x128x1536 rectangular prism and rendered in-game using a separate "curved voxel" technique (more on this below).
Creating our levels like this meant that we had a fixed grid size for all levels, which standardized many of our exporting and in-game procedures. It also compressed well, and allowed for more complex levels within the same grid without much overhead.
These are the "cube mesh" constructs we used for things such as the Player Ship, Enemies, Humans and various decoration items. Although our levels used voxels in a more traditional sense (adhering strictly to a grid), for enemies we allowed for cubes of different sizes, which could be rotated and animated freely.
To create these cube meshes, our artists would again use standard Maya tools to define rough planes and primitives, which would define the basic shape of the entity and where the cubes would go. Our custom tool would then iterate over all primitives, and generate individual cubes based on each polygon's location, orientation and size. This process often required a bit of guesswork, but thankfully re-generating the voxel data from adjusted primitives was fairly fast so iterating over entities was efficient.
The steps of creating the Ferox ship using the cube mesh generation tools.
During export, everything was "flattened" into raw cube data, which contained per-cube offset, material, orientation, and grouping information. We needed to separate cubes into groups and sub-groups to correctly define their connectivity and behavior, so that e.g. if an arm of an entity is blown off during gameplay, all logically connected cube groups would be detached at the same time. The cube groups were also used to define separate bounding spheres for more accurate gameplay collisions.
Earlier on, we needed to be careful about memory consumption, but now we could potentially use more memory for a single level's voxel grid than the PS3 had in total. This meant we could keep the entire level's voxel data in memory, and update the state and material of each block individually. This allowed for fully destructible environments built out of millions of cubes, that could blow up in a voxel-perfect and spectacular fashion.
To construct the levels in-game, we utilized two separate (but fairly similar) systems: one for the level's centerpiece, and another one for the gameplay ring. Both shared the same geometry generation compute shader code, but the gameplay ring's rectangular prism was curved/"bent" during rendering to allow it to form an actual circle.
Once the static level data is loaded, our compute shader iterates over all the voxels and their materials in the 3D texture, and constructs the surface geometry of the level. The level data is broken up into separate 64^3 voxel blocks, and only the ones containing something are processed. The surface area of each voxel block is then polygonized as a series of quad-strips, and base colors are sampled from the 3D textures and combined with different material textures for the end result. We're only constructing the surfaces for the outer voxel layer, so no geometry actually exists for the inner cubes until they're exposed.
The surface geometry for our levels was rendered as a series of quad strips.
When an explosion occurs during gameplay (which is quite often) and a part of the world is "chipped away", the affected geometry for that segment is reconstructed in real time. Since we're keeping all level voxel data in memory, all material properties for the inner cubes are preserved.
With each explosion, every individual voxel that is chipped away from the world is converted to a "physical cube" (see below). The entire process of updating the level grid geometry and chipping away individual cubes from explosions is performed entirely on the GPU through compute shaders.
In addition to the static, fixed-size cubes we used for the levels, we needed to implement a separate system for rendering free-floating, dynamic cubes as well. Compute shaders lent themselves well to this problem, as their architecture allows for very efficient handling of large chunks of small data like particle (or cubes!)
The geometry for each individual cube was constructed dynamically using our vertex shader. Since each cube is a volumetric entity, it has its own material, receives its own lighting, and casts its own shadow. This simple, lightweight system is what we used to render hundreds of thousands of cubes in-game, both for constructing CPU-controlled gameplay entities such as enemies, and also for GPU-controlled physical cube effects.
Cube mesh entities consisted of thousands of cubes that were individually processed and animated. While these cubes were "attached" to an entity, all their new positions would be updated exclusively by the CPU, and the rendering information was simply passed to our shaders. Tracking all of this cube data wasn't cheap of course, so we ended up using about 1GB of memory just for the entity cube meshes.
All entity cube meshes utilized a fairly simple but sophisticated damage model, which allowed individual cubes to be chipped away when parts of them received damage. When cubes were detached from an entity, ownership of them would be transferred (in a "fire and forget" manner) from the CPU to our GPU-based "physical cube" system. This separate sub-system would then assume control of each individual cube's behavior, and update its physics, collisions and lifetime completely independently of gameplay.
Keeping the level's static voxel grid in memory lent itself well to quick collision lookups, so that each physical cube could bounce off level surfaces naturally. We also implemented another sub-system which allowed us to feed additional collision info from the gameplay side to our compute shader; this was used to make physical cubes react to gameplay events, so that e.g. cubes would be pushed away during a nearby explosion or when the player boosted through them.
Each individual cube had its own geometry, material and physics.
With this revamped voxel tech, the game gradually transformed into a much more elegant beast. By constructing everything from the same building blocks and using one single system for rendering all the voxels in the game, RESOGUN achieved a much more cohesive and unified presentation. Everything in the game could now be accurately destroyed in a spectacular fashion, and all the individual cubes flying around made the game feel very reactive and dynamic, which dramatically improved the player experience.
In addition to our voxel tech, we also worked with compute shaders to create a GPU-based particle system, which we internally called the "Turbo Particle System."
Offloading the workload exclusively to compute shaders meant we could have much more impressive effects without a performance overhead. Effects for this were simply spawned and controlled by the CPU, and the updating of each effect was left to its designated compute shader. The particle update performed sub-frame simulation for all effects, so that even super-fast moving particles at very high spawn frequencies would still look good and fluid. This system also supported a collision system similar to that used for the physical cubes, so that each individual particle could potentially collide and deflected off gameplay entities such as enemies.
This system was very powerful and allowed for spectacular looking effects. It was used in specialized hand-crafted effects like the player's Overdrive beam, the lightning bolts, the player's shockwave/bomb and even the "Save the last humans" texts you see in the game. However, since each effect needed to be hand-coded, this system wasn't very artist-friendly. So we still kept and heavily utilized our "normal" CPU-based particle system, which was easier for artists to work with and lent itself better to simple effects like explosions.
The player's "shockwave" was one of several effects which utilized our "Turbo Particle System."
For our gameplay systems, we utilized a multithreaded fiber system which was originally developed for our PS Vita title Super Stardust Delta. This framework allowed hundreds of lightweight gameplay tasks to run independently across multiple threads, and their execution order would be determined at run-time by resolving each the tasks' dependencies. This was a very flexible and high-performance framework, and was directly responsible for keeping our CPU footprint very low during gameplay.
For our online multiplayer, we went with a deterministic execution model. The theory here is that given the same exact input, the game should produce the same exact output across multiple running instances. In practice, this meant that we only needed to send the player's input over the network, and only run the next frame when input from both players was available. This resulted in very light network packets, and also drastically streamlined our online multiplayer development.
Of course, the downside here was that we needed to actually get the game running deterministically. Doingso in a heavily multithreaded environment was not an easy task, and the delicate nature of determinism meant that even simple human errors (such as leaving a single variable uninitialized) could cause the game to go off-sync. Attempting to find these corner cases ourselves would be an exercise in futility, so we created an automated system that would detect determinism errors for us during execution instead.
The architecture of our fiber system lent itself well to such a change. We first extended our fiber tasks, so that each one would calculate its own running CRC checksum from variables we needed to keep deterministic. We then wrote a quick (...and not very smart) "AI" to play the game automatically for us and record the CRC data for each frame. The system would then run the game again multiple times with the same exact input, and if a CRC mismatch was detected it would trigger an error at the exact variable and location that caused it.
Once this system was in, it allowed us to effectively test the stability of our deterministic model even locally, as we only needed one instance of the game running to "emulate" the multiplayer rules and perform the checks. So everyone would leave these automated "determinism checks" running when away from work, and see if we had any surprises waiting for us when we got back. This automated checking helped us identify and fix countless errors (both determinism-related and otherwise), and proved instrumental in achieving a high stability for the final game.
By the time we shipped RESOGUN, it was stable enough to "survive" our automated checks for over a week at a time. Fun fact: the same AI we used for the determinism checking made it into the "Attract mode" of the game, which you can see if you leave the game idle for too long at the title screen.
It’s kind of tricky when you are working on an expansion, because if you deviate too much from the core formula, people are going to be disappointed. On the other hand, if you give them something too similar, they’ll also be disappointed. So for both of our expansions we decided to have the best of both worlds: something familiar, and something entirely new.
Survival mode was our take on the "endless" formula, something we wanted for RESOGUN from the start. We knew that it needed to restrict the player to a single level which would get progressively harder. Just like the Arcade mode, each game session would be focused and tight, and not require players to invest hours of their time to chase a new high-score.
We also needed to introduce some new elements to the mode, to help it establish a unique identity:
Saving humans: We started off with players needing to take humans to their Escape Pods just like Arcade. Very soon we wanted to try something different, so we made the humans get collected instantly upon contact with the player. This greatly streamlined the human-saving gameplay, and allowed us to have many more humans active in the game. We also needed a new way to spawn humans, so we made them drop with parachutes. This also helped introduce some randomness to the core formula, so that each playthrough would be slightly different.
Dropping the humans with parachutes introduced an element of randomness to Survival.
Day and night cycle: Being an "endless" mode, one of the problems we faced was communicating the progress of the player during gameplay. Players would have a hard time understanding how far they'd gotten, which diminished their sense of having an "end goal" to improve upon in each run. Aesthetically, we also wanted the mode to be easily recognizable when e.g. looking at screenshots. We ended up solving both of these problems by introducing a day and night cycle, comprised of 9 distinct “phases”; this gave the mode a unique visual identity, and also helped players track their progress through each day.
You only live once: Giving the player only a single life was perhaps the most critical decision we made for the mode in terms of gameplay. This strongly emphasized the "survival" aspect and greatly increased the "edge of your seat" tension for the player. During development we received a lot of criticism for this choice, both from test players and from our publisher, but we strongly opposed adding more lives as we felt this would dilute the experience. The constant friction surrounding this feature led to a lot of brainstorming (and sleepless nights), which eventually led to the idea of the "Fallen Hero" mechanic.
The Fallen Hero: The Fallen Hero was an idea largely inspired by the Souls games -- it is, after all, your ship’s “blood stain”, which is dropped at the last point the player died at. If the player manages to reach that point again, they're rewarded with bonus points and an extra shield, effectively extending their chance at the game. This introduced a clear marker for players to reach with each new try, and scaled effortlessly across various skill levels. This was a great way to solve the "extra lives" dilemma, and further helped the mode establish its own identity.
On a very personal note, the concept of a "Fallen Hero" sadly carried a strong connotation for me during this time, as one of my own personal heroes, my grandfather, passed away during the development of Heroes. To honor his memory, I asked if we could add a small monument of a single “Hero” human holding a torch atop the mode's central spire.
Although there are countless storms and lightning bolts constantly hitting the level, the monument always stands there proud and unaffected. This monument would unfortunately be changed later to include a second person, my grandmother, who passed away during the development of Defenders. Both of these events had a very profound impact on me, and I’m grateful that I had a chance to honor their memory this way. It's comforting to know that atop the central spire, they will stand inseparable forever.
With Stardust we had learned the ropes of modifying the core gameplay in meaningful ways; some of you might for example remember the Booster Mode or the Bomber Mode. Demolition also started out as a simple "Bomber Mode," where you would only make use of your Overdrive bomb and try to stay alive as long as possible. That was fun for a few seconds, but intensity dropped too fast. The core avoidance gameplay was still fairly clean and satisfying though, so we just needed to introduce some new element to make things more interesting...
Wrecking Balls: The idea for the wrecking balls came a little bit after our trip to New York around the PS4's launch. While we were there we visited an arcade bar in the city, where I spent a couple of hours playing Arkanoid, one of my favorite arcade games. I felt re-captivated by the elegance of its design: although things would get really intense as the balls multiplied and moved faster, the game never “broke character” and always maintained a level of clarity and predictability.
Arkanoid served as a great inspiration for Demolition mode.
This eventually inspired the idea to introduce "Wrecking Balls" into Demolition, which dramatically altered the character of the mode. The Wrecking Balls introduced an interesting dynamic, as they could be used to destroy enemies in their path, but could also harm the player. While players were charging their bomb, we added a slowdown that allowed them to aim the Wrecking Balls' trajectories with precision, which felt instantly satisfying. They would also bounce off of each other, so as the number of balls increased the mode would get crazy very fast. It helped make gameplay intense, predictable, and most importantly fun.
The combination of the Wrecking Balls and carefully selected enemy patterns made this mode feel familiar but fresh at the same time, and helped Demolition establish its own identity in the RESOGUN universe.
The biggest feature we added for this free patch was the Ship Editor, which introduced the concept of custom ships. Players could now craft their own ships on a 21^3 voxel grid, equip them with their choice of weapon and attributes, and even share them with the RESOGUN community. Development on the Ship Editor had begun way before the update was shipped, but it did take us a fairly long time to flesh out the interface and get all the features we wanted in there.
The Ship Editor allowed players to craft all kinds of custom ships.
Adding the Ship Editor introduced the side-effect of needing to rebalance the game. Originally, RESOGUN only had three ship types, and each was balanced according to its stats and weapon power. For example, the "Phobos" ship had a very powerful weapon to make up for its severe lack of mobility. This made sense in the context of the original game, but the custom ships quickly highlighted the Phobos weapon as being massively overpowered compared to the others. This forced us to revisit the attribute distribution and how the weapons behaved.
In hindsight, this rebalancing was perhaps our biggest misstep during the development of RESOGUN. Players who had spent time with the game had grown attached to the original version, so we received some justified backlash for some of the changes we made. These concerns were promptly addressed in subsequent patches that largely restored the core RESOGUN experience to its original state.
Generally though, the Heroes expansion and patch enjoyed a very positive reception. Both the press and players widely praised Heroes as being even better than the main game, which set the bar pretty high for us. No rest for the wicked though, as we needed to start prototyping for Defenders right away.
The name of our second and last expansion was a direct homage to Defender, one of our key inspirations. This also served as a reference to us doing our part in "defending the arcade spirit," as now it would be time to pass the torch on to the next big game to do this.
Although Protector Mode ended up being the "familiar" mode of the two, when we first started working on Defenders we initially pursued an entirely different direction.
"Booster Mode": This was the first thing we prototyped for Defenders, and was originally slated to be the expansion's "main mode." This limited the player to a single level and only allowed the use of the boost ability. Even during early prototyping, there was a clear conflict in the dynamics of this mode: we encouraged players to move super-fast, but doing so made the gameplay difficult to follow (some players even got severe motion sickness from it!). Also, keeping the player invincible while boosting nullified all tension, but leaving them vulnerable while boosting led to many unpredictable deaths. We spent a lot of time (perhaps too much) evaluating various iterations of this mode, but its potential was clearly limited so we ultimately abandoned this direction.
Initial concepts for the "Booster Mode" level with its rotated background.
"RESOGUN RPG": After giving up on the Booster Mode, we briefly explored the idea of a "roguelike" mode; we envisioned this as having randomly-generated levels, and that players would progress through the mode by ascending a massive, vertical tower. We thought there could be lots of crazy new power-ups, new gameplay mechanics, and some RPG elements like upgradable levels and stats. We soon came to our senses and realized that time constraints wouldn't allow for something that ambitious.
Eventually, we ended up making Protector mode another take on the "Endless" formula, but fleshed out in a slightly different direction. One of the key things that defined this mode was the "level rotation": each time a phase is completed, the centerpiece of the level would rotate 180 degrees. This was something we initially prototyped as part of the Booster Mode, and it looked very cool so we ended up using it in both of our new modes. The "super boost" power up was another leftover from our "Booster Mode" tests.
Originally we envisioned this as a mode where you'd play a full, cylindrical RESOGUN level with a human, but that idea was dismissed early on as being too large in scope. So initially we scrapped the idea of a "commando" mode and started prototyping other things instead.
I mentioned earlier how some "leftover" ideas ended up as Challenges in the game -- with Commando the opposite actually occurred. When we first started prototyping ideas for Challenges, one of them was our take on Missile Command. This mini-game had a static turret in the middle, with houses left and right to protect, and countless meteorites coming down that you were shooting at. That early version got repetitive very quickly, but there was something we liked so we explored it further. Eventually we came up with the idea of replacing the main turret with one of the last humans, and Commando mode was (re)born.
The first iteration had a single human and multiple houses. We decided to keep only one house because that created a larger sense of attachment with your home. Initially we only had Meteorites as enemies, but we saw a lot of potential so it eventually got fleshed out to a mode with 20 "phases", each with its own unique enemy flow. This made Commando different from the other "endless"-style modes, as it even featured a final boss and an actual end screen. Like Arcade, the mode also looped over and introduced "Revenge Bullets" in its second loop.
Commando Mode was directly inspired by many of the great action movies of the '80s.
There were also many clear '80s action movie inspirations in this mode, starting obviously from the name itself. The new power-ups in the mode played with this trope, such as the Minigun, a Bandana, and Sunglasses. Fun Fact: the Sunglasses were a direct homage to the movie "They Live" by John Carpenter. Keeping with the '80s theme, we also wanted to throw in some reference to the greatest action star of all time. Luckily, Ari Pulkkinen (our sound guy) does a really mean Arnold Schwarzenegger impersonation, so we added dozens of samples that referenced some of his more famous quotes.
Commando also deviated from the core RESOGUN story in a bittersweet way. In this "alternate timeline," the normal RESOGUN player ships have failed to save the humans; the background is a destroyed version of the "Protector" level, and if you search its remains you will even find a crash-landed Ferox ship there (one of the many "Easter eggs" we added to the levels). So humans were now forced to take matters into their own hands and make their last stand.
Alongside Defenders we also released another free expansion called Challengers, which one again changed the core RESOGUN experience by introducing lots of new cool things:
Challenges: These are essentially some smaller modes which play with the RESOGUN formula in different ways. These introduce countless variations to the core gameplay, such as Super Revenge Bullets, humans being released by every enemy, or using only boost like we had in our "Booster Mode" prototypes. Lots of the ideas we prototyped but didn't make it into the final modes ended up here instead. The "Super Stardust" Challenge is a great example, which allows the player to use 360 degree shooting. Challenges added lots of replay value to the game, and allowed players to experience RESOGUN in fun new ways.
Feats: We received really good feedback from our fans for RESOGUN's trophies, but we felt severely limited by the number of trophies we could provide through Sony's official systems. So we decided to create our own "in-game trophy" system instead and add a couple of hundred of them. Feats introduced extra goals for the player to achieve during gameplay, which covered a broad range of skill levels. This was another way to extend the longevity of the game.
Photo Mode: Throughout development we'd often pause the game and roam around freely with the debug camera, and marvel at how great the game looked. We aren't cutting any corners with our rendering, so even up close the game looks great. Adding a Photo Mode allowed players to pause the action and take spectacular looking screenshots of RESOGUN in all its voxelized glory. This also gave us the chance to introduce several "Easter eggs" throughout the levels for players to find.
The Photo Mode allowed players to take a closer look at the action.
Both the Defenders expansion and the free update received great critical reception. We knew from the start that Defenders would be our last expansion, and everyone worked very hard to add lots of cool new stuff that would bring RESOGUN to its best, most refined state. It seems to have paid off: many media outlets commented on the Defenders update -- combined with the free patch -- as setting a new standard for post-launch support.
We're really happy with what we managed to pull off for the original version of RESOGUN, but having a tight and immovable deadline tied to the PS4’s launch meant that certain compromises were made regarding the amount of content we delivered. Players who merely wanted to explore the Arcade mode's five levels could admittedly do so in a limited time, which limited the long-term appeal of RESOGUN and didn't allow us to achieve a high retention outside of score-hunters.
This pressure to deliver RESOGUN on-time also meant an intense focus on the launch version of the game, with little time to prepare effectively for future expansions. This affected both of our expansions, which introduced drastic changes to the core game.
For instance, we didn't plan ahead for the inclusion of the editor and custom ships for our "Construction Kit" expansion, and certain oversights in the main game responded poorly to this change. This demanded large changes to the game, which both put a strain on our resources and divided players when the patch was released. Although we still stand firmly behind these changes, many of them could've been avoided with more careful planning and thorough testing beforehand.
For our second free expansion, Challengers, implementing and iterating over the various Challenges proved to be very time-consuming, as a lot of RESOGUN's systems weren't designed in the most modular fashion beforehand. This made writing some of our "mix and match" Challenges very stressful, as we often needed to make nerve-wrecking changes to established systems and ensure we wouldn't break anything. This fact combined with the sheer quantity of Feats and Challenges put a tremendous strain on our testing and QA resources.
Hand-crafting levels also proved to be a huge task for our artists, as there were millions of voxels that needed their individual treatment. This was especially time-consuming, which forced us to be very selective with the designs for our levels, and slightly discouraged large-scale changes to them. Also, constructing complex enemies (such as bosses) from multiple cube-meshes turned out to be a very complicated and time-consuming affair. We eventually ended up using this approach for only our first two bosses in Arcade; the ones for levels 3, 4, and 5 were created dynamically code side, which ended up being a faster approach (and also lent itself well to some cool demo-like effects).
Although RESOGUN development never felt "rushed," we did face tremendous pressure to deliver a "next-gen" experience within a limited timeframe. Thankfully, having so many talented people working together meant a constant flow of creative energy; everyone in the team was vital to the project, and everyone brought their own personal touches to the game. Time is never enough of course, and there’s always something you can do better, but ultimately we're very proud of what we accomplished with RESOGUN. Now we just need to make sure our next game is even better!
Overall, creating RESOGUN was a fantastic experience for us. Being able to create a game like this in 2013, with a large budget, incredible new tech and a publisher support was a great opportunity. The shoot 'em up genre has been sorely underrepresented in the medium, and it's tough to convince publishers that a high-end shoot 'em up is a fruitful prospect. Thankfully Sony believed in our vision, and with their support RESOGUN became a reality.
Our producers at Sony XDev also helped substantially in achieving the highest possible standards, and I can say that we couldn't have worked with a better publisher for the development of RESOGUN. Of course, when you put two passionate parties together, it's not uncommon to have differences in opinion. At times we felt compelled to defend our vision, but ultimately this only strengthened our resolve to refine it further. In some cases (like with the single-life feature of Survival), it even stands as a testament to how sometimes creative friction can lead to the betterment of ideas.
Developing the game exclusively for the PS4 allowed us to pull off lots of cool things that hadn't been done to this extent in the genre before. Innovative tech aside, RESOGUN would have been little more than a glorified tech demo if it wasn't fun to play. We're an interactive medium, and there's no substitute for good gameplay. We'd like to believe that by carefully iterating and pushing to innovate from the start, we managed to craft a solid entry in the genre that will hopefully stand the test of time. Especially with the inclusion of our two expansions, we can now find closure in knowing that all our main aspirations for RESOGUN have been realized, and that we're leaving RESOGUN as a complete package for players to enjoy throughout the rest of the PS4's lifecycle, and hopefully even beyond that.
One final note I'd like to make here is related to our work philosophy. Working at Housemarque has taught me that despite some basic "hierarchy" existing in each project, the supreme authority is always the game itself. The game is the boss. The game always comes first, and you need to learn to keep your ego out of the equation regardless of what your title or role implies. It's often difficult to accept that a certain idea or feature you've grown attached to isn't serving the game's best interests, but you need to overcome that in order to make the best possible game. You need to listen to what the game is telling you, and not silence it with your own voice.
So learn to be stubborn when defending your vision, but also learn to let go. Allow yourself to be tested, and encourage feedback from a wide variety of sources to get a fresh perspective. Treat negative feedback as a challenge to prove your vision, but also as an opportunity to refine it. Always remain open to the possibility that another, better solution exists for what you're trying to achieve. Keep iterating, have frequent test sessions to expose your game to as many eyes as possible, and let the game decide.
After all, the game is the boss.
Thanks for reading!
You May Also Like
