Showing posts with label Modularity Project. Show all posts
Showing posts with label Modularity Project. Show all posts

Friday, October 29, 2021

Self Reflection, Avatar Reflection

It started as a joke.

One day I decided that my game development was going poorly because I was too attached to my characters. If I messed anything up, like accidentally replacing the sprite rig's head with a hand, then a tiny twinge of regret wormed itself into my head. That twinge could grow and blossom into a fully-fledged loss of the character, until I went back and started changing everything about it so it actually matched what I saw.

Every programmer starts making things with basic blocks. Ugly, placeholder pieces of art that are there just to get the ideas down right. Every artist starts with an idea and tries to draw out the thing in your head to a real form. The schism between the two gets strange sometimes.

I don't want to work with placeholder art forever, and I can't get the personality down right with a bunch of rotating blocks. Thus the joke: mDiyo enters the game! Take my avatar, make it as high quality as the artwork I eventually want, slice it up, and if something weird happens then I hurt 'myself' in the process, slap myself in the knee, and fix the bug. This worked so well that I'm not even mad about 'my' face flipping backwards in a weird way:

Over time I found myself doing what I normally do with characters that I spend with: building them up. In this case it's been great for defining things that may or may not have impact later on down the line. I can find what works (equippable gauntlets over the hands) and what doesn't (armor layering), then fix things up proper when I get to characters that I really want to make.

My end goal is a procedural metroidvania game with multiple characters that both give upgrades and let you actually play the game with them. Mid goals are multiple types of games with unique and interesting mechanics that can support the end goal. I have a lot of notes on mechanics, characters, lock-and-key design structures, and potential puzzles or action sequences to be solved. Drawing up mDiyo-character-specific items here isn't a waste of time; I would need to spend the time figuring out how to relate these concepts to the endpoint. These articles are similar; it's just a lot more out in the open for everyone to read.

Sometimes in the process of making things, I come across a question that needs answered. Some of these questions have obvious answers. For example: "What sort of upgrades exist in Metroid Dread that aren't in my list of upgrades?" Combing through a game takes a bit of time, and to fully understand things it can take 3-4 playthroughs of the game. Other questions have more nebulous answers, like "how do controllable enemies work?". Given enough time and the proper context, these problems can be boiled down to math and have a solution, or they can be rendered into an art and the answer doesn't matter, only the execution.

Occasionally I find a question that demands an answer that doesn't exist. These are usually for ideas that don't exist in any of the references I have. "How do you make more than two playable characters function in a Metroidvania?" is a question that still doesn't have an answer, and this question prompts others like "what happens if I try to combine some of my example characters like Samus and Jason Frudnick?" or "Who is mDiyo's partner?"

That last question is irritating. There are feelings attached to it, feelings that I thought didn't exist because the avatar is not supposed to be something I'm attached to. I'm absolutely sure that it's not related to the thing I made, because this is fine.

It's not the character. The abilities built up for him are well defined and have specific goals for the future. Telekinetic swords are fascinating, armor needs an equipment framework built in code, and having the sheer versatility of a miniature army and a boost in power from magic is a fantastic power set worthy of the fantastic humans that are being worked on. The design looks good, the character's class is a sword-dancing puppeteer, and the lore already supports something like that, so why? Why does the idea of the character that represent me having a partner bother me so much?

The adventuring archetype for the character is a self-made army. Necromancers, puppeteers, beast tamers, and leaders in a rag-tag bunch of mercenaries all fit this idea perfectly. I've even written other characters with this archetype; it's one of the concepts I've been exploring lately and the gameplay style I enjoy the most. Everything fits here, everything should fall into place and all of the content should flow outwards in a fun and exciting way, but it doesn't. The process is maddening. What is so important in that question that it pulls at my heartstrings?! Why, why, WHY?!

These feelings make me uncomfortable. It's the kind of discomfort that wells up deep within your chest, burying itself so deep that merely asking the question brings up a perverse sense of nostalgia from a time that existed last year and before. The feeling is so gut-wrenching that I need to describe it in the abstract, as if it was something else outside of me, despite the fact that it's buried so deep that I'm afraid that it is me.

These feelings have more than a little to work off of. This is the first time in my life where things are actually going right, where everything could come together and work right for once. The perverse sentimentality is from the before time, where fear and mitigation ruled the day.

Let's put this in another context. mDiyo is the pinnacle of Metroidvania design and sympathetic magic. He is genre savvy and capable of replicating ideas through material manipulation, construct creation, essence weaving, and a hand from an outside source beyond his control. This source is known as a 'World Seed' and grants information on a variety of sources of information. Piece by piece, idea by idea, the world is being built around him.

For mDiyo's personal path, he pulls from a number of heroes. All of these heroes are interesting from a do-crazy-sensible-things standpoint:

Samus Aran - Intergalactic bounty hunter and the progenitor of Metroidvanias.
Jason Frudnick - Alternate universe earth genius who happened across a frog, a tank named Sophia, and a scenario that was too ambitious for its own good.
Alisia Deena Rain - A lilliputian that uses her pet dragon to manifest lightning. She sets off to rescue her husband from a cult that successfully summons their god.
Sonic the Hedgehog - A blue creature that has no business being a hedgehog. He's pretty famous for his sidekicks and his speed.
Red - A pokemon battle legend.

Morph Ball, Sophia, a pet dragon, Tails, and pokeballs. We shall swipe all of these and make them real. There are other things, of course, but for the character, it's...

There's that feeling again. The worst part of that is 'we' and 'swipe'. It's almost like I'm trying to create something that's fake, something that couldn't possibly be real, and because this character represents myself then what I'm building here has to be for me. Separating the character from the person doesn't seem to be an option either, as the entire point of putting my own avatar in this setting is to make something that doesn't matter in the grand scheme of things.

It's different though... more subtle. Like part of the problem is the conflation of the character and the persona, the persona and the writing, and the writing with the real mind behind all of it. I am genuine, honest, and true. I do not like being fake. Despite the sheer amount of things that distance the avatar from me, it still feels like I'm being fake by taking ideas from other people somehow. After all, if I want to take the Morph Ball, why not take the entire Power Suit or Samus herself? Why not just take a whole game and call it my own?

Take a person, make them real, and give myself a partner while overriding free will. Yes... that's it. That is a really nasty feeling that makes me want to laugh like an evil genius from my throne atop the world. Enslave someone and make them do my bidding, because I am the all powerful god of the world that I make and who would stop me from taking what's already mine? There's no way to stop me and everyone already agrees with what I'm doing because the only person that matters here is me. BWAHAHAHAHAHAHAHAHAHAHAHAHAHA

Mix that feeling with the incessant need for answers and a wistful longing for the amount of time I've spent alone and that explains everything. Too much lost time, too little free will, and too many things that I can't make on my own.

"Who is mDiyo's partner?" is the wrong question. The character is an abstract of a real person, and the character itself is not a "who", it's a "what". Let's rephrase the question: "What is mDiyo's partner?"

I've been multiple different people over my lifespan. Trying to resolve the utter garbage life that I've had into something useful and interesting has been what I've been trying to do most of my life. mDiyo was the third incarnation of myself, the one that stuck around when I finally started making the first thing in my life that was worthwhile. Who would have thought that the rapid changing of names, personality fragments, and ideas would settle on a gardevoir with a pickaxe that taught itself how to code?

Let's give mDiyo the rest of my past life. All the pieces, all the fragments, all the bits and weirdness that came with it. If mDiyo deserves a partner at all, then he will have everything that I thought I discarded, brought back together, and reclaimed.

That should answer the question well enough.

Sunday, September 5, 2021

The Fantastic Human

Games used to be simple. Score a certain number of points, use a variety of tricks to get those points, and all of your natural ability can shine through. This is still how sports works, and most board games can be boiled down to a few pieces, a few rules, and a wonderful social experience with your friends.

Video Games are a bit different. Computers have grown so powerful that they can hold a myriad of information that people would have a huge problem with. They're wonderful tools that can do things that we are really bad at, like storing the entire calculated length of pi. If you can put a number to an idea, a computer can store - and copy - the idea billions of times.

Most video games are still stuck on the same ideas that any analogue game would handle. We can do better than that... and by we, I mean myself and the computer working in concert. Let's make a human in a fantastic setting from the ground up.

A couple terms we'll need before moving forward:

Human: A digital approximation of the real world experience that our fleshy meatsuits are having.
- Most video games do this so badly that we can replace every human with a stick.

Invariant: A function, quantity, or property which remains unchanged when a specified transformation is applied.
- On a design level, this is a fundamental statement that is always the same. Sometimes it's arbitrary, more often it's because we need a foundational idea and/or restriction to build on.

With that out of the way, here's a human.


This guy has all of the traits that platforming characters have. Well defined graphics, awesome physics, a hitbox tied to a health pool, and it spontaneously explodes when you get to zero health. Perfect, done, ship it.

Something's wrong. I can feel it all the way deep into the back of my head. It's design sense - that feeling that you get when there's a perfect walkway and someone just happened to 'misplace' a brick because "only god is perfect". Some people call this OCD, but the feeling you're getting is cringe and out-of-order, not obsession.

The part that's wrong is obvious: A stick can't be a human no matter what you do. Unlike most video game characters this human violates the most basic principle of humans. Even if it walks like a human, speaks flawless English, and has an internal simulation that can spray blood everywhere, it still looks like a stick.

Instead of a random inanimate object that could be anything, let's make something real. How about my own avatar?

This human is highly stylized. it has eyes, legs, hands, and wears clothes. It's not quite what we would imagine as a human, but that's not the goal here. We're trying to build something close enough to a human that it can't be confused with the stick.

The avatar is drawn like this because it's part of an animation framework that lets each piece be rotated, stretched, and manipulated independently. I did this for stylistic reasons to begin with, but the idea lends itself towards the cornerstone of this design.

Invariant 1: Humans can be divided into zones called Body Parts

Let's set up a few basic rules on top of this:
- Humans have six zones: left leg, right leg, left arm, right arm, head, torso
- Each part has its own pool of hit points
- The human is killed or otherwise incapacitated when their torso runs out of hit points.


This gives us a lot of fine-grained control over a standard health pool. A standard video game hero will run around smacking everything until everything explodes into a puff of smoke, or they do the same. With this setup, we can damage just the legs or arms.

An absolutely hilarious thing that happens in a lot of video games is that you can run out a character's hit points by throwing tiny pebbles at their big toe over and over until they collapse. This chip damage is supposed to build up over time and break the character's body. Any fighting game worth its salt will give the character a block that reduces knockback, but may still incur chip damage.


If our character were to block continuously with a shield, then the damage they would incur would be absorbed into their arm. Chip damage that would normally wipe out the character instead breaks their arm.

Any game that has equipment either picks an arm for a shield, or has the hilarious effect of equipping two shields for no good reason. No game that I have seen would ever have a two-handed shield. Here though? We could hold the shield in both hands and have twice as much health to go through before our critical torso is exposed.

Locational damage in most games boils down to a critical hit system. Shooting someone in the head grants double damage or shooting them in an exposed arm bypasses any armor stats. Damage that hits a zone tied to behavior takes that idea and turns it into a risk-assessment problem. For example: "Knee-high acid is dangerous because it burns my character's legs until they can't run anymore. I need to carry a grappling hook in case I have to get out of the acid or my heart will get hurt."

Bats swoop down on your head, trying to knock you unconscious. Loss of control, lying prone, and having your torso exposed is a massive problem. It means almost certain death. A savvy player will put extra protection on their head, and a skilled player will use the character's blocking ability to hit their arms instead of the head.

Enemies that constantly target your legs from both sides are dangerous because you can limp around on one leg, but two broken legs mean you're not going anywhere. Backstabbing enemies are nasty not because they do extra damage, but because they bypass your guard and go directly for the heart.

The main advantage this gives the design is a sort of gradient between one hit point and zero hit points. A character with a broken arm will be unable to fight, but a character with a broken skull may as well be dead if they're adventuring by themselves.

"Congratulations! Your Stick has evolved into Stick Figure!"

 

We've moved from a stick to a stickman. Let's put some flesh on those bones.

Magic systems are ubiquitous throughout gaming. The systems are usually simple: cast your fancy magic attacks from a pool of blue mana until you're depleted. Some games will throw in an extra stat like stamina or technique points, and a few will let you use hit points directly.

The mDiyo character wants to cast magic from 'life essence'. Most media is nebulous about this. Is it your spirit? Lifespan? Are you overweight most of the time because the best spells require your fat reserves?

Invariant 2: Each body part has four fantastic resource pools.

Some of our more fantastic spellcasters will realize that these pools represent the four elements: earth, air, fire, and water. Others will think they're talking about the fundamental essences of breath, spark, form, and life. mDiyo sees these and doesn't care; he want to cast magic from his life essence, his body, or wherever the heck it comes from.

Let's break down what each of these resource pools actually do.

Red is meat. These are the physical characteristics associated with a body part, or the amount of damage that it can take. Meat is directly tied to your health pool and having red energy is what causes their hit points to regenerate. Maximum red energy is the same as maximum health points, so more is always better.

Yellow is the stand-in resource for a hunger system. Most games merely have a meter that depletes over time, but Mabinogi takes this a step further and gives a lot of physical attacks a stamina requirement. Getting hungry makes the maximum amount of stamina you have deplete over time, and eating food will regain both some of the stamina resource and its maximum. Stamina regenerates slowly, and can be helped along by resting. Sleeping should set it to maximum - as long as you eat, of course.

Blue is breath, and its physical counterpart is oxygen. In any breathable space this should regenerate fairly quickly. Using blue energy as a resource for casting spells should allow for a lot of low-power, repeatable spells. Think something like an energy shot from an arm cannon or an aura that requires breathing techniques to function.

Green is the stand-in resource for what most games call 'mana'. Its physical counterpart should be hormones like adrenaline, or less tangible ideas such as prana, chi, midichlorians, or magicules. It can also be a measure of how awake the player is; running out of spirit means you get tired, grumpy, and stressed. 

We can even compare green to chakras. Let's call it a physical manifestation of a divine energy unit and can use that to manifest the most fantastic ideas. Enhanced speed, superhuman punches, casting fireballs, or using Pokemon attacks are derived from this resource.

Most games have mana as blue. Most games also have their oxygen meter as blue or white. Almost no game has the two mechanics working together, and I would be very surprised if any of them would try to combine "cast magic from oxygen" and "I am hungry".

That just leaves one question: Why separate these resources into separate body parts? We don't have to, but having them does open up the design space for some interesting interactions.

Let's say that mDiyo wants to take a trip underwater. His lungs are stored in the chest, so normally he'd be able to spend about a minute underwater. Recently he visited a witch that taught him a special technique called 'deep breathing' to pull more breath out of his body and into his lungs. This technique can be performed as many time as he has body parts, so when the time expires he performs the technique and moves blue resource from his head into his lungs. Now he can spend two minutes underwater. Or six. Depends on how many times it's used.

"Congratulations! Your Stick Figure has evolved into Meat Golem!"


My design sense is still tingling. The mDiyo character may have some physical aspects that represent a body, but it's still lacking something... this version of the character isn't much better than an automaton or a meat golem. We need one more layer to make this design truly shine.

Invariant 3: Each body part has a set of attributes that can be manipulated via growth or status effects

This is the point where we start losing people. You can only keep so much information in your head at a time, and most people don't think on more than one level at once, so for the sake of keeping things manageable this needs to be consistent all the way through the design. The computer can keep track of everything; players will keep track of the effects, and maybe some of the numbers if they're into the metagame.

For consistency's sake, we'll give every body part exactly the same set of attributes. Let's also both arms into one class, so we don't need to worry too much about a missing left hand in our calculations. The same applies to legs. Let's also say that legs generally affect how a character moves, arms affect how a character interacts, head affects everything active that is neither of those, and the torso, heart, or body affects concepts that are innate to a character.

Each invariant has a set of rules built on top of it. Here's mine:

Strength (Red)
- Head: Intelligence
- Arms: Dexterity
- Legs: Jump Height
- Body: Carry Weight

Speed (Yellow)
- Head: Time Awareness
- Arms: Attack Rate
- Legs: Run Speed
- Body: Resource pool regeneration

Affinity (Blue)
- Head: Spellcasting
- Hand: Tools
- Legs: Movement Adaptations, Vehicles
- Body: Armor

Potential (Green)
- Head: Social Interaction, Fate
- Hands: Mysticality, Luck
- Legs: Athletics, Dancing
- Body: Physical Enhancement, Chi


One of the goals in this design is to try and take familiar game concepts, and re-mix them in a way that creates an extensible system to layer on other things. The design should be flexible enough that we can drop it in any game and robust enough that it stands up to the harshest scrutiny and the most obtuse system imaginable. Anything that can stand up to the utter design mess that is all of gaming will have an usual layout full of familiar ideas that end up in odd places. My particular focus is on some sort of RPG-esque metroidvania, so it runs the full gamut of ideas.

Each one of the pools has a particular concept tied to it. Most people wouldn't think about mixing intelligence with carry weight, and good luck trying to define what mysticality is. Let's go through each of these in turn before we try manipulating them.

Strength: A measure of the body's ability to push things around or otherwise manipulate the world around you. Raw strength itself can be measured as a stat. In specific body parts, it's a measure of how much force can be put into a task. High dexterity measures the speed and precision of handiwork, and is often associated with archery. A person with high intelligence will be able to connect patterns and recall information to solve a problem a lot easier than someone with low intelligence. The others are self-explanatory.

Speed: A measure of the body's ability to do things quickly. Some games will separate how fast a player can move and how fast they can attack; we can put these into the legs and hands respectively. The body itself has natural processes going on all the time, and generally tries to replenish its pools of fantastic resources as fast as it can. Anything that would affect regeneration should target the body's speed stat directly.

The odd one here is time awareness. How does that fit into speed? Well, if you've played a game where time manipulation is a mechanic at all, then I would say that someone is manipulating the person's head to move faster than the surrounding area. This carries over into all aspects, moving the player 'faster' while everything around them slows down, or even stops.

Affinity: A measure of the character's ability to understand something. This can happen through training, natural gifts, or experience. Anyone wandering around and leveling up is increasing their affinity stat, and all of the associated increases boost how well their natural strength works with tools or their natural intelligence works with spellcasting.

Potential: A measure of the character's limits in a category, both ceiling and floor. These are softer skills and more nebulous ideas. They may have varied effects that have little bearing on how the character actually does things, like luck changing the world around them or being able to manipulate fate directly.

The only way for a character to go beyond their limits is to increase their potential. A character with no limits has effectively unlimited potential.

Attributes are all well and good for calculating statistics, but we can do one better. Let's manipulate them. I cast Haste!

This is the fun part. Status effects need to target a body part to have any effect. Casting haste on a player's legs will let them run faster, while targeting their hands will have them stabbing things at lightning speeds. Targeting the body will accellerate natural processes, making the player regenerate health quicker at the expense of getting hungry faster. Hasting their head will increase their perception of time, slowing everything down around them.

A character on a long excursion may want to slow down their body processes. A monk of sufficient training may slow down their body to a stunning degree and have increased their regeneration to get back to 'normal'. Putting a character in stasis can cause all of their

The design broadens the Haste spell into a single idea. We target a resource and a body part, then decide whether we want to increase or decrease it. Give it a name, spread it around a bit, and we have some basic status effects.

Boost/Break: Targets strength
Haste/Slow: Targets speed
Enhance/Erode: Targets affinity
Shine/Dull: Targets potential

Status effects in other games tend to have the same problem as one hitpoint explosions do. The character is affected for a certain amount of time, something nasty happens, and it's at full potency the entire time you're afflicted. This is a relic of turn-based RPGs where everything is bunch of numbers on a spreadsheet with pretty animations. These ideas transfer poorly into games like platformers, with the exception of damage-over-time mechanics.

If we can target specific body parts, and body parts are associated with behaviors, then our effects can affect the behaviors instead of the stats. Doing something in real time has a very different effect from a turn-based game, so we need to be careful with this. The overall goal is still to make a human, after all.

Let's throw mDiyo off a cliff. BWAHAHAHAHAHA, er, this is bad. We could have his legs take a lot of damage for doing something like that, and if he falls far enough that's appropriate. If he falls three meters there's a good chance he'll be bruised a bit, the jolt will send shockwaves through his body, and he'll have to walk off the effects... but walk off he will. Instead of doing a bunch of damage to him, let's paralyze him for a few seconds instead.

Paralysis:
Stun (Can't move at all) -> Addle (Confused movements) -> Slow (50% move speed) -> Recovery (75% move speed) -> Not Afflicted

This is a layered status effect. Each one of them has a timer and an expiration. The most potent level stops the entire character from working, effectively leaving your character completely vulnerable to whatever comes along. Falling off of a cliff does have its downsides, after all.

The second layer is movements that make no sense. If mDiyo fell on his butt, then he can probably get up during this time period, but good luck doing much else with your legs. Attacking or using your noggin' should be fine though.

The third and fourth layers are movement speed reductions. These are the points where you 'walk it off'. Each of these effects can take progressively more time. Stun might only last a second, addle a couple more, but the slow and recovery could be an agonizing 5 seconds and 10 seconds overall time.

This whole setup is a punishment to the player for not being good enough at covering their mistakes. It's visceral: You can feel deep in your guts that you've made a mistake by jumping off a cliff. The landing was botched, recovery was poor, there was no double jump, and now you get to suffer the consequences. It's also not so punishing that you could spontaneously explode into meaty chunks. Worst case scenario: your character fell so far that both of their legs are broken and now you get to sit there and regenerate, drink a potion, or the game designer was particularly evil and put spiders at the bottom of a ravine.

 

"Congratulations! Your Meat Golem has evolved into Fantastic Human!"

 

This system should encourage players to experiment with the character while still bringing the consequences of being a human into the mix. It's a bit hard to keep track of everything, but if we keep things consistent then players can pick it up easily enough. Most importantly, this design should go a long way towards making a character feel like they're more than a stick.

Combining all of the rules together, we have this set of rules:
- Humans have six zones known as body parts: left leg, right leg, left arm, right arm, head, torso.
- Each part has its own resource pool with a physical aspect and a resource counterpart. These pools are hit points (regeneration), oxygen (breath), hunger (stamina), and vital spirit (mana).
- Each part is tied to a set of behaviors that define a human. Legs for running, arms for attacking, head for seeing and interaction, body for passive effects
- Behaviors are measured with the attributes strength, speed, affinity, and potential. Changes to these behaviors are called Status Effects
- Each body part keeps track of its own status and can be manipulated independently
- The human is killed or otherwise incapacitated when their torso runs out of hit points.


Whenever you have an idea like this, you need to have an entire game built up around it. As of right now I have very little. Writing this post has brought a lot of the ideas I've been thinking about together into one place and now I need to get it into this:

An idea is only the start of something. Like Sivers says, ideas are just a multiplier on execution. You need multiple ideas all working on concert to get things rolling, and getting multiple layers of ideas to work in concert is something else entirely. It's a good thing I have very little to do or I would despair at the difficulty of this task.

If there's one thing I am good at, it's layered design. Now I just need to get this to work.

Friday, September 3, 2021

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.

Thursday, July 15, 2021

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.

Wednesday, July 14, 2021

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.

Monday, May 17, 2021

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.

Self Reflection, Avatar Reflection

It started as a joke. One day I decided that my game development was going poorly because I was too attached to my characters. If I messed a...