Interview with Decemberborn’s Eric Lavesson about Cathedral, the first Evercade native title

The Blaze team keep pulling clever tricks out the bag for Evercade, and in celebration of the first native release, Cathedral, we talk to Decemberborn Interactive’s Eric Lavesson about the effort required to cram a game built for modern consoles into the modest Evercade platform. 

Update, cart now available for pre-order on Amazon!

From a player perspective, retro game development must be a fantastic challenge, trying to build a title that appeals to modern tastes into the smallest of digital, audio and palette footprints. Let’s see what Decemberborn has to say (many thanks to Eric for his time) about the proverbial pint-pot trick it pulled off with Cathedral on Evercade? 

So, firstly why bring Cathedral to the Evercade? 

When we got the opportunity to do this, we just couldn’t turn it down. Honestly, just the fact that we were going to be the first natively ported game was enough to convince us that we wanted to do this. It was a bit daunting at first, since we were kind of treading on new ground; It’s not like there’s a forum of other developer’s who have done this before where you could get help. The first couple of weeks of porting were mostly for us to make sure that we could even get things up and running, and that it would run at a decent framerate. Luckily, the folks over at Blaze Entertainment were more than happy to help out whenever we had dumb questions about the hardware!

How hard/easy did your team think it would be, how many people were involved and how long did the port take? 

Essentially it was me and the other programmer of Decemberborn (Mattias) who have been involved since the early days of the company that did the porting.

Regarding difficulty: We had no idea. We weren’t even sure if it would be doable at first, so once we actually got that initial screen rendered, and got the game running, we basically said “yeah, this is doable”. Once we could compile and link everything and get the game started, everything else was going to be a matter of optimizations. Granted, it crashed every now and then due to us using up all the memory on the console, ran below 20 fps and had completely unacceptable load times. But it *ran*, and that was big.

Is there an Evercade dev kit or was this project all done in software? And what tools were used?

There’s a devkit, which is pretty much the original hardware with different firmware running on it. Having hardware access was crucial to doing a reasonable port.

We did do a lot of changes that we could test directly on PC, but we also had changes that were made specifically for either the original handheld, or for newer consoles, such as the VS and EXP ones. Most of the time we started out testing the game out on PC with the changes that we made. Testing things out on the actual hardware was a must though, to make sure that we kept within memory limits, and at target framerates. Also, we had some hardware-specific rendering issues from time to time, which could only be reproduced on the original hardware.

What were the technical challenges in bringing the base game over? 

We were in a pretty good place technically speaking, since what we had to port was a custom engine that we wrote ourselves. Each console has had its own set of challenges, and the Evercade wasn’t different in this aspect. What WAS different was that the Evercade (and the handheld original console specifically) was a lot more restrictive than any other console we had ported to to date.

We definitely had our fair share of challenges though. First off, a lot of our UIs were not meant to be rendered on a screen the size and resolution of the Evercade, so we ended up having to redesign a lot of them to suit the device better.

Another recurring issue was memory. The original Evercade does not have a lot of memory (256 megabytes). There’s no dedicated graphics memory, so these 256 MB need to cover just about everything, including the machine’s own processes. Originally, we were definitely over that limit by quite a lot since we never had to care too much about memory usage. We spent a lot of time on memory optimizations.

What are the specific benefits of porting Cathedral, and what optimisations did you manage? 

As I mentioned, memory optimizations were a big part of our optimizations. Cathedral loads all its textures into memory at startup, which we might have designed differently, had we known about the Evercade port beforehand. This is all packed into a giant texture called a texture atlas, which alone took almost all the machine’s RAM.

So a lot of time was spent rewriting texture loading. We split the atlas up into smaller ones, and worked on reducing each texture atlas as much as possible in size to save memory.

We did also have a target of keeping the framerate as close as 60 fps as possible. To keep some levels running smooth we simplified some levels by removing background parallax, reducing tile count, reducing enemies and other dynamic elements, and (most importantly) porting a lot of our code from Lua (the script language we used) to C++ (which the engine is written in)

Is there anything a player of the Switch/PS4 versions would notice as different? 

The most notable change is definitely the UIs. A lot of them have been replaced completely to make sure that they look good on the smaller screen of the Evercade. There are also some level tweaks here and there, as mentioned above. It’s mostly cosmetic, but we also took the opportunity to fine tune some levels that we weren’t 100% happy with. Mostly minor changes though!

Is there a performance or cunning visual trick (even if invisible to the eye) that the team is most proud of?

Oh yes. Remember how I mentioned that we needed to reduce texture atlas size? One thing that we realized was that we had a lot of sprites looking the same, with only the palette shifted. For instance, the player has different colors depending on armor, and a lot of sprites in-game follow this pattern in general - they’re identical, but the colors differ. This is much like you’d have in a lot of older games; Link’s different armor colors in the original Zelda for instance, or Super Mario Bros 1 reusing cloud sprites as bushes on the ground and just setting a different palette.

The thing is that we did this as a nod to those older games and because it fit the style, rather than out of necessity, so we just ended up saving one copy of each color. When we needed to reduce our memory footprint on Evercade, we realized that we could actually take a cue from older consoles and use this idea on a modern platform.

We ended up building an indexed palette system, where we could load a palette into memory to color our sprites, and keep just one version of each thing, rather than one copy of each color. So instead of doing palette swaps to make Cathedral look like an NES game, it ended up allowing us to save a lot of memory by mimicking what machines did back then.

Is it weird working on a physical cartridge for a console with limited connectivity for patches? And is that creating any issues? 

We had some concerns about this early on. The good part is that Cathedral has been battle tested for a few years now, and it’s essentially still the same code running on the Evercade (for the most part at least). That said, it’s not impossible to patch your games, but we’d like to avoid it as much as possible. For that reason alone, we’ve played through the game on both the original handheld as well as the VS more times than I can remember by now.

Elden Pixels published the current versions of Cathedral have Alwa’s Awakening on the same cart, is there a sense of competition to see who’s game gets the best response? 

I honestly don’t think there is - I think both companies want to see the other one succeed. Both games shine in their own way, and while everyone will have their favorite, I think that if you like one, you will probably like the other one as well. It’s two games that go great together!

Have you had much experience of Evercade as a gamer, and what is your favourite cart/game? If not, what would you say is the ultimate retro property you’d like to work on? 

I have to admit that most of my Evercade cartridges have been bought since around the same time I started working on the Cathedral port, so I’m still going through the carts. I’m looking forward to the C64 cart, and I really like the Interplay Collections. I grew up with C64, Atari ST, Amiga 500 and NES, so any cart with games that was playable on those machines usually gets my attention.

And, what next for you guys? Or can’t you talk about it. In general terms are you loving the retro life or would you like to spread your dev skills further? 

We are actually working on a new game engine, with a game attached to it of course. Right now, it’s looking to be a pixel art metroidvania again, but in a slightly different setting and style. Less NES, more 16-bit(+) era with less restrictions. Down the line, we do have some ideas that we’d like to try out that won’t necessarily fall into the retro category. Still, retro gaming is close to our hearts, and I have a feeling we might hang around all things retro for years to come.

Evercade cart 27 featuring Cathedral and Alwa's Awakening will be available in October