When planning out the level, we want to make sure that the player experiences a sense of progression. That is to say, the challenges they face should start out simple to ease them into the game and then become progressively more difficult. There should be some fluctuation, of course - without moments of low tension as well as high tension, the pacing won’t be satisfying. But overall, the player should start off dealing with relatively simple problems and steadily progress to tougher ones.

In addition, the game should present new elements, abilities, and obstacles to the player one at a time so they have sufficient opportunity to learn each one in isolation before having to handle all of them at once. And even when they are handling multiple things at the same time, dealing with a pair of familiar concepts should come before having to manage a group of three or more simultaneously. Even though the player doesn’t unlock any new abilities in the traditional sense in this game, this principle is still important in establishing an effective learning curve for the player without having to resort to cumbersome tutorials.

To map this all out when designing the room layout of the level, we’ll need to assign each room one of several color-coded categories, which will appear in roughly this order:

1. Basic Jumping: Rooms with no enemies that require simple jumps in order to proceed, but otherwise have no challenge. These are just to make sure the player is comfortable with jumping, or possibly as a breather towards the latter half of the level.

2. Basic Archer: Rooms with one or two Skeleton Archers, and not in a place where more than one can hit the player at a time. These get the player used to how enemies and enemy projectiles work without making them very difficult to avoid.

3. Charger: Rooms with a Skeleton Charger or two, but not right next to each other. These familiarize the player with this enemy’s aggression while there’s only one to deal with.

4. Advanced Jumping: Rooms with no enemies, but tricky platforming. These prepare the player for having to make difficult jumps before having to do so with enemies present.

5. Archer/Charger Combo: Rooms with both Skeleton Archers and Chargers. These introduce the player to dealing with multiple types of enemies at once, especially Archers placed behind other units.

6. Floating Skulls: Rooms with Floating Skulls, but no other enemies. Should be large and contain some tricky jumps. These prepare the player for avoiding enemy patterns while platforming.

7. Advanced Archer: Rooms with several Skeleton Archers, ideally positioned to catch the player off guard and keep them constantly dodging arrows. These prepare the player for dealing with large amounts of attacks at once.

8. Solo Knight: Rooms with Skeleton Knight. These teach the player how to defeat Knights in isolation.

9. Boneyard: Rooms with multiple Skeleton Archers, Skeleton Chargers, and Floating Skulls. These challenge the player to deal with large quantities of mixed enemies.

10. Knight Formation: Rooms with a Skeleton Knight backed up by Skeleton Archers. These prepare the player for fighting off a single tough opponent while also dodging unavoidable enemy fire, or perhaps skipping ahead to take out the Archers first.

11. Gauntlet: Rooms with multiple Skeleton Archers, Skeleton Chargers, Skeleton Knights, and Floating Skulls. These challenge the player to incorporate everything they’ve learned so far. There should probably only be one of these, right before the

12. Boss: Room containing Osmeus, Dastardly Lich. The player’s final challenge.

In addition to these learning curve rooms, there are two other types of rooms (also color-coded) which server other functions:

• Powerup: Rooms containing an Elixir of Fortitude, which increases max HP. These should generally be hidden, hard to reach, or otherwise off the beaten path, in order to reward the player’s curiosity and exploration.

• Save Point: Rooms that let the player heal, record their progress, and take a break from being attacked. We’ll talk more about them later.

These give us a rough idea not only of what the challenges in the level will consist of, but in what order the player will have to confront them. With these building blocks in place, we can start mapping out our critical path using each of these categories. Once that’s done we can then add branching sidepaths which contain hidden powerups.

So now that we’ve figured out the building blocks of the gameplay, it’s time to bring it all together and start planning from a top-down perspective. That includes not only a big picture view of the game experience, but also an eye towards the fluffier side of game design: what it’s about narratively, and what it’s going to look like. It will also answer the question, “Why are all the enemies skeletons?” Thrilling stuff.

To decide these things, I looked through what I’d done so far and realized there was a bit of a conundrum caused due to the player having both a ranged attack and a melee attack: in most cases, the melee attack had to be more powerful. This ordinarily could be resolved with a little creativity, such as by saying “the main character can just throw rocks or something - that’ll handle it,” but I had a particular aesthetic I wanted to make happen in this game. Specifically, I wanted the main character to wield a blade in one hand and a gun in the other. This is a bit idiosyncratic, but what’s art without some interesting restraints?

Which leads to the problem: generally speaking, bullets cause more damage than knives, or even swords. If I wanted to make this work and not have it be completely silly (which is an option but not really what I’m going for this time), I’d need some sort of enemy which is actually more susceptible to melee attacks than being shot at. Whereupon I realized that undead, being able to easily shrug off internal organ damage, were the perfect way to go. And skeletons are even better, as compared to zombies they’re not particularly vulnerable to headshots, but you can easily image one collapsing into a pile of loose bones when given a good thwack.

Thus was born the idea that this game would be about an undead hunter wading through hordes of skeletons and wielding only a revolver and a cutlass (because she took it from a pirate once). I already had a concept for a monster hunter-y main character from a JRPG idea I was brainstorming a while back, so I decided to run with that: Anna Ramirez, undead Slayer, in a somewhat Castlevania-inspired fashion. After which I decided, what the heck, let’s just call it Slay. I’m not changing the name of the series now, though - that would just be confusing.

There’s plenty to work with here in future installments, including silver bullets, vampires, necromancers, etc. For now, this series will continue to document my design work on Slay Part I, which will constitute our dauntless hero exploring a single skeleton-filled cave network, collecting health upgrades, and eventually defeating the complex’s boss: a fearsome lich! Next time, we’ll start fleshing out the level itself.

If you’re wondering why this wasn’t posted on Saturday, that’s because I decided retroactively that these “daily” posts would be more manageable if they were only on weekdays. I’ll see about upgrading to every day once I’ve got the regular update schedule thing down.

Today’s topic is enemies. This is an area where it can be easy to go overboard with large amounts of content. To maximize the economy of development, we want to aim for only a small number of enemies that each provide a distinct, interesting challenge to the player, ideally ones that don’t require a large amount of unique graphics for each one. This small list of enemies can then be combined in different groups, layouts, etc. for specific enemy placements to mix up the moment-to-moment gameplay.

To get the most bang for our bang, we need to identify the core function for each enemy type, of which there should probably be 3-5 in total. There might end up being a couple attributes jammed together onto a single enemy, but this isn’t a huge problem as long as each one is distinct. Properties I’m interested in include:

• Stationary ranged attackers. These should fire in a predictable pattern or reliably shoot whenever passes in front of them. In isolation this predictability will make them relatively easy to avoid, but in combination with other hazards the player may have to think about their approach.

• Mobile but non-aggressive enemies. These should move in a predictable way but not respond to the player, so they’re just kind of in the way. Something like the Medusa Head from Castlevania, which spawns randomly and just moves lazily across the screen, would be ideal. Since this is technically more of a projectile than an enemy, they should go down in one hit no matter what.

• Mobile melee skirmishers. These should approach the player when they get close, either in a slow and inevitable fashion or quickly but with a slight delay before attacking. In either case, being able to knock enemies back with melee attacks is important for these guys. Probably one or two melee hits should be sufficient to finish them off.

• Large, beefy monsters. Another classic Castlevania-type enemy, a slow-moving (or stationary) but powerful behemoth. If possible these should be large so the player has to deal with them to pass through. They should attack every once in a while (with a tell to let the player know it’s time to back off), leaving small windows of time for the player to strike back. Even more than other enemy types, they need to be resistant to ranged attacks so the player feels somewhat threatened (although if the enemy has its own ranged attack that fixes the problem - a floor-hugging projectile would be good).

This list already provides plenty of interesting archetypes to work with. The one wrinkle so far is that with the setup we have, ranged attacks will probably have to be relatively weaker than melee attacks in order for melee attacks to be viable. We’ll be looking at ways to possibly counteract that in future. For now, though, here’s a tentative list of enemies for our game:

1. Skeleton Archer. Fires arrows horizontally as long as it has line of sight of the player (in either direction). Takes two melee attacks or three ranged attacks to defeat.

2. Floating Skull. Floats across the screen from right-to-left (or left-to-right) in an undulating pattern, doing damage and disappearing on contact with the player. Generally spawns randomly in groups when it appears. Takes one hit from any weapon to defeat.

3. Bouncing Skull. Like the Floating Skull, but bounces along the ground and has faster horizontal movement.

4. Skeleton Charger. Swiftly runs toward player when they come into view, slashing at them once in range. Takes two melee attacks or four ranged attacks to defeat.

5. Skeleton Knight. Wields a shield to block attacks and a sword to attack, but does not pursue the player. Immune to attacks from the front while blocking, but leaves itself vulnerable when preparing to attack, and will turn to face the player if its back is exposed. Ranged attacks when it’s blocking break its guard temporarily. Takes four melee attacks or six ranged attacks to defeat.

That should give us plenty of options to work with. Why are they all skeletons, you ask? Find out next time, as we dive into the aesthetic/narrative concept for this game!

Continuing from yesterday’s minimalist Metroidvania, we’re going to dive into the meat and potatoes of the core gameplay: the combat! Since we want to keep the scope small, there needs to be just enough variation to keep things interesting, and no more than that. First we’ll start with the player’s weapons.

Similar to Gather, one of my design goals here is to give the player both a ranged and a melee attack so that they have some short-term tactical options. To properly incentivize switching, though, I’d like to make a couple changes:

1. Melee attack is a vertical slash instead of a horizontal strike. This makes it much easier to hit enemies, especially multiple enemies at once, which is sort of the point of melee combat.

2. Melee attack should push (small) enemies back on hit. This gives the player just enough crowd control to manage mobile enemies that like to get up in their face, which would otherwise be frustrating to fight in close range. Bosses are generally excluded, naturally.

3. Ranged attack should be possible in at least 4 directions. If an enemy is above or below you, there’s no reason you shouldn’t be able to shoot it provided you have sufficient aim. Support for diagonal shots would be ideal, but probably outside scope for the first iteration.

4. Crouching should be possible to hit low targets. I think that’s pretty self-explanatory.

5. Ranged attack should never permanently run out of ammo. This was one of the annoying things about Gather, conserving the very limited ammunition that was available on top of having to reload every 6 shots. Special, empowered shots might have finite ammo, but for the basic ranged attack, the only limit to its reliability in this game should be having to spend a moment to reload every so often.

This adds some programming complexity, but should make the experience much more responsive and engaging for the player, especially with the addition of vertical shots (a feature sorely lacking from Gather). Tomorrow we’ll discuss enemies, which present a similar design challenge.

For all 2 of you that are reading this and wondering what “Daily Game Design” is, let me briefly explain. Basically, I feel like I’ve had less motivation for game development lately, and a not-insignificant cause of this issue is that I haven’t been thinking about ideas for games in my spare time.

To help get back into this habit and make it more reliable and consistent, I’d like to start writing short posts on game design everyday to get those creative juices flowing. They won’t be very long and they probably won’t be particularly great, but they should at least be interesting. Plus, it’ll finally get some regular content up on this sorry excuse for a blog. Anyway, let’s dive into it.

Today’s Topic: Minimalist Metroidvania Gameplay

The Metroidvania genre generally consists of games with large, sprawling world that are packed to the gills with different areas, enemies, bosses, upgrades, and secrets. For a novice developer, though, this scale is a bit daunting, and definitely somewhat over-ambitious. To come up with a way to make this sort of game feasible as a basic hobby project, I’m going to try to identify the key elements of the design and then strip them down to pure essentials. If relevant, I’ll also be listing design choices where tradeoffs need to be made to keep the scope low.

Key Elements of the Metroidvania Genre

• Side-scrolling: This is somewhat nitpicky but I think needs to be stated outright. Running and jumping make up the bulk of the most of these games, and are a large component of what makes them fun. There are similar types of games that use a different perspective, but for my purposes I’d like to focus on platformers.

• Focus on Combat: A lot of side-scrollers place a lot of emphasis on accurately-timed jumps and precise platforming across bottomless pits, but Metroidvanias generally focus on dangers that the player can fight off. Some environmental hazards (e.g. spikes, lava, etc.) may be present, but in general falling off a ledge does not lead to instant death. This reduces the player’s concern of messing up a jump, allowing them to concentrate on maneuvering around enemies and managing resources.

• Exploration: The player should be rewarded for going off the beaten path and investing time to find hidden things. This is probably the most critical part of the experience: even if there are a bunch of upgrades available, if they’re all mandatory and acquired in a totally linear fashion, player freedom isn’t entering into the equation.

• Item-based Progression: Whether through big upgrades like new abilities and weapons or small power-ups like boosts to max HP/ammo capacity, there are things players can find in the field to permanently improve their capabilities. For a small game, we’ll have to rely primarily on the latter.

• Non-linear Progression: The player should have several options for locations to visit, at least by the mid-way point of the game. Even if most players stick to the critical path, they should have the freedom to venture off it if they so desire. This requires several different areas to properly accomplish, though, so it’s not as feasible for a small game without cutting back on other features.

• Bosses: At the end of most areas, there is a single challenging enemy that cannot be avoided (generally speaking) and the player must defeat. Boss monsters aren’t restricted to Metroidvanias, but they’re definitely a staple of the genre. For a small game, there’s probably not room for more than one boss, but that only makes it an extra opportunity to be a greater, more exciting challenge than the regular enemies.

This gives us a rough list of what’s needed to make a Metroidvania-style game. In particular, for a small scope it looks like the best approach is to create a combat-focused platformer that has a single area with a boss at the end. The level will be mostly linear by necessity, but there will be several “pockets” at various points branching off from the main path that contain hidden upgrades (max HP boosts, max ammo/resource boosts, maybe even damage or defense buffs).

This will be simple enough to be manageable with a small scope, but still meaty enough to be a satisfying and challenging experience for the player. There are other ways I could have broken this down, such as stripping down the combat mechanics and/or boss to focus on a maze with non-linear exploration and lock-and-key upgrade advancement (c.f. Knytt Stories or You Have to Win the Game), but for this project I want to try my hand at an action-platformer. Tomorrow I’ll start hashing out the details for how this particular game will work.