Hello everyone!

It's been almost a year and a half since the first release of The Trespasser, so I thought it would be a good time to reflect on the past, hopefully to better prepare for the future. I write this mostly for myself, but if you're interested in the nitty-gritty of game development, you may get something out of it too. ;)

Let's start way back, with The Trepasser's predecessor: The Lightkeeper. This project started because I wanted to quickly make a game for my portfolio and I happened to have metrdoivanias prototypes ready to be repurposed into a single, coherent game. Of course, my main inspiration was the very first Metroid, but I was also inspired by Xeodrifter. Not because I loved it (I don't even remember if I finished it or not) but because I thought I could achieve something of a similar scope by myself, in the few months I had. It worked out pretty well, and The Lightkeeper is still to this day my most downloaded game.

After that, I focused on paying homage to another series from my childhood by making a Zelda-like named Lunar Wake. Once I was done with it, I started to imagine going back to metroidvanias to create something more polished than The Lightkeeper, by taking advantage of all I had learned since then. But if The Lightkeeper was an homage to Metroid, this spiritual sequel would play more like the Castlevania side of the genre. This single decision also contributed to make The Trespasser way more ambitious than its predecessor.

So what went right and what went wrong?

Right: Using 3d models

The Lightkeeper's protagonist had very few animations: walk/run, jump/fall, crouch and climb. That's it. And each animation only had a couple frames. I still had to draw each one for each costume, but it was very manageable.

But I knew I would need a lot more for The Trespasser, due to the different influence, the melee combat and the additional abilities. I also wanted bigger sprites. Looking at the sprites for the DS Castlevania games, I quickly realized there was no way I could do that myself.

Thankfully, I had been playing with a custom raytracer for a while. I knew I could setup a pipeline to assemble and pose 3D models and render them as 2D sprites. But would it work for very small pixel art sprites? Or would it only output an unrecognizable mess of pixels?

So I asked myself how I would shade that sprite by hand and then I wrote a custom shader to automate just that: simple cel shading, eliminating single pixels of color, having a lighter color for the outline on top, and many other "little tricks" to bring it closer to genuine pixel art.

And it worked! It's not the cleanest pixel art you will ever see, but it's good enough and the fluidity gained by introducing many more frames made up for it.

Suddenly it became possible to introduce many alternate costumes, which is something I took great advantage of. It worked so well that most humanoid enemies use the exact same model and animations, to the point the player sprite could be replaced by any of those enemies without missing a frame.

I don't think I will ever go back to handmade sprites for the protagonist of a game, doubly so for top-down games where you need to account for 4 to 8 directions!

Right: Splitting the world in chunks

The world of The Lightkeeper was a single continuous map. One huge block. It meant it was very hard to change it. Wanted to introduce a new room between two others? Nope, not happening.

To avoid the same fate for The Trespasser, I decided to split the world in multiple maps that would then be stitched together with another editor. I thought one map per biome would be enough (it mostly was).

This idea was quickly battle-tested: right in the middle of development, I went back to the drawing board to improve the flow of the game. The biggest change I identified was the need to connect back the underground tunnels to the beginning of the game, which was the next objective. Well, no big deal, I thought. That's what the chunk system is for. I had to split the caves into more chunks to reorganize them as needed, but it was working just fine. Until I realized another biome was in the way: The Temple of Madness. To make room for the new loop, I had to move the temple from the left side of the world to the right. But that's not a trivial change because the entrance was on the right, and you explored by going to the left. That wouldn't work now that it was on the other side of the world! It needed to be mirrored to still connect to the central hub and be explored left-to-right. But because the temple was one independent chunk, I only had to write some code to mirror its tile map and then edit everything that wasn't symmetrical by hand. It was work, yes, but it was doable. With The Lighkeeper's approach, it wouldn't have been possible, I would have simply given up and accepted a worse game.

Because I was creating those maps one at a time, I could not see in the editor if the connections matched together. But there wasn't many of them, so I simply launched the game and checked them manually. No big deal.

So yes, big win!

Wrong: Over-engineering the prefab & scripting system

Both The Lightkeeper and Lunar Wake described their entities entirely in code, including their sprites and animations. I thought it wasn't great. I wanted to create prefabs as data, directly from the editor, with a live preview.

For The Trepasser, I started writing a few different "spawners" that would configure entities in different ways, according to data-driven parameters. It worked, but only for similar families of entities, like destructible props with different sprites each or relatively similar enemies. But a lot of behavior was orthogonal of those spawners, so I added a list of "traits" to all spawners. Those traits where often 1:1 equivalent of components, to the point where I made it possible to register any serializable component as a trait. At this point, the whole idea of the spawner system was pretty compromised, with some prefabs having an empty spawner and a long list of traits.

It was even worse for bosses. I didn't want to create a different spawner in code for each one, I wanted them to be purely data-driven. To do that, I introduced a scripting system based on a tree of serializable objects embedding behavior. It worked, of course, but it required extensive tooling.

Every single bit of behavior meant writing a new serializable class. Then I needed a visual editor to build that tree, with drag & drop features to rearrange the commands, etc. And what if I removed a command in code that was still referenced in data? Now I needed extensive validation, the ability to load scripts with unknown commands, etc.

I built it all. But why?

It's like I forgot I was a lone developer with a programming background. I could, like... just write code... with a text editor. It's like I wanted the game to be fully moddable by non-programmers, but it was never a stated goal of this project. It certainly wasn't user-friendly enough for that and I never advertised it.

A ton of work and additional complexity for no real gain.

And it also made a mess of the codebase and the data, with some prefabs relying on spawners, others on traits, and other on scripts. Some scripts were written in Lisp, other with the new tool. There was zero consistency.

I still want to be able to build prefabs outside of the game and reload them without restarting the executable (something The Trespasser's system didn't even allow!), but I can do that in code. It's super easy in .NET where I can compile C# on the fly (and reference the precompiled assembly in release). That's probably the direction I will use for future projects.

Right: Releasing a big extension

I don't really do marketing. Not the traditional "advertise your game" marketing, at least. I don't really talk about my games before they're near completion (when I know for sure I'm gonna release them) and then I publish them on itch with only a tweet to see them off.

It means I'm very dependent on itch's visibility to get the ball rolling. Sometimes I'm lucky, sometimes I'm not. And as years go by and itch expands, luck is getting harder to come by.

That's one of the reasons I publish big updates called 'extensions': to get another shot at this. It's like a second release day.

And on this front, the 'Ice Caves' extension delivered. It really acted like a second launch, with renewed attention on the game. It almost reached x4 the number of downloads compared to the initial launch! And the tail was much better:

Honestly, it was the kind of numbers I had expected from the initial launch. The game was even the most popular metroidvania for a fleeting moment!

Sure, this extension improved a great many things (including the attack animations) and added a lot of content to the game, but I don't think any of this made the game visibly more desirable than the initial packaging. I assume the difference in numbers in pure luck and algorithmic snowballing.

Seeing this makes me reconsider my stance on "open development". I'm a lone developer who's very busy with life and the day job, so every minute of free time I have goes to the actual development of the game, not chasing attention on social media. But the real reason I don't really talk about my games before launch is because I can't promise a release date... or even that they will come out at all. But in my fear to not over-promise, I may be shooting myself in the foot. The first version of The Lightkeeper was pretty rough but I improved it over time to great success. Maybe I should plan lighter initial releases and more additional content over time, both big and small updates. Kind of like the "Early access" model.

Wrong: melee combat 

Melee combat is hard.

The projectile-based combat of The Lightkeeper didn't stop the player's movement, but melee attacks do. And with that comes a lot of issues.

First of them, you don't want the player to mash the attack button to hit an enemy and miss every time because they're slightly too far from their target. To fix that you give them some forward momentum so that subsequent attacks will reach. But then you risk getting in contact with the enemy and receive damage yourself... The way I worked around that was ultimately to reduce the enemies hitbox to the point you have to overlap them to get any contact damage. It really drove home to me the fact that visuals and hitboxes are two completely different things and that I shouldn't be afraid to have very small damage hitboxes for the enemies (in addition to having generous hitboxes for the player's attacks, but I was already doing that).

Second is: should enemies be stunned by player's attacks? If they are, you could stun-lock them and remove all challenge. In The Lightkeeper,  I had them keep moving, which fitted the ranged combat: can you kill them before they reach you? It doesn't work as well in a melee-based game though. You need to be up-close and personal to attack them, so they will reach you instantly. After some back-and-forth on that, I booted-up my copy of Dawn of Sorrow to see how they did it. Enemies kept moving! But how did they solve the issue of avoiding them while staying in-range to attack? By introducing a backstep move. I reused that idea, but I never made it work. I went to great pains to have the backstep cancel the attack animation and allow you to get out of range of the incoming enemy attack, but in practice it never came together. I don't think many players used the backstep past the tutorial prompt. I don't think I've ever used the backstep when I playtested it. Maybe I could have introduced a stamina cost and invincibility frames to the backstep, to make it more useful as an early evasive action, instead of a mere "I regret my attack" panic button?

Considering all that, balancing melee attacks against the gun was a problem. Sure the gun uses stamina, but it's not enough to balance the advantage gained by being far from enemies that were made for melee combat. Bombs were also a problem. Not because they're overpowered (that's the point) but because the intended drawback was you could easily blow yourself up as well... but by the time you get them, you have so much health that you can take the hit without worrying too much. And the boss rooms usually lack the obstacles that could trigger such accidents. I knew about those issues, but I never really found a way to fix them.

It all drive home the fact that the micro considerations of minute-to-minute gameplay are not my strong suit. I'm more interested in the macro structure, the progression, world design and narrative. And that's fine. That's one of the reasons why I err on the easy side for my games. Only carefully-tuned encounters can afford to be difficult. But I still need to improve for future games.

No idea: Making a trailer

I hate making trailers. It's a chore. But I'm told they're important, so I made one for The Trepasser.

When the game was nearing completion, I recorded a full playthrough and cut some clips that could help me convey the gameplay and the mood of the game. But when I tried to edit the footage together I realized I recorded it wrong: I should have muted the music but kept the SFX. So now I had to re-record the whole thing, and of course I never managed to reproduce my favorite shots exactly. It was a ton of tedious work.

But was it worth it?

It got a bunch of views, but as far as I can tell, not many of them converted to page views on itch, let alone downloads. Years after the release, the game has way more downloads than the trailer has views.

When I updated the game, improving the graphics, lighting and animations, I looked at the numbers and decided not to redo the trailer. I thought it would be a waste of time. And I'm pretty sure it was the right call.

The only thing that makes me doubt it is that I've recently stumbled upon a video of people watching and discussing metroidvania trailers. The trailer for The Trespasser seemed to have caught their attention, as well as a commenter who expressed interest in the game. So maybe it was working as intended?

I don't know. I'm still not sure it was worth the trouble. What I know is that I will only make more trailers if I can find a way to streamline the process. Maybe even automate it, somehow.

Conclusion

The Trepasser was a somewhat difficult project for me, and the slow adoption was a bit demoralizing, but in the end I'm really happy where it ended up. I think it's a pretty good game, that manages to differentiate itself from its predecessor while still building upon it. And by the time I implemented the Ice Caves, creating content for it was pretty smooth. I'm sure I can do better, and I intend to. I've learned a lot making it and hopefully that kind of articles can give other developers ideas.

I talk a bit more about my general process and what I've learned making those games in this article titled How to create your own Metroidvania, back on my website.

If there's another topic you would want me to cover, feel free to tell me in the comments! ;)