WOLFHOUND: WWII Sci-Fi Metroidvania From Chasm Developer

WOLFHOUND blends a WWII setting with sci-fi horror and classic Metroidvania structure. How did that concept come together, and how early did you lock in those core pillars?

It was a slow process to reach the end concept. The starting point was only that I knew I wanted to make another adventure game in the Metroidvania genre. The market looked overcrowded with fantasy ones, so I decided to go back to the roots and lean into the Metroid side. I began brainstorming different ideas that would fit, and one day a vivid image came to me of a soldier fighting zombies in the woods. I thought that could be interesting, but I still didn't have a who, why, or when.

The rest of the concept finally came together when I was restoring old photos my grandfather took in World War II. One of the photos was of ragged prisoners marching in file, and on the back was written "More of Hitler's Supermen." While I had considered a WWII theme before, that cemented it, and I knew that I needed a wisecracking tough guy like Grandpa to lead it. The campy mad scientist, hidden island, mutant creatures, etc., all fell in line after those key pieces were in place.

You've moved away from procedural generation seen in Chasm toward a fully handcrafted world. What drove that decision, and how did it impact your level design and production workflow?

I'm really proud of what we were able to accomplish with Chasm, but I can't say I'd want to go through it again. The initial prototype was inspired by Diablo with isolated floors that just went downwards, but we really wanted to make something that felt like a traditional Metroidvania. That led to trying to get everything interconnected, which is much trickier than it seems at first. We ended up using a concept of hand-made sections that serve as the anchor points between the procedurally generated paths. So, to go fully hand-made for WOLFHOUND, the tools pretty much already had everything that was required, and it basically just came down to pulling out the procedural generation code from the engine.

The game takes place across a single, interconnected island with seamless transitions. What technical or design challenges come with building a world that functions as one continuous space?

The biggest headache by far is fitting all the different areas and keypoints on the grid and knowing that if you need to add a room or path here or there, you could be affecting all the other rooms around it. I've tried to keep the debug graphics in as long as possible, so I don't waste a lot of time styling and restyling rooms over and over as things are modified.

The rooms themselves are all individual assets, so when you scroll between them its more of a magic trick than anything. A screenshot is taken of the room you're in and the next room, and then it scrolls the 2 screenshots across the screen in the direction you are moving, switching back to gameplay once the scroll is complete. This can be tricky between certain transitions due to how the camera behaves, so the doorways need to be precisely placed.

Your approach seems heavily inspired by NES-era design, including deliberate pacing and limited combat options. How did you translate those constraints into a modern game without frustrating players?

I want players to feel the weight of the character, as well as the mechanical action of the weapons. That kind of tactile feel is very important to me from an immersion standpoint. And while the player moves deliberately and you need to plan your attacks, I've tried to keep the collisions very clear so that nothing ever feels unfair or unexpected.

Combat emphasizes careful positioning, reloading, and limited firing directions. How did you design and implement these mechanics to reinforce tension and strategy?

That was mostly just going back to the original Metroid and studying what worked about its combat. In run 'n guns like Contra you can typically fire diagonally and hang far back trying to hit things across the screen, which contrasts with Metroid where the range of the bullets is much smaller, and the player must carefully approach enemies to engage. Adding the reloading mechanic on top adds another layer of preparation for each engagement rather than just spamming the screen with projectiles. To me, this method works better for an exploration game where the rooms aren't forever scrolling hallways that need to be traversed back and forth.

The game features a relatively low native resolution (320×180) with options for CRT-style presentation. How does that resolution choice influence your art pipeline, rendering, and UI design?

I prefer to keep all the art assets at native pixel scale, render the scene, and then upscale at the very end to the player's system resolution. This method feels much more authentic since it keeps all the pixel sizes uniform and locked to the grid, but it does have some downsides. It looks worse if it's stretched out of the original aspect ratio, and complicated text characters like Kanji don't work well in small spaces. The way the text bubbles were designed in Chasm, it made it almost impossible to support some languages, so I've tried to take that more into consideration this time around.

Can you walk us through your pixel art pipeline, from concept and sprite creation to animation and final in-engine integration? And which software is used?

The artists both work in Aseprite. Background art is delivered as power-of-two PNG tilesheets (1024x1024 is most common), while animations are delivered as individual PNG animation strips that are combined into giant atlas textures (2048x2048) at compile time. The rooms are styled in the in-house editor Apparatus, as well as setting up the animations and adding hitboxes.

How do you balance authenticity to 8-bit aesthetics with modern expectations for readability, animation fluidity, and visual clarity?

We're using a limited palette of about 60 colors for WOLFHOUND, based on Arne's Famicube palette with a few tweaks and additions. We have to carefully choose colors to keep the important foreground elements popping from the background, especially since we avoid using outlines. Depending on the area, this can become tricky given the overall tone of the area and the colors in the player sprite. Most animations are relatively low FPS, typically run between 12-16 FPS in-game, but are plenty fast for the scale of pixels and timing of movements.

What tools and technologies are central to your workflow for building environments, systems, and gameplay logic?

The game engine is built on the FNA framework, an open source implementation of Microsoft's retired XNA Framework. FNA utilizes SDL under the hood for video, audio, and input device support, so I can just focus on gameplay logic instead of supporting a million devices. The editor is made with WPF and is all C#, along with the game engine.

Looking back at development so far, what were the biggest technical or design challenges, and what lessons have shaped how you're finishing the project?

I definitely underestimated just how much work an 8-bit game would be compared to a 16-bit game. Sure, the graphics are a little more primitive, and scenes don't require as much detail, but from a general production perspective, it feels like the same amount of effort overall. Luckily, I haven't really run into any major technical issues this time around, as building off Chasm's well-tested engine gave me a big head start.

However, the design challenges are continuous and never-ending! No matter what the project is, it always comes back to finding the fun. So if you're able to keep that as your central focus, I think you're doing about as well as you can be.

James Petruzzi, President at Bit Kid, Inc.

Interview conducted by David Jagneaux