A Stick is not Human

Video Games have built up a set of tropes and ideas over time that have arisen out of necessity and tradition. A lot of these ideas come out of older games, where it's hard to keep track of a lot of moving parts at once.

Occasionally I like to wander down to the bowels of the internet and see what it has in store. You can find items that are the stuff of legends on the dark web, or find yourself wondering why Elsa and Spiderman are singing the Family Finger Song. Me, I like to go to the dark place that hardly anyone would ever admit to: Japanese Hentai Games. I'm not looking to get my rocks off, it's the other side of hentai that I'm interested in. Yes, the absolutely depraved side.

This side of gaming is fascinating. There are games that take power fantasies and flip them on their head, subvert them in weird ways, or simply put the player on the receiving end of the plot. You can play as villains, side characters, legendary heroes, ordinary monsters, or even the table. Many of the traditions in gaming just don't seem to apply here... and the ones that do are the absolute foundational, cream of the crop tropes that make the game happen in the first place.

There's something to be said about the quality of these games. Almost universally, the games are either garbage heaps of bad design and fetish fuel, so specialized that the rest of the game languishes, or "If this wasn't a hentai then this would be the best game I've ever played?!". Mediocrity is not something that happens when these authors are either extremely passionate in their ideas or trying to sell to that crowd.

Why do I keep playing these games? In a word: humanity

Most video games with human characters don't really have humans in their games. If you can swap out the character with a ball and the game mechanics make just as much sense, then you're not really playing a human. That's a big reason why a lot of games in the 90's did fairly well with their animal mascots: Sonic the Hedgehog isn't a human, he's a blue fairy hedgehog thing that turns into a ball and runs like a madman. Who needs human flesh when you're made out of pure attitude?

I'm sure this is why survival games struck a chord within the gaming community as well. It's why Minecraft can justify having a 'survival' mode even though the only real survival aspect is that the main character needs is food. Getting hungry means you need something to keep going, right?

If I were to point at a game style that shows off this idea of 'humanity', then I would have to point at Dark Souls. Your character is squishy, running at a reasonably athletic pace, uses their own skills and abilities to move forward, and you as the player need to learn how the game is played before you move on. There's a special kind of harmony between the bone-crunching death of the character and your own resolve to improve yourself.

I'd like to play more games like this. Sort of. It's not the difficulty of the game that really speaks to me, it's the relatability of playing with a character that isn't just a toy. Humans have consequences for their actions. We make a lot of little We. They end up hurting ourselves or pushing their bodies too far. Even when we do that, our bodies take a couple of days to heal up and then we can do it all over again.

Some video games try to replicate that idea with the limited amount of tools they have. Have you fallen too far? Take a point of damage. Jump in lava? Well, you can move just like the air, but your life counter is going to go down rapidly. You exist in an RPG? Status effect! You now act at random. These games try to bring back some of the aspects of human biology that exist, but it's done in a way that has been oversimplified, extruded into a paste, and then smeared on the player.

Chip damage bothers me on so many levels. It's hard to justify a character blocking hit after hit, blow after blow, perfectly taking everything in the most robust stance, then suddenly exploding into meaty chunks because their health points went from 1 to 0. Likewise, the fall damage in Minecraft is infuriating. Why can I explode into an array of item drops just because I dropped from the sky a little too high? 

Sure, some games prevent you from dying due to this chip damage, but if the hero walks through acid I would expect them to have a real bad time walking instead of being able to jump up 50 feet onto the ceiling. This is part of why superheroes are such fun; superman can defy physics because he is superman.

"Well well well. If it isn't the consequences of my own actions."

 

A common argument against this idea is that "this isn't fun". That's true, but it's the wrong argument. Stealth sections in first person shooters aren't fun because the type of experience you're having is a bombastic jaunt through enemy lines as a one-man-army blasting through everything in your way. Likewise, any game that relies entirely on stealth will be a lot less satisfying if you can just barrel through every stage with brute force. These games have a particular focus, and when that focus deviates into a gameplay style that is not complementary to its vision, the entire game suffers.

Dark Souls is the perfect counterargument to this. We can describe it as "a different type of fun", but it's really the entire game having this brutal, punishing, and overbearing experience that grinds you down and chews you up until you finally get through the boss that was in your way and now YOU are the grindmaster. The entire aesthetic and gameplay experience leans into this idea so hard that, if you enjoy this kind of thing, you won't even notice that you're not 'supposed to' be having fun.

Let's do something a little different. I want an experience where the fundamental aspect of what and where a person is, is the thing that matters most. We can keep a lot of the basic mechanics that have been built up over decades of playtesting, and then layer a few new things on top of those. I don't want to punish the player with death... only with the consequences of their own actions.

Super Metroid is definitely shaping the idea here. At the beginning of the game you move around like a kind of odd floating tank. Leaving out all of the upgrades that you get, there are a lot of mechanics that make Samus not annoying, not irritating, not clunky, but some combination of these at a lot of small levels. The best players make everything look easy, when in fact the game is doing everything it possibly can at any given time to make the way Samus moves mediocre. Not hardcore, not crazypants, and not irritating. Just... kind of bad. It's hard to describe exactly, and should be even harder to replicate without copying the entire game.

On the flipside, The Legend of Zelda: Breath of the Wild is the best example of bringing humanity into an existing world. Open-world exploration, crafting, weapon durability, and a defined goal come together to make something that feels both like something that's been done so many times and still shines in its absolute quality of an experience. Despite being a Hylian from another world, that incarnation of link is one of the most human characters in all of gaming.

A man's gotta eat, after all.

Metroidvania and Randomization: Forgetting the Moment

What comes to mind when you hear the term "Metroidvania"? Is it a connected world full of secrets and treasure? Is it a bounty hunter exploring a deep dungeon, jumping on platforms and shooting everything in the way? What about an rpg-esque level up system and a series of equipment that gets stronger as you progress? Deep lore that provides ultimate immersion?

What if I told you that the core of a metroidvania isn't any of that? It's actually just the map, with upgrades-as-keys needed to unlock areas. Take a look: https://www.kongregate.com/games/lozzajp/maptroid

Maptroid is a wonderful proof of concept. There are various lore bits scattered around the world to fill in the gaps, but the emphasis is on upgrades. You need a shovel to break through weak floors and a hammer to break weak walls. Cold areas need warm clothes. The map itself supports this; the first upgrade unlocks areas that you had seen before, but couldn't access due to the lack of a grappling hook.

Maptroid strips away all of the fancy graphics, world building, and platforming you would find in other, the game can be simplified to a basic story: Go left, find a key. Use it to move downward, find a second key. Repeat until you find all the keys and finish the game.

Creating a map in a more complex environment is a challenge. The world needs to have a cohesive idea. Traps, puzzles, roadblocks, and keys need to be scattered all over the places. Dead ends with precious loot entice the player into exploring every nook and cranny. Various parts of the map are intended to be replayed in the first run, let alone any replays that happen. All games need to start somewhere, so let's draw up a basic design for a procedural map that does one thing.

The Backtracking T

We start in the center. Basic controls are movement; we can go left and right. A door blocks our way to the right, and we can't jump, so we go to the left and grab a key. The key unlocks the door, so we go to the right and grab the next item. Now we can jump, so we go to the top of the map and touch the flag. You win!

This certainly works as a proof of concept. It has all of the core elements of a metroidvania: exploration, lock-and-key progression, and a connected world. The map was procedurally generated with an algorithm that can only follow one procedure with some slight variation, so you don't have to worry too much about testing branching paths, the map looping back in on itself, or odd ideas like the map changing as you progress through the run.

Let's assume that the basic mechanics are rock solid. At any given second the player has full control over the player. Platforming is fun, enemies are engaging, and everything on the screen does exactly what you want it to. At this very second, the game is great. A lot of games get built from the smallest details and expand over time.

Let's also assume that a game designer comes along and sees this well-working game and decides to layer on some of the more interesting things, like story and themeing. The generator gets split up into different zones. A Robot Named Fight separates its map out into a new city, a cave, a robot factory, an old city, and then expects you to travel these in reverse after you're done. This means we get to build from both ends of ground-up and top-down.

On the surface, there's nothing missing from this plan. The player's story should sound something like "The megabeast is closing in, you must defeat it! You start in a city, defeat a boss, grab a random upgrade, and progress into a cave where you do it all again. Find the cave's boss, grab the abandoned city's ultimate power, and return to the surface to defeat the megabeast."

Unfortunately, most procedurally generated games I've seen stick to this formula. The best ones focus on the "overall experience", while many of them focus on the interesting parts on the edge. They work on the smallest details like combat or upgrade variety or challenge. They might instead focus on the overall story, like a cult kidnapping villagers and the hero rescues the town, then takes on the elder god X'Tua Ulak. With all the effort and all the compromise to get both large and small working it should work out, right? Right?!

Desperation kicks in at some point when the developer realizes the entire process they thought would magically come together doesn't materialize. A lot of people will see the big and the small working just fine and assume they come together for a great experience. The novelty and the uniqueness of each experience will surely cover up any blemishes on the project. That is a trap that leads developers to layer on more and more ideas, or tweak and compromise on some of the core premises until the entire project is simultaneously hollow and bloated. 

Magic in the middle

 

What part is actually missing from the overall experience? In a phrase: moment-to-moment gameplay. It is the time period between twitchy active gameplay and a slow, methodical story. The moment-to-moment gameplay is where most games live and thrive, and is what many people mistakenly call 'Content'. This is the middle ground.

- Great mechanics. Platforming, upgrades, and combat. Timeframe: half a second
- MAGIC?!?! Timeframe: ???
- Great theme. Story and lore and bosses. Timeframe: 20 minutes to 300 hours

Let's focus on that middle part for now. Minecraft embodies moment-to-moment perfectly, to the exclusion of everything else. Combat is lame and movement is basic. It takes forever and a day to do anything. I would wager that you could tell me everything that went on the first day you played the game. Here's how mine went

1. The title screen started up, version 1.2 beta. I created a world called "New World". The game loaded up and I was off
2. Everything is made of blocks? This is cool, let me look around and get used to the controls
3. Sheep! Punch the sheep! I have wool? Place the wool? OOH THIS IS HOW THE GAME WORKS
4. Punch the nearest tree. Logs are nice, leaves don't do anything. Punch more trees.
5. Punch the sand. Water pushes me around, so I want more sand. Sand is life.
6. The sun is getting lower in the sky. I should find somewhere to shelter for the night. Dirt on the side of a cave is the way forward.
7. The sun is setting. I built a nice hovel with a doorway. The game is lagging now... let's go inside.
8. Nothing to do inside. Stare at the sand... I guess I can get the sand
9. WHAT THE HECK IS THAT AND WHY IS EVERYTHING EXPLODED?!?!
10. Delete world, throw computer in trash

That is the story of the first 15 minutes of gameplay. The minute, miniature story beats that define quite a lot of games. For some games this time scale runs on a bit too long and for others it gets compressed and chaotic, but the underlying structure is the same. This is also why older games tend to be more interesting than newer games. Filling 200 hours of content 90 seconds at a time is a nigh impossible challenge.

It also seems really weird that Minecraft would focus exclusively on the middle ground. There are a lot of ideas floating around about how game mechanics work and how overall game story progresses, but very little that focuses on the middle. When games were shorter, they had to fill in the middle as much as possible. Complicated mechanics are very hard to program in assembly, and memory limitations prevented anything but the most basic of games from having long-lived experiences. These games needed to focus on the most important aspect to deliver maximum potential. 

Building up Features

 

How do we deliver on the middle ground? We have obviously good mechanics and obviously good themeing. Generating a dungeon randomly is still missing something... let's add in some structure and see where that leads. The Backtracking T map needs a few more rules to it. Our initial rules:

1. The map is divided up into separate areas called zones. Each zone has a key area that unlocks the next zone. Zones are desert, cave, and mountain.
2. Zones have their own set of rooms, picked randomly from a list of choices.

We have the high end of design - zones - and the low end of mechanics - rooms. The design is flexible; it can be any size that we want. The design is also sparse enough that anything at all can be inserted. We can use this as a base to build off of and add in story, enemies, crafting, jukeboxes, liquid particle simulation, jaywalking, and stealing candy from the dirt.

 

Thinking that this is a complete design is a trap. If the design is so flexible that you can put anything in it, then it has to accept everything. The design doesn't add enough restrictions so anything that goes in needs to fit with everything else. The stories that the design will tell do not depend at all on the design, but from the content. If the intention is chaotic random happenstance, then it's a fine idea. If the intention is poor, you will end up with generic cookie-cutter pieces that make a complete puzzle of a square built out of squares.

We need more rules than that. Let's go deeper.

1. The map is divided up into separate areas called zones. Each zone has a key area that unlocks the next zone. Zones are desert, cave, and mountain. The starting area is a forest.
2. Each zone should be around 3 moments long, or about five minutes.
3. Zones have their own set of rooms. Rooms are grouped up into features, and each feature has its own story to tell.
4. Features can overlap and blend together.

Rooms in many metroidvania games try to capture a single moment in time. This is why Super Metroid's rooms tend to be so large. You will spend as much time as you need to in them, they are distinct and the expected time in any single room varies somewhere between 30 seconds and 4 minutes.

Features are a way of trying to string these individual moments along. They can form a miniature cohesive story on their own. If two features overlap, then they can blend together in a way that leads the player down a path from one miniature story to the next. You might end up walking down a path, stop to smell the flowers, get off on a side trail, find a squirrel, climb its tree, and then return to the trail. This was expected, and the experience still feels like a natural exploration of the world.

Features can also control the flow of difficulty and pacing in a game. A particularly difficult obstacle will be notable if the surrounding area is easier, and will seem out of place if it's put in at random. In fact, extra difficult obstacles are usually left out of randomized games because they break the flow too much. If you can guarantee that an infinite pit comes after a series of smaller pits though... you can work in the idea of a death trap at the end of a series of constantly increasing difficulty features.

The design structure for blending features looks like this:
<[ 1 ]=[ 1 ]=[ 12 ]=[ 12 ]=[ 12 ]=[ 2 ]=[ 2 ]>

Features 1 and 2 are both five rooms long. They have a significant amount of overlap in the middle. The overlap will take more effort to generate than simply randomizing everything around it, but will allow for much smoother transitions than "this magic portal leads to space". You might need to run some special code to generate two rooms on top of each other or have a kind of middle ground between the two.

An expanded blended map looks like this:
     [!1]=[12]=[2 ]>
      ||
{ !]-[!@]-[@#]-[#$]-[$%]-[% ]>
      ||
[AB]=[!A]
 ||
[B ]>

Every room blends into every other room here. The main intersection has a primary type [!] and a blending type [@].

Moment to Moment Story

 

Now that we have everything defined we should be able to define everything between mechanics and theme.

- Mechanics. Platforming, upgrades, and combat. Timeframe: half a second
- Rooms: Self-contained area for a story beat. Timeframe: one moment, 90 seconds
- Features: A small series of events with a cohesive experience. Timeframe: 3-7 moments
- Levels or Zones: A general area with a common set of features, difficulty progression, and significance in the overall story. Timeframe: 5 minutes to 2 hours.
- Theme. Story and lore, overall playthrough. Timeframe: 20 minutes to 300 hours

With these extra structures in place, what the story of The Backtracking T look like with a real set of assets?

- Test player controls. Examine your surroundings. Find a door that needs a round object of some kind and some kind of unscaleable mountain.
- Leave the forest and traverse the desert. It's treacherous, so keep track of the sandpits.
- Find the mystic gem. Quickly backtrack and dodge the sandpits, then put the orb in the door.

- Find your way through the cave, dodging bats and slick floors. Grab the climbing claws.
- Dodge and smash all the bats on the way out. The place is still quite treacherous, so it takes time, but less so because you can scale walls.

- The climbing claws let you climb the mountain! There are harpies, so you get knocked off multiple times and have to start over
- The top of the mountain has a harpy queen. She agrees to give you medicine for a mystic orb. Down you go and up you go, but quicker this time.
- Gain the medicine, the game ends.

This story takes 8 moments to complete. Each moment is a miniature arc in the story. The player can relate to each part, find a particular memory to differentiate it, and then describe in their own words what happened. The middle arc is the least defined of the group, but the middle of a video game can vary in length quite a bit based on the differences in player skill, experience, and knowledge of your game.

This is a far cry from the previous story of "go left, find the key, go right, find the key, go up, beat the game". Even better, the game can have bad mechanics, no story, look terrible, and have no sound. The chance you would remember this game as being a bad game would be high, but it would still hold your interest long enough to finish it. THAT is the important part.

By restricting the rules into a set of features, the designer is forced to think about each one of those features. Each one needs an emphasis and a connection to the rest of the world. By combining theme and mechanics, we have what lies in the middle.

Conclusion

Make sure you include the middle when procedures are written. Players do not live in the minute or on the theme. Grand overarching epics of greatness and wonder still need time to pass. Minute mechanics can be wonderful in an instant, but out of place with other things. Most importantly, stories are not constructed out of the largest or the smallest pieces. They lie somewhere in the middle.

We live in the moment. Make sure your game knows what a moment is.

Metroidvania and Randomization: Breakdown

Objective: A full-scale random map generator that is indistinguishable from a hand-crafted experience. Will we get there? Who knows!

Analysis:
Metroidvania games are based around tight hand-crafted experience. Levels are built in a way that encourage backtracking, to show improvement in the player's avatar and skill over time, a lock-and-key system to gate progression, and repeat playthroughs tend to change the way the game is experienced though advanced tricks or sequence breaking.

Procedural generation has the opposite promise. Every playthrough and experience has been shuffled, randomized, or otherwise changed. Each run is novel and unique. The world itself is unknown until explored and discarded at the end.

These two experiences are fundamentally incompatible. Combining the two will end up compromising on the promise of one or both experiences. This may be a small way, but

I believe the incompatibility exists on an experiential level. Super Metroid is a masterpiece of gaming; a randomly generated Super Metroid game is the holy grail of game design. Attempting to make a randometroidvania game requires a high level of design skill. The idea has been attempted, but it's hard. Let's take a look at why.

Problem 1: Randomized games are a lot less memorable

The core promise behind randomizing a game is that it is novel and unique. Seeing something for the first time is exciting; imagine seeing everything for the first time every time you started up a game. It would truly be a unique experience that can be shared and related to other people. There might be some common thread running through the gameplay, such as building a dirt house in Minecraft, but that common thread could happen on top of a mountain or next to a river or even inside a cave.

Experiences have narratives. Anyone who plays a game becomes the main character in their story. If the story is about making a tree, then it might involve research, a sketchbook to draw out a rough design, scanning, painting, and eventually taking the finished piece and putting it in a game. It might be about pulling up the dictionary in Scribblenauts and dropping a tree on a vampire. It might just involve bone meal to magically sprout a full size tree out of a sapling. The story itself is how we share games, and "random" games tend to be bad at this.

Trying to build something "random" makes building up the story of the world difficult. It's a lot easier to describe a single tree in a field than a single tree in a forest. It's also a lot easier to describe a forest in space than a forest next to a plain next to another forest next to a lake next to another forest. Differentiating the first forest from the last is difficult enough when the game is static; when the game constantly shifts around under its own weight, you miss the forest for the stars.

Procedural games tend to make everything into the forest: level elements are cookie cutter, bland, and can be shuffled around or inserted at any given point. Every piece in the story needs to be self contained and inserted into an experience at any given point. Relative difficulty over a scale becomes impossible to pin down, and the closest thing you'll see is that an area is more difficult because the monsters in it have more health and damage.

Cookie-cutter rooms are a design trap. If every piece needs to fit everywhere, then every piece needs to be more-or-less the same. Sure, the level might have some difference in the way it looks, and later parts of the game may have more traps or features to traverse, but they still can't have much variation.

If every piece is generic, then every piece is the same. If you're doing the same thing again and again for a few minutes, it's going to get boring. Why would you do a repetitive task that merely has slight variations? It's almost like the designer lost part of the design in the process or didn't know how to handle this to begin with.

Many games treat procedural generation as a blank check to replace what would be interesting and engaging content with novelty. The systems can be the best technical gameplay ever made and they will still be disappointing if there is no challenge or variation to use it on.

This problem rears its face again and again across any game with a randomized system. The problem can be solved; the best randomly generated games have a particular idea or experience they're going for. The randomness may blend into the background, or it may become the centerpiece of what the game is trying to express.

Random generation done right can can be better than hand-crafting everything. When it's done poorly... well. Let's just say that the results don't speak for themselves.

Problem 2: Procedural levels do not tell a cohesive story.

If we define a dungeon as a series of traps and pathways full of loot and danger, then Super Metroid becomes one of the greatest dungeon crawlers of all time. Its platforming system is quirky and floaty. The game is easy enough that a random person could pick it up and have a fun time over a 10-20 hour experience, but the skill ceiling is high enough that the human limit may not be reached. The game even has the same constraints as a lot of modern procedural counterparts: the entire game is a series of rooms and tubes connected up at doorways.

Super Metroid's greatest strength is in the way player skill is handled. A new player will find themselves fumbling through the entire world looking for the next upgrade. They will stumble into areas that show that Samus has skills that the player doesn't know about: running, wall jumping, and the shinespark. Once the player has mastered each of these skills, a new game opens up. Suddenly you can go where you hadn't before, beating the game "out of sequence", and with enough practice the common experience that everyone had when they started gets shattered into a wide variety of routes and choices.

(Above this plant is an item that needs a shinespark to access)

The unchanging map also lends itself towards mastery over the game itself. There are tiles placed strategically around the level to show where certain tricks or borders are. The level may seem a bit dull at first, but every tile, enemy, and doorway is placed in a way that notes "I am here". Even the smallest detail can be used as a visual cue. Combine that with completing the game out of order - sequence breaking - and eventually you can go anywhere in the game at any time provided you have the personal skill to do so. 

Super Metroid's story is something that can be explained as "I accidentally found a new area, got an upgrade, and then went back and did it again. The varia suit lets you run in super hot rooms to find a speed booster that turns you into the flash, and there was a boss the size of the entire screen, pools of acid to burn your face off, and the planet exploded!"

You'd be forgiven for missing out on the details of your journey. I'm sure each area was memorable, and subsequent trips will make all the little things shine.

Contrast this with Dead Cells, the roguelite metroidvania fusion. Every time you play the game a new world is generated. Characters do not start off fresh; instead they start with all of the skills and unlocks that have been gained over previous runs. A player who has been playing for an hour has likely died five times, unlocked two levels of potions, gotten used to how the basic sword and bow operate, and found themselves at the mercy of the prison.

Because each run is unique, the player needs to rely on their general gaming skill to get by. There aren't any specific training areas. The levels are mostly comprised of a linear path with some branches, and each section has a teleporter to make backtracking faster. Most areas are flat. Traps tend to be blocky, made of spikes, and infested with enemies.

Dead Cells sacrifices its individual upgrade aspects and some fine tuned gameplay to offer up a huge variety in weapons, good variety in enemies, a branching progression path that resembles its level layout, a level-up system based on loot, and a permadeath system that brings some upgrades forward each time cells are spent. It's a good tradeoff that leans heavier on its roguelite aspect than its countepart.

Dead Cell's story can be summarized as "I found a sword, killed some things, ran around AS a chicken with its head cut off, got my head cut off, and did it again. Each time I got a little further and the game got harder, but I finally triumphed after countless deaths."

This game gets around the problem of moment-to-moment player story by absolutely littering every level with enemies. There are occasional areas tacked on to the level called "lore rooms" that expand on the actual story, and each new level has a theme and a different type of layout behind it. The Docks always comes after a boss fight, has a lot of vertical buildings thatyou can go inside, and there are a good number of secret rolling areas to visit.

(the most interesting part of the game is the very beginning)

Let's look at another game with the same intention. A Robot Named Fight has the same roguelite metroidvania fusion as Dead Cells, but leans much heavier on its metroid roots. In fact, the robot controls so similar to Samus that you could play Super Metroid as a training area. That fact alone wouldn't be a problem if the difficulty of the terrain wasn't exactly uniform across the entirety of the game. There's no challenge in movement; you either jump high enough or you don't. You either jumped or you didn't.

Upgrades are randomized without any progression. The start may have a double jump, an explosive shot, or a movement shell. The last boss may have the same items. Every one of the items is about the same power level, give or take, and the only real thing that matters is damage or bolt changes.

Unfortunately, Fight comes out as the worst of the bunch. The entire world is shaped like an upside down e. It's broken up into four distinct zones, and the deeper you go into the map the harder the enemies are. However... every room feels like every other room across the entire game. The lock-and-key system is preserved, but it feels arbitrary to block off doorways with explosives or lightning because there's no real way of identifying where these doors are outside of looking at the map.

How much meaning can you find in the placement of an empty room? Nothing. How much meaning can you find in the placement of a completely randomized upgrade? Also nothing. How about single templates level layouts? Maybe something, but not much. At least not without making it painfully obvious.

A Robot Named Fight's story can be summed up as "Robot fights meat and gets random things to open random areas". It's not compelling. My own story hardly worth a mention. Each run is 'unique', but when you've played one run you've played them all.

Fight's problems go deeper than the fact it is a mediocre game. Narrative and story is not something that can simply be put on after the fact. Each area should be something the player interacts with and can get behind. Instead we get generic, bland, recycled single templates that get stitched together in a broken line. I couldn't even tell you what planet you're on.

Maybe the problem is the roguelite aspect? Let's try a pure version instead: Chasm

The entire game is generated at the start of a run. You can explore, collect resources, gather upgrades, die, respawn, and do it all again. This one leans more on Castlevania than it does on Metroid, and the weapons certainly match that. Daggers are quick with impossibly low range, greatswords are slow but highly damaging, and skills take mana that can be found inside random objects.

It seems like a great setup. The idea is sound and it wants to scratch the itch of a wonderful platforming upgrade niche. Bait, meet switch.

The game quickly turns into a drag. The character's movement speed is as slow as any Belmont's movement, but without the precision in level design, devilishly placed enemies, or intricate maps. Most of the terrain is flat platforms in wide open rooms.

The map is a sprawling list of tunnels that connect to other tunnels in long hallways of tunnels. Very occasionally the path branches off, but they don't connect. You would be forgiven if you would get lost in the bland nature of the open level design if it were not for the strictly linear nature of the paths. On the off chance you do have to go off the beaten path for an upgrade, you probably won't remember where the upgrade actually is.

This project commits the cardinal sin of gaming: boredom. The entire thing is boring from start to finish. The idea of a procedurally generated game is enough to suck you in, but the sheer amount of compromise in this product turns the entire thing on its head. The best thing I can say about Chasm is that it serves as an example of what not to do.

Chasm's story goes like this: "I started in a castle, got a message to travel to a place, took a look around, and jumped right in. After that I got lost multiple times and died a lot and then stopped playing because the last upgrade was a double jump."

Conclusion

We have two main problems to deal with that have the same root problem. Trying to marry a game type that tells its story through hand-crafted environments and repetition with a design pattern that rewards novelty and uniqueness leaves the two at odds. The ideas don't seem incompatible; hand-crafted and unique areas are similar, and repetition can be married with novelty in a variety of interesting ways.

 The real problem comes down to the restriction of completely replaceable templates all over the map. If these two ideas are going to get along they will need more structure, not less.

Once again, but with Templates

I've been wrestling with the system behind visible terrain for the past week. It's been in this awkward state of "I almost like using this" for too long now. I'd like to use the system for real... so let's make a real game.

How about we combine the idea of a tower defense game with a card-system that ties structures to rooms? The player can create defensive areas and manage resources to build new rooms. I'm a big fan of platformers; that should give this game a lot of verticality and make falling traps - both creatures falling and spikes from above - fun to design.

Anything built here can be re-used elsewhere. Alisia Deena Rain can stave off every enemy from her game, use every one of her powers, and have a failure state based on lives. mDiyo (the character) can build swords and armor, 'find' soldiers to give the swords to, and fend off a whole bunch of slimes. As long as the game is fun, anything goes!

Basic Game Stats

Resolution: 640x360 px

Tile size: 16x16

Template size: 8x8 tiles or 128x128 pixels

Room size: Minimum of 1 Template. Maximum of... a lot?

 

Style: 2D sidescroller

Genres: Platformer, Tower Defense

Aesthetics of Play: Challenge, Fantasy, Discovery, Expression

References: Boss Monster, Super Metroid, Starcraft

Resolution

 

640x360 (360p) is the ideal resolution for retro-styled games. Most monitors use a 16x9 resolution with 1920x1080 (1080p) as their base. The scaling works near perfectly:

360p: 1x

720p: 2x

1080p: 3x

1440p: 4x

4K: 6x

5K: 8x

There are a few resolutions where this doesn't scale up as nicely such as 1366x768. In these cases, we can give the player a bit more screen space in whichever direction doesn't match. 

Tile Size

 

Tile sizes were picked by feel, system limitation, and tradition. Unity lets tiles be any resolution at all; you can even mix and match them. Traditional tile sizes are 8x (Sega Genesis), 16x (very common), or 32x (RPG Maker), with a few crazy systems going for larger systems and a few super-constrained systems going for less. 

At 16x, the screen can display tiles 40 wide and 22.5 down. This gives us a nice area to work with that isn't so small we end up fiddling with all the tiny little details, but isn't so large that a good artist needs to make multiple variations on tiles to get them right. This size groups up well in sets of 2, 3, and 4.

Video cards store textures and process information in powers of 2. Unity automatically adds a buffer to the edge of graphics that aren't a power of 2. A lot of weird problems are mostly mitigated, but there are still a number of features that don't work correctly with odd shaped textures due to under-the-hood shenanigans that the engine performs to prevent your computer from exploding.

Templates and Rooms

 

 

This is a full-size mockup of the game. Each light blue square and its border is a set of tiles that we can call a template. Groups of these templates make up a room. Rooms can be as small as 1 template or larger than the entire screen. Templates can be arbitrary shapes, but rectangles should be easiest to work with. 

Making it Work

Mockups aren't too hard to make in-game. The base project has tiles, colliders, characters, health, tools, and anything else needed already set up. Almost all of it is in a state of "this works, but it's ugly/hardcoded/barely useful", also known as "good enough". Let's just grab some basic colors for tiles and...

Perfect. I can work with this. 

Getting the template system working was no easy feat. I had duplicated a lot of code into six separate places... templates were loading differently from the editor's inspector, the game itself, and I wanted to make them load by clicking on the asset. Editing one thing would leave the rest intact; refactoring this mess down was mandatory. The entire workflow needed to be adjusted so that I could spend more than a moment in the editor without short-circuiting my brain with code questions.

 

The code's flavor changed from 300 lines of spaghetti into this:

public void LoadTemplate(Template template)
{
    //Find tilemaps
    Tilemap[] maps = TemplateHelper.FindTilemaps();

    //Let the Template Builder know that we're adjusting it from the outside
    TemplateBuilder builder = GameObject.Find("Template Builder").GetComponent<TemplateBuilder>();
    builder.assetName = template.name;

    //Load the room
    Vector3Int templateCorner = Vector3Int.zero;
    TemplateEditorHelper.LoadRoom(maps, template, builder, templateCorner);
}

A lot of effort was put into making a template system that could save and load rooms that have a background, terrain, and foreground layer. The template needs to keep track of objects like trees, spikes, or special creatures. It also needed a new set of paint.

 

This looks good. Suspiciously good... has it ever looked this good? I don't think so. Why does this feel right and why didn't I spend the time before to make this actually work in a reasonable manner that a designer could understand? It feels like I've spent so much time floundering around in my own head that actually showing this off is a feat in and of itself.

 

Let's grab a few sprites from my unsorted design archives and the Open Pixel Project, a few sounds from royalty free sites, and string everything together in the most basic version of 'reasonable'. Write just a little bit of code to get this whole thing working... 

 

public override void GenerateLevel()
{
    //Terrain
    Tilemap[] maps = RoomTemplateHelper.FindTilemaps();
    Vector3Int roomSize = groundLayer[0].GetBaseSize();
    Vector3Int mapSize = new Vector3Int(roomSize.x * groundSize.x, roomSize.y * groundSize.y, 1);
    TileBase[] tiles = new TileBase[mapSize.x * mapSize.y];
    Debug.Log("Making " + tiles.Length + " tiles betterererer");

    //Wipe the map
    maps[0].SetTilesBlock(new BoundsInt(Vector3Int.zero, mapSize), tiles);
    maps[1].SetTilesBlock(new BoundsInt(Vector3Int.zero, mapSize), tiles);
    maps[2].SetTilesBlock(new BoundsInt(Vector3Int.zero, mapSize), tiles);

    //Generate ground
    int baseCount = groundLayer.Length;
    for (int y = 0; y < groundSize.y - 1; y++)
    {
        for (int x = 0; x < groundSize.x; x++)
        {
            RoomTemplateBase template = groundLayer[rand.Next(0, baseCount)];
            RoomTemplateHelper.LoadRoom(maps, prefabContainer, template, new Vector3Int(x * roomSize.x, y * roomSize.y, 0));
        }
    }

    //Generate top layer
    baseCount = grassLayer.Length;
    int treeCount = grassTrees.Length;
    for (int x = 0; x < groundSize.x; x++)
    {
        if (x % 4 == 2)
            RoomTemplateHelper.LoadRoom(maps, prefabContainer, grassTrees[rand.Next(0, treeCount)], new Vector3Int(x * roomSize.x, (groundSize.y - 1) * roomSize.y, 0));
        else
            RoomTemplateHelper.LoadRoom(maps, prefabContainer, grassLayer[rand.Next(0, baseCount)], new Vector3Int(x * roomSize.x, (groundSize.y - 1) * roomSize.y, 0));
    }
}

The overall result?

We have ground, grass, trees, a ghost template, the character, a multi-part hitpoint and status effect system from another source, and a tool UI from that same other source. The ground is built from rooms and everything works as intended.

 

It just works. Huh.  

 

IT FINALLY WORKS!!

I spent a week getting all of this to work. Most of it was in place already; it was ugly, sabotagetastic, and weird. Now it's something I can be proud of and have enough progress to think about sharing with the world. 

 

I'll work on the other systems in due time as the card system gets fleshed out and the skeleton turns into a fully-fleshed out game. For the first time in the history of the Base Project, a game has been built out of its pieces. This has been a long, long time coming and I'm glad it's finally coming together.

Content Versioning

Version numbers are like opinions: everybody has one, they tend towards the majority, or you're a madman who thrives in utter chaos. The programmer side of life tends towards regimented, structural numbers, and the marketing side sees a version number as a way to show progress or change in their project.

 

Small video games or projects that constantly change in early development tend to have version numbers that don't make a lot of sense. It may not be feasible to keep track of a version in a way that makes sense to a machine. Projects can get pretty wild before they've been scoped out and defined even with the best idea behind them.

This gets even more complicated when you throw in mods. Do mods need to include the game version they're built against in the version itself? If the mod works on a range of acceptable game versions, does it need to include that? What about addons for tabletop games? Hacks? Total conversions? Grafting an entire game onto another game?

I developed this versioning format to try and sort out some of the weirdness and incompatibility that comes with rapidly creating content on top of systems and then gutting the entire thing because the core of your design is good, but the implementation is horrid.

This format works best for alpha or beta projects before their full release. Projects that are content heavy, like video games, benefit the most. Marketing may like the nice feeling of a 1.0 public release or a continual push towards the future, but this format has an advantage that no others do: the version history itself can tell a story of development, of progress, and of change.

Content Versioning

Format: MAJOR[DEVELOPMENT_PHASE].SYSTEMS.CONTENT.PATCH/TEST

Example: A.6.2
Example 2: 3A.4.17.340
Example 3: (1.16).4.1

Major Version: The intended version of the project you're working on. Generally, this will be your first project. The first version can either be 1 or 0 until there's a full release of the game.

The major version number is optional before a full release. It's most useful when the project you're working on is a sequel to another project. A or B at the beginning of the version is painfully obvious that this is not a completed project.

Major version is also a good place to put a game's version. Minecraft tends to change itself every 6 months or so and Windows 10 breaks drivers like clockwork.

Development Phase: These are usually referred to as "alpha", "beta", or "release", with the occasional extra step such as release candidates. This can also be arbitary; replace the letter as the project moves from phase F to G in its nine-phase development outline.

Systems: The most useful number for programmers. The number represents how many working modules of code, gameplay dynamics, or miscellaneous systems are currently working as intended. 

A simple platformer may have a character, level, and UI system. Complicated games will have systems built on top of systems and the layers themselves will interact in multiple ways. This number will naturally go up quickly at the beginning of a project and level off towards the end.

Content: This number relates to the amount of content in the game. Divide up the game into bite-sized pieces and increment the counter when one of them gets made. 

Made a new enemy for a level? Bump up the content number. Your custom crafting system had a significant amount of new content put in that is going well? Bump it up some more. Finish off the final boss in the game? Bump it twice for good measure.

For good measure, keep track of how much content each bite actually takes up. Refining a level or a content system can make the number go up, down, sideways, down some more, and shoot way up on a day of inspiration. Try not to make this number go down after release or you will have people asking a lot of questions; version numbers only go up, after all.

Patch/Test:  

Before release: You released a new test version or wanted to make a build just for the sake of it? Number goes up. No thought required.

After release: Something broke, you just wanted to make a couple small changes, or forgot a readme file. These changes don't change the project substantially, so the number goes up. This number resets any time the systems or content increments.

The content, systems, and test numbers work independently from each other. Content and systems are often related no matter what type of project you're using, but sometimes you'll develop the entire system before touching one drop of content and other times two groups will work on the entire project in parallel.

Detailed Example: Tinkers Construct 1

Tinkers' Construct 1 was the main source of frustration with versions. Let's apply this system to the mod retroactively and see where we end up. From the top:

The initial public release had three systems: Tool Core, Modification, and Crafting. Content would be broken down into rough chunks of swords, other tools, tables, patterns, and a couple more for modifiers. The initial release was on Minecraft v1.4.7... so the mod would have a version of 

 

Initial version: 1.3.6

 

The first release was botched pretty badly; I ended up hotfixing it 8 times before adding more content. 

 

Hotfix version: 1.3.6.8

 

There was a bit more development to flesh out modification and the tools with a proper release every two weeks. Add in another system to make auto-smelting, fortune, or silk touch on tools and carry on.

Midpoint version: 1.4.14.2

The second major release was a continuation of the project. There's a new idea in town: The Smeltery. This took a very long time to build and involved multiple new systems: structure creation, alloying, casting, fluids, networking, and broad tools. Content amount goes up in spades and the mod obtains an inordinate amount of content compared to before.

Smeltery release: 1.9.30

That's a huge jump in systems and a rather large jump in content. It took 6 months to sort out all the bugs, finish up content, and get everything moving smoothly.

Smeltery endpoint: 1.9.38

At this time I had switched to a content-driven development format. The version was bumped up to "1.3.0" from its "1.2.18" point, but there was no real reason for that. I just wanted to make a whole lot of things after spending so much time on systems. There was also the odd problem with armor being wanted, and I tried adding a system for that... but it was not exactly great. I had to add things and rip them out multiple times.

Content start: 1.10.40

The overall quality of the mod went up over this time. Things were refined and polished in a way that hadn't been done before. Most of the systems were already made; it was time to add the rest of the things on top of that.

Final version: 1.10.70

 

This version history tells a much different story than the butchered semantic versioning that I was using before. There wasn't a real rhyme or reason behind anything. The number was detached from the source, and while it was still useful to compare and see whether things were out of date, it wasn't useful beyond that.

Let's compare against the two most common versioning systems:

Semantic Versioning

Semantic versioning is great for keeping track of a particular version in a project. Its best use is for libraries or similar files that code or documentation depends on. You know immediately if your code is out of date, or if the library you're using is going to work at all.

SemVer has a very mechanistic view on how its versions should be described. The format is simple: MAJOR.MINOR.PATCH.BUILD

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.
4. BUILD version when a program attempts to compile a nightly build
   

Projects with automatic build systems need more information. BUILD is an extension of this format, but is usually left out on releases.

 

jashkenas has a good writeup on why semantic versioning is not semantically sound. In short, the version format compresses too much information into a single three-number phrase and doesn't take into account the human factor. It's not good for dynamic systems that are constantly changing.

Calendar Versioning

Some software is updated regularly. Some companies have taken this idea and incorporated it directly into their version numbers. If a piece of software has a major change once per year, then it has a larger number to match. EA games such as FIFA or Madden, Adobe products, and Ubuntu releases follow this mold.

CalVer takes a temporal view on how its versions are described. Let's take a look at Unity3D's format: 2018.4.35f1

• Major - Calendar Year. Unity used 1-5 for its calendar version up until 2017, which switched the version number itself to the year.
  
• Minor - Changes. Unity uses this for new systems that tend to change or break things.
  
• Micro - Patch. Small but significant changes like bugfixes.
  
• Modifier - An optional text tag, such as f1 for "final/hotfix on version 35". Unity has one of these on every build (usually f1, but people make mistakes)
  

The date may end up directly in the version number somewhere, usually the major number. Other times the number will be incremented automatically each time the date switches over.

 

This format is great for long-term projects with a regular release cycle and a marketing team behind it. The larger and longer-lived the project is, the more benefit they will find in the consistency of time.

 

Final Thoughts

Content Versioning is best used on projects that have an erratic development process or lean heavy into content like video games. The version itself holds more meaning than an increment in the development process and can be used to gauge how the project is going. It is best used where other version formats are inappropriate or are a poor fit. 

I use this format for game development. It's a far cry from the mechanical incrementation of SemVer, and who in their right mind would use a calendar format on a project that isn't even released yet? The format is a tool, and like all tools they have a time and a place where they are best used.

I may carry this format into full release later. I'm not sure if I'm going to have an external version of 1.0 alongside an internal version of 1.40.3249 on any future projects; we'll see when we get there.

Room Template UI Improvement

 

Poor programmers blame their tools for their mistakes. Great programmers build their own.

 

I've found myself picking up game development, putting it down, starting on a new project, picking up game development again, putting it down again, and on and on the cycle goes. This cycle has been going on for some time and I haven't really been sure why. It's almost like something was short-circuiting my flow state and making the entire experience dissatisfying.

Today, I came to the realization that all of the tools I have made are getting in my way.

Unity is a game engine in two parts: the designer interface and the scripting backend. The design side of making a game has enough information and enough niceties that a skilled designer can take art, scripts, and sounds, combine them all into a series of experiences, and end up with a polished product at the end.

Programmers, on the other hand, bury themselves in the code. The behavior of everything from enemies to GUI is their domain. Each and every thing

The problem when you mix these two workflows together is that they can sabotage each other. A programming task that wants feedback will have the developer jumping into the unity editor - design side - and immediately testing out what they have. This is great when everything is working smoothly, not so much when you have to figure out what you're doing every time. 

 Say you have a box like this:

This is the ugly cake room. I'd like to save this room for later; let's put it into a data structure called a Template so we can take it down and pull it up on a whim. How do we do that? By building an asset file out of it.

This is the inspector UI of a room template builder. Things are organized roughly in order, but it's hard to tell what's what at a glance, there's a bunch of useless information that the builder needs but the designer doesn't care about, and who can tell what template 2 exits to at all? I certainly couldn't.

This is actually the improved UI. The old one was worse... we'll just pretend that doesn't exist.

The template itself saves just fine. The UI on this asset is also kind of ugly, and it has no texture. Only the Unity default image.

Normally when I pull up an old project I'll get excited about some idea that I would like to try making and make it as fast as possible. I'll muddle through any weirdness in here, re-learning anything as I go along, getting used to the thing that I had made, and eventually just leaving with a feeling that I made what I wanted but something about the whole experience was off. 

Any time I would hit the UI I would already be in the mindset of "design" and not the mindset of "programmer". Everything I have built like this is built with knowledge of how it works in mind. There's no room for mis-remembering and if I showed a random person what this did, who knows? Looks like a bunch of text, some numbers, unsorted checkboxes, and buttons. Nothing really draws your eye to any part and the best you can do is "muddle through".

Switching from Visual Studio to Unity is like flipping a switch. One side is code, the other side is design. The designer in me is cringing at the programmer who just wants to get things done, and the programmer in me is getting frustrated at the ease of flow between prototyping, testing, and bugfixing. It's so bad that I'm repeating myself. 

If it's that bad, then I can certainly do something about it. What about this...

That's a LOT better. It's so much better that I'm surprised I didn't try this before. There's a large button to draw your attention, multiple buttons below it that are easier to navigate, the checkboxes for room exits are sort of in the same spot as the room connections, and there's a readout on the (now somewhat in order) location of the rooms in this template group.

The code for this is at the bottom of the post. It was tedious to write and was repetitive and fiddily. A lot of the code looks like this:

int spacer = 40;
for (int i = builder.foldoutConnections.Length - 1; i >= 0; i--)
{
    int y = i % builder.templates.y;
    int x = i / builder.templates.y;
    builder.foldoutConnections[i] = EditorGUILayout.Foldout(builder.foldoutConnections[i], "Template " + (i + 1) + " (" + x + "," + y + ") connections");
    if (builder.foldoutConnections[i])
    {
        GUILayout.BeginVertical();

        GUILayout.BeginHorizontal();
        GUILayout.Space(spacer);
        builder.connections[i * 4 + 0] = EditorGUILayout.ToggleLeft("Up", builder.connections[i * 4 + 0]);
        GUILayout.EndHorizontal();

        GUILayout.BeginHorizontal();
        builder.connections[i * 4 + 3] = EditorGUILayout.ToggleLeft("Left", builder.connections[i * 4 + 3], GUILayout.Width(60));
        builder.connections[i * 4 + 1] = EditorGUILayout.ToggleLeft("Right", builder.connections[i * 4 + 1], GUILayout.Width(60));
        GUILayout.EndHorizontal();

        GUILayout.BeginHorizontal();
        GUILayout.Space(spacer);
        builder.connections[i * 4 + 2] = EditorGUILayout.ToggleLeft("Down", builder.connections[i * 4 + 2]);
        GUILayout.EndHorizontal();

        GUILayout.EndVertical();
    }
}

Not bad for a bit of time in Unity's documentation on EditorGUI. I'm sure this can be improved; template connections would look nice in the same layout as a 2x2 grid with buttons instead of checkboxes... but that would take more than the 3 minutes I spent figuring out how to arrange them properly. I'll chuck it on the back burner for now.

What about the cake room asset?

Scriptable Objects automatically change their icon when their script is changed. This works well enough for differentiating generic objects. The templates don't particularly need an icon associated with each one... that will come later.

The main thing that's bothered me for a long time is the flow of loading up templates. You have to go to the template builder, type in the name of the template, and press load. This is more-or-less fine... is what I keep telling myself. I swear, on the blood of monsters and all that is worthy of derision, this problem is just like the other problems fixed today: it's tedious, irritating, and why did I put up with it this long?!

Let's just load the asset directly from its display.

It would also be nice to preview this template without needing to load up a scene dedicated to editing them. That's... going to come later. The button will eventually bother me enough that the feature will get built, and the button can just exist for now.

Here's a lesson in being lazy: The GUI elements are in the correct spot and I'm too tired to get this done in one day. Things are arranged in quite a bit more readable fashion, so it's good enough for now. Plus anyone who looks at this can ask why there's a bunch of TODOs staring them in the face.

There's been quite a few changes in all of this. I just need to test everything out to make sure that nothing is broken and...

I forgot to save the rotation of the tiles in this template. There wasn't any code to save the rotation when I started on this trip. I just wanted to make some nice rooms so I could take this idea of building a dungeon of cards and protecting the mDiyo workshop from a whole ton of slimes crawling on every wall they can touch.

This entire process is a lesson in Yak Shaving that turned into the primary goal. I'm not sure exactly how I feel about that, but it feels good enough for one day.

Anyone who wants to peruse my code can take a look at pastebin. TemplateBuilder needs to be attached to a GameObject; everything else should work as-is.

TemplateBase
Template
TemplateMaster
TemplateEditor

Template Builder
Template Builder Editor