Image courtesy of Implausible Industries
RESEARCH and DESTROY highlights how a team of four were able to re-engineer the turn-based strategy formula
Brian Crecente
9 de septiembre de 2021
Located in Tokyo, Japan, Implausible Industries was formed in 2013 by four highly experienced games developers from across the globe.
Our team members have worked on more than ten different completed Unreal Engine titles on PC and console with some of Japan's best-known studios. Before starting Implausible Industries, our members worked on many games of well-known franchises such as Driver, Fatal Frame, FIFA and No More Heroes.
RESEARCH and DESTROY is Implausible Industries' first original title.
Our team members have worked on more than ten different completed Unreal Engine titles on PC and console with some of Japan's best-known studios. Before starting Implausible Industries, our members worked on many games of well-known franchises such as Driver, Fatal Frame, FIFA and No More Heroes.
RESEARCH and DESTROY is Implausible Industries' first original title.
RESEARCH and DESTROY is a clever blend of turn-based strategy and third-person shooter that drops in three scientists—pulled straight from a late-night 1950s sci-fi flick—and has them do battle with a horde of the sort of supernatural creatures you might find in a Scooby-Doo or Dexter’s Laboratory cartoon. To make matters even better, the scientists are armed with an array of goofy weapons that they develop and upgrade along the way.
The turn-based action game (with online and local co-op) is the product of a four-person development team based in Tokyo with decades of Unreal Engine experience. Implausible Industries showed off their in-development game back in 2017 at Tokyo Indie Fest and later BitSummit, where it received some very valuable player feedback and won the Popular Selection Award.
We chatted with the group about how they blended genres, art styles, and development techniques to come up with such an entertaining game. Most importantly, they also walked through just how important Unreal Engine and spreadsheets were to envisioning their title and then bringing it to life.
The turn-based action game (with online and local co-op) is the product of a four-person development team based in Tokyo with decades of Unreal Engine experience. Implausible Industries showed off their in-development game back in 2017 at Tokyo Indie Fest and later BitSummit, where it received some very valuable player feedback and won the Popular Selection Award.
We chatted with the group about how they blended genres, art styles, and development techniques to come up with such an entertaining game. Most importantly, they also walked through just how important Unreal Engine and spreadsheets were to envisioning their title and then bringing it to life.
Chris Willacy: I’ve been a game developer for about 23 years. I’ve worked on AAA and indie and everything in between across the UK, Australia, China, and Japan. During the summer, I like the beach. In winter, I like the mountains. I have a family I love and a cat called Monty, who I also love.
Daniel Markiewicz: I am also a game developer and wear many hats. Some of them fit. Most are metaphorical.
Kees Gajentaan: And I’m the artist. Nice to meet you!
You note on your website that it is your strong experience with Unreal Engine that allows you to quickly prototype and develop top-quality games. Can you explain how Unreal Engine makes that possible?
Daniel Markiewicz: I’m not sure what we can say here that hasn’t probably already been said in most of these interviews, but Unreal Engine pretty much has everything, right? There were maybe a few things missing back when we started this project (I wish the Marketplace then was what it is now!), but if you’re making a 3D game, it’s a full toolbox that can get you a working prototype in weeks, or even days depending on what you’re trying to make.
Prototyping new gameplay features is a snap, especially with Blueprints — There are some really useful sample projects included that make what might otherwise be difficult to understand systems easy to grok. Shooter Game was basically my ultimate cheat sheet.
Daniel Markiewicz: I’m not sure what we can say here that hasn’t probably already been said in most of these interviews, but Unreal Engine pretty much has everything, right? There were maybe a few things missing back when we started this project (I wish the Marketplace then was what it is now!), but if you’re making a 3D game, it’s a full toolbox that can get you a working prototype in weeks, or even days depending on what you’re trying to make.
Prototyping new gameplay features is a snap, especially with Blueprints — There are some really useful sample projects included that make what might otherwise be difficult to understand systems easy to grok. Shooter Game was basically my ultimate cheat sheet.
Image courtesy of Implausible Industries
What made you decide to blend turn-based strategy and real-time shooting for your approach to RESEARCH and DESTROY?
Markiewicz: The TL;DR is that we originally wanted to make “very vertical co-op X-COM.” It turned out that waiting for your friends to finish their turns (to use a technical term) sucked. We prototyped a version that used simultaneous “click on destination to move, click on target to shoot” controls, but there ended up being a lot of friction when characters would cross paths and bump into each other. In the end, we realized that “action points,” “turns,” etc. were really just abstractions for the amount of time characters had to act in a turn, so we cut out the middleman and tried giving direct third-person-shooter controls to the player. This resulted in us veering quite a bit away from the very strategic gameplay we had already envisioned, but it has become its own, surprisingly tactical thing.
RESEARCH and DESTROY’s story, cast of heroes, and enemies has a strong 1950s vibe to it. How did that era of schlocky science fiction and horror influence your game design and art approach?
Kees Gajentaan: The setting of RAD was brainstormed after we’d created the first rough prototype, but once we had decided on it (a small team of super scientists fighting the supernatural), a lot of the influences came naturally.
A small team of colorful characters taking down classic monsters already sounds like Scooby-Doo and the many other Hanna-Barbera cartoons from that time. The whole scientists-as-heroes idea came from our love of X-COM, as we wanted the players to develop lots of cool weapons and gadgets to both make combat and the vertical traversal unique and fun.
By going with a non-realistic and not-serious style, we knew we would be able to get a lot more inventive and crazy with those. Players can get to higher ground using rocket boots, a portable trampoline called the Propellor, the Max Plank (a hoverboard), and several other pieces of equipment that allow for short-range teleportation. Players can also bounce off awnings and other objects in the environment like they do in cartoons.
Many of the weapons are also very cartoon-like, letting players boost supernatural enemies into the air with sticky rockets, send them flying using hypercubes, or just drop a grand piano pulled from another dimension on them.
We also needed some kind of vehicle to get in and out of the many different missions across the continent. Like all those cartoon and TV characters from that era, I felt our team of heroes also needed a really cool car to get around, hence the sentient flying RADvan was born.
Most simply put, the game’s design and a strong desire to make things fun really influenced a lot of the art design. We didn’t set out to make a Scooby-Doo / Dexter’s Lab-influenced game, but a lot of elements from those cartoons seemed to easily fit what the game needed.
Markiewicz: The TL;DR is that we originally wanted to make “very vertical co-op X-COM.” It turned out that waiting for your friends to finish their turns (to use a technical term) sucked. We prototyped a version that used simultaneous “click on destination to move, click on target to shoot” controls, but there ended up being a lot of friction when characters would cross paths and bump into each other. In the end, we realized that “action points,” “turns,” etc. were really just abstractions for the amount of time characters had to act in a turn, so we cut out the middleman and tried giving direct third-person-shooter controls to the player. This resulted in us veering quite a bit away from the very strategic gameplay we had already envisioned, but it has become its own, surprisingly tactical thing.
RESEARCH and DESTROY’s story, cast of heroes, and enemies has a strong 1950s vibe to it. How did that era of schlocky science fiction and horror influence your game design and art approach?
Kees Gajentaan: The setting of RAD was brainstormed after we’d created the first rough prototype, but once we had decided on it (a small team of super scientists fighting the supernatural), a lot of the influences came naturally.
A small team of colorful characters taking down classic monsters already sounds like Scooby-Doo and the many other Hanna-Barbera cartoons from that time. The whole scientists-as-heroes idea came from our love of X-COM, as we wanted the players to develop lots of cool weapons and gadgets to both make combat and the vertical traversal unique and fun.
By going with a non-realistic and not-serious style, we knew we would be able to get a lot more inventive and crazy with those. Players can get to higher ground using rocket boots, a portable trampoline called the Propellor, the Max Plank (a hoverboard), and several other pieces of equipment that allow for short-range teleportation. Players can also bounce off awnings and other objects in the environment like they do in cartoons.
Many of the weapons are also very cartoon-like, letting players boost supernatural enemies into the air with sticky rockets, send them flying using hypercubes, or just drop a grand piano pulled from another dimension on them.
We also needed some kind of vehicle to get in and out of the many different missions across the continent. Like all those cartoon and TV characters from that era, I felt our team of heroes also needed a really cool car to get around, hence the sentient flying RADvan was born.
Most simply put, the game’s design and a strong desire to make things fun really influenced a lot of the art design. We didn’t set out to make a Scooby-Doo / Dexter’s Lab-influenced game, but a lot of elements from those cartoons seemed to easily fit what the game needed.
Image courtesy of Implausible Industries
It sounds like you did quite a bit of surveying of players while showing the game at Tokyo Indie Fest and Bitsummit, how did what you discover in those post-play surveys influence the game’s evolution?
Chris Willacy: The feedback from both events was almost entirely positive so we didn’t have to remove or refactor any pillars, but there was some glaring stuff that we immediately knew we had to fix. For example, the initial version of one of our weapons—the Test Tube Launcher—had an extremely powerful explosion that was slow to reload, and a pretty situational shield as its alt-fire mode. We saw the overabundance of friendly fire with the explosive mode and under-utilization of the shield mode straight away. There was quite a bit of stuff like that. We had the bones down but the clay was rough. Our golem clearly needed some work.
Every time you watch a new player try your game, you learn something new. A certain amount of self-belief is necessary but you almost have to disembody to understand why new players do what they do sometimes; it can take effort to kind of remove that pride that stops you from accepting that you haven’t nailed it the first, second, or even third time. Getting those new perspectives is essential. Without them, we’d basically end up just making the game around the experiences and sensibilities of just a handful of people, which would be disastrous.
In the end, that feedback allowed us to see we were on the right path but the game needed additional auxiliary systems to help players understand what was going on. While it hasn’t been an easy journey, we’ve had the luxury of being able to iron out a lot of those wrinkles organically over time.
Gajentaan: One thing we did learn from showing our game hands-on was that, because of its unique time-based mechanic, it took a lot of time to explain that in person. Shortly after the events, we created a standalone tutorial mission that since has always been accessible from the main menu, both in the demo and the full game. If you have the game at home and want to play a mission in local co-op with a visiting friend, that friend just needs a few minutes to play the tutorial to fully understand the game’s mechanics.
Markiewicz: We also learned that people universally found friendly-fire accidents to be hilarious and that human beings are horrible.
Chris Willacy: The feedback from both events was almost entirely positive so we didn’t have to remove or refactor any pillars, but there was some glaring stuff that we immediately knew we had to fix. For example, the initial version of one of our weapons—the Test Tube Launcher—had an extremely powerful explosion that was slow to reload, and a pretty situational shield as its alt-fire mode. We saw the overabundance of friendly fire with the explosive mode and under-utilization of the shield mode straight away. There was quite a bit of stuff like that. We had the bones down but the clay was rough. Our golem clearly needed some work.
Every time you watch a new player try your game, you learn something new. A certain amount of self-belief is necessary but you almost have to disembody to understand why new players do what they do sometimes; it can take effort to kind of remove that pride that stops you from accepting that you haven’t nailed it the first, second, or even third time. Getting those new perspectives is essential. Without them, we’d basically end up just making the game around the experiences and sensibilities of just a handful of people, which would be disastrous.
In the end, that feedback allowed us to see we were on the right path but the game needed additional auxiliary systems to help players understand what was going on. While it hasn’t been an easy journey, we’ve had the luxury of being able to iron out a lot of those wrinkles organically over time.
Gajentaan: One thing we did learn from showing our game hands-on was that, because of its unique time-based mechanic, it took a lot of time to explain that in person. Shortly after the events, we created a standalone tutorial mission that since has always been accessible from the main menu, both in the demo and the full game. If you have the game at home and want to play a mission in local co-op with a visiting friend, that friend just needs a few minutes to play the tutorial to fully understand the game’s mechanics.
Markiewicz: We also learned that people universally found friendly-fire accidents to be hilarious and that human beings are horrible.
Image courtesy of Implausible Industries
How did you manage to carry across RAD’s direct control approach to its strategy map?
Gajentaan: The game mechanics of the strategy map part of the game are very much in line with the turn-based action missions. Just like in the missions, players will need to manage their time, which is paused as long as they don't move.
Markiewicz: Players drive around the world map, build defenses, and perform research simultaneously. After doing this for a while, the supernatural hordes get a turn to buff up their regions and maybe invade, and then on to the players again. Originally, we were planning on this being a four-player game, so this sort of approach was necessary to keep all players engaged and not bored. In retrospect, had we known we were going to go down to two players, this part of the game probably would have been quite different, as I don’t think the real-time element would have been quite as essential. But in the end, it’s at least consistent with the game’s real-time/turn-based ethos and works reasonably well as a place to build up your gear with a buddy and choose your next mission.
The game’s colorful art direction looks pulled directly from comic books, what made you decide to take that approach and how did Unreal Engine help with that decision?
Gajentaan: That decision was both artistic and practical.
We knew from the start that the scope of the game was going to be quite big, while our team was very small, so I needed to come up with an art style that would make creating assets less time-consuming. I also wanted to avoid having to worry about texture budgets later in production, as well as reuse assets a lot in different levels.
I’ve been wanting to make a game with a unique cartoon look for many years. As I began developing the art style, I thought about how coloring in cartoons differs from coloring in games. Typically in a 3D game, a background object is colored “realistically,” and then lit using the lighting in-game. But in cartoons, of course, it is painted in the color it needs to be. So, for example in Disney’s Aladdin, the streets and buildings are painted a salmon/orange color for the daytime scenes and blue/purple for night scenes.
So I developed shaders that would use fewer textures and help me determine colors using parameters. The shader also creates a cel-shading effect based on the angle of the directional light in the scene and the normal map and lets me pick the exact colors for the main color, highlight color, and shade color on the object.
That opened up many possibilities, as we’re able to change colors whenever we need to, no longer locked in by texture colors. Using Material Parameter Collections and Lighting Scenarios, we’re able to completely paint a daytime scene in one set of colors, and completely change it for the nighttime scenes. The added benefit is that to the average player, an “orange rock” looks like a different object to a “purple rock,” so it somewhat disguises that objects are being reused. Players will also revisit certain areas of the game, so the different color schemes for day and night also help add a perceived variety to these.
Parameter-based color techniques are applied to characters as well. The zombies in the game have randomized skin tones and clothing colors, and we allow players to fully customize their team of super scientists.
Gajentaan: The game mechanics of the strategy map part of the game are very much in line with the turn-based action missions. Just like in the missions, players will need to manage their time, which is paused as long as they don't move.
Markiewicz: Players drive around the world map, build defenses, and perform research simultaneously. After doing this for a while, the supernatural hordes get a turn to buff up their regions and maybe invade, and then on to the players again. Originally, we were planning on this being a four-player game, so this sort of approach was necessary to keep all players engaged and not bored. In retrospect, had we known we were going to go down to two players, this part of the game probably would have been quite different, as I don’t think the real-time element would have been quite as essential. But in the end, it’s at least consistent with the game’s real-time/turn-based ethos and works reasonably well as a place to build up your gear with a buddy and choose your next mission.
The game’s colorful art direction looks pulled directly from comic books, what made you decide to take that approach and how did Unreal Engine help with that decision?
Gajentaan: That decision was both artistic and practical.
We knew from the start that the scope of the game was going to be quite big, while our team was very small, so I needed to come up with an art style that would make creating assets less time-consuming. I also wanted to avoid having to worry about texture budgets later in production, as well as reuse assets a lot in different levels.
I’ve been wanting to make a game with a unique cartoon look for many years. As I began developing the art style, I thought about how coloring in cartoons differs from coloring in games. Typically in a 3D game, a background object is colored “realistically,” and then lit using the lighting in-game. But in cartoons, of course, it is painted in the color it needs to be. So, for example in Disney’s Aladdin, the streets and buildings are painted a salmon/orange color for the daytime scenes and blue/purple for night scenes.
So I developed shaders that would use fewer textures and help me determine colors using parameters. The shader also creates a cel-shading effect based on the angle of the directional light in the scene and the normal map and lets me pick the exact colors for the main color, highlight color, and shade color on the object.
That opened up many possibilities, as we’re able to change colors whenever we need to, no longer locked in by texture colors. Using Material Parameter Collections and Lighting Scenarios, we’re able to completely paint a daytime scene in one set of colors, and completely change it for the nighttime scenes. The added benefit is that to the average player, an “orange rock” looks like a different object to a “purple rock,” so it somewhat disguises that objects are being reused. Players will also revisit certain areas of the game, so the different color schemes for day and night also help add a perceived variety to these.
Parameter-based color techniques are applied to characters as well. The zombies in the game have randomized skin tones and clothing colors, and we allow players to fully customize their team of super scientists.
Image courtesy of Implausible Industries
What made you decide to use Unreal Engine for RESEARCH and DESTROY?
Willacy: Between the three of us, there are about 30 to 40 odd years of combined experience in various Unreal Engines so I don’t think we ever even discussed it, it was just assumed. We’ve been lending our Unreal Engine expertise to other studios to help fund RESEARCH and DESTROY over the last six years and every project you work on you learn more. So stuff that was done early in production may have been redone once or twice over that development period as we learned new or better ways to do things.
Were there particular elements of the engine that attracted you to using it for your game?
Markiewicz: Its cross-platform capabilities, and we were already using it all the time in our “day job” helping clients with their projects.
Willacy: I found that as long as I could understand the “when” and the “why,” Unreal took a lot of the “how” out of the day-to-day math duties that various disciplines perform, and as a guy who’s not that strong at math, that's a huge thing for me.
Gajentaan: Unreal Engine has always been a fantastic tool for artists. There are always lots of ways you can add variety to your content using a relatively small pool of simple source assets.
Are there any design challenges that you overcame that you could walk us through?
Willacy: I think most of our design challenges were born out of being a small team creating an ambitious title on a modest budget.
The biggest challenge for me in designing a lot of the weapons and gadgets and gameplay actors was just making it all kind of fit together in a coherent way. There was a lot of emergent gameplay that became part of the design just because a weapon and a gadget revealed some kind of interplay we hadn’t anticipated.
There are nine weapons with two fire modes and eight upgrade combinations per weapon, as well as nine gadgets with two potential upgrades each, and they often influence each other in different ways. Those numbers make my head hurt. Thankfully it wasn’t just me on my own, the other guys have keen design sensibilities and our team was small enough to bounce ideas off each other and contribute without workflows getting bogged down.
A concrete example would be centralizing all of our battle data externally in spreadsheets. Since I was the only member doing level design and wrote the enemy spawning system I had to write something I could use to flesh out battles and iterate on them quickly. Using spreadsheets and Unreal Engine’s data import system meant I could quickly visualize problems with battle over/underloading. I could graph them up, create arrays of UE4 readable links, and have them validated before importing and such. That would have saved weeks or months of work over the course of the project.
UE4 is very good when you take a data-driven approach; you can save a lot of time.
Another example would be that I’m also wearing the audio hat on the team but I didn’t have huge amounts of time to make the background music so I came up with a dynamic music system that changes based on various things like whose turn it is, who you are controlling, gameplay events and such. Firstly, this was done with UE’s Time Synth and later with Quartz, which is basically the thing I have been waiting for since forever. It allowed me to create something that has been swirling around in my head, but couldn’t do for one reason or another for about 15 years, which is hugely gratifying. I'd like to take it even further in future projects, if possible.
Markiewicz: A core element of our game is the idea that when characters run out of time, they freeze. It doesn’t matter if they were running, flying, falling, or in the middle of a ragdoll freakout. They need to stop what they are doing, but be able to resume immediately at a moment’s notice. This ended up being a bigger challenge than I had anticipated, especially once you go into online multiplayer.
For example, if you launch a werewolf into the air with an explosion—and why would you do that, you monster? That werewolf is a single parent with two kids!—they’d end up frozen in mid-air, in a pose determined entirely by ragdoll physics. We can have a lot of characters in play at a time, and a lot of explosions, so that can result in a load of frozen ragdolls.
Synchronizing them over the network wasn’t really in the cards at the time we implemented the system. I tried a few approaches, but it never quite worked out, especially under bad network conditions. The thing is, in most games, ragdolls kick in once characters get killed, and at that point are mostly cosmetic.
In our game, you can still take your time and try to headshot that werewolf who is frozen in mid-explosion (YOU. MONSTER.) I ended up addressing this problem by making all weapon hit detection client authoritative. That is to say: the client decides whether they hit or not and lets the server know, instead of the usual pattern of having the server decide what’s hit and what isn’t. Were this a competitive game, this would open up a huge can of potential cheating worms, but we’re not too concerned here. What’s most important is that if the client player lines up a shot on a frozen/flying enemy’s noggin, they HAVE to hit, even if that head is positioned slightly differently on the host. We don’t care too much if things occasionally look a little weird for the host player because of that, because the shooting player’s experience takes precedence.
Willacy: Between the three of us, there are about 30 to 40 odd years of combined experience in various Unreal Engines so I don’t think we ever even discussed it, it was just assumed. We’ve been lending our Unreal Engine expertise to other studios to help fund RESEARCH and DESTROY over the last six years and every project you work on you learn more. So stuff that was done early in production may have been redone once or twice over that development period as we learned new or better ways to do things.
Were there particular elements of the engine that attracted you to using it for your game?
Markiewicz: Its cross-platform capabilities, and we were already using it all the time in our “day job” helping clients with their projects.
Willacy: I found that as long as I could understand the “when” and the “why,” Unreal took a lot of the “how” out of the day-to-day math duties that various disciplines perform, and as a guy who’s not that strong at math, that's a huge thing for me.
Gajentaan: Unreal Engine has always been a fantastic tool for artists. There are always lots of ways you can add variety to your content using a relatively small pool of simple source assets.
Are there any design challenges that you overcame that you could walk us through?
Willacy: I think most of our design challenges were born out of being a small team creating an ambitious title on a modest budget.
The biggest challenge for me in designing a lot of the weapons and gadgets and gameplay actors was just making it all kind of fit together in a coherent way. There was a lot of emergent gameplay that became part of the design just because a weapon and a gadget revealed some kind of interplay we hadn’t anticipated.
There are nine weapons with two fire modes and eight upgrade combinations per weapon, as well as nine gadgets with two potential upgrades each, and they often influence each other in different ways. Those numbers make my head hurt. Thankfully it wasn’t just me on my own, the other guys have keen design sensibilities and our team was small enough to bounce ideas off each other and contribute without workflows getting bogged down.
A concrete example would be centralizing all of our battle data externally in spreadsheets. Since I was the only member doing level design and wrote the enemy spawning system I had to write something I could use to flesh out battles and iterate on them quickly. Using spreadsheets and Unreal Engine’s data import system meant I could quickly visualize problems with battle over/underloading. I could graph them up, create arrays of UE4 readable links, and have them validated before importing and such. That would have saved weeks or months of work over the course of the project.
UE4 is very good when you take a data-driven approach; you can save a lot of time.
Another example would be that I’m also wearing the audio hat on the team but I didn’t have huge amounts of time to make the background music so I came up with a dynamic music system that changes based on various things like whose turn it is, who you are controlling, gameplay events and such. Firstly, this was done with UE’s Time Synth and later with Quartz, which is basically the thing I have been waiting for since forever. It allowed me to create something that has been swirling around in my head, but couldn’t do for one reason or another for about 15 years, which is hugely gratifying. I'd like to take it even further in future projects, if possible.
Markiewicz: A core element of our game is the idea that when characters run out of time, they freeze. It doesn’t matter if they were running, flying, falling, or in the middle of a ragdoll freakout. They need to stop what they are doing, but be able to resume immediately at a moment’s notice. This ended up being a bigger challenge than I had anticipated, especially once you go into online multiplayer.
For example, if you launch a werewolf into the air with an explosion—and why would you do that, you monster? That werewolf is a single parent with two kids!—they’d end up frozen in mid-air, in a pose determined entirely by ragdoll physics. We can have a lot of characters in play at a time, and a lot of explosions, so that can result in a load of frozen ragdolls.
Synchronizing them over the network wasn’t really in the cards at the time we implemented the system. I tried a few approaches, but it never quite worked out, especially under bad network conditions. The thing is, in most games, ragdolls kick in once characters get killed, and at that point are mostly cosmetic.
In our game, you can still take your time and try to headshot that werewolf who is frozen in mid-explosion (YOU. MONSTER.) I ended up addressing this problem by making all weapon hit detection client authoritative. That is to say: the client decides whether they hit or not and lets the server know, instead of the usual pattern of having the server decide what’s hit and what isn’t. Were this a competitive game, this would open up a huge can of potential cheating worms, but we’re not too concerned here. What’s most important is that if the client player lines up a shot on a frozen/flying enemy’s noggin, they HAVE to hit, even if that head is positioned slightly differently on the host. We don’t care too much if things occasionally look a little weird for the host player because of that, because the shooting player’s experience takes precedence.
Image courtesy of Implausible Industries
What PlayStation 5 and Xbox Series X/S features did you use in the development of the game and how did it help shape your creation?
Markiewicz: The new consoles came along too late in development to shape the design in any way. That said, we added some adaptive trigger support on PS5, and adding activity cards gave us an extra way to nudge players in the right direction while providing just a bit more color. On XSX/S, we didn’t use any obviously player-facing new features but did take advantage of some recent SDK additions that made my life significantly easier. We have, of course, cranked the settings way up for the newer consoles. UE4’s Device Profiles made this delightfully easy!
What challenges did you face when developing a game for two generations of platforms, PC, and the Nintendo Switch, and how did you overcome them?
Markiewicz: We’re lucky in that our visual design allows for a pretty lean memory profile, and isn’t as taxing on graphics hardware as something that required more realistic, lived-in-looking worlds would be, so going (or rather staying) multi-platform was less of a challenge than it could have been. The Switch was, of course, our main bottleneck in terms of memory, CPU, and GPU. We used the Animation Budgeting plugin to help keep CPU performance reasonable-ish on enemy turns and made the tough decision to disable dynamic shadows on Switch to maintain visual fidelity and framerate consistency.
The new generation brought about some issues with networking as well. On PS5, in particular, we had to implement friend-session finding ourselves. Similarly, system-level friend invites on Switch were a reasonably recent addition, so we had to go in and manually implement those. Luckily, UE4’s Online Subsystem architecture is pretty consistently implemented and easy to read, so it was mostly a matter of aping what was already there while staring at Sony and Nintendo’s documentation. I don’t think anyone jumping into a UE4 (or UE5) project right now will have to worry about these issues though. Plus, there’s Epic Online Services!
Gajentaan: Despite our years of experience, we’ve never developed a game on so many platforms simultaneously (PC, PS4, PS5, Xbox One, Xbox Series X, Switch). Of course, the game needs to be playable both on Switch when handheld and when docked, so you can count that as almost two platforms. What’s more, some of these platforms come in different flavors, so there’s a need to also tune the game for Xbox One X, PS4 Pro, and Xbox Series S in addition to their base models to create the best possible experience. And finally, our game supports split-screen co-op play.
Thankfully, UE4 has an enormous amount of scalability parameters and settings that can be used to tune the content and rendered output for each possible scenario. I call these scenarios, as split-screen would nearly always require different settings from full screen.
To keep my head above the water, I kept track of all these parameters and their values in a spreadsheet, so I could see how each platform/scenario compared to the other. And of course, I investigated what each parameter does and how it influences the visuals and performance.
For several platforms, we use dynamic resolution for when things get a little heavy on the GPU. For scenarios on the lower-end hardware, materials are simplified using Quality Switch nodes and non-essential detail meshes and particles are hidden using Detail Mode. LOD distances, shadows, post-process quality, foliage density, screen resolutions, and many, many others are scaled to best fit each scenario.
Markiewicz: The new consoles came along too late in development to shape the design in any way. That said, we added some adaptive trigger support on PS5, and adding activity cards gave us an extra way to nudge players in the right direction while providing just a bit more color. On XSX/S, we didn’t use any obviously player-facing new features but did take advantage of some recent SDK additions that made my life significantly easier. We have, of course, cranked the settings way up for the newer consoles. UE4’s Device Profiles made this delightfully easy!
What challenges did you face when developing a game for two generations of platforms, PC, and the Nintendo Switch, and how did you overcome them?
Markiewicz: We’re lucky in that our visual design allows for a pretty lean memory profile, and isn’t as taxing on graphics hardware as something that required more realistic, lived-in-looking worlds would be, so going (or rather staying) multi-platform was less of a challenge than it could have been. The Switch was, of course, our main bottleneck in terms of memory, CPU, and GPU. We used the Animation Budgeting plugin to help keep CPU performance reasonable-ish on enemy turns and made the tough decision to disable dynamic shadows on Switch to maintain visual fidelity and framerate consistency.
The new generation brought about some issues with networking as well. On PS5, in particular, we had to implement friend-session finding ourselves. Similarly, system-level friend invites on Switch were a reasonably recent addition, so we had to go in and manually implement those. Luckily, UE4’s Online Subsystem architecture is pretty consistently implemented and easy to read, so it was mostly a matter of aping what was already there while staring at Sony and Nintendo’s documentation. I don’t think anyone jumping into a UE4 (or UE5) project right now will have to worry about these issues though. Plus, there’s Epic Online Services!
Gajentaan: Despite our years of experience, we’ve never developed a game on so many platforms simultaneously (PC, PS4, PS5, Xbox One, Xbox Series X, Switch). Of course, the game needs to be playable both on Switch when handheld and when docked, so you can count that as almost two platforms. What’s more, some of these platforms come in different flavors, so there’s a need to also tune the game for Xbox One X, PS4 Pro, and Xbox Series S in addition to their base models to create the best possible experience. And finally, our game supports split-screen co-op play.
Thankfully, UE4 has an enormous amount of scalability parameters and settings that can be used to tune the content and rendered output for each possible scenario. I call these scenarios, as split-screen would nearly always require different settings from full screen.
To keep my head above the water, I kept track of all these parameters and their values in a spreadsheet, so I could see how each platform/scenario compared to the other. And of course, I investigated what each parameter does and how it influences the visuals and performance.
For several platforms, we use dynamic resolution for when things get a little heavy on the GPU. For scenarios on the lower-end hardware, materials are simplified using Quality Switch nodes and non-essential detail meshes and particles are hidden using Detail Mode. LOD distances, shadows, post-process quality, foliage density, screen resolutions, and many, many others are scaled to best fit each scenario.
Image courtesy of Implausible Industries
What excites you and your team the most about the long-term possibilities of next-gen hardware and Unreal Engine?
Willacy: I’m looking forward to playing around with MetaSounds in UE5, personally. I love working with audio and I hope people can see that with the audio in RESEARCH and DESTROY. It looks like MetaSounds will allow even more gameplay-entangled audio madness.
In terms of hardware, I just look forward to the day when you can care a little less about a lot of the busy work that's necessary to make games. I think we’re taking our first steps down that road, particularly when this new hardware is in lockstep with some of the stuff in UE5.
Markiewicz: Nanite combined with the fast loading times of modern consoles (and PCs) has me really excited for the potential of scale (and dynamic changes thereof) in gameplay.
Thanks for your time. Where can people learn more about Implausible Industries and RESEARCH and DESTROY?
Learn more about Implausible Industries at http://implausibleindustries.com/ and learn more about RESEARCH and DESTROY at https://rad-official.com/.
Willacy: I’m looking forward to playing around with MetaSounds in UE5, personally. I love working with audio and I hope people can see that with the audio in RESEARCH and DESTROY. It looks like MetaSounds will allow even more gameplay-entangled audio madness.
In terms of hardware, I just look forward to the day when you can care a little less about a lot of the busy work that's necessary to make games. I think we’re taking our first steps down that road, particularly when this new hardware is in lockstep with some of the stuff in UE5.
Markiewicz: Nanite combined with the fast loading times of modern consoles (and PCs) has me really excited for the potential of scale (and dynamic changes thereof) in gameplay.
Thanks for your time. Where can people learn more about Implausible Industries and RESEARCH and DESTROY?
Learn more about Implausible Industries at http://implausibleindustries.com/ and learn more about RESEARCH and DESTROY at https://rad-official.com/.
Get Unreal Engine today!
Get the world’s most open and advanced creation tool.
With every feature and full source code access included, Unreal Engine comes fully loaded out of the box.
With every feature and full source code access included, Unreal Engine comes fully loaded out of the box.