Cola Powered Gamer with an exclusive interview with Ion Fury team!

It feels like it was only just yesterday we were banging on the drums about Voidpoint's excellent first person shooter of 'Ion Fury'; a game created using the Build engine, which powered Duke Nukem 3D, Blood, and Shadow Warrior. It featured kick ass weaponry, hand crafted textures and sprites and much much more, in all of its hand-crafted pixelated glory. In fact it was such a good game, that as of today you can check out the latest interview from Cola Powered Gamer with an exclusive interview with Lead Programmer, Evan Ramos and Max Ylitalo, Lead Level designer of Ion Fury .

Q: Evan Ramos, Technical Director of Ion Fury, How did you came to the idea of developing Ion Fury? Why exactly Bombshell?

In 2015, 3D Realms put out a call for Build Engine modders to make a prequel mini-episode to Bombshell (2016) as a tie-in bonus for its Deluxe Edition. Richard Gobeille ("TerminX") and I had recently founded Voidpoint to pursue commercial game development, so we reached out, and we all agreed it was a natural fit for us to form a team and lead the project. They already knew us for several reasons. For one, we develop EDuke32, an enhanced source port of Duke Nukem 3D, and the only one with advanced modding capabilities. 

We operate Duke4.net, an online community centered around the Duke Nukem games. At that time, Voidpoint was working on Duke Nukem 3D: Hail to the King Collection, an official port to Android and iOS which was unfortunately shelved later that year. We had most recently helped 3D Realms look through archival materials such as old beta versions of classic Apogee games after it was acquired by its current Denmark-based leadership. Richard had also been a moderator on the classic 3D Realms web forums in the 2000s and made the well-regarded Cinema mod for Max Payne 2.

To begin the development process we assembled an initial team of level designers ("mappers") and artists, and sketched out the story of the campaign, which survived all the way into the final product. As our team demonstrated what they were capable of and new members joined us, the Bombshell Prequel project grew in scope over time and evolved into a full-fledged standalone title, Ion Fury.

The idea for the Bombshell character originated in the late 90s as a sidekick to Duke Nukem. 3D Realms retained the rights to her from back then and decided to feature her as a badass action hero in her own right. Voidpoint then re-concepted her character design with influence from her design in Bombshell (2016), plus Sarah Connor (Terminator), Anne Lewis (Robocop), Joanna Dark (Perfect Dark), Ellen Ripley (Alien), and more.

Q: You used a source port of the Build Engine to develop Ion Fury. Did you have problems getting it to work on modern systems?

Our team has developed EDuke32 since 2004, and in that time we've gotten it working on a variety of systems, from 64-bit Windows to ARM handhelds. Our engine technology powers fan ports of Duke Nukem 3D, Shadow Warrior, Blood, Redneck Rampage, Exhumed, and more. Ion Fury is built using EDuke32, so getting it to work was no trouble. Getting to work *well* was another matter! We learned a lot about the expectations users place on commercial games throughout our time in Early Access, particularly fine-tuning of controls and rendering performance. We eliminated stutters, slowdowns, and rough edges in the mouse aiming.

When we showed the game at our first conference, PAX South, we saw players running in circles in the first room of our playable demo because they didn't know you had to press a button to open doors. This led us to display a message on the screen when you approach a door in the game for the first time, as a modern way of teaching new players how to interact with the world. It never appears again after that, true to our classic FPS roots.

I studied Computer Engineering in university, and one of the things I learned is that the limiting factor of modern computing performance tends to be the cost of moving data around. In a game, that can mean from disk into memory when loading assets, and from the CPU to the GPU in the course of drawing a frame, just to name two examples. We refactored our texture system to read all the art in the game into a texture atlas and send it to the GPU once at the beginning of execution so that performance would not be interrupted by unnecessary synchronization points in the course of gameplay. We also replaced our emulation of indexed shading lookup tables: while previously we generated a separate texture for each shade index, we now perform the lookup on the GPU with a shader program, drastically reducing our video memory footprint.

Q: During the development you switched to voxels for various pick-ups in the game. Was it hard to implement this in the Build Engine?

Voxels first appeared in the Build Engine in Blood and Shadow Warrior. Ion Fury uses the same functionality. One important improvement we added was storing voxel data in vertex buffer objects in hardware accelerated mode so that they could stay in the graphics card's memory instead of being re-streamed with every frame.

Voxels were not in our initial Early Access debut because we had not yet found a voxel artist, but in time that was fixed! I'm proud of our community and the voxel artists who have emerged since then.

Q: The levels are bigger than in any other Build Engine game. How long did it take to create a level?

The seven zones of the main campaign were planned from the start, but other than that, the pieces came together in a way that was more freeform than traditional pre-planned timelines. Some environments were gradually constructed over the entire span of the project from 2015 to 2019, while others took shape in the last few months as we connected the dots.

The size of the levels in the game is owed to two features in EDuke32. One is raised limits of the building blocks of Build Engine levels: sectors, walls, and sprites. The other is the ability to save map state while the player travels to a different one, originally intended for hubmaps as seen in Hexen.

Q: Ion Fury is set in a dystopian future, unlike Bombshell. What was your biggest inspiration for this setting?

Robocop, Terminator, Judge Dredd, Deus Ex, FEAR, and Perfect Dark, just to name a few.

Q: Like most Build Engine protagonists, Bombshell also speaks one liners. Who came up with those? (Btw I love all the 90s references.)

It was a team effort. We shared a spreadsheet and wrote down what we could think of, then picked the good ones. "Worthless consumer models" refers to a character played by Jon St. John, the voice of Dr. Heskel. "Bowling bomb likes you" is of course a play on Lo Wang's sticky bombs.

The same goes for many of the references and Easter eggs scattered throughout the game world, such as a profanity originally hidden in Commander Keen, and a tribute to the Graffiti Soul from Jet Set Radio.

Q: Are you planning a sequel or an expansion pack, perhaps?

Yes, development of an expansion pack is underway! Ion Fury: Aftershock will feature all-new zones, weapons, enemies, and inventory items. One piece of feedback we got on the base game is that players loved the outdoor and open areas in our levels. We're tailoring the experience to this desire in the new expansion campaign.

We're open to a full sequel in the future too. We love Shelly and the world we created around her. Voidpoint is also exploring an original IP of our own.

Q: What was your biggest challenge during development?

Unlike an off-the-shelf product like Unity or Unreal Engine, any conveniences we wanted to provide to the customer had to come from our own engineers. Sometimes extending a legacy codebase like EDuke32 in ways necessary for a commercial product like Ion Fury can clash with the needs of its original purpose as a source port of older games with modding communities that still actively produce content. Our software development had to strike a balance between these two concerns so that the work we do could benefit the entire ecosystem without deviating from the standard of quality the user expects.

Q: Ion Fury won several awards and even is compared to the classic FPS games. Did you ever think Ion Fury would become such a success when you started the development?

We originally honed our skills as a hobby, making mods that were fun to play and had rich aesthetics, all while designing the experience with the player in mind. It's rewarding to see the time and effort we've poured into the Build Engine get recognized by our newfound fans. We're honored to be listed alongside the greats. We couldn't have hoped for more.

Q: What is your advice for up and coming developers?

Know what you're capable of. Have the portfolio to show it. Figure out how to talk about your skills to others so they recognize the value you provide. If you find a publisher in the niche you're filling, they can give you a leg up. But also remember, publishers need developers, not the other way around. Know your worth when negotiating contracts. At the end of the day, you are the artist bringing your vision into reality.

Max Ylitalo, Lead Level designer for Ion Fury

Q: How long did it take to create a level?

So when asked "How long does it take to make a map", it's actually somewhat hard to define so I'll share a bit of story instead.

Many of the levels that ended up in the final product actually started life as early as 2015 when the game was first conceived as a prequel bonus tie-in for Bombshell (2016), obtainable by purchasing the Collector's edition. Now of course a lot happened as the level design style and scope could be defined as "generations" of development, in a way we set ourselves chasing a moving target.

"First generation" is when the game had a much reduced scope and the game was simply to be a quick side story for Bombshell (which we referred to as the "main game"). This would be accomplished with virtually zero budget and heavy reliance on converted assests from Bombshell. Game was to be around 6 maps, with 15-25min length on average and detail the story of what happened to Shelly during her GDF days, ending with how she lost her arm. Thus "Project Washington" was born (PW).

We had quite a bit of liberty when it came to the main campaign itself and quite early on thought about what would be cool scenarios to go trough. The full and final list of key areas in the campaign were actually decided on very early on with very few changes. Mapping and visual style was closer to what you'd get in a more typical Build Engine shooter/mod and we didn't really expect to push that many cool things out of the engine. With about a year's worth of development time allocated, each designer got assigned their own map and got busy!

Development continued mostly independently and the game was slowly starting to take some shape. Just before Bombshell's release, we had most of the campaign blocked out and prepared few areas ready for "bullshots", which would end up being some of the first ones shared.

Q: What was in your opinion the biggest challenge during development?

Unfortunately the challenges with Bombshell during it's release posed some uncertainties about the future of the project and the IP. PW started facing some serious development slog as just making a quick promo didn't feel like what we wanted to do anymore. 

It took some time to realize that we still wanted to just create a damn good and impressive build game instead, that's what kept us going. In a way, we knew would miss the deadline regardless as we had subconsciously avoided the idea of converted assets and quicker results in favor of creating our dream "what if?" new build game scenario. We had a dream team of artists, programmers and designers ready to tackle this question!

What about mapping? Well a typical build map with current limitations can at most have 16384 walls, which dictates a lot of the size and complexity you can accomplish. To give a sense of scale, a typical Duke3D map from the 90s would use maybe few thousand walls at most. But on more complex maps made today it's commonly considered a small milestone when you "max out on walls" as it forces your map to be mostly content complete and to add anything new, something old must go. This can force a healthy dynamic as it forces you to revisit and optimize your work multiple times. However even with mapper optimizations it doesn't allow detailed larger sprawling areas to be created easily. Take Zone3 for example, a building with multiple floors. Leaving few thousand walls per floor would be fine, however if you wish to increase detail level you would run out very quickly! Enter the hubmap system, very similar to Half-Life in function and purpose, now we could create seamless transitions between map files and still have them be part of the same level for the player.

Now we could do all sorts of crazy set pieces and push the game world to be a much more seamless experience.

However now it meant that instead of 1 map to detail, mappers now had multiple maps for their areas to work on, yikes!

"Second generation" Would start late 2016, after 1.5 years in development. Better known as the "Preview campaign"

Choosing the "cool game" route did take it's toll. It was getting increasingly unlikely that the project would ever finish at this rate in our minds as many of us just couldn't dedicate more time along our full-time jobs. This lead to us deciding do a final big push in order to release the promised tie-in in some shape or form for Bombshell owners and call it a day. Mappers would take their best looking areas and start refining those in to a stitched "mini-campaign" with some original content, which would form the basis for what the concept of a zone would be later on. This was in a sense a step back. Now the mappers would utilize one of the maps they previously split and simply focus on polishing that as much as possible but it started to produce fruit.

It's here that I want to emphasize the importance of having prototypes and proof of concepts, "PW" at this stage had barely any real gameplay beyond few enemies, pickups and weapons. The best tool that every mapper had was the fact that we were Build engine modding veterans and had the general intuition on what worked and what didn't. It was only around spring of 2017 where we started to have proper game play in and levels could finally start having proper enemies, weapons and combat design to them. Roz provided his first few tunes and it really did start to feel like a game after 2 years.

I guess you could put it that It's much more fun to create maps for a game than trying to create a game from maps.

Major milestone was that we finally had a playable campaign ready for internal testing at mid-2017. It was again a monumental relief to finally have something that felt like a playable game and less like a collection of maps stuck in a perpetual alpha state.  We were extremely happy to get the first outsider feedback on what had been our labor of love for the past two years and while we had a lot to work on, we got back some extremely good feedback that finally let us know that we are on the right track. Start nailing gameplay early, this will give you a baseline identity you will build on. Otherwise you will be stuck making best effort generic maps that might or might not work at all.

At this point the game was finally strong enough to stand on it's own two feet and was ultimately spun off as a stand-alone title with a "beta demo" destined for pre-order users, fulfilling the original scope and more. Internal testing resumed for the rest of the year and we were mostly content complete by the time 2018 started.

In retrospect this was a powerful tool as we ultimately ended up creating a very polished vertical slice: Let every mapper extract areas from their creations and combine them in to one campaign that let them also get tweaks done on what worked and what didn't and all these changes could be almost fully "backported" to the main campaign levels. This really helped us with establishing common conventions and forced us to share more of the areas, resulting in better consistency across. All of this gave us a clear blueprint and a fresh pair of eyes to build upon.

The bar was now set high!

This kicked off the "third generation", with a clear blueprint to work on and a fresh pair of eyes it was time to dust off those old maps from 2016. From here on it was very focused development as new enemies and mechanics were added to augment the existing ones.

Queen of the hill was developed around two weeks as a fun project between me and Jonathan after a silly idea of creating a horde mode with map effects alone while utilizing an existing map from preview for this. End result as wonderfully stupidly complex, but it worked! This helped us with adding more useful features to the respawn and patrol system, which allowed for more complex enemy patrol setups in the full version. We pretty much created a new game mode with very little help from code side.

By the end of the year it was time to show off new content at PAX and one of the later maps was pretty well along. Few months were dedicated to polishing it up to the standards seen in the preview campaign. Corentin would work on this and it got released as "Heskel's house or horrors". A sudden collision revamp followed during early 2019, which made us spend about two months in order to accommodate a lot of the levels and physics towards something that was ultimately much less buggy. Temporary voice lines got recorded in order to get the story beats down (Including Shelly, voiced by yours truly). round this time we kicked off another round of testing and had most of the main content done, similar to preview, we got a lot of good feedback and fixed many of the issues and bugs. Huge thanks to our testers!

Q: What is your advice for up and coming developers?

My advice is to get the game play dynamics right and write good world design guidelines that everybody will follow.

Games are forgiving for this, but you should not have every map feel like a different country, like a movie where every scene is done by a different director. Make designers play each other's maps, copy and share designs. 

For an "old engine game" like this, level designers have generally have a lot of responsibility from blockout all the way to the final details, you're also doing duties of a writer in some sense. Make sure that the fictional world being created is the same as the player will experience the journey as a whole. 

Simple fictional quirks like a fire extinguisher making a crack in the wall might be stupid but is something they can reasonably expect to see for every other one in the game if you show this early on. Another element such as inserting an access card for a door needs to be agreed on. If you simply unlock the first few doors, don't have any doors later in the game that automatically open upon card insertion as that will just result in frustration if the player didn't expect it and enemies on the other side would immediately start firing at you. Fiction you create, even if unrealistic sets the logic, follow this logic.

As for the question of time it took to make a level (map), My answer is anything between 4+ years and few months :)

Thank you for your time talking to us here at Cola Powered Gamer and Indie Retro News, to everyone else make sure to check out the game if you haven't, linked here -> :1) Steam 2) GOG 3) Website