Talking about Inspiration and Stuff

I've been working on this game for about 9 months now, and this is the first I've put anything about it online. Sure, I've let friends people playtest it in-person, but as far as the internet is concerned, it might as well not have existed up until now. So I just want to play a bit of catch-up and talk about the inspirations behind this project, some of the tech I've built for it, and how it's going so far.

For my elevator pitch, I often tell people it's a Metroidvania loosely inspired by Avatar. Sometimes I also throw in the word "roguelite." Usually it's the phrase "very light roguelite." When they hear that, most people ask, "Avatar as in The Last Airbender? Or the blue aliens?" I usually respond, "The good one." Everyone I have talked to has known then that I was referring to The Last Airbender. But that's all a horrible way of describing my game.

An Aside on How Much I Dislake the Term 'Metroidvania'

First I want to take a brief aside on how bad a genre name Metroidvania is. That means absolutely nothing to someone who doesn't play a lot of games, and it doesn't mean much to even a lot of gamers. Mention a platformer to most people, even non-gamers, they'll know what that is. Even if they don't, tell them "like Mario," and then they'll know. When someone inevitably doesn't know what a Metroidvania is, you could tell them "like Metroid," and that doesn't really get you anywhere else. They're more likely to ask "Then where does the '-vania' part come from?" And that's a good question. It comes from Castlevania, but why? Castlevania didn't invent the genre. Metroid did. Castlevania switched over to the genre after Metroid pioneered it. The first few Castlevania games were not in that genre. They were linear and level-based.

Castlevania merely adopted exploration and empowering items. Metroid was born with it. Molded by it. Metroid didn't see linearity until Other M on the Wii.

First-person shooters were called Doomlikes at first, because Doom was the first popular example of the genre. Eventually as the genre became mature and mainstream, it got a more descriptive name: First-person shooter. That does a much better job describing the key features of the genre: you have a first-person camera, and you shoot things. Doomlike means nothing to someone who isn't familiar with Doom.

But Metroidvania is even worse than Doomlike. It's kind of like if we had instead called them Doom Nukem's. Duke Nukem was a series that also jumped on the first-person shooter bandwagon soon after Doom, and helped popularize the genre. But the first few Duke Nukem games were 2D sidescrolling shooters. They moved to 3D and a first-person camera after Doom pioneered it. Just like how Castlevania moved to open exploration and empowering items after Metroid pioneered the genre. The genre name Metroidvania gives too much credit to Castlevania, just like a silly genre name like Doom Nukem would have given too much credit to Duke Nukem.

So Metroidlike would be better than Metroidvania. Of course, it still means nothing if you aren't familiar with Metroid. I've heard the term "Search Action Game" recently, and while that's a mouthful, it is more descriptive. I prefer the word "exploration" over "search" personally. Maybe that's just because of my software engineering background. When I hear "search," I think search algorithms. I think, "what kind of search are we doing? Is it a graph? Can we do A-Star? Depth-first? Don't tell me we have to do breadth-first." But when I hear "exploration," I think Breath of the Wild or Hollow Knight. Or, like, going outside, I guess. I've also heard "mapformer," a portmanteau of "map" and "platformer," which is pretty good, though that still may go over a lot of people's heads. So I would prefer to call this genre either "Action Exploration Game," "Platforming Exploration Game," or "Mapformer." but for now I'll settle for Metroidlike, since that's something most developers and gamers will recognize right now, even though non-gamers definitely won't know what it is.

I will not settle for Metroidvania.

Doom Inspiration

When I tell people my game is a Metroidlike Roguelite inspired by Avatar, I'm not even mentioning one of the biggest inspirations: Doom 2016. I first started wanting to make some of this tech when I saw this GDC talk from a combat designer and engineer pair at id: 

• Enemy AI is limited on how many enemies can be attacking at once, to avoid overwhelming the player. They implemented this with a token pool. If you've done any server-side engineering, you've likely handling throttling with a similar mechanism. And if you've done server-side engineering without throttling, keep that a secret or someone will definitely DDoS you. The idea is, an enemy has to acquire a token from the token pool before they can start an attack. Then they return the token to the pool once they either finish attacking, or are interrupted.
  • This approach also gave them an easy way of adjusting difficulty. On higher difficulties, they can make enemies more aggressive by increasing the total number of tokens in the pool, allowing more enemies to attack at once.
  • They also gave nearby, on-screen enemies priority in attacking. If an off-screen enemy is winding up for an attack, but there is an enemy on-screen right in front of you and the token pool is empty, that on-screen enemy can steal a token from the off-screen enemy. That will allow the enemy you can see to attack you, which makes it more something you can react to. And the off-screen enemy will be forced to cancel their attack, but you probably won't notice because they're off screen
• Enemies are less accurate the faster you are moving. The designers really did want you to always be moving. None of this Mass Effect 2-style hiding behind cover all day while enemies make no attempt to flank you. Always stay in motion, because being active is more fun than being passive. They actually defined statistical distributions for how much an enemy's aim should be off by depending on how fast you're moving. If you're still, it's a normal curve with low standard deviation, centered on you. If you're moving full speed, the mean of the normal curve is about 3 meters off.
• They had several different levels of hit reaction animations in the enemies, ranging from the most common but least impactful, to the least common but most impactful. The three I remember specifically are the ones I use in my game.
  • Twitch is the most common, least impactful hit reaction. It happens from any little hit against the enemy, and happens in an additive layer on top of the enemy's regular animation. It doesn't interrupt their actions, but it can throw off their aim.
  • Falter is a medium hit reaction. I happens from significant hits against the enemy, and interrupts their action with a new stagger animation.
  • Stun is the rarest, most impactful hit reaction. It's the one where the enemy stands still, dazed, and you can go in for a glory kill.

So I basically stole these techniques for the combat in my game. Steal from the best, you know? I have implemented the token pool, but I have not implemented priority, and allowing enemies with high priority attacks to steal tokens from lower priority enemies. It's also a little different in my game, since it's 2D and all of the enemies in a given encounter will be on-screen for as long as they're alive. So I may not implement that part. I also have not implemented enemies being less accurate based on your movement speed yet. That also changes some with the change to 2D. There's one less axis to dodge enemy attacks on, and one less axis for them to be inaccurate on. So it's actually harder for them to miss, even if their aim is off.

And I have partially implemented the different levels of hit reactions. The trouble here is that I'm using an asset pack for my enemies and all their animations. Beggars can't be choosers. The asset packs come with stagger animations that make a good falter. But they don't come with a twitch or a stun. For stun, I might be able to just kind of loop and adjust the speed and timing of the stagger animation. And for twitch, I might be able to just apply the stagger animation as an additive layer with low weight. But I haven't tried either of those things yet, because I've got the whole rest of the game to build. I only recently put in any assets for the enemies at all!

On stun, though, I do disable enemy action, give them that highlight you know and love from the recent Doom games, and let you glory kill them.

The glory kill is the more obvious thing that I didn't even need a GDC talk to copy. It's great design. While Call of Duty or Mass Effect 2, the worst game in the Mass Effect trilogy, make you wait in timeout behind cover to heal after taking damage, Doom pushes you to be even more aggressive. You have to stun an enemy, get into melee range, and deliver a beautifully animated finishing blow, and because you finished them with that finishing blow, they will drop tons of health pickups to heal you. An early inspiration for this was thinking of that as a healing mechanism in the context of a Metroidlike game.

For healing systems, I am a proponent of the adage "If it's not broken, don't fix it." And I think Dark Souls kind of solved it for a large portion of games. Unless you have good reason to do otherwise, just use an Estus flask-type system. You get X number of healing potions, they will heal you most of the way to full health if not all the way, and they recharge at each checkpoint. So each run between checkpoints, you get that many mistakes.

I liked Death's Door, but I think it would have been much better served by just using Estus flasks. The system they had instead made you find seeds in the levels, then find pots to plant them in, and then you could interact with the flower that grew once per run between checkpoints. So the system they had basically became Estus flasks, except healing was tied to specific locations in each level. Which just forced empty backtracking.

Doom, on the other hand, doesn't have checkpoints, so you need something to sustain play without having dedicated places to rest and recharge. Having enemies drop health pickups, as well as putting health pickups in the occasional crates and such, was a natural solution. Making those health drops from enemies conditional on getting up close and personal with those enemies, is the real great innovation here.

Every mechanic in a game should be examined to ensure it encourages and rewards the behavior you want in the player. In the very good and sadly obscure 2020 Metroid-and/or-Souls-like game Grime, the devs wanted you to parry a lot. So they tied healing to your parry. You have to parry enemy attacks to fill up a meter, and only once it is full can you heal. In probably the best Metroid-and/or-Souls-like game of all time, Hollow Knight, they just made you get in attacks on enemies to fill your meter that will fuel your heals. The takeaway is still clear: The solution is not shying away from combat. Only by continuing to fight can you actually be able to heal again.

Metroid went with the natural solution of just making enemies drop health pickups. That led to the degenerate gamer strategy of standing in front of a spawner and waiting for tiny bugs to fly out, shooting them one at a time and picking up a small amount of health from each one, simply because they were low risk. What would have happened if you made the health drop conditional, like in doom? The newer Metroid games have a parry and counter system, which is higher risk and higher reward than just shooting a helpless little bug just as it exits the spawner. I’m not sure if that actually increases the health or ammo pickup rewards, but it would incentivize higher risk, more interesting play if it did. I’m at my computer and could easily look up whether it increases health or ammo pickup drops, but I’m not going to. I’m just gonna let that be a hypothetical.

So that was one branch of the inspiration behind this game: I like Metroidlike, and I wanted to make one with juicy, viscerally satisfying combat that encourages going in for melee finishers like the recent Doom games. So how does that square with Avatar: The Last Airbender, where the title character is notably pacifist?

Avatar Inspiration

This is the inspiration I’m more forward about in casual conversation, even though it’s ultimately less apparent on the moment to moment gameplay. The idea came to me when I was watching Avatar for the first time in the year of our lord 2022, at the age of 27. They were establishing the rules of reincarnation for the avatar, and the Avatar State™. If you’re unaware, the avatar is reincarnated through time to a different elemental clan in each life. The current avatar in the show, Aang, is an airbender. The Last Airbender, in fact. The previous avatar was a firebender. The one before that was an earthbender. The one before that was a waterbender. And the cycle repeats itself the further you go back.

The avatar state is kind of a rage mode that Aang can go into, where he connects with the power and knowledge of all the previous avatars. I do love a rage mode in video games. But there’s a risk to it. If he dies in the avatar state, he dies for good. The line will be severed, and the avatar will never again be reincarnated. I wanted to adapt that risk-reward model to a video game. Here’s a rage mode that is very powerful when used, but if you die while using it, you die in real life. Er, you get permadeath in the game.

Now obviously, it would be incredibly mean to do that in a long game, but that’s not a problem for me. I’m just one developer; I can’t make a game very long even if I wanted to. So I decided to lean into it and make it run-based.

I don’t like referring to this game as roguelite, because hearing a game described as roguelike or roguelite makes me not want to play it, because it communicates to me that there is no level design. Don’t @ me. So I wanted real, coherent level design, but I also wanted runs to feel different each time. So I took inspiration from the reincarnation aspect of Avatar.

There are four zones, one for each element. Your first run, you are a waterbender, starting in the water zone. Next run, you are an earthbender, starting in the earth zone. Next run, you are a firebender, starting in the fire zone. Next run, you are an airbender, starting in the air zone. And the cycle repeats itself. That makes each run different, because you have a different starting point, and will find different abilities first. Sure, your current run will be pretty similar to your run four attempts later, but that’s a sacrifice I’m happy with.

So I took the prototype I had started of a Doom-inspired Metroidlike, where each new gun is both a new weapon in combat and a new traversal tool, and retrofitted each gun into an elemental power. The shotgun became a fire blast (basically burning hands, if you’re into D&D), the laser became a fire laser, the mine launcher became the ability to earthbend a rock out of a surface and make it explode when enemies get near, and the grappling hook became a water tendril. On a waterbender run, you’re most likely to get the wall jump, grapple, and heal abilities first. I justified wall jump being a water ability by saying it works by freezing your hand to the wall. On an earthbender run, you’re most likely to get the down slam, rock mine, and rock guard abilities first. On a firebender run, you’re most likely to get the fire laser, fire shotgun, and long-range glory kill first. I like the long-range glory kill. It turns the melee combat finisher into a traversal tool by allowing you to turn into a great ball of fire and zip straight across a room to a stunned enemy to finish them off. And on an airbender run, you’re most likely to get the double jump, dash, and glide abilities first, and you won’t encounter any combat until you go on to a different area.

I haven’t implemented the avatar state yet, by the way (it’s one of the last mechanics I have left to implement), but this is a big part of why I decided to smoosh my Doom-inspired Metroidlike and my Avatar-inspired Metroidlike into the same game. A rage mode mechanic does suggest a focus on combat. So I decided to take more inspiration from how the avatar state works in the show. Aang usually can’t enter the state at will. It comes out when he or his loved ones are in mortal danger. So in this game, you’re only able to enter it when you’re low on HP, making it an inherently risky maneuver, since dying while in the state means losing all of your inter-run progress. The way I plan to implement it is by making your health steadily regenerate while in the state, and the state ends once you’re at full health. That makes it so that you’re incentivized to be super aggressive during the state, and accept taking damage, because that ultimately makes the state last longer. And that fits nicely with the Doom style and the glory kill mechanic encouraging you to get up into melee range to finish enemies off.

A unique thing about the rage mode in this game - it won’t just make your attacks stronger. It will give you access to all of the abilities from your previous runs. Because that’s how the avatar state works in the show. Aang is able to channel all of the knowledge and power of all of the past avatars while in that state. And that’s the progress you will lose if you die in the avatar state.

Randomizer Inspiration

I’m also a fan of item randomizer mods. I generally play through a Majora’s Mask randomizer once or twice a year. They’re great. For those not familiar, an item randomizer mod is a mod that takes a game you know and love, and shuffles all of the item locations while ensuring the game is still beatable. It won’t put any items in places where there weren’t items before; it will just put items into places where there were originally different items. And this has a fun effect on games that you’re already very familiar with. It’s the same game you know and love, except you’re experiencing it in a new order, remixed.

In Majora’s Mask, there’s normally a prescribed order in which you get progression-critical items: First the deku mask, then a bottle, then magic beans, then you learn the sonata of awakening, then you go to the first dungeon, get the bow, and fight the first boss. Then you can use the bow to access the next region, where you get the lens of truth, then the goron mask, then learn the goron lullaby, then you go to the second dungeon, get the fire arrows, and fight the second boss. And so on. But in a randomizer, I may get the bow and the goron mask before I get the deku mask, and so I end up going to the second region to see what I can get there before I ever visit the first. This doesn’t only result in experiencing the same things in a different order. It also results in experiencing the same things in a different way. You may come to an area missing items that you would normally have by that point, or with items that you normally wouldn’t have by that point. If you include keys in the randomization pool in Majora’s Mask, you may come to Snowhead Temple, the second dungeon, without any of the three keys that would normally be required to get through it. But if you come in with the zora mask, or the hookshot, or the fire arrow, which you would normally find halfway through the dungeon, there are alternative ways of getting through the dungeon that bypass the locked doors entirely. It’s a satisfying way to recontextualize the space. In order to get magic beans in the normal game, you have to go through a stealth section sneaking past deku guards. But if you already got the magic beans elsewhere, you might just skip that section entirely in the randomizer. Or, you might come to it with the stone mask, which you would normally get much later in the game, which makes you invisible to enemies and NPCs, obviating stealth.

I’m hoping to achieve that sort of effect by making you start in a different zone each run. You will probably have a much easier time with combat in the other zones if you already have burning hands and the fire laser from the fire zone. You will have a much easier time with navigation in the other zones if you have the wall jump from water or the double jump and dash from air. None of these powers are required outside the zone you find them in, but they are helpful. They may open up some alternate paths and shortcuts through the level, or unlock the path to some optional goodies.

I’m also planning on just adding a randomizer mode to the game. Normally, item randomization would be done by a mod after the fact, but why not just put it in the base game, when this appeal of changing sequencing is already so central to the appeal of the game? It will unlock after you beat the game normally for the first time.

I’m excited to do this because randomizers are also interesting to me from a technical standpoint. Shuffling items while ensuring that the game is still beatable is an interesting problem. It involves graphs, and you know I’m way into graph algorithms.

Tech Talk

If you’re not interested in tech, just skip this section. A graph is a collection of vertices, connected to each other by a collection of edges. There are lots of cool applications for graphs. The world’s road network is represented internally as a graph in Google Maps. Intersections and points of interest are vertices, and the streets connecting them are edges. One of the most common types of graph algorithms is pathfinding, i.e. if every edge has a certain cost to navigate, how do I find the cheapest path from one vertex to another? There are a few popular algorithms for computing that cheapest path, Dijkstra’s algorithm and A* being top of the list. I’m not going to go into those today, but you better believe I’ll talk more about A* in a future devlog. The category of graph algorithm broadly applicable to item randomizers is called a topological sort. This is when you have a directed, acyclic graph (a concept so common computer scientists abbreviate it as DAG), and you want to sort all of the vertices so that every vertex in the sorted list is before any other vertex that can be accessed from it by following one or more edges.

First, definitions:

• If a graph is directed, that means the edges are directional. A directed edge AB goes from vertex A, to vertex B, and not the other way around.
• If a graph is acyclic, that means there are no cycles. Once I follow an edge out of vertex A, there is no path back to vertex A. This is obviously only possible if the graph is directed.

Now, a diagram might help.

As we can see, you can move from A to either B or C, from B to either C or D, from C to D, and nowhere from D. This graph is acyclic, because there is no path back to any vertex once you’ve followed an edge out of it. And because it’s acyclic, there is guaranteed to be a valid topological sort of it. That sort is A, B, C, D. Sometimes, like in this case, there’s only one valid topological sort for a graph, and sometimes there’s more than one. If it weren’t for that edge from B to C, B and C could be in either order, so A, B, C, D and A, C, B, D would both be valid topological sorts.

Now let’s apply this to a video game. Let’s say A is the wall jump, B is the double jump, C is the dash, and D is the endgame. Then the edges would represent that the wall jump is required to reach the double jump and the dash, the double jump is required to reach the dash and the endgame, and the dash is also required to reach the endgame.

Put another way, reaching the endgame requires the double jump and the dash, reaching the dash requires the double jump and the wall jump, reaching the double jump requires the wall jump, and no special abilities are required to reach the wall jump.

This game is obviously finishable. You can get the wall jump, then the double jump, then the dash, then reach the endgame. And, wait a minute, that’s the topological sort of this graph!

So the challenge of a randomizer is to shuffle these items while ensuring that there is a valid topological sort of that item graph, i.e. ensuring that the graph is acyclic. If I shuffled the wall jump to where the dash is now, it would be unbeatable. I would need the double jump to reach the wall jump, but I would need the wall jump to reach the double jump. That graph would look like this:

Notice how we’ve got cycles. BAC is a cycle. AB is a cycle. There’s no valid topological sort because there’s no vertex that doesn’t require another vertex to reach it.

Now, applying this to a real video game and not this oversimplified version of it becomes more complex because of ORs. In this example, there are only ANDs. Reaching the dash requires the wall jump AND the double jump; reaching the endgame requires the double jump AND the dash. But in a real game, it might be the case that reaching the dash only requires the wall jump OR the double jump, but not both. So that adds some complexity to the problem. But whether a randomizer is beatable ultimately still comes down to: is the graph acyclic?

And that’s an exciting problem to me, because I’m a fucking nerd.

End tech talk.

Conclusion

So that’s the inspiration behind the game, and what I’m planning with the game. It’s a collection of neat tech that I wanted to implement, cool ideas from shows that I thought translated well to game mechanics, mechanics from other games that I just wanted to copy, and an interest in altering the sequencing of games. And it all fits together pretty well. Well, not yet, but it’s not unfixable. I just need to do some bug fixing on the enemy AI and implement the last of the mechanics. Thanks for reading this! I’m not sure how interesting this is to other people. But I am excited to write more. I might do one just on the enemy AI tech I’ve built for this game. I might do one on level design, one on the character controller, and so on. There’s a lot I want to talk about on this game, and I have a lot of catching up to do after not writing about it at all for the first nine months of development. So, if you stuck around to the end, hopefully I’ll see you next time! Until then!