How to create your own Metroidvania

The metroidvania genre is an indie darling. And for good reason! It's an old, beloved genre that went through a recent renaissance, and it's relatively approachable for smaller developers (including one-person armies like me).

So maybe you're in the mood to make one yourself? I made two, let me tell you how I did it.

• What's a Metroidvania?
• Why make a Metroidvania?
• Why not make a Metroidvania?
• Where to start?
• Implementing Player Abilities
• Mapping
• Storytelling
• Live Updates
• Conclusion

What's a Metroidvania?

As genres go, metroidvania is not very well defined. To make sure we're talking about the same thing, I will give you the definition I'm operating on.

The portmanteau comes from the release of Castlevania: Symphony of the Night, a spin-off of the main Castlevania series staring Dracula's son. What set it apart from other installments were Alucard's increased mobility and the huge single-level you could explore in a non-linear fashion. Gaining new mobility abilities would unlock new parts of the castle. In other word, it played a lot more like a Metroid game than a regular Castlevania. Which is why the press coined the term Metroidvania to describe it. (Funnily enough, the developers were more inspired by Zelda than Metroid!)

Nowadays, metroidvania is used as a genre name. It would imply that it describes anything that looks and plays like either of those games. But there's a lot of overlap and differences between the two, so what's required and what is not? Do metroidvanias need to be side-scrolling platformers? What about Metroid Prime then?

For the purpose of this article, let's focus on the progression system: in a metroidvania, you explore a large interconnected world that is gated by player abilities. So it cannot be open-world, it needs gates, and those gates cannot be simple keys. 'Solving the map' is the main gameplay loop: your exploration is blocked by gates and you have to find your way to the abilities that will unlock them until you reach the ending. And each time you collect a new ability, the way you play changes.

Why make a Metroidvania?

People love them

If you clicked on this article, chances are you're already drawn to the genre. You like metroidvanias, don't you? That could be reason enough to make one. I work for the AAA industry, but the games I make on the side are a hobby. I don't have any financial incentive, so I can afford to make anything I want to do.

People play them

But if you do want to earn money, know that metroidvanias have an advantage: they are like books or movies, self-contained experiences with a beginning and an end. Some genres are more like sports or hobbies, so their fans are only playing one at a time, for a very long time. It leads to a winner-takes-all market: if you make a new battle royale game, you will compete against Fortnite... and you will lose. But if you make a new metroidvania, people may still play it after they finish Hollow Knight! That's a huge advantage in this saturated market.

They're developer-friendly

Another advantage of metroidvanias is that the barriers to entry for developers are relatively low. Especially for the pixel-art 2D side-scroller incarnation. There's no shortage of tutorials and samples to create 2D platformers, so it's easy to get started.

Getting started is one thing, but finishing and making it good is another entirely. So let's talk a bit about Return on Investment (ROI), because I'm going to use this word a lot, and I'm not using it in the traditional monetary sense.

I have a notion that this article will be read mostly by smaller developers, with a fair share of beginners among them. AAA don't really do metroidvanias, and even if they did, they don't need my advice. So it's safe to assume that we're dealing with severely limited manpower here. Which is also my experience, as a hobby developer working a second shift after my AAA job.

So, is the effort you're spending on each part of the game relative to its contribution to the players' enjoyment? That's the important question, and what I mean by ROI.

To get a good ROI, the assets that take time and effort to create need to be either reused frequently, have inherent synergies with each other, or have a big impact on players.

By their nature, metroidvanias have a good ROI overall. It's not as good as purely systemic games like Rogue-likes (the indie darling for a reason), but it's not bad either. Want bad? Think about JRPGs: lots of hand-crafted content, most of it only experienced once. Yikes.

The biggest development effort for metroidvanias are the player abilities. And that's the most systemic aspect of the genre too, so the ROI is pretty good on those. (And we will see tricks to keep a high ROI.)

It makes the genre quite developer-friendly.

Why not make a Metroidvania?

Let's face it: for all the reasons above, everyone is making a metroidvania these days. It's quickly becoming a saturated genre. It may attract some stigma, as the general audience may roll their eyes and exclaim 'oh not another indie metroidvania!'. And even the dedicated audience can struggle to find your game among the masses.

But hey, what genre nowadays doesn't suffer from this?

Where to start?

So, how do you design a metroidvania?

I can only tell you how I did it. But it worked for me and it could very well work for you. Feel free to keep or discard my advice on a per item basis.

The initial concept

When I started working on The Lightkeeper, I already had a setting in mind. Lovecraftian horror, as it turned out. I knew there would be a lake, and under the lake would be weird alien stuff. I knew you would start as a random part-timer at the lighthouse and end up with a similar skillset to Samus Aran.

I suspect you already have a similarly vague idea of what you want to do with your game. So how do you translate that into an actual plan?

Listing the biomes

My first step was to list the different biomes and organize the progression through them.

For The Lightkeeper, I wrote it as a table. Each row would be a biome, visited in order from top to bottom. Some rows would be split in two columns, meaning two biomes you can access at once. And in each cell, I would list different places in the larger biome, and what I was thinking you could find there.

From a world-design standpoint, it worked well. It was very logical to split the "Derelict Spaceship" biome into a "Docking Pad", a "Control Room", an "Armory" and an "Engine Room", for instance. So even before I opened the game editor, I knew what rooms I needed to create, and how they fit the world logic.

Once I have this list of locations, I need to gate them. Remember: gating with player abilities is what makes it a metroidvania! The next step is going to be crucial.

Listing the abilities

Once again, I start with a list. I write down the player abilities I want to see in the game, ordered from first unlocked to last. They're all mandatory and obtained in order. That way I can figure out the critical path through the game.

Some of them come from the world design. I have a lake, but I don't want you to explore it right off the bat, so I'm going to need an unlockable diving ability. Some abilities I just knew I wanted before I started, and a few other came from looking at what I had and thinking where it could go from there.

Then, I write a second list, for the optional abilities. Things that the player can miss, or get out of order. It's important for me to separate the two, as it makes it way easier to place the gates. The main path can only be gated by mandatory abilities, and they have a strict order. Everything else is optional. With those rules in place, you cannot mess up and introduce soft-locks in your game. Which is one less source of stress during development!

Despite your players being able to miss the secondary abilities, they should still feel significant. In The Lightkeeper, the Morphball was actually an optional ability! I used it to gate further optional content, including the Bombs upgrade that unlocked other places and items in turn. Some players were pleasantly surprised by how deep this rabbit hole went, while many others didn't even notice it wasn't part of the critical path. I think it's a good way to handle non-linearity while still adhering to a safe structure.

Creating a graph

When I have both lists, it's time to combine them by placing mandatory abilities in the biomes.

This exercise will often change my plans for the world. For instance, in The Trespasser, I knew the player would visit a mansion. But it's only when I placed the morphball-like Spider-Form ability in it that I decided the mansion would belong to a cult obsessed with spiders. (And suddenly I also had a notion that many of the enemies fought in this biome would be either cultists, spiders or a mix of both.)

One way to represent that association is with a graph. For The Trespasser, I used a Miro board. I added colored nodes and linked them together. Blue blocks were biomes to visit, red ones were gates and yellow for abilities or other items. The links described how they connected or blocked each other, with dashed edges indicating optional content.

By arranging the nodes spatially in the Miro canvas, I could already get a feel for what the world map would look like.

Listing the enemies

Considering the definition of the genre above, I don't think fighting and enemies are mandatory in a metroidvania, but they're still a good way to spice up the exploration.

Thematic matching

Remember the example I gave you about the mansion and the spiders? Now is the time to do that with all your biomes. Once you know what their theme is and what kind of ability you get in the area, you have everything you need to come up with a good list of enemies.

Gameplay matching

Of course the theme needs to match, but so does the gameplay! In The Trespasser, one of the first areas you visit is the Morlock Village. You've been fighting those cave-dwellers for a while now, but right before I give you the Double-Jump ability, I introduce Flying Morlocks. They're harder to reach, which ramps up the challenge. But the Double-Jump you get is a good tool to even the playing field. It's satisfying to struggle until you get a power-up, and then use it to tear through what used to be challenging. It's the classic Metroid feeling.

How many enemies do you need?

It depends on how large your biomes are. I found that for my games, 3 to 4 is usually enough. I often re-use enemies from previous biomes too. My tools have the ability to count how many times I use an enemy in the world, so I can make sure all of them get enough mileage. In The Lightkeeper, I implemented an enemy that ended up appearing only once in the game. It was a waste of effort (back to that ROI question), so when the time came to add a new extension to the game, I reused that enemy for the new biome. I even added a bigger variation to act as a mini-boss. This variation is unique, but it's very memorable, so this time it was worth it.

Split them into components

When you define the behavior of your enemies, try to reuse as much as possible. Come up with small components that are mix-and-matched throughout. It has a few benefits:

• It's less work. Once you've coded the "patrol horizontally" component, you can use it for both Goombas and Koopas, for example.

• It helps players create a clear mental image of the rules. When you meet a Koopa, you instantly recognize its movement pattern from the Goombas you're familiar with, and you only need to concern yourself with what makes it unique: the shell. And when you meet the Paratroopa, you're already familiar with the shell and can focus on the wings, etc.

• You will also find it easier to balance your game, by introducing enemies with fewer components first, and then ramp up their complexity.

• It may even end-up suggesting new enemies to you, when you realize some unused combination of components could produce interesting results!

Iterating

Of course, you're reading this article in a straight line from top to bottom, as a list of steps, but let me assure you that game design is more like a circle. Every decision you make will ripple both forward and backward. Embrace it! You're only working on paper right now, changing stuff is still cheap.

By now, you should have a good idea of what you're planning to do. It's not necessarily what you will end up with, but it's a good foundation to build your game. If there's something you're not happy with, now is the perfect time to change it, because later it will be may more expensive to do so.

Implementing Player Abilities

You know the player abilities you want to have in your game, now is the time to implement them.

What makes a good ability?

We already covered a few elements of this answer, like the fact your abilities need to be tied to your world, both from a thematic and gameplay standpoint. But here's a few more things to consider.

Multiple uses

It's also good for an ability to be multifaceted. The most obvious example is an ability that can be used for both navigation and combat. Zelda is a very good example of that, with the Hookshot being used to both reach new places and stun enemies. Metroid and Castlevania usually have specific upgrades to make navigation abilities useful in combat, like the Bombs for the Morphball or the Fireballs for the Bat form.

But navigation/combat isn't the only way you can go. In The Lightkeeper, you eventually stumble upon the Helmet to complete your power armor. Its main use is to let you dive underwater, unlocking a large part of the map, but it's also a universal translator! With it, you can now read alien script and learn more about the lore.

That said, optional secondary abilities can afford to be less versatile, as they're usually lesser rewards.

Builds

Most of the time, player abilities are always active after being unlocked. But it can be a good idea to also have some abilities tied to your gear, with more options available than equipment slots.

The Charm System of Hollow Knight is a really good example: it forces you to make choices, and thus let you build your character differently. You may discover you like spell-oriented builds better than melee combat, or maybe you will switch depending on the situation. Anyway, it makes you think and engage with the mechanics on a deeper level, and that's exactly what we want from our players.

Also, equipment slots can become a new type of meaningful collectible, which is always a good thing to have in a metroidvania.

But be careful about assigning mandatory abilities to equipment slots, as it forces players to give up one of their slots to make room for it. Used sparingly, it can be a good challenge. But too much of it and players will feel hindered in the builds they can make. In The Trespasser, the only mandatory ability tied to equipment is the Lava Ring, but thankfully it's only used for a short section, after which you're free to go back to your usual build. It spices things up without getting in your way too much.

Synergies

Synergies are when two or more abilities work together to produce a new effect. Maybe it's been implemented explicitly by the developers, but it can also be purely emergent. The latter has obviously a better ROI, but can be tricky to get right without breaking the game (but then, breaking a metroidvania is often a fun exercise, so you may be able to get away with it).

A good example of an emergent synergy is in Hollow Knight, with the Hiveblood + Joni's Blessing combo. Joni's Blessing gives you extra health, at the expense of your ability to heal, while Hiveblood automatically heals after a while, but only the last (or any extra!) HP. Stacking the two negate their weaknesses and can make you invincible in some portions of the game!

Don't skimp on polish!

Metroidvanias are all about the macro gameplay, the "solving the map" core loop, but the moment-to-moment gameplay is still very important. It needs to feel good to play, otherwise it's going to be a chore, especially when backtracking is involved.

Animation is a big part of that feel, and it can mean a lot of effort. As my first metroidvania, The Lightkeeper was relatively stiff, so for The Trespasser I used 3D meshes pre-rendered in a way that emulates pixel-art. It was a way easier to animate that way, and to tweak the animations as needed. I even used it for most humanoid enemies, as the meshes were built from a character-builder tool. The low resolution meant I could get away with cutting some corners. For example, the models use plain colors (no textures) and the mesh was broken down for each joint (no vertex skinning). Still a lot of work, but better!

VFX and SFX are the other side of that coin. It's not specific to metroidvanias, and there is already a lot of literature on the subject, so I will just stress their importance.

Make them easy to test

You will need a few debug rooms to test those abilities, a playground that you will reuse throughout the development of the game to quickly test for regressions. You will also need a debug menu to unlock abilities on the fly.

I usually make a few artificial save files I can choose from when booting up the game in debug mode, starting at different places in the world with different combinations of abilities. It makes testing a lot easier.

Mapping

So far you have a debug room with your player character able to execute various abilities. Now is the time to actually implement the world you planned in your engine of choice.

World map creation

Making the world is probably the biggest task awaiting you. I find it helpful to break down the map so that each biome is a separate file. That way you can rearrange them easily, which is something I had to do for The Trespasser. I even had to write a script to mirror a map on the X axis when I decided to move the temple from the left side of the world to the right. Some biomes I split in multiple maps, like the hub that connect all the other regions together. Again, it makes it easier to reorganize them as needed.

But it's just as important to have tools to connect those biomes together and make sure they mesh well together. For The Trespasser, I made a special editor to arrange the biomes. I still had to boot the game to make sure the entrances on each side of the transition matched, but it was easy enough.

Rooms creation

To create the map of a biome, I start with stamps. I have a black and white tileset where each tile is the size of a screen (20x11 in my case). A black pixel means a wall, a white pixel is free space, transparent means nothing changes. In my map editor, I can switch to the stamp tool and use those tiles to paint a quick grayblock version of the map. I have tiles for the walls, and other tiles for frequent platforms placement.

The point of quickly creating this grayblock version of the map is to test it early, before any detailing effort has been done. According to interviews, Hollow Knight did something similar, by placing black tiles around to get a feel for collisions, before overlapping 2D art. In my case, I keep the tile aspect for the final look, so I use the paint bucket to replace the gray tiles and then use the pencil to dress it up.

To reduce the need for art, I reuse the same tileset for the foreground and background, but I apply a color overlay to the background layers. That way the foreground still pops out without needing different tiles.

Enemy placement

Enemy placement can sometimes be tricky. You want to give your players some heads-up before facing enemies, meaning placing them on the other side of the room, to let them plan their approach. But what happens if you come back from the other side? You will risk being hit the moment you enter the room. Placing enemies in the middle is not always possible, so one trick is conditional placement: if you enter by the left, the enemy will be on the right, but if you come through the right side, it will be on the left. One way to implement that is to use a trigger around each enemy. When entering the room, if the player starts within the trigger, the enemy does not spawn. So now you just need to place two instances of the enemy (one at each entrance), and only the one opposite the player will actually spawn. You can see this in action in Bloodstained.

Placing save rooms and warps

Depending on your design, save rooms and warps may or may not be the same (if you even have them). But assuming you do, it's often a good thing to place warps at crossroads, so that they may service multiple paths.

You probably already have good instincts for where to place save points, but of course playtesting will refine your intuition. If you notice players struggling with a long stretch of rooms, you may want to break up the challenge with a save point in the middle. Unlockable shortcuts are another good candidate for this purpose, whether or not they're tied to an ability.

Tutorial rooms

If you've ever played a Nintendo game before, then you're probably already familiar with this concept. The point of tutorial rooms is to lock you up until you've demonstrated a basic understanding of your new ability. The Morphball room in Metroid is famous, considering it's the second room you visit in the whole game: you fall from a high place you can't jump back to, and have to use the Morphball to exit through a small conduit at the bottom. By the time the players are back to the first room, the designers can safely assume they know how to use the Morphball and in which situations.

(Of course, locking up the player isn't enough to teach them the ability. You still need some text prompt or something else to teach them how to perform the move.)

Practice rooms

A variant of the tutorial rooms are the practice rooms. You're not locked in those rooms, but you still need to use your new ability to progress. But it's no big deal if you fail. There's no stakes, you can try again right now. Once you've managed to progress, you will find the next rooms relatively similar, except this time you're in actual danger. You've been given some time to practice, now is the test. And each room in this "chain" will ramp up the difficulty.

In The Trespasser's ice-themed extension, I introduce melting platforms to the player. You may be surprised to see them melt under your feet if you're not fast enough, but in the first room it will just get you down on solid ground, with a ladder to climb back up. In the second room, however, I remove the solid ground and you will lose health if you fall. But by then, you know how those platforms work, so you're ready to take on the challenge.

Backtracking

Common wisdom in level design is to avoid backtracking. Of course, it's not going to work in a metroidvania. When the whole point is to look for a way forward, you bet players are going to revisit some old places. Otherwise it means the game is too easy (Metroid Dread is a "good" example of that: it tries to hide how much it funnels you toward the correct path, but you can still feel the invisible hand of the designer).

Make it interesting

Still, you want backtracking to be interesting. Having an enjoyable moment-to-moment gameplay is of course the most surefire way to do this, but some tricks exist to complement that.

One of them is to make sure your new abilities change the way you progress through this well-known space. Obviously, you can hide collectibles that are at first out of reach, so that players will be eager to return to get them. But you can also do it in subtler ways, like in my previous example with the Flying Morlocks where the balance of power is completely different on the way back than it was on the way in.

Another way is simply to give a different way back. At some point in The Lightkeeper, you progress through a temple to unlock the ability to dive underwater. You can exit from the way you came, but you can also use the sewers to do that. That path is underwater, so you could not use it before you completed the temple. It's new to you, and it's a good occasion to practice your new ability and get some optional upgrades on your way out.

And of course, if all else fails, you can just throw events at the players to change things up. After some point in Hollow Knight, the starting area becomes infested by the plague, closing off some convenient accesses and powering-up all enemies. Just when you started to get bored with this hub, it changed to keep you on your toes. Of course, it requires a lot more work than the other options, so it's a bit of a blunt instrument.

Help your players remember

Players will have to backtrack to finish a metroidvania, but it doesn't mean they should just wander aimlessly until they stumble on the path forward. It works better when they have a hunch of where they should go next, and they're actively acting on a plan to check it out. To get that, they need to remember the locks they've encountered prior.

One way to make your locks memorable is to use landmarks. Noticeable custom graphics that are seen nowhere else in the game. In Super Metroid, you will quickly encounter this scary statue, but it's too high for you to reach it (normally). Yet, it makes a strong impression. So the moment you get the Hi-Jump ability, it's the first thing you have in mind and you can't wait to go back to it.

Placing collectibles

We have discussed player abilities extensively, but we didn't talk about collectibles yet. And for a genre based on exploration, they're pretty important!

To make exploration engaging, you will have to give players options. Multiple paths. And some of those paths are not going to lead forward. So it's really important that they still reward players for the time and effort committed. Collectibles are your main currency for that. And even if the two paths ultimately lead to the same place, you didn't spent time designing both of them for your players to only experience one. That would be a waste. Again, collectibles are a good way to encourage dedicated players to explore both options.

Tying your collectibles to your other abilities is a good idea, that way players feel like they're making progress toward some goal. The reward can be immediate, like the Energy Tanks in Metroid, or delayed, like the Piece of Hearts in Zelda, but in both cases you feel like you're making progress. You're not just increasing a meaningless counter, you're building yourself up.

If some of your collectibles are used as a currency to gain a new upgrade or ability, it may be good to offer intermediate rewards. Think of the Golden Skulltulas in Zelda Ocarina of Time. It's even better if those abilities are related: in The Lighkeeper, 5 alien eggs can be exchanged for the GPS upgrade that will annotate your map with the location of save points and warps you already visited. 10 alien eggs will net you the Sonar upgrade, which reveals the annotations for rooms you have never seen. The next level reward improves on the previous one.

When mapping the world, you may find yourself in need of a collectible to reward players without necessarily knowing which one it should be. I find it important to be able to leave those rewards blank for the time being, and focus on the exploration. Of course, I then need to have a tool to list every "empty chests", so to speak. A map with the placement of all items is also a good tool to have to gauge the spread of collectibles. Too many in one area and not enough in another is probably a pacing problem you need to fix.

Storytelling

Embrace the medium

Depending on who you ask, video games can either be a great storytelling medium or ill suited to it. How come? Like many arguments, I believe it all comes down to the definition of the words we use, in this case "story".

As I define it, "story" is a bit of an abstract concept, built from three components that are way more tangible:

• Characters

• Settings

• Plot

Characters and settings should be self-explanatory, but what is plot, exactly? It's the sequence of events (hopefully linked by causality) that makes up the story. A happens, thus B happens, but C happens and now D happens. That kind of stuff.

And I do believe video games have it rough in the plot department, compared to books or movies. Plot requires careful planning, which is often incompatible with player agency. Game designers have to relinquish some control to their players, acting as co-authors of the story, which does hamper their ability to plot intricately. It's especially true for action games, where the player is front and center. I think this is where the idea that "video games are bad at story" comes from.

But characters and settings? Still gold. Settings especially is given a chance to shine in video games, with the ability for players to explore it at their convenience.

Keep that balance in mind when creating a metroidvania. The medium and the genre in particular are ill suited to deliver a plot full of twists and turns, but it works perfectly for a lore-rich exploration of a place and its inhabitants.

That doesn't mean you can't have any twists and turns. But it's probably best to keep them limited to a few, as you will have precious little time to set them up properly.

One trick to set this up is to start the game with a plot well underway, just in time for the player to write its conclusion. Metroid, Castlevania and Dark Souls are all examples of this: you arrive in a new place, uncover whatever happened in your absence, and then promptly resolve the conflict. (Often with a few different possible endings, ranging from equally valid propositions in Dark Souls to "that was a fake-out, you missed half the game" in Castlevania.)

Protagonist vs Main character

In traditional storytelling media, the protagonist and main character are often the same person. They don't have to be.

A good way to differentiate the two is to say the protagonist is the agent of change, while the main character is the one with the most stakes in the story.

Western stories often give both roles to the lead character. But if you watched any shounen anime, you will be familiar with the trope where the shallow hero is the protagonist acting on behalf of a deeper main character that changes for every arc. One Piece loves this: protagonist Luffy reaches a new island, meets a nice person in trouble, help them with all their problems and leave.

Turns out, it's a good way to do things for games where the protagonist may not be well defined. While recent Metroid games try to give her some personality (to varying degree of success), Samus is mostly a silent exterminator. The whole point of the Knight in Hollow Knight is that they're an empty husk. Dark Souls characters are pure player avatars. You can't do much with those blank slates, but you have free rein when it comes to NPCs.

Again, keep that in mind when coming up with your story.

Environmental storytelling

"A picture is worth a thousand words", as we say, and environmental storytelling is similar, except the picture is the world you can explore.

To be effective, environmental storytelling requires the player participation. It's a puzzle, one that requires to pause and engage with the background in a more involved way than just locate the next platform to jump on. Done well, it's a good way to make your environments memorable, and to cram more optional lore.

Thinking about the world logic back when we worked on designing the world is a good first step to implement environmental storytelling. Your rooms make logical sense, beyond a mere sequence of challenges. You already got a sense of place. But we can do more.

Let's study an example. In The Lightkeeper, you eventually stumble upon a spaceship abandoned under the lake. Its very presence tells a story, but eventually you find yourself in this room:

It does a few things:

• It draws your attention. The panels in the background are unique tiles, and considering that the environments are usually quite minimalist, you get the sense there's something important about it.

• It identifies itself clearly. By virtue of being part of the background and offering no button prompt, you know you're not meant to engage with it directly. You understand it's a mental puzzle, not a mechanical one.

• It gives you context. One of the shapes is instantly recognizable as the last boss you defeated to get there. The others are similarly shaped, so you get a sense they're bosses as well.

• It foreshadows what's to come. The shapes you don't recognize act as a promise: you will fight those bosses at some point. And if you remember that you're in a prison ship, you understand the meaning behind the green light: this boss is still contained within the ship and waiting for you at the end of this biome.

• It challenges what you thought you knew. And yet, one of those shapes does not fit the pattern. It's small and looks like an NPC you've encountered at the beginning of the game. So you can't help but wonder why this friendly face is lumped with fearsome monsters. It triggers your imagination.

This is just one example, but having those ingredients is a good foundation for an environmental storytelling scénette.

Item Descriptions

Not all metroidvanias have item descriptions beyond a single line telling you what it does in gameplay terms. That's fine. Lore-filled item descriptions are more of a "Soulsborne" tradition anyway. But still, those two sub-genres of the "action adventure" family have a lot in common and what works in one can often be brought to the other.

Both The Lightkeeper and The Trespasser tell their story partly through item descriptions, and the way I approach it is by making each description its own short story. Or rather micro-story, like those Twitter accounts who try to tell a story in one tweet.

If you went through the steps outlined before, each item should already have a place in the world that can be used as a springboard for ideas. Let's take the Spider-form ability in The Trespasser as an example: it is found in a mansion filled with fanatics who long to become spiders themselves. Naturally, the short-story for this powerup will be all about them, what they tried to reach their goal and how they failed. And then, as is natural for most short-stories, I end it on a twist by telling you that where they failed, you succeeded. Which naturally flows into the second part of the item description: what it does in gameplay terms.

I try to keep both the short-story and the gameplay-oriented TL;DR parts on different paragraphs because while I hope players will be sufficiently interested in the lore to read the story, some will want to skip it to get to the gameplay part. Again, it's fine.

One of the powers of item descriptions is how multiple items can mention the same entities, giving you a sense of them without having to actually feature them in-game. Dark Souls is a great example of this: many of its prominent characters are just not in the game beyond item descriptions.

Live Updates

They say that no piece of art is ever finished, only abandoned, and it's true for games. When making yours, it's very important to know which tasks and elements are mandatory, important or simply nice to have: you need to know at any point if your game is ready to be "abandoned" or not. I believe that every hobby project is a race against the loss of motivation, so you need to be ready to push the "release" button when this time comes.

But then what happens to all the neat ideas you left on the table? Could you add them back later?

As mentioned before, metroidvanias are "media" games intended to give you a complete experience while you're playing. They're not rogue-likes you can forever extend: once a player reached the end, they're done. So how does that work?

Both The Lightkeeper and The Trespasser received significant updates after completion. The way I did it is that I only added optional stuff. I didn't want a player updating in the middle of their playthrough to discover they were stuck because I introduced a new mandatory ability they "missed" and couldn't go back to.

But I didn't want the additional content to feel tacked on at the end either. I want new players to believe it was all built at the same time, all part of a larger whole. How to do that retroactively? I believe the key is to draw connections.

One way to do that is to introduce abilities that feel required in the base game. For example, in The Trespasser base game, you get bombs to blow up the rocks standing in your way. Sometimes those rocks are in small crevices and you're supposed to find the right angle to throw the bomb into it. But if you visit the Ice Caves zone added in the extension, you can get the ability to place bombs while you're in spider-form (the equivalent of the morphball). It makes those puzzles considerably easier, to the point players feel like it's the intended solution. Suddenly half a dozen pre-existing "locks" get connected to this "key" that was added way later. And because the initial solution is still around, players are rewarded for experimenting and finding it before getting the new ability, making them feel a bit like a speedrunner discovering a "skip".

Obviously, you can also add new "locks" in the base game for the "keys" found in the extensions. There's probably plenty of room left to append stuff, but once again, I believe it's better for them to be optional.

Connections between the extensions and base-game don't have to all be mechanical "keys/locks". One obvious candidate is the story. When I approach a new extension, I try to make it about one or more elements of the lore that may have been underserved in the base game. For example, The Trespasser repeatedly mentions a mysterious man who kickstarted your journey off-screen by tricking you into coming to this strange place. Why? What's his deal? When I started working on the Ice Caves extension, I decided it would be his home, so you could learn more about him and maybe even meet him.

For players discovering the game post-extension, it all feels like part of the same game, and only the fact none of it is part of the critical path may hint that it was added later.

Conclusion

There you have it, everything I know about making metroidvanias! It's all based on my own experience, so hopefully it can jump-start your own journey.

If you were hoping for a more technically-inclined writeup, I do have a postmortem for Aereven: Lunar Wake, a 2D Zelda-like built with the same engine as the The Trespasser: Postmortem, part 1: the Engine.

If there's any other topic you're wondering about, feel free to reach me, I may be able to expand on it. A good way to do it is to join Dreamnoid's Discord server, but you can also find my contact at the bottom of the page.

Good luck on your gamedev adventures!