Switch’s “impossible ports” are the new “perfect arcade”: games designed for much more powerful hardware somehow miraculously receive remarkably impressive conversions on relatively meager hardware. However, variable performance and low resolution are also the hallmarks of these amazing technical achievements and this is where we should highlight the work of Rebellion North to deliver some exceptional conversions. Zombie Army 4 is its latest Switch conversion, running at the same 30fps as the PS4 game with a 1080p target resolution and retains the title signature, a horde of 80-100 strong zombies on the screen. Below you will see our analytical work on this exceptional port, but most of this piece is not about the “what”, but about the “how”, with the developer himself sharing his methodology and knowledge about the conversion process.
At first glance, Zombie Army 4 a Switch is a ringtone for the PS4 version and seems to match the resolution and frame rate goes a long way, just as it did for the excellent Sniper conversion Elite 4 of the company. As you will read in the interview, the development aims at native resolution and 30 fps in Switch mobile mode, before increasing the docking experience. It uses a dynamic resolution, with a range of 918p to 1080p, dropping from 684p to 720p portable. Beyond that, the gaps and positions are many and varied, but most of all, they are not particularly noticeable. However, there are some exceptions: cuts in dynamic shadows and the lack of environmental occlusion of the screen space.
Tom Morgan presents this video, breaking down how close Zombie Army 4 is to the PlayStation 4 version, while maintaining the same 1080p target resolution and 30 fps performance level.
The changes from here are more subtle. The quality of the geometry is reduced to the distant distance, with a more aggressive LOD change that is not noticed in normal play. Effects such as particles and transparencies also return in quality. Also for the texture situation. With only 3.5GB of RAM usable for working on Switch, memory was a big limitation for Rebellion’s Zombie Army 4 port. Still, the team found smart solutions. Above all, they were determined to keep a blanket from falling into anything on every texture in the game. The reflections also adjust, but the reflections in the screen space remain in the water bodies, supported by an improvement on Rebellion North’s existing cube mapping technology for Switch.
The result is that the proven track record of the studio in delivering excellent Switch conversions is only embellished with this latest version. Now, let’s find out more about how this was delivered in this interview with Rebellion North studio head Arden Aspinall, senior programmer Alex Gray and environmental artist Reece Parrinder.
To view this content, enable targeting cookies. Manage cookie settings
Digital Foundry: What was the biggest challenge in changing a game like Zombie Army 4?
Alex Gray: To be honest, all the limitations of Switch’s hardware were a challenge with this one. Previously, CPU and GPU performance was a big issue, but this time it was ZA4’s exclusive memory pressure. Because it’s such a big game, and there are so many things going on, we actually had to spend a lot of time tackling memory. Now this is not something where you can have DRS [dynamic resolution scaling] climb back. If you run out of memory, this is the end. It crashes. Still, performance was the biggest issue as expected, especially with so many zombies on the screen. I mean, I think in some sieges, you can reach between 80 and 100 zombies at any one time, which is a little crazy, know how much is going on – update all your logic and show them all the different happens. This is a pretty high level.
Arden Aspinall: It took us a long time to bring it back to memory. The way we’ve always focused on Switch ports is that we want to keep trying to maintain the quality of what we’re doing in terms of resolution. And then, once we have that parity [with other consoles], where it works exactly as it does, no matter what the frame rate is, even if it’s one frame per second, we make it work exactly as it does on PlayStation. Then, we can start turning the dials and pressing the buttons to try to figure out what is the best compromise we think is acceptable. But to get to this point with Zombie Army 4 we had to save everything in memory. And even using Nintendo’s development kits, even that was a stretch. Just running it on Switch development kits with expanded memory, usually this gives you a chance. So it’s an interesting challenge.
But it meant we couldn’t see it all [picture]. It’s like you climb to the top of a mountain, you see a whole mountain range, you think, “God, we have to climb all these mountains too.” It took quite a while to get to this point. And I think the team has shown a lot of patience, because we were really looking forward to starting putting all the tools we already had in the box for Sniper Elite 4, to say “okay, let’s see.” And we were telling everyone, “Look, wait. First, let the thing work.” You know, we put everything we had done in Sniper 4 [into the game]. And obviously we had also done the zombie army trilogy. So there were some little optimizations we could do there. Things like shadows when they’re out in the distance, doing them with less quality and things you wouldn’t notice unless you were comparing A and B from different platforms. So we could also put in some of that [for Zombie Army 4]which we didn’t have to present for Sniper 4, because there weren’t so many enemies on the screen at once.
Reece Parrinder: One of the main differences I saw from the artistic team’s point of view was that with older games like Zombie Army Trilogy and Sniper Elite 4 and Strange Brigade, we were kind of a team focused on the GPU. We could only focus on the GPU statistics that were coming in, where these really smart guys focused on sorting out the CPU side. So we finally get them [to help on CPU]. And the same thing happened with the memory side of things. The most important change with Zombie Army 4 was that then we had to come up with new tasks that we could help from the outside to try to recover additional things from the CPU and memory side.
Digital Foundry: When you started Zombie Army 4, what was the status on Switch compared to where you ended up? As it looked, right at the beginning when you just said “let’s see how it works?”
Alex Gray: From the first moment, you obviously start to get the compilation of the code, but then it’s mostly about connecting the NVN renderer. So the first time it runs, and we haven’t put the renderer on yet, you’re sitting there on a black screen and correcting the first error with the renderer. And then start working with the issues, implementing more snippets of the renderer. So you’ll start with a black screen, which is actually a massive milestone, just get to a black screen.
Arden Aspinall: A black screen with a game behind it … if you’re very lucky, you have the audio so you can listen to the background music!
Alex Gray: There’s a big leap from this black screen to even representing the loading screen, which is just a static image. You have to work hard: shaders are built and run properly just to render it. So this is another massive milestone where we start and finally get into 3D. I mean, I remember seeing that zombie depicted on the front screen for the first time. This was immensely satisfying.
Reece Parrinder: I don’t know if any of you remember specific stats, but I went back and extracted some of the first smoke tests we had. One of the levels of this, for example, I’m not sure when it will line up, or if a certain amount of time passes before we run the last month’s build. But for one of the levels, it ran at 116 ms on the GPU [around 8.5fps, the target being 33ms/30fps].
Arden Aspinall: I should mention the other thing we did working the doors, we really leveled up on Sniper Elite 4 when it came to doing our smoke tests. Artists would find all the real hotspots around the levels and put performance points so that the encoders would connect a bunch of performance statistics, where we could break down where all the cycles went to both the CPU and the GPU, and also where there are there was memory. going, so it was really good. From the start of the project, we could literally graphically represent our progress. We had like a burn-down about the task until it was completed, like our own drop chart to reach our magic 30 frames per second. So it was a little fun. But it’s also fun to look back now.
Digital Foundry: Is there a stress testing area, where if you can get the performance, should you follow the rest of the game? Or was it mostly uniform, just trying it all out?
Reece Parrinder: At first, when I got into the project, I was thrown into the worst level of performance, which was the 160 ms we were looking at. And a lot of the things I was doing was clarifying, okay, if we do everything we need to do – big bulk tests like lower LODs and stuff like that. If we manage to reach this level to a reasonable point, all other levels in theory should go down much easier.
Alex Gray: I mean some scenes will be in a forest and the foliage rendering is inherently slow, just because there’s so much excess. And then other places, when you can see very, very far away, you end up having to represent a lot. So, you know there are certain sections of the game where there is a lot of foliage, and it was very far away, and then you had 80 zombies represented at the same time …