A while back, I designed a very silly combat video game for three players which involved pools and water guns and trying to keep your balance on a float. I may actually implement it later, because it's an easy game to implement and would show off the avatar creation system I'm using - launch a tool with a sample project, basically.
The rules of the game are too stupid to go into detail about here, but in essence your techniques are limited depending on whether you're on your home float or not. If you're on your home float, you can use your hands or your foam pipe. If you're not, you can only use the foam pipe. So jumping to another player's float means you'll take them on with a disadvantage.
Most combat games are weighted in favor of offense or defense. Most one-on-one fighters such as Street Fighter try to avoid that, but most team-on-team or melee fighters are heavily weighted one way or the other. For example, in many sports it's illegal for an attacker to bump into a defender, giving an advantage to the defender. In a typical army game, creating barricades and hunkering down is typically a huge advantage when compared to charging into those barricades. In Disgaea, the upper tier combat is entirely about first strike victories, and the attackers have a massive advantage.
I think these asymmetries are really interesting, but they are most interesting when they cause a continual back-and-forth between offense and defense, and also more interesting when they are organic, generating more complexity than they contain.
For example, kabaddi is an unusual ball sport where you have to hold your breath while on the opponent's side of the field. This fills both of my criteria for interesting asymmetry.
It doesn't say "you need to give the ball to the other team after 15 seconds". Instead, it simply destroys you when you go on the offense. The longer your offensive drive, the most oxygen-deprived you become, and that takes some time to recover from even when you return to your side. There's no iron rule locking you into taking turns - instead, it allows you to weight your actions with an eye towards the longer-term consequences.
The rule also opens up a new area of specialization. You might be fast, or a good thrower, or a good catcher - or, in kabaddi, you might have excellent lung capacity. Every facet of skill that a player can have is one more way for a player to shine and for a team to be colorful together. "Doug is our primary striker, but it's Chad's role to spend most of his time lounging about in the enemy base trying to foul up their defense..."
Compare this to baseball. The rules of baseball are like iron bars, each made specifically to lock the player into a specific kind of performance. Rather than having complex tradeoffs and incentives, the sport is structured specifically to make teams go head to head with a very specific pattern. If someone does something that is within the rules but isn't part of the intended ritual, precise rules are laid out to force them to perform the ritual properly. For example, there are dozens of rules about how a pitcher can pitch. Must be within this precise rectangle. Must have these characteristics. Must be caught properly. Must be a ball in perfect condition. Must be... and so on.
This is the difference between a "restrictive" rule and a "facilitating" rule. Fundamentally, a rule prohibits or enforces a particular behavior, so in both cases something is being required or outlawed. However, a restrictive rule exists to reduce the complexity of the topology of the game, while facilitating rules increase the complexity of the topology. That is, restrictive rules give the players as a whole fewer options and paths, which facilitating rules give them more options and paths.
Holding your breath is a facilitating rule. It does require you to do something - hold your breath - but in turn it creates a whole bevy of complex behaviors that players can be good or bad at, all of which also affect their core performance at other facilitating rules (such as how you can throw the ball, how you can score, etc).
Requiring the pitcher to throw within a particular rectangle is a restrictive rule that exists solely so that the batter can continue to use the specific skill of batting. It doesn't open up new topologies, it carefully builds walls so that you can't go to those new topologies.
... Those new topologies of hitting people in the face with an 80 mph hunk of rubber.
Obviously, restrictive rules aren't bad. They're just not as interesting. I like facilitative rules.
So let me think of some.
The most common and fundamental facilitative rule is having a single ball. The act of controlling a single ball makes a game fundamentally weighted in favor of whoever is holding the ball. Additional rules about how the ball can be moved around can facilitate more complex play - such as the dribbling rules in basketball, or the no-hands rules in soccer.
But I like the idea that the ball is actually a dangerous thing. For example, in most modern capture-the-flag matches in FPS games, the flag makes you move slower, or limits your weapon use. Yes, you need it to score, but it doesn't give you the advantage. The game is weighted in favor of defense.
Well, you could pull a kabaddi. What if you weren't allowed to breath while you were holding the ball? Prioritizes passing the ball, interceptions, and so on.
What if there are specific limits on where you can go? For example, something like water polo. Except whoever has the ball has to stay submerged. Or stay outside of the pool, or something. I'm stuck on the whole "pool games" thing.
You can even make it so that the ball isn't a scoring device. For example, the game takes place in an unstable, shrinking island at the center of a pool. If all members of a team are in the water, that team is defeated. However, you can climb out of the water as long as you have the small handball. So if your team members fall into the water, you should toss them the ball, help them climb up, toss the ball to the next person, and so on...
I also like the whole "double ball" category of games, where there are two balls in play. There are a ton of options here. One option I like is having two balls in two colors to match two teams in two colors, and then change up the rules based on which ball is which.
For example, you have to hold your breath if you have either ball... but you can only score points with your own color. So there's a lot of game around whether you can keep your enemy's ball away from his team through repeatedly holding your breath and passing a ball around that is useless to you. Maybe you can focus your efforts by having one person hold both balls for a little while, allowing everyone else breath...
If you don't like the "breath holding" mechanics I'm stuck on today, you could also just use a time limit.
Anyway, it's fun to think of new mechanics. This gets much more open when you start to consider video game mechanics rather than human mechanics. For example, everyone can double jump or fly except for the guy holding the ball. Everyone can summon monsters except the guy with the ball. The ball is the source of energy, recharging all your robotic allies if they are nearby, regardless of who is holding it...
Tuesday, April 30, 2013
Monday, April 29, 2013
Avatar Creation Tool: POOFY SLEEVES TIME
TECHNICAL POST
I've made a lot of progress on the avatar creation tool, after two weeks wasted. Right now, you can paint clothes in multiple layers, and then rearrange the layers, move them to different avatars, and so on.
For example, you could paint a shirt. Then you could paint chainmail. The mail would be a specular rather than diffuse material, it'd be bumpmapped properly, and the shirt would show through the holes. You could then switch the order, putting the shirt on over the chainmail. The shirt (assuming it was 100% opacity) would obscure the mail, but the mail's heightmap would make the shirt bumpy in a muted version of the mail's bumps.
Also, you can paint on wrinkles and thickness, and you can paint skin as well if you want tattoos or warts or whatever.
This actually works really well. I am very happy with it. But this is all texture/bumpmap stuff. Meaning that your arm will always be shaped like your arm. This is fine for tight sleeves, but if you have poofy sleeves at all, you'll need to actually modify the mesh.
Originally, the plan was that I would create modified versions of the mesh, and you could just select which one you wanted to use. Your shirt is based on the short sleeve mesh variant, or the poofy sleeve mesh variant, or whatever. It'd be a lot of work, not just because I would need to create a ton of variants, but because every variant would have to be mapped to the half dozen body shape keys/morph targets so that each would look correct on beefy people, fat people, and so on.
But... the success of this in-unity clothes generation means I'm rethinking that. Is there a way to allow the users to create their own mesh?
Sure!
First off, it's easy to actually modify or create meshes. The hard part is determining what to create, how. And UV mapping it.
Let's say that you're building the top half of a Disney princess dress - floofy and pastel. You want the shoulders to floof: right now, they're just that frosting-colored blue painted right on the skin, like a tight shirt. So you switch from texture paint mode to mesh edit mode.
You mouseover the shoulder and scroll-wheel up. The shoulders inflate along their normal. Perfect. Your shoulders are floofy.
That part is easy. It's just another morph target. Morph targets are stored as "Vertex N offset by XYZ", and that's literally what you're doing. Except we would store it in a 4D Vertex, where W would be the normal. By allowing it to be offset by the normal instead of (or as well as) XYZ coordinates, we allow for bodies that are different shapes. This probably isn't a big deal with shoulders, since most people's shoulders are roughly the same shape, but it really matters when you're trying to do armor on a fat guy.
Oh, is it not flounced quite right? Click and drag to move the vertices around with a grab brush. Again, very easy. Now the morph target is offset by a multiple of the normal and a certain XYZ value. Mousewheel down to pull the point inward...
You can use this trick to do mesh digging as well as floofing. Let's say you want to make someone with a robot arm, so you want the arm to have actual indents along metallic tracks. You paint the metal tracks, then you mousewheel down to pull the vertices in along their normal, digging into the mesh.
This stuff is the cake. The hard part starts now:
You want a sleeve. That is, you want a short sleeve that stands slightly away from the arm and the arm is within it. You don't want to simply modify the arm's size. You want to create more mesh around the arm.
Let's start with the UI. It's the same. The user mousewheels up on the sleeve. The algorithm detects the edge of the clothing you've painted, and says "okay, this texture ends between this vertex and the next vertex on the triangle. So I can't just move this vertex, that would affect a region not covered by the texture. I have to tear it."
So it clones the vertex, lifts it along the normal of its parent vertex, and creates tris trying it back to its parent mesh on the shoulder side while leaving it detached on the elbow side. A sleeve. It's got the same bone weights and tracks fine.
Mousewheel down, it retracts towards the parent until it merges and vanishes.
Want your poofy edge to have a poofy shoulder? Mousewheel up on the shoulder. This is all connected space, so it doesn't detach from the parent model. Only the edge points detach, meaning that your model only gains a few vertices instead of cloning vast amounts. Depending on the quality of the model, this may actually go in a few vertices: the point is that the sleeve gives the indication that there is an arm up it, so the detached portion does have to have a certain depth.
Collars or unbuttoned fronts or whatever all have the same method, except that with collars you'd want to drag the new vertices down and out so that they fold over properly. That may actually require a special function, since otherwise they might be attached to the neck bone rather than the chest bone. Still, it's not that bad - a "reparent to closest vertex" would do.
If you did want to create something that is an entirely separate layer, that'd be a slightly different system built on the same principle: instead of editing the base mesh, you'd create a clone of the base mesh containing only the vertices that are covered by the texture, then edit that.
In both cases, these vertices can be stored in the exact same WXYZ from N framework that we used for offsetting parent vertices. Except, instead of moving the parent vertex, they clone it.
However - this is the rough part. They can't clone the UV map location of the parent. Instead, they have to create a new UV map position for their tris, and cut the pixels that were on their parents' UV map, pasting them to their own. This is required because otherwise the arm inside the sleeve would be the same color as the sleeve.
I'm actually... not sure about how to do that. I know there's a way to do it, but I've never tried it out. It may be annoyingly complex. But it's an absolute necessity.
...
Okay, we've discussed sleeves and collars and entirely distinct layers... but what if we want a topology that isn't simply an offset version of the parent?
The obvious example is skirts. What if we want a skirt?
When you mouse up along the inside of the leg, you'll quickly cross over the X axis. If you're in "merge mode", those vertices would impact and merge, causing their triangles to also merge (and average their bone weights). If any vertex only has triangles which are entirely along 0 X, it self-destructs, "hollowing" the skirt out. (Otherwise you would have extremely loose shorts).
This is not so hard, although it has one big downside: the skirt would end up with a very low poly count horizontally. Because of that, we may need an algorithm to add "stripes" to the skirt. This'd be easy if the skirt was just a standalone mesh: we could just do loop cuts. But since it's often going to be integrated into the overall mesh, we need to come up with a method of creating vertical cuts that don't screw up the topology near the waist. that's going to be some work, but it's not nightmarish, just annoying. Alternately, I could just make the legs themselves have a high poly count so that skirts wouldn't suffer.
...
IT ALL SEEMS FEASIBLE LET'S DO IT.
I've made a lot of progress on the avatar creation tool, after two weeks wasted. Right now, you can paint clothes in multiple layers, and then rearrange the layers, move them to different avatars, and so on.
For example, you could paint a shirt. Then you could paint chainmail. The mail would be a specular rather than diffuse material, it'd be bumpmapped properly, and the shirt would show through the holes. You could then switch the order, putting the shirt on over the chainmail. The shirt (assuming it was 100% opacity) would obscure the mail, but the mail's heightmap would make the shirt bumpy in a muted version of the mail's bumps.
Also, you can paint on wrinkles and thickness, and you can paint skin as well if you want tattoos or warts or whatever.
This actually works really well. I am very happy with it. But this is all texture/bumpmap stuff. Meaning that your arm will always be shaped like your arm. This is fine for tight sleeves, but if you have poofy sleeves at all, you'll need to actually modify the mesh.
Originally, the plan was that I would create modified versions of the mesh, and you could just select which one you wanted to use. Your shirt is based on the short sleeve mesh variant, or the poofy sleeve mesh variant, or whatever. It'd be a lot of work, not just because I would need to create a ton of variants, but because every variant would have to be mapped to the half dozen body shape keys/morph targets so that each would look correct on beefy people, fat people, and so on.
But... the success of this in-unity clothes generation means I'm rethinking that. Is there a way to allow the users to create their own mesh?
Sure!
First off, it's easy to actually modify or create meshes. The hard part is determining what to create, how. And UV mapping it.
Let's say that you're building the top half of a Disney princess dress - floofy and pastel. You want the shoulders to floof: right now, they're just that frosting-colored blue painted right on the skin, like a tight shirt. So you switch from texture paint mode to mesh edit mode.
You mouseover the shoulder and scroll-wheel up. The shoulders inflate along their normal. Perfect. Your shoulders are floofy.
That part is easy. It's just another morph target. Morph targets are stored as "Vertex N offset by XYZ", and that's literally what you're doing. Except we would store it in a 4D Vertex, where W would be the normal. By allowing it to be offset by the normal instead of (or as well as) XYZ coordinates, we allow for bodies that are different shapes. This probably isn't a big deal with shoulders, since most people's shoulders are roughly the same shape, but it really matters when you're trying to do armor on a fat guy.
Oh, is it not flounced quite right? Click and drag to move the vertices around with a grab brush. Again, very easy. Now the morph target is offset by a multiple of the normal and a certain XYZ value. Mousewheel down to pull the point inward...
You can use this trick to do mesh digging as well as floofing. Let's say you want to make someone with a robot arm, so you want the arm to have actual indents along metallic tracks. You paint the metal tracks, then you mousewheel down to pull the vertices in along their normal, digging into the mesh.
This stuff is the cake. The hard part starts now:
You want a sleeve. That is, you want a short sleeve that stands slightly away from the arm and the arm is within it. You don't want to simply modify the arm's size. You want to create more mesh around the arm.
Let's start with the UI. It's the same. The user mousewheels up on the sleeve. The algorithm detects the edge of the clothing you've painted, and says "okay, this texture ends between this vertex and the next vertex on the triangle. So I can't just move this vertex, that would affect a region not covered by the texture. I have to tear it."
So it clones the vertex, lifts it along the normal of its parent vertex, and creates tris trying it back to its parent mesh on the shoulder side while leaving it detached on the elbow side. A sleeve. It's got the same bone weights and tracks fine.
Mousewheel down, it retracts towards the parent until it merges and vanishes.
Want your poofy edge to have a poofy shoulder? Mousewheel up on the shoulder. This is all connected space, so it doesn't detach from the parent model. Only the edge points detach, meaning that your model only gains a few vertices instead of cloning vast amounts. Depending on the quality of the model, this may actually go in a few vertices: the point is that the sleeve gives the indication that there is an arm up it, so the detached portion does have to have a certain depth.
Collars or unbuttoned fronts or whatever all have the same method, except that with collars you'd want to drag the new vertices down and out so that they fold over properly. That may actually require a special function, since otherwise they might be attached to the neck bone rather than the chest bone. Still, it's not that bad - a "reparent to closest vertex" would do.
If you did want to create something that is an entirely separate layer, that'd be a slightly different system built on the same principle: instead of editing the base mesh, you'd create a clone of the base mesh containing only the vertices that are covered by the texture, then edit that.
In both cases, these vertices can be stored in the exact same WXYZ from N framework that we used for offsetting parent vertices. Except, instead of moving the parent vertex, they clone it.
However - this is the rough part. They can't clone the UV map location of the parent. Instead, they have to create a new UV map position for their tris, and cut the pixels that were on their parents' UV map, pasting them to their own. This is required because otherwise the arm inside the sleeve would be the same color as the sleeve.
I'm actually... not sure about how to do that. I know there's a way to do it, but I've never tried it out. It may be annoyingly complex. But it's an absolute necessity.
...
Okay, we've discussed sleeves and collars and entirely distinct layers... but what if we want a topology that isn't simply an offset version of the parent?
The obvious example is skirts. What if we want a skirt?
When you mouse up along the inside of the leg, you'll quickly cross over the X axis. If you're in "merge mode", those vertices would impact and merge, causing their triangles to also merge (and average their bone weights). If any vertex only has triangles which are entirely along 0 X, it self-destructs, "hollowing" the skirt out. (Otherwise you would have extremely loose shorts).
This is not so hard, although it has one big downside: the skirt would end up with a very low poly count horizontally. Because of that, we may need an algorithm to add "stripes" to the skirt. This'd be easy if the skirt was just a standalone mesh: we could just do loop cuts. But since it's often going to be integrated into the overall mesh, we need to come up with a method of creating vertical cuts that don't screw up the topology near the waist. that's going to be some work, but it's not nightmarish, just annoying. Alternately, I could just make the legs themselves have a high poly count so that skirts wouldn't suffer.
...
IT ALL SEEMS FEASIBLE LET'S DO IT.
Friday, April 26, 2013
Survival horror isn't about disempowerment
There's an extremely common thought among game designers that survival horror games are based on disempowerment. I really don't know how this got to be a common theory, because it's wrong. It's wrong in the same way that "the sun rises" is wrong.
Balloons rise. Smoke rises. The sun does not do that. The sun only appears to rise because of our perspective.
The disempowerment thing is the same. It only appears to be founded on disempowerment because we're looking at it from the eyes of the player, and that's what it appears to be from that perspective.
But it's not.
Survival horror is, in the very first word, about survival. The primary challenge of the game is going to be about surviving, not about winning or shooting accurately or gaining levels. It's a different focus, although often not a very tight focus.
In order to make the game about survival, "disempowerment" is required. More accurately, "game balance that makes the challenge of surviving actually challenging" is required.
Thinking of it as disempowerment is probably not accurate, because disempowerment implies some kind of absolute norm of power that you're undercutting. That's not really accurate: it's just game balancing, and surviving has more subdued encounters. Typically, attrition is a much more powerful and effective tool to make survival feel like survival. Even that, however, is not the core of survival horror.
For example, the scariest games I ever played were System Shock II and Silent Debuggers.
System Shock II didn't have disempowerment as it is commonly defined. However, it did have the long, grinding road of attrition. Similarly, in Silent Debuggers it was rare that any given enemy would threaten you, but trying to hunt them all down before they blew apart critical ship resources was a terrifying ordeal. Especially since every level you advanced left destroyed resources destroyed. Again, attrition. But attrition is just a survival mechanic, not a horror mechanic.
Neither attrition nor disempowerment make a game horrifying. Neither do any competing ideas, such as limited information, excessive travel dangers, safe-and-dangerous zoning, and so on.
There's loads and loads of games that use these things and aren't horrifying. For example, Chess. Cooperative board games. Solitaire.
If you really aren't convinced, think about all the times you had an enforced stealth mission. Was it horrifying when Link had to escape prison again? Was it horrifying when Sam Fischer wasn't allowed to shoot anyone this mission? Similarly, what about when you're deprived of weapons and have to push through the beginning of the third act with your weakest weapon. Those are all disempowerment scenarios. Horrifying?
No! It could be heart-pounding, but that's absolutely unrelated. Football is heart-pounding.
To be blunt, the core of survival horror is the horror part. There's not really many non-survival but-still-horror games on the market, so the two words have become wedded in our mind. Survivalhorror.
The feel of the game owes a lot more to the horror half of that, even though we've been giving the survival half all the credit. Having a tense moment does make it easier to convince you that things are horrifying. But that's more like having a crack to shine the light of horror through, rather than it being the light of horror itself.
What is "horrifying"?
I would say it's seeing people hurt. Broken people. Suffering.
Yeah, that easy.
See, in video games, most of the mobs we face aren't "people". They may be shaped like people, they may even have faces, but we're taught to dehumanize them. They don't have any real human characteristics.
But in a horror game, we give those human characteristics back to the enemies. The enemies are recognizably individuals that have suffered and been driven far past sanity. Bloody nurses, baby-headed spiders, butchers with their faces torn off...
Of course, it's best to take it further. Not only have the enemies been given human characteristics, but the NPCs and often the avatar have been given human characteristics as well.
The avatar is the most common: terror by direct proxy. We put the avatar in a situation that would make him scared, and the player therefore feels his fear. This is the "survival" part. So if you want to talk about survival horror's "disempowerment", this is what you're doing. This one piece. You're building a situation where the avatar should feel scared.
But let's not overlook the NPCs. It's an extremely common and very powerful tool to build up the NPCs as humans before killing them or turning them into monsters. Sometimes it's very quick and easy - a few lines of dialog and then they are eaten by a monster. They are chased down a corridor while you can't follow. You find them dead, with their last email still on their PDA. Whatever. You understand that they were people who suffered.
Sometimes games take it a lot further, a lot more effectively. System Shock 2 is pretty much the reigning king of this even now, with the classic build up and staged reveal of SHODAN. It's actually legitimately horrifying. And the scariest parts of the game are when SHODAN acts more human. Those are the horrifying parts of Portal, as well. You can connect with the enemies as humans all the sudden, which means that they aren't faceless monsters: they're completely broken humans. Horrifying.
The most effective horror methods are those that let us feel the fear and pain of those in the situation. As an example, if a little girl is killed, you'll probably be horrified. But if her family survives it, and you hear their wailing grief... that'll turn it up a lot. This is one reason why horror games tend to torture rather than kill: the expression of pain is horrifying, a very clear way to communicate suffering.
Survival horror. Survival, sure, the survival part. You can argue it's disempowerment. I would argue that it's simply making the challenge of the game "survival" rather than whatever other default you would go for.
It's the "horror" part that matters, though. And that's just seeing suffering, seeing broken humans. Understanding that people hurt.
At least, that's what horrifies me.
Balloons rise. Smoke rises. The sun does not do that. The sun only appears to rise because of our perspective.
The disempowerment thing is the same. It only appears to be founded on disempowerment because we're looking at it from the eyes of the player, and that's what it appears to be from that perspective.
But it's not.
Survival horror is, in the very first word, about survival. The primary challenge of the game is going to be about surviving, not about winning or shooting accurately or gaining levels. It's a different focus, although often not a very tight focus.
In order to make the game about survival, "disempowerment" is required. More accurately, "game balance that makes the challenge of surviving actually challenging" is required.
Thinking of it as disempowerment is probably not accurate, because disempowerment implies some kind of absolute norm of power that you're undercutting. That's not really accurate: it's just game balancing, and surviving has more subdued encounters. Typically, attrition is a much more powerful and effective tool to make survival feel like survival. Even that, however, is not the core of survival horror.
For example, the scariest games I ever played were System Shock II and Silent Debuggers.
System Shock II didn't have disempowerment as it is commonly defined. However, it did have the long, grinding road of attrition. Similarly, in Silent Debuggers it was rare that any given enemy would threaten you, but trying to hunt them all down before they blew apart critical ship resources was a terrifying ordeal. Especially since every level you advanced left destroyed resources destroyed. Again, attrition. But attrition is just a survival mechanic, not a horror mechanic.
Neither attrition nor disempowerment make a game horrifying. Neither do any competing ideas, such as limited information, excessive travel dangers, safe-and-dangerous zoning, and so on.
There's loads and loads of games that use these things and aren't horrifying. For example, Chess. Cooperative board games. Solitaire.
If you really aren't convinced, think about all the times you had an enforced stealth mission. Was it horrifying when Link had to escape prison again? Was it horrifying when Sam Fischer wasn't allowed to shoot anyone this mission? Similarly, what about when you're deprived of weapons and have to push through the beginning of the third act with your weakest weapon. Those are all disempowerment scenarios. Horrifying?
No! It could be heart-pounding, but that's absolutely unrelated. Football is heart-pounding.
To be blunt, the core of survival horror is the horror part. There's not really many non-survival but-still-horror games on the market, so the two words have become wedded in our mind. Survivalhorror.
The feel of the game owes a lot more to the horror half of that, even though we've been giving the survival half all the credit. Having a tense moment does make it easier to convince you that things are horrifying. But that's more like having a crack to shine the light of horror through, rather than it being the light of horror itself.
What is "horrifying"?
I would say it's seeing people hurt. Broken people. Suffering.
Yeah, that easy.
See, in video games, most of the mobs we face aren't "people". They may be shaped like people, they may even have faces, but we're taught to dehumanize them. They don't have any real human characteristics.
But in a horror game, we give those human characteristics back to the enemies. The enemies are recognizably individuals that have suffered and been driven far past sanity. Bloody nurses, baby-headed spiders, butchers with their faces torn off...
Of course, it's best to take it further. Not only have the enemies been given human characteristics, but the NPCs and often the avatar have been given human characteristics as well.
The avatar is the most common: terror by direct proxy. We put the avatar in a situation that would make him scared, and the player therefore feels his fear. This is the "survival" part. So if you want to talk about survival horror's "disempowerment", this is what you're doing. This one piece. You're building a situation where the avatar should feel scared.
But let's not overlook the NPCs. It's an extremely common and very powerful tool to build up the NPCs as humans before killing them or turning them into monsters. Sometimes it's very quick and easy - a few lines of dialog and then they are eaten by a monster. They are chased down a corridor while you can't follow. You find them dead, with their last email still on their PDA. Whatever. You understand that they were people who suffered.
Sometimes games take it a lot further, a lot more effectively. System Shock 2 is pretty much the reigning king of this even now, with the classic build up and staged reveal of SHODAN. It's actually legitimately horrifying. And the scariest parts of the game are when SHODAN acts more human. Those are the horrifying parts of Portal, as well. You can connect with the enemies as humans all the sudden, which means that they aren't faceless monsters: they're completely broken humans. Horrifying.
The most effective horror methods are those that let us feel the fear and pain of those in the situation. As an example, if a little girl is killed, you'll probably be horrified. But if her family survives it, and you hear their wailing grief... that'll turn it up a lot. This is one reason why horror games tend to torture rather than kill: the expression of pain is horrifying, a very clear way to communicate suffering.
Survival horror. Survival, sure, the survival part. You can argue it's disempowerment. I would argue that it's simply making the challenge of the game "survival" rather than whatever other default you would go for.
It's the "horror" part that matters, though. And that's just seeing suffering, seeing broken humans. Understanding that people hurt.
At least, that's what horrifies me.
Thursday, April 25, 2013
Heuristic-aided Player Content
I always want to lower the bar for players. I want every player to create content. I want every player to play content created by players. This makes sense from every conceivable angle.
To lower the bar, one thing I've experimented with is "heuristic-aided player design", where players create things using fast, easy methods and the algorithms fill in all the details. These can then be tweaked or used as-is. This is an alternative to modular design systems.
For example, if you're building a dungeon. One option is modular design, where you have a bunch of rooms and you put them down in the places you want them. This is good if you're aiming for balanced challenge creation, but it's difficult for the player to really express themselves.
So I played around with "finger painting" the dungeon. The players just draw general strokes, and the heuristic translates them into corridors and halls. Switch "colors", and the heuristic interprets it as a new kind of zone - for example, creating a guard-filled security sector in front of a wealth-filled complex of vaults.
The problem with this is that the specification is shallow. Even if you use the strokes to determine connectivity, you're still doing very basic stuff. There's no meat in these designs - it's the same level of expression as dropping in premade rooms. You lack all the custom stuff - tricky traps, conditionals, chatty NPCs, unusual combats, chains of scenarios. That's stuff you get a good custom-made level. You can't get that with finger-painting.
I saw a little blurb by Corvus Elrod about how he was planning to do algorithmic melee weapon generation, allowing users to submit images of their weapons and then calculating the various parameters like damage, speed, accuracy... but he had also assumed that the player would have to mark the handholds on the weapons. I mean, obviously: knowing the handhold location means you know the lever length, the balancing, the level of control... you really can calculate out the mechanics of a melee weapon with just a colored silhouette and handhold marks.
I thought to myself: it is these anchor points that give the heuristics what they need. The weapon's silhouette can only be interpreted in light of these anchor points.
Put more precisely, the weapon has a role in the system. The role is to be swung or thrust in combat. How well it fulfills that role depends on both the construction of the weapon and how the wielder holds it. The actual method can vary wildly - some weapons are better at thrusting than swinging, some are short, some are long, some are heavy, some are light, some are blunt, some are sharp, some are spiked, some have handguards and counterweights... but around half of these things can only be determined if you know where the adventurer will hold the weapon!
In designing a dungeon using finger paint, I was neglecting the handholds. A dungeon serves a specific role: it exists to be traversed by the adventuring party. So the shape of the dungeon can only be properly interpreted when you know where the adventuring party will be "gripping" it, and how.
Like a melee weapon, a dungeon might end up feeling a bit different depending on who "swings" it, even between different swings. But the fundamental nature of the dungeon is based on how the dungeon can be gripped. In the case of a dungeon, we're not talking about hands, we're talking about adventure beats. Places that give the adventuring party purpose and invest them in the adventure.
There are probably more kinds of adventure beat than handhold, because we probably want to allow for a lot of different kinds. This one is freeing hostages, this one is finding records about the boss, this one is overhearing a password from the guards, this one is where you get dumped down a level by a trap...
Moreover, the dungeon around these beats will change. Its role will change, and therefore its implementation will change. A series of halls leading to a hostage-freeing situation will be geared for hostage keeping and containment, with locked doors and guards and cells. On the other hand, the same hallways leading to an "endless waves of enemies until you retreat" beat will be spookily empty and spattered with blood.
Much like you can understand the transmission of forces and the effective impact points by understanding the handhold on a melee weapon diagram, you can also understand the transmission of adventure and the effective emotional impact points by understanding the intended story beats in a dungeon.
...
Actually, I'm pretty sure you could do this for a lot more than dungeons. Clothes, spells, starships, alien civilizations, even social NPCs...
Forever, I've been drawing diagrams of these sorts of things. And, well, that works. But to really understand them and make the diagrams actually matter in-world, you also need to understand exactly how they will be used. This means putting down operational anchor points.
This is a really fun little idea. I might create some prototypes based on it.
To lower the bar, one thing I've experimented with is "heuristic-aided player design", where players create things using fast, easy methods and the algorithms fill in all the details. These can then be tweaked or used as-is. This is an alternative to modular design systems.
For example, if you're building a dungeon. One option is modular design, where you have a bunch of rooms and you put them down in the places you want them. This is good if you're aiming for balanced challenge creation, but it's difficult for the player to really express themselves.
So I played around with "finger painting" the dungeon. The players just draw general strokes, and the heuristic translates them into corridors and halls. Switch "colors", and the heuristic interprets it as a new kind of zone - for example, creating a guard-filled security sector in front of a wealth-filled complex of vaults.
The problem with this is that the specification is shallow. Even if you use the strokes to determine connectivity, you're still doing very basic stuff. There's no meat in these designs - it's the same level of expression as dropping in premade rooms. You lack all the custom stuff - tricky traps, conditionals, chatty NPCs, unusual combats, chains of scenarios. That's stuff you get a good custom-made level. You can't get that with finger-painting.
I saw a little blurb by Corvus Elrod about how he was planning to do algorithmic melee weapon generation, allowing users to submit images of their weapons and then calculating the various parameters like damage, speed, accuracy... but he had also assumed that the player would have to mark the handholds on the weapons. I mean, obviously: knowing the handhold location means you know the lever length, the balancing, the level of control... you really can calculate out the mechanics of a melee weapon with just a colored silhouette and handhold marks.
I thought to myself: it is these anchor points that give the heuristics what they need. The weapon's silhouette can only be interpreted in light of these anchor points.
Put more precisely, the weapon has a role in the system. The role is to be swung or thrust in combat. How well it fulfills that role depends on both the construction of the weapon and how the wielder holds it. The actual method can vary wildly - some weapons are better at thrusting than swinging, some are short, some are long, some are heavy, some are light, some are blunt, some are sharp, some are spiked, some have handguards and counterweights... but around half of these things can only be determined if you know where the adventurer will hold the weapon!
In designing a dungeon using finger paint, I was neglecting the handholds. A dungeon serves a specific role: it exists to be traversed by the adventuring party. So the shape of the dungeon can only be properly interpreted when you know where the adventuring party will be "gripping" it, and how.
Like a melee weapon, a dungeon might end up feeling a bit different depending on who "swings" it, even between different swings. But the fundamental nature of the dungeon is based on how the dungeon can be gripped. In the case of a dungeon, we're not talking about hands, we're talking about adventure beats. Places that give the adventuring party purpose and invest them in the adventure.
There are probably more kinds of adventure beat than handhold, because we probably want to allow for a lot of different kinds. This one is freeing hostages, this one is finding records about the boss, this one is overhearing a password from the guards, this one is where you get dumped down a level by a trap...
Moreover, the dungeon around these beats will change. Its role will change, and therefore its implementation will change. A series of halls leading to a hostage-freeing situation will be geared for hostage keeping and containment, with locked doors and guards and cells. On the other hand, the same hallways leading to an "endless waves of enemies until you retreat" beat will be spookily empty and spattered with blood.
Much like you can understand the transmission of forces and the effective impact points by understanding the handhold on a melee weapon diagram, you can also understand the transmission of adventure and the effective emotional impact points by understanding the intended story beats in a dungeon.
...
Actually, I'm pretty sure you could do this for a lot more than dungeons. Clothes, spells, starships, alien civilizations, even social NPCs...
Forever, I've been drawing diagrams of these sorts of things. And, well, that works. But to really understand them and make the diagrams actually matter in-world, you also need to understand exactly how they will be used. This means putting down operational anchor points.
This is a really fun little idea. I might create some prototypes based on it.
War Stories and Power Rangers
A while back, I read something about the new XCom game. The guy (I don't remember who) said that, regardless of the mechanical changes, the new XCom game was great because it still allowed you to build emergent stories with your characters. The way that your characters operated in combat was easy to turn into stories in your head, as your badass Rambo held off half a dozen monsters against all odds before dying to a brain-eater. War stories.
At the time, I thought to myself "oh, I geuss I can see that." It's been bouncing around in my skull for a few months, though, and now I'm really starting to explore it.
It started with my exploration of the Power-Rangers-Spoof RPG that I created but never polished or finished. I came up with some mechanics for creating a unique fusion of teamwork and independence, and it seemed like it'd be fun. So I made a prototype, as you do. In the process, I learned way too much about Power Rangers. I'm not really a fan, so I didn't really know anything about them aside from the very basics. But it turns out that there's a lot of character development packed into the various seasons, at least if Linkara's summaries can be trusted. It's shaky and bumpy, but the character growth definitely adds to the show... even though some of it seems to be post-hoc rationalization.
I started thinking to myself about that XCom game that let you build your own stories out of the battlefield circumstances. I started thinking about how Power Rangers does something similar off the battlefield. You can't do the XCom thing in Power Rangers, because Power Rangers is a TV show, not a video game. Tactical complexity is sharp and easy in a video game, but on TV it's heavy and opaque. On the other hand, it's not so easy to do the out-of-combat narratives in a video game, because there's not really any mechanics that communicate it.
Fundamentally, it felt similar. The way a ranger will show up, drop out, get injured, recover, save everyone, fail miserably, be in the right place, be in the wrong place, pull out a can of whoop-ass... it's identical to the pattern you get when you reassemble the war stories from an XCom battle.
You can split both things up into the same basic kinds of progression made out of the same kinds of elements. Let's go ahead and explore them.
There seem to be two fundamental kinds of element: engagement elements and maneuvering elements. In XCOM, moving your characters is the maneuver element - and the enemies also move. In Power Rangers, the maneuver element is story beats. As you would move a soldier into position behind cover, in Power Rangers they would have a ranger go spying for monsters in the Abandoned Warehouse District. In the same way that you might open a door and find an enemy waiting for you, the ranger might find himself ambushed. In the same way that you might have a medic rush over to heal a soldier, a ranger might be encouraged and focused by a pep talk.
Of course, then you have the engagements, where the soldiers and rangers are actually in direct danger. In both cases, this is always strongly tied to the maneuvering that surrounds it. Both sides maneuver to keep conflicts weighted in their favor, delaying or accelerating them, gathering allies or obstructing enemies, moving out of sight, moving to see if there are enemies hiding, creating cover and safety, flanking to eliminate cover and safety. On the other hand, this isn't strictly one-way. There are many different kinds of engagements, and you may simply choose to use a different engagement if maneuvering seems difficult. The enemy is behind cover? Blow away the cover, or throw a grenade in behind.
The same kind of philosophy can be applied to Power Rangers. The different kinds of engagement don't map one-to-one with machine guns, sniper rifles, grenades, rocket launchers, etc, but they do have similar depth. Civilian fighting, basic suit fighting, enhanced suit fighting, mecha fighting, combined mecha fighting... while it's true that each ranger has a specialty, in most cases the engagement type is determined by how the group chooses to fight, rather than by which of the group steps forward. I think that's interesting.
The maneuvering is also very diverse. Since it's actually written rather than algorithmic, it probably doesn't fit as neatly into the kind of topological jockeying you get with XCom soldiers. What are the story-beat maneuvers which match "move agent 1 up to the trash can for cover. Agent 2 should angle for a look in through the window at range. Agent 3 should close and look through the window close-up"... it'd be a stretch to try and make the story beats mimic that precisely. But, on the other hand, they don't have to. Like engagement types, it's more important that the depth and connectivity to the engagements be maintained, not the precise methods.
One advantage we have when we're doing team-based engagement determination rather than unit-based engagement determination is that we can lose members of the team without losing any options. Aside from special cases, it doesn't matter whether we have all 5 team members or only 2: we can still fight as civilians, power suits, upgraded suits, or mecha. Sure, we'll have less power, but we'll have the same options. This means that members of the team can be tokens traded in maneuvering, which seems to be the core idea in story-beat maneuvers.
Rather than being concerned with topology, story-beat maneuvers are about who is with who. You don't creep up and look through a window: you send off a member to spy. You don't step on a trap and take damage: you get ambushed and captured. You don't take cover behind a trashcan: you stand your ground so that the other rangers have more time.
Without trying to clone the exact situations that the Power Rangers find themselves in, it's possible to create a maneuvering system which is still flexible. It needs to be unit-centric rather than team-centric, though, because stories mean more when they are about people. Even though engagements are about how the team decides to recombine and spend their shared energy, maneuvers still need to be individual.
The easiest solution is probably just to use the new XCom solution. Each team member's turn is maneuver-act, with some acts being engagements and some not. Similarly, as you level up you might find the actual mechanics slowly shifting. However, in essence, the idea of maneuver-act is a good one, sharp and clean.
Because maneuvering doesn't happen on actual space, it might be best to use "tagging" instead of "walking". So instead of telling a unit to walk X steps, you would tell a unit to tag another unit. Tag an ally to stay close to them, to engage when they engage. Tag an enemy to chase them, unlocking advanced attacks when you engage them. Every unit has two (or three, for tactical classes) tags, and they cycle. So you could tag an ally, and then tag an enemy on the next turn. You'd still be tagged to your ally, so if you then engaged the enemy, both of you would attack and be able to use advanced modes and techniques. Of course, if the enemy had double-tagged your ally, the enemy would have an even more significant bonus...
This is a simple method to create interconnectivity and topology from nothing. Moreover, your action phase after your maneuver phase offers a lot more options than simply "fiiiight!" You could shed an enemy's tag against you, for example. Or give an ally a pep-talk. Or scout. Or work on community awareness. Or pin an enemy down in a drawn-out fight that prevents them from tagging next round. Whatever.
The enemies have more or less the same rules, although they also have a bunch of other abilities. For example, some monsters might be able to kidnap a ranger in certain circumstances, or hold hostages, or depower rangers. These are usually related to acquiring a certain number of tags against noncombat targets, but in many cases the player can't even see those targets... or maybe even the monsters that did the tagging. So if a monster gets a turn and didn't seem to tag anything, maybe you ought to tag that monster and go a-spying before he digs up the depowering candle or whatever.
Other units and targets also exist - military bases, vulnerable townsfolk, suddenly-appearing secret labs full of magic crystals, ominous portals in the sky... the same tag-and-act method applies to them as well. In many cases you'll want to tag defensively so that you can defend them if the enemy attacks. This is where tactical classes are useful, because of their extra tag token. Of course, tags cycle, so you may end up holding off on tagging on round 4 so you don't lose that important defensive tag you put up on round 1...
In the end, the emergent topology and complex "who is teamed up at the moment" mechanics should result in the same kind of stories that emerge from games like X-Com.
This allows us to create stories in the same tense way that XCom combats do by using noncombat maneuvers as part of the overarching story.
... Now, what if you replaced the engagement conflict with a noncombat conflict?
At the time, I thought to myself "oh, I geuss I can see that." It's been bouncing around in my skull for a few months, though, and now I'm really starting to explore it.
It started with my exploration of the Power-Rangers-Spoof RPG that I created but never polished or finished. I came up with some mechanics for creating a unique fusion of teamwork and independence, and it seemed like it'd be fun. So I made a prototype, as you do. In the process, I learned way too much about Power Rangers. I'm not really a fan, so I didn't really know anything about them aside from the very basics. But it turns out that there's a lot of character development packed into the various seasons, at least if Linkara's summaries can be trusted. It's shaky and bumpy, but the character growth definitely adds to the show... even though some of it seems to be post-hoc rationalization.
I started thinking to myself about that XCom game that let you build your own stories out of the battlefield circumstances. I started thinking about how Power Rangers does something similar off the battlefield. You can't do the XCom thing in Power Rangers, because Power Rangers is a TV show, not a video game. Tactical complexity is sharp and easy in a video game, but on TV it's heavy and opaque. On the other hand, it's not so easy to do the out-of-combat narratives in a video game, because there's not really any mechanics that communicate it.
Fundamentally, it felt similar. The way a ranger will show up, drop out, get injured, recover, save everyone, fail miserably, be in the right place, be in the wrong place, pull out a can of whoop-ass... it's identical to the pattern you get when you reassemble the war stories from an XCom battle.
You can split both things up into the same basic kinds of progression made out of the same kinds of elements. Let's go ahead and explore them.
There seem to be two fundamental kinds of element: engagement elements and maneuvering elements. In XCOM, moving your characters is the maneuver element - and the enemies also move. In Power Rangers, the maneuver element is story beats. As you would move a soldier into position behind cover, in Power Rangers they would have a ranger go spying for monsters in the Abandoned Warehouse District. In the same way that you might open a door and find an enemy waiting for you, the ranger might find himself ambushed. In the same way that you might have a medic rush over to heal a soldier, a ranger might be encouraged and focused by a pep talk.
Of course, then you have the engagements, where the soldiers and rangers are actually in direct danger. In both cases, this is always strongly tied to the maneuvering that surrounds it. Both sides maneuver to keep conflicts weighted in their favor, delaying or accelerating them, gathering allies or obstructing enemies, moving out of sight, moving to see if there are enemies hiding, creating cover and safety, flanking to eliminate cover and safety. On the other hand, this isn't strictly one-way. There are many different kinds of engagements, and you may simply choose to use a different engagement if maneuvering seems difficult. The enemy is behind cover? Blow away the cover, or throw a grenade in behind.
The same kind of philosophy can be applied to Power Rangers. The different kinds of engagement don't map one-to-one with machine guns, sniper rifles, grenades, rocket launchers, etc, but they do have similar depth. Civilian fighting, basic suit fighting, enhanced suit fighting, mecha fighting, combined mecha fighting... while it's true that each ranger has a specialty, in most cases the engagement type is determined by how the group chooses to fight, rather than by which of the group steps forward. I think that's interesting.
The maneuvering is also very diverse. Since it's actually written rather than algorithmic, it probably doesn't fit as neatly into the kind of topological jockeying you get with XCom soldiers. What are the story-beat maneuvers which match "move agent 1 up to the trash can for cover. Agent 2 should angle for a look in through the window at range. Agent 3 should close and look through the window close-up"... it'd be a stretch to try and make the story beats mimic that precisely. But, on the other hand, they don't have to. Like engagement types, it's more important that the depth and connectivity to the engagements be maintained, not the precise methods.
One advantage we have when we're doing team-based engagement determination rather than unit-based engagement determination is that we can lose members of the team without losing any options. Aside from special cases, it doesn't matter whether we have all 5 team members or only 2: we can still fight as civilians, power suits, upgraded suits, or mecha. Sure, we'll have less power, but we'll have the same options. This means that members of the team can be tokens traded in maneuvering, which seems to be the core idea in story-beat maneuvers.
Rather than being concerned with topology, story-beat maneuvers are about who is with who. You don't creep up and look through a window: you send off a member to spy. You don't step on a trap and take damage: you get ambushed and captured. You don't take cover behind a trashcan: you stand your ground so that the other rangers have more time.
Without trying to clone the exact situations that the Power Rangers find themselves in, it's possible to create a maneuvering system which is still flexible. It needs to be unit-centric rather than team-centric, though, because stories mean more when they are about people. Even though engagements are about how the team decides to recombine and spend their shared energy, maneuvers still need to be individual.
The easiest solution is probably just to use the new XCom solution. Each team member's turn is maneuver-act, with some acts being engagements and some not. Similarly, as you level up you might find the actual mechanics slowly shifting. However, in essence, the idea of maneuver-act is a good one, sharp and clean.
Because maneuvering doesn't happen on actual space, it might be best to use "tagging" instead of "walking". So instead of telling a unit to walk X steps, you would tell a unit to tag another unit. Tag an ally to stay close to them, to engage when they engage. Tag an enemy to chase them, unlocking advanced attacks when you engage them. Every unit has two (or three, for tactical classes) tags, and they cycle. So you could tag an ally, and then tag an enemy on the next turn. You'd still be tagged to your ally, so if you then engaged the enemy, both of you would attack and be able to use advanced modes and techniques. Of course, if the enemy had double-tagged your ally, the enemy would have an even more significant bonus...
This is a simple method to create interconnectivity and topology from nothing. Moreover, your action phase after your maneuver phase offers a lot more options than simply "fiiiight!" You could shed an enemy's tag against you, for example. Or give an ally a pep-talk. Or scout. Or work on community awareness. Or pin an enemy down in a drawn-out fight that prevents them from tagging next round. Whatever.
The enemies have more or less the same rules, although they also have a bunch of other abilities. For example, some monsters might be able to kidnap a ranger in certain circumstances, or hold hostages, or depower rangers. These are usually related to acquiring a certain number of tags against noncombat targets, but in many cases the player can't even see those targets... or maybe even the monsters that did the tagging. So if a monster gets a turn and didn't seem to tag anything, maybe you ought to tag that monster and go a-spying before he digs up the depowering candle or whatever.
Other units and targets also exist - military bases, vulnerable townsfolk, suddenly-appearing secret labs full of magic crystals, ominous portals in the sky... the same tag-and-act method applies to them as well. In many cases you'll want to tag defensively so that you can defend them if the enemy attacks. This is where tactical classes are useful, because of their extra tag token. Of course, tags cycle, so you may end up holding off on tagging on round 4 so you don't lose that important defensive tag you put up on round 1...
In the end, the emergent topology and complex "who is teamed up at the moment" mechanics should result in the same kind of stories that emerge from games like X-Com.
This allows us to create stories in the same tense way that XCom combats do by using noncombat maneuvers as part of the overarching story.
... Now, what if you replaced the engagement conflict with a noncombat conflict?
Tuesday, April 23, 2013
Ensemble Games - Character Establishment
Let's talk about the difficulties in creating ensemble games. That is, games where there are a huge number of characters.
Recently, I've been playing drips and drabs of Valkyria Chronicles. Not long ago, I played lots and lots of Fire Emblem Awakening. Let's compare Valkyria Chronicles and Fire Emblem: there's a lot to be learned.
Valkyria Chronicles and Fire Emblem have comparable ratings (very high for a niche tactical game), but Fire Emblem made a huge splash while Valkyria Chronicles sank without a murmur. So sad. But they are games of similar quality - both have deep and interesting gameplay, both have a fairly decent story line, both have annoying, uninterruptable enemy turns that can last ten minutes...
And both are ensemble games.
In both cases, you pick around eight characters out of a massive bank. Fire Emblem has around 35 characters, while Valkyria Chronicles has at least 50 and probably more like 80. All of the characters are unique but scripted - that is, no random characters like you'd get from Final Fantasy Tactics.
In both cases, a major piece of annoyance is the same thing that gives the game their ensemble flavor. Choosing 8 out of 50 characters feels arbitrary and limited. Unless you're a power leveler, you're generally going to just have a dozen or so that are your "first tier" characters and ignore the rest. At least, that's the normal way to do it. But let's get into the nitty gritty details.
Valkyria Chronicles has waaaaay better character design than Fire Emblem. Although it has around twice as many characters, few of the characters feel like clones, repeats, or schtick characters.
In Fire Emblem, the characters always feel like schtick characters. They have a thing they do. They may have a personality behind that somewhere, but nearly everything is dominated by their schtick. For example, the dragon shapeshifter is theoretically a very interesting character with an interesting take on life... but her loli schtick is so heavy you rarely see it. Similarly, there's a candy-eating rogue, a clutzy knight, an overly rational mage woman, a yaoi-bait butler knight... most of the characters are built around a schtick first, and a character idea second.
It feels like they came up with a bunch of "adjective noun" character descriptions, handed them out to half a dozen character designers, and then just threw them in the game. Unfortunately, this resulted in a lot of the characters feeling very similar, because "clutzy busty knight", "obsessed busty knight", and "pet-obsessed busty knight" given to three different people are often going to come back as the same character three times.
In Valkyria Chronicles, on the other hand, the characters were clearly designed to feel distinct from each other. Valkyria Chronicles chose to design every character with an eye for what other characters there are, especially within their class. There's only a few characters that feel overly similar, and those are typically characters with completely different combat roles - there's a sniper and a machine gunner that have very similar character designs, but you're not going to confuse a sniper for a gunner.
Valkyria Chronicles' much stronger character design shines through even in a game where none of the characters are ever introduced. In Fire Emblem, every character has an introduction skit where you can get to know them a little. Valkyria Chronicles doesn't: they just show up in the list of hireable soldiers.
Still, Valkyria Chronicles' better character design is not necessarily a better approach.
Fire Emblem has a lot of character interaction - characters talking to other characters and so on. The schtick approach means that you'll always know precisely who is in the skit. "Oh, it's laughing evil mage and foppish archer guy". It also gives each character a clear line of interaction when the two core characters might not have anything particularly compelling to say to each other: "foppish archer guy gets creeped out by laughing evil mage! It's funny!"
Valkyria Chronicles took the opposite approach in that the character relationships are supposed to feel more... realistic. War stories are about camaraderie under fire. The relationships aren't typically very complex: there's only a few basic shapes they take. Character schticks are typically to add flavor to the relationship, rather than to define it. I think that's fine. In fact, it offers an advantage that Valkyria Chronicles didn't take advantage of: because the relationships are generic war story relationships, you could create friendships and bonds between any characters. Even though each character has a unique feel to them, their relationships are quite simple.
Valkyria Chronicles didn't do that, of course, which we'll get to in a minute.
One of the things Valkyria Chronicles did do, that I applaud them for, is that their characters aren't painfully boring. It's a standard of tactical games to make the main characters insaaaaaanely boring and safe. Fire Emblem did so: virtually all of the characters are boring and safe, certainly all the main ones are. In Valkyria Chronicles the main trio are pretty dull, I admit it. But the fourth and fifth members of the band are a dismissive career grunt and a classy racist. Both of these characters are grating but also appealing: even as they grind against the main characters' unfailing Jesus-like goodwill, they never feel like villains or bad characters because their flaws are offset by their very real character strengths. They feel like flawed, interesting characters and their collisions with the main characters add a lot of spice to the party dynamic without falling back on the tired meme of "secretly an evil spy" or whatever.
In Fire Emblem, this never would have happened. All the characters worship the main characters, they all get along perfectly, they all fit into the same group and feel like part of the same crowd. But in Valkyria Chronicles, you really feel that these people might be a good team, but they don't all fit into the same social group. Some are from different generations, have different interests, different social groups... it really gives a much stronger sense of a group being drawn together by circumstance and hard work, rather than fate just gathering up all the perfect people in the world and tossing them in a giant generic pot.
So, final thoughts on character design:
1) Design your characters to be distinct from each other, not just to have a distinct schtick. Even if you do schtick-based design, redesign characters that end up too similar. This means both visual design and personal characteristics.
2) Make flawed characters. We're not talking about tragic heroes that are undone by their own flaws, we're just talking about characters with some thorns. Make them prick the other characters from time to time. They need to have good traits, too: the player should never think they are beyond redemption or are awful people... but their prickles will make the party seem much more interesting and realistic, and also give them a good character arc.
3) Make characters that don't really have much in common a lot of the time. Not everyone needs to be 22-year-old highly energetic adventure-ho man. Look at the people who don't hang out with you: put them in your game and make it so they don't really hang out with you there, either. They're still team members and even friends, but if there's a vacation where you all go to the beach, not everyone is going to go swimming, not everyone is going to play volleyball.
Fire Emblem and Valkyria Chronicles both have excessive amounts of personal characteristics attached to their characters. But this is where Valkyria Chronicles falls short. While Valkyria Chronicles was better in terms of character design, it's a whole lot worse in terms of making them feel distinct statistically.
In Fire Emblem you grow into the character's distinct traits. Who they can get into relationships with, what classes they can change over to - these are often quite complex and specific, but they don't have any effect until you decide to develop them. They are uniquenesses that grow as the player wills.
In Valkyria Chronicles, the characters have friends and unique traits in a vaguely similar fashion, but they're mostly just BAM right up front. So you're suddenly faced with 50 unique characters, each of whom has 2-4 unique traits and 1-3 unique friendships and you're trying to select 20 of them and them winnow it down to 8 and... whew, the game just drowns you in uniqueness.
This is made worse because Valkyria Chronicles doesn't really have any directed character growth of any type. It doesn't matter whether you take someone into combat or not - everyone levels at the same rate no matter what. Even their personal traits are relatively minor - I frequently take people with severe allergies to the battlefield into battle, because the severe allergies do almost nothing. Of course, on the flipside, the advantages also rarely work, and rarely do much even if they do work. "Night vision" sounds like a great trait for a scout or sniper to have... but it only kicks in once every ten turns or so. How does that even work?
Well, either way, when it comes to creating unique character stats, I recommend taking after Fire Emblem, not Valkyria Chronicles. The player should be able to grow the characters' unique traits, both in terms of combat capability and in terms of relationships.
Also, I think it's worthwhile to have characters volunteer information about their specialties on the battle selection screen. When you highlight someone to add them to the battle, they should have a little passive dialog box that pops up and says "I can see in the dark, that's gonna be real handy in this battle!"
Another important feature is whether or not the player cycles the characters. In both Valkyria Chronicles and Fire Emblem, I typically settle on a few mains and then everyone else is left in the background. I think this is a real shame. It'd be worthwhile to have some character cycling impetus.
One small method of character cycling used in Fire Emblem is the buddy system. Because you're inevitably going to want to at least try to fill in the buddy list on your mains, you start to cycle people in so you can become buddies with them.
There are other ways, too. I like the idea of forcefully cycling characters. I think Valkyria Chronicles would be better if, instead of choosing 20 characters that you then choose 8 from, the 20 characters were randomly determined each time (with guaranteed ratios of class types).
Another option is the "everyone every round" method, where you can engage in any number of fights in a given story turn (week, day, month, whatever), but each character can only be in one fight. So if you have 50 characters, you might split them up into 8 different battles and fight each. The downside of this is that you may need to have some memory aids in place (such as sub-unit colors and extensive team chatter) or you'll start to lose track of the 50 characters.
...
I guess that's it.
Recently, I've been playing drips and drabs of Valkyria Chronicles. Not long ago, I played lots and lots of Fire Emblem Awakening. Let's compare Valkyria Chronicles and Fire Emblem: there's a lot to be learned.
Valkyria Chronicles and Fire Emblem have comparable ratings (very high for a niche tactical game), but Fire Emblem made a huge splash while Valkyria Chronicles sank without a murmur. So sad. But they are games of similar quality - both have deep and interesting gameplay, both have a fairly decent story line, both have annoying, uninterruptable enemy turns that can last ten minutes...
And both are ensemble games.
In both cases, you pick around eight characters out of a massive bank. Fire Emblem has around 35 characters, while Valkyria Chronicles has at least 50 and probably more like 80. All of the characters are unique but scripted - that is, no random characters like you'd get from Final Fantasy Tactics.
In both cases, a major piece of annoyance is the same thing that gives the game their ensemble flavor. Choosing 8 out of 50 characters feels arbitrary and limited. Unless you're a power leveler, you're generally going to just have a dozen or so that are your "first tier" characters and ignore the rest. At least, that's the normal way to do it. But let's get into the nitty gritty details.
Character Design
Valkyria Chronicles has waaaaay better character design than Fire Emblem. Although it has around twice as many characters, few of the characters feel like clones, repeats, or schtick characters.
In Fire Emblem, the characters always feel like schtick characters. They have a thing they do. They may have a personality behind that somewhere, but nearly everything is dominated by their schtick. For example, the dragon shapeshifter is theoretically a very interesting character with an interesting take on life... but her loli schtick is so heavy you rarely see it. Similarly, there's a candy-eating rogue, a clutzy knight, an overly rational mage woman, a yaoi-bait butler knight... most of the characters are built around a schtick first, and a character idea second.
It feels like they came up with a bunch of "adjective noun" character descriptions, handed them out to half a dozen character designers, and then just threw them in the game. Unfortunately, this resulted in a lot of the characters feeling very similar, because "clutzy busty knight", "obsessed busty knight", and "pet-obsessed busty knight" given to three different people are often going to come back as the same character three times.
In Valkyria Chronicles, on the other hand, the characters were clearly designed to feel distinct from each other. Valkyria Chronicles chose to design every character with an eye for what other characters there are, especially within their class. There's only a few characters that feel overly similar, and those are typically characters with completely different combat roles - there's a sniper and a machine gunner that have very similar character designs, but you're not going to confuse a sniper for a gunner.
Valkyria Chronicles' much stronger character design shines through even in a game where none of the characters are ever introduced. In Fire Emblem, every character has an introduction skit where you can get to know them a little. Valkyria Chronicles doesn't: they just show up in the list of hireable soldiers.
Still, Valkyria Chronicles' better character design is not necessarily a better approach.
Fire Emblem has a lot of character interaction - characters talking to other characters and so on. The schtick approach means that you'll always know precisely who is in the skit. "Oh, it's laughing evil mage and foppish archer guy". It also gives each character a clear line of interaction when the two core characters might not have anything particularly compelling to say to each other: "foppish archer guy gets creeped out by laughing evil mage! It's funny!"
Valkyria Chronicles took the opposite approach in that the character relationships are supposed to feel more... realistic. War stories are about camaraderie under fire. The relationships aren't typically very complex: there's only a few basic shapes they take. Character schticks are typically to add flavor to the relationship, rather than to define it. I think that's fine. In fact, it offers an advantage that Valkyria Chronicles didn't take advantage of: because the relationships are generic war story relationships, you could create friendships and bonds between any characters. Even though each character has a unique feel to them, their relationships are quite simple.
Valkyria Chronicles didn't do that, of course, which we'll get to in a minute.
One of the things Valkyria Chronicles did do, that I applaud them for, is that their characters aren't painfully boring. It's a standard of tactical games to make the main characters insaaaaaanely boring and safe. Fire Emblem did so: virtually all of the characters are boring and safe, certainly all the main ones are. In Valkyria Chronicles the main trio are pretty dull, I admit it. But the fourth and fifth members of the band are a dismissive career grunt and a classy racist. Both of these characters are grating but also appealing: even as they grind against the main characters' unfailing Jesus-like goodwill, they never feel like villains or bad characters because their flaws are offset by their very real character strengths. They feel like flawed, interesting characters and their collisions with the main characters add a lot of spice to the party dynamic without falling back on the tired meme of "secretly an evil spy" or whatever.
In Fire Emblem, this never would have happened. All the characters worship the main characters, they all get along perfectly, they all fit into the same group and feel like part of the same crowd. But in Valkyria Chronicles, you really feel that these people might be a good team, but they don't all fit into the same social group. Some are from different generations, have different interests, different social groups... it really gives a much stronger sense of a group being drawn together by circumstance and hard work, rather than fate just gathering up all the perfect people in the world and tossing them in a giant generic pot.
So, final thoughts on character design:
1) Design your characters to be distinct from each other, not just to have a distinct schtick. Even if you do schtick-based design, redesign characters that end up too similar. This means both visual design and personal characteristics.
2) Make flawed characters. We're not talking about tragic heroes that are undone by their own flaws, we're just talking about characters with some thorns. Make them prick the other characters from time to time. They need to have good traits, too: the player should never think they are beyond redemption or are awful people... but their prickles will make the party seem much more interesting and realistic, and also give them a good character arc.
3) Make characters that don't really have much in common a lot of the time. Not everyone needs to be 22-year-old highly energetic adventure-ho man. Look at the people who don't hang out with you: put them in your game and make it so they don't really hang out with you there, either. They're still team members and even friends, but if there's a vacation where you all go to the beach, not everyone is going to go swimming, not everyone is going to play volleyball.
Character Stat Design
Fire Emblem and Valkyria Chronicles both have excessive amounts of personal characteristics attached to their characters. But this is where Valkyria Chronicles falls short. While Valkyria Chronicles was better in terms of character design, it's a whole lot worse in terms of making them feel distinct statistically.
In Fire Emblem you grow into the character's distinct traits. Who they can get into relationships with, what classes they can change over to - these are often quite complex and specific, but they don't have any effect until you decide to develop them. They are uniquenesses that grow as the player wills.
In Valkyria Chronicles, the characters have friends and unique traits in a vaguely similar fashion, but they're mostly just BAM right up front. So you're suddenly faced with 50 unique characters, each of whom has 2-4 unique traits and 1-3 unique friendships and you're trying to select 20 of them and them winnow it down to 8 and... whew, the game just drowns you in uniqueness.
This is made worse because Valkyria Chronicles doesn't really have any directed character growth of any type. It doesn't matter whether you take someone into combat or not - everyone levels at the same rate no matter what. Even their personal traits are relatively minor - I frequently take people with severe allergies to the battlefield into battle, because the severe allergies do almost nothing. Of course, on the flipside, the advantages also rarely work, and rarely do much even if they do work. "Night vision" sounds like a great trait for a scout or sniper to have... but it only kicks in once every ten turns or so. How does that even work?
Well, either way, when it comes to creating unique character stats, I recommend taking after Fire Emblem, not Valkyria Chronicles. The player should be able to grow the characters' unique traits, both in terms of combat capability and in terms of relationships.
Also, I think it's worthwhile to have characters volunteer information about their specialties on the battle selection screen. When you highlight someone to add them to the battle, they should have a little passive dialog box that pops up and says "I can see in the dark, that's gonna be real handy in this battle!"
Character Cycling
Another important feature is whether or not the player cycles the characters. In both Valkyria Chronicles and Fire Emblem, I typically settle on a few mains and then everyone else is left in the background. I think this is a real shame. It'd be worthwhile to have some character cycling impetus.
One small method of character cycling used in Fire Emblem is the buddy system. Because you're inevitably going to want to at least try to fill in the buddy list on your mains, you start to cycle people in so you can become buddies with them.
There are other ways, too. I like the idea of forcefully cycling characters. I think Valkyria Chronicles would be better if, instead of choosing 20 characters that you then choose 8 from, the 20 characters were randomly determined each time (with guaranteed ratios of class types).
Another option is the "everyone every round" method, where you can engage in any number of fights in a given story turn (week, day, month, whatever), but each character can only be in one fight. So if you have 50 characters, you might split them up into 8 different battles and fight each. The downside of this is that you may need to have some memory aids in place (such as sub-unit colors and extensive team chatter) or you'll start to lose track of the 50 characters.
...
I guess that's it.
Monday, April 22, 2013
Glitch Games
There's always a steady undercurrent of glitch-related art and commentary. Modern games tend to have physics glitches where they fling you off into the sky, or texture glitches where things are painted in solely red warning text.
But in the old days, glitches were often significantly deeper. I think my favorite glitch engine was Sierra Online's "The Shadow of Yserbius". The game itself never had any significant glitches for me during play. But if you went into the save file and hex-edited it, you could cause a hugely entertaining variety of glitches, such as your character turning into a giant stack of "scrolls of boomerang". Fun times.
My interest in glitches began a lot earlier than that, though, because I began on the Apple II. The Apple II I had had a serious overheating problem: after two hours or so, it'd begin to overheat and randomly corrupt working memory. Rather than get upset about it, as a child exploring what Basic could accomplish, I became really interested in incorporating these RAM glitches into the games, capturing corrupt memory as text or images and trying to use it later, when the computer had cooled off.
Of course, I also had an NES, and NES glitches typically changed the way the game worked. While you could simply have a visual glitch, NES games were programmed pretty tightly, so that kind of offset error usually meant the game code was about to fly off into the wild as well. At the time, I thought of glitches as destructive exploration: if you got one, something interesting and entertaining was happening... but you wouldn't survive it. I don't think I considered glitches as methods for cheating until the Playstation era.
I think a lot of people like glitches. There's games simulating glitches, games that attempt to be made out of glitches, glitch art, and so on. There's something artistic about the computer's misinterpretation of things. That said, glitching is not an easy thing to actually incorporate into a game: it tends to result in crashes. So most such games are engineered with carefully programmed glitches that simulate the best possible kinds of glitch.
I think the games which do glitch stuff most authentically are the monster games where you can scan something and get a monster out of it. Barcodes, images, QR codes - anything that produces a string of digits that the game interprets as a monster. However, typically these games play it very safe, and instead of trying to actually interpret the code, they simply use the code to select from a variety of premade monsters.
Weak!
If you allowed the game to actually compute the monster programmatically, then you begin to see real glitch games in action. The game's code base acts as a structured container, insuring that the glitch will never (or very rarely) actually kill off the game. However, by interpreting incoming data as a certain kind of code, you can get the same kind of glitch situation that you would have gotten by corrupting a NES game. Even the art used to draw the monster - rather than reading in pure gibberish and displaying static, you can use programmatic commands to draw chunks of the monster, allowing the code in question to draw something that looks vaguely in-world valid. Allowing for any length of code is also important: we're not talking about a string of integers used to select body type, head type, weapon type. We're talking about code that executes.
There's not any particular reason it has to be monsters, either - that's just what's been built to date. You could do absolutely anything: dungeons, cities, ancient spells, anime magical girls... it would be a lot of fun to play around with things. Take any image or string of text and interpret it as a place, person, monster, thing, spell... stitch together your world and share it with your friends. Of course, try to progress through it as well.
That last part is the iffy one. You can't really balance a game where code is arbitrarily executed.
I think that rather than try to balance it, you need to just create a progression structure. For example, you might have a few NPC friends. Progressing through the game isn't about gaining levels. It's about surviving with your NPC friends. As time passes you grow closer and friendlier. There may also be some statistical progression, but rather than combat statistics it should be glitch slot growth. For example, you can only have two places in memory at the beginning, so each time you scan a potential place, you have to drop an old one. But as you gain levels, you gain more glitch slots, or perhaps can cement glitches into place so they don't take up slots.
Either way, the point of the game is not to "win" it, although those mechanics exist. Instead the point of the game is to create a world and share it with your friends. Come up with the zaniest world, scariest world, most normal world - whatever you can come up with.
The heart of such a game would be the interpreter, of course. There are a few ways to do that.
One way is to interpret it as a byte array and simply treat each byte as a potential command or argument. So byte value "26" might be "draw arm". Then you have the next chunk spent on arguments: offset from cursor, arm type, arm size, arm color, etc.
The problem with this is that most data will be pretty bland. There is a high chance that the input data will not have a byte value of "26" at any point. So most data would result in armless monsters.
The solution to this is to have some kind of memory/changing command system. The most basic form of this would be that each time you receive a command, you rotate the command space a certain number of steps. So even if every byte is "26", you would end up receiving a lot of different commands and have a complete result.
A more elegant method would be to combine that with a command chain system where a few commands are all clustered around the same core command space. For example, a "26" might be draw arm, but all of the 20s are "draw monster part" commands. The first 20-something results in drawing a torso, regardless of which command it actually is. Afterwards, they'll draw as they should. Or maybe 26 draws arms the first time is it called, but then overwrites the left arm the next time it is called, the right arm the time after that, and so on. 27 draws a new pair of arms...
This kind of execution can also work well for powers and behavior... but, still, if you're planning on reading in pretty universal data, it's not ideal. For example, if people are submitting a compressed image like JPG, there's going to be a familiar pattern in every image. If they're submitting an uncompressed image, there's going to be vast numbers of repeating byte segments due to very similar pixel coloration.
If you simply interpret these with a script interpreter as explained above, then many of your results are going to have a very patterned feel.
In these cases, it may be best to use a data eater rather than a data parser. Use an algorithm which explores the topology of the data.
So instead of interpreting "26" as "draw arm", you would have a "draw arm" subroutine that looks at, say, the byte 30% through the total data string. It then reads forward, counting the first five or so values it finds as seed values, and then continuing to count forward until it finds a new, distinct value. The quantity of each seed value and the value that stopped you would then be the arguments for your "draw arm" function. You could easily chain this - for example, the stopper value could be interpreted as a command which then works like a script interpreter to determine the attack linked to the arms, or even whether or not to start drawing more arms or something.
This is a good way to operate within a very strict framework. If you're doing something like a dungeon level, you'll need to allow for arbitrarily complex structures painted by arbitrary code... but if you're trying to create an anime magical girl, there's a strict framework. Some elements will basically be arguments (height, for example). Others will be complex patterns (hair, magic attack)... but they'll all always have to exist. So you can't use a low-context interpreter like you would for dungeons. For these situations, using subsystems which read arbitrary points in the data may be better.
Both methods combine with a few other features you may want to remember.
The first is state. In most cases, you'll have some kind of state. For example, if you're creating a new attack pattern, then each new phase of attack you read is going to be attached to the end of the previous phase. If you're creating a monster's attack pattern, it's important to know whether you're laying a new attack piece into an existing attack, creating a multi-phase attack, or creating a brand new attack. So state is important.
The next important thing is parallelism. In many situations, you'll want to have situations where several things are being added at once, or there is mirroring, or some such. For example, if you're drawing a dungeon, you may hit a T-junction. One option is to execute one side and then, when it completes, execute the other side from wherever the first side ends. But that implies a halting condition, which is not generally a good idea. A better option is to execute one side from where the T junction call is made, and simultaneously create the other side from a different point in the byte array. Even so much as a single byte offset is typically enough to create completely different results due to the difference in interpreting commands as arguments and arguments as commands. Mirroring is possible, too, in which case you probably want a condition where the mirroring will break and the two sides will diverge (or one side stop). That can be "X commands in" or "certain data read" or whatever.
The last important thing I've used in my experiments is marking.
Marking is what happens when a command creates a framework for stuff, but then you want to go back and fill it in later. Typically, I'll use front-to-back to create the scaffold, and then back-to-front to fill in the markings, although you could also divvy it up into something like "first 40% of code is scaffold, next 60% is fill-in".
As an example, a scaffold might be the basic layout of a dungeon. You blitz through the architecture phase, creating tunnels and doors and rooms and all those basics. But every one of those commands also puts down markers - on the walls, the doors, the floors, and so on. The markings have three pieces: the core marking type (wall, door, floor, etc), the marking subtype (arbitrary, typically only 1-2 of each subtype in a room), and the marking order (a simple incrementing counter).
When you complete the architecture, the fill-in phase begins. This is used to fill in those markings.
The commands will typically fill in swaths of markings all at once. For example, "fill in the last 10 wall-A markings as type 1 torches". Those markings are then removed (or moved to a detailing list, depending on the depth of the generation algorithm). So if you then get the same command again, you'll have filled in the last 20 wall-A markings. But the rooms those torches are in are not entirely full of torches: they still have some wall-B, wall-C, or even wall-D markings. Plus, the halls might have wall-A markings and then something like wall-D and wall-E markings: each subtype is a different category of intended good, although there's no guarantee that is the good that will get placed there. For example, there is a (small) chance that wall-A markings will be filled with tables, or topiaries, or even spy hallways.
There's also the commands to fill in just one, or fill in one, skip some, fill in one, skip some... for example, you may get the command to fill in wall-B markings with topiary in the pattern "topiary-skip-skip-topiary-skip-skip". Or you might get the command to replace every ninth wall-A with a doorway - and if there's no room on the other side of that wall-A marking, automatically create a closet and mark it with a storage-A mark.
There are also commands to change the nature of markings. For example, "change the last 10 wall-A markings to wall-SECURE markings, and change the door-A markings in affected rooms to locked doors". These sorts of commands allow you to create zones with differing content, rather than simply relying wholly on randomness.
Either way, you'll probably run out of marks before you run out of code. That's the intention, at any rate. If you still have marks left over, start over with the remaining marks, perhaps with some displacement. Don't leave marks unfilled.
Markings can also be useful in creating monsters or items, but in those cases it's often just a matter of detail work rather than this kind of fundamental "where treasure chests get put" stuff.
Anyway... that all sounds pretty far from glitches, right? I mean, generative dungeons and glitches aren't really the same thing...
Well, I think they are. Fundamentally, my enjoyment of a glitch comes from the fact that the computer is interacting with me in a way the developer didn't intend. By giving the computer means to do that, I feel this kind of generative stuff is in the same spirit as hacking a save file to turn yourself into a stack of scrolls.
And you can play it pretty fast and loose. If you prefer to have a more glitchlike experience, use fewer premade elements (such as "torches" or "arms") and instead generate those elements using more interpretation. Personally, I want the generated content to feel like it fits at least vaguely into the world without shattering it, but I still want it be crazy and weird. This is how I accomplish that.
WELL THAT WAS LONG.
But in the old days, glitches were often significantly deeper. I think my favorite glitch engine was Sierra Online's "The Shadow of Yserbius". The game itself never had any significant glitches for me during play. But if you went into the save file and hex-edited it, you could cause a hugely entertaining variety of glitches, such as your character turning into a giant stack of "scrolls of boomerang". Fun times.
My interest in glitches began a lot earlier than that, though, because I began on the Apple II. The Apple II I had had a serious overheating problem: after two hours or so, it'd begin to overheat and randomly corrupt working memory. Rather than get upset about it, as a child exploring what Basic could accomplish, I became really interested in incorporating these RAM glitches into the games, capturing corrupt memory as text or images and trying to use it later, when the computer had cooled off.
Of course, I also had an NES, and NES glitches typically changed the way the game worked. While you could simply have a visual glitch, NES games were programmed pretty tightly, so that kind of offset error usually meant the game code was about to fly off into the wild as well. At the time, I thought of glitches as destructive exploration: if you got one, something interesting and entertaining was happening... but you wouldn't survive it. I don't think I considered glitches as methods for cheating until the Playstation era.
I think a lot of people like glitches. There's games simulating glitches, games that attempt to be made out of glitches, glitch art, and so on. There's something artistic about the computer's misinterpretation of things. That said, glitching is not an easy thing to actually incorporate into a game: it tends to result in crashes. So most such games are engineered with carefully programmed glitches that simulate the best possible kinds of glitch.
I think the games which do glitch stuff most authentically are the monster games where you can scan something and get a monster out of it. Barcodes, images, QR codes - anything that produces a string of digits that the game interprets as a monster. However, typically these games play it very safe, and instead of trying to actually interpret the code, they simply use the code to select from a variety of premade monsters.
Weak!
If you allowed the game to actually compute the monster programmatically, then you begin to see real glitch games in action. The game's code base acts as a structured container, insuring that the glitch will never (or very rarely) actually kill off the game. However, by interpreting incoming data as a certain kind of code, you can get the same kind of glitch situation that you would have gotten by corrupting a NES game. Even the art used to draw the monster - rather than reading in pure gibberish and displaying static, you can use programmatic commands to draw chunks of the monster, allowing the code in question to draw something that looks vaguely in-world valid. Allowing for any length of code is also important: we're not talking about a string of integers used to select body type, head type, weapon type. We're talking about code that executes.
There's not any particular reason it has to be monsters, either - that's just what's been built to date. You could do absolutely anything: dungeons, cities, ancient spells, anime magical girls... it would be a lot of fun to play around with things. Take any image or string of text and interpret it as a place, person, monster, thing, spell... stitch together your world and share it with your friends. Of course, try to progress through it as well.
That last part is the iffy one. You can't really balance a game where code is arbitrarily executed.
I think that rather than try to balance it, you need to just create a progression structure. For example, you might have a few NPC friends. Progressing through the game isn't about gaining levels. It's about surviving with your NPC friends. As time passes you grow closer and friendlier. There may also be some statistical progression, but rather than combat statistics it should be glitch slot growth. For example, you can only have two places in memory at the beginning, so each time you scan a potential place, you have to drop an old one. But as you gain levels, you gain more glitch slots, or perhaps can cement glitches into place so they don't take up slots.
Either way, the point of the game is not to "win" it, although those mechanics exist. Instead the point of the game is to create a world and share it with your friends. Come up with the zaniest world, scariest world, most normal world - whatever you can come up with.
The heart of such a game would be the interpreter, of course. There are a few ways to do that.
One way is to interpret it as a byte array and simply treat each byte as a potential command or argument. So byte value "26" might be "draw arm". Then you have the next chunk spent on arguments: offset from cursor, arm type, arm size, arm color, etc.
The problem with this is that most data will be pretty bland. There is a high chance that the input data will not have a byte value of "26" at any point. So most data would result in armless monsters.
The solution to this is to have some kind of memory/changing command system. The most basic form of this would be that each time you receive a command, you rotate the command space a certain number of steps. So even if every byte is "26", you would end up receiving a lot of different commands and have a complete result.
A more elegant method would be to combine that with a command chain system where a few commands are all clustered around the same core command space. For example, a "26" might be draw arm, but all of the 20s are "draw monster part" commands. The first 20-something results in drawing a torso, regardless of which command it actually is. Afterwards, they'll draw as they should. Or maybe 26 draws arms the first time is it called, but then overwrites the left arm the next time it is called, the right arm the time after that, and so on. 27 draws a new pair of arms...
This kind of execution can also work well for powers and behavior... but, still, if you're planning on reading in pretty universal data, it's not ideal. For example, if people are submitting a compressed image like JPG, there's going to be a familiar pattern in every image. If they're submitting an uncompressed image, there's going to be vast numbers of repeating byte segments due to very similar pixel coloration.
If you simply interpret these with a script interpreter as explained above, then many of your results are going to have a very patterned feel.
In these cases, it may be best to use a data eater rather than a data parser. Use an algorithm which explores the topology of the data.
So instead of interpreting "26" as "draw arm", you would have a "draw arm" subroutine that looks at, say, the byte 30% through the total data string. It then reads forward, counting the first five or so values it finds as seed values, and then continuing to count forward until it finds a new, distinct value. The quantity of each seed value and the value that stopped you would then be the arguments for your "draw arm" function. You could easily chain this - for example, the stopper value could be interpreted as a command which then works like a script interpreter to determine the attack linked to the arms, or even whether or not to start drawing more arms or something.
This is a good way to operate within a very strict framework. If you're doing something like a dungeon level, you'll need to allow for arbitrarily complex structures painted by arbitrary code... but if you're trying to create an anime magical girl, there's a strict framework. Some elements will basically be arguments (height, for example). Others will be complex patterns (hair, magic attack)... but they'll all always have to exist. So you can't use a low-context interpreter like you would for dungeons. For these situations, using subsystems which read arbitrary points in the data may be better.
Both methods combine with a few other features you may want to remember.
The first is state. In most cases, you'll have some kind of state. For example, if you're creating a new attack pattern, then each new phase of attack you read is going to be attached to the end of the previous phase. If you're creating a monster's attack pattern, it's important to know whether you're laying a new attack piece into an existing attack, creating a multi-phase attack, or creating a brand new attack. So state is important.
The next important thing is parallelism. In many situations, you'll want to have situations where several things are being added at once, or there is mirroring, or some such. For example, if you're drawing a dungeon, you may hit a T-junction. One option is to execute one side and then, when it completes, execute the other side from wherever the first side ends. But that implies a halting condition, which is not generally a good idea. A better option is to execute one side from where the T junction call is made, and simultaneously create the other side from a different point in the byte array. Even so much as a single byte offset is typically enough to create completely different results due to the difference in interpreting commands as arguments and arguments as commands. Mirroring is possible, too, in which case you probably want a condition where the mirroring will break and the two sides will diverge (or one side stop). That can be "X commands in" or "certain data read" or whatever.
The last important thing I've used in my experiments is marking.
Marking is what happens when a command creates a framework for stuff, but then you want to go back and fill it in later. Typically, I'll use front-to-back to create the scaffold, and then back-to-front to fill in the markings, although you could also divvy it up into something like "first 40% of code is scaffold, next 60% is fill-in".
As an example, a scaffold might be the basic layout of a dungeon. You blitz through the architecture phase, creating tunnels and doors and rooms and all those basics. But every one of those commands also puts down markers - on the walls, the doors, the floors, and so on. The markings have three pieces: the core marking type (wall, door, floor, etc), the marking subtype (arbitrary, typically only 1-2 of each subtype in a room), and the marking order (a simple incrementing counter).
When you complete the architecture, the fill-in phase begins. This is used to fill in those markings.
The commands will typically fill in swaths of markings all at once. For example, "fill in the last 10 wall-A markings as type 1 torches". Those markings are then removed (or moved to a detailing list, depending on the depth of the generation algorithm). So if you then get the same command again, you'll have filled in the last 20 wall-A markings. But the rooms those torches are in are not entirely full of torches: they still have some wall-B, wall-C, or even wall-D markings. Plus, the halls might have wall-A markings and then something like wall-D and wall-E markings: each subtype is a different category of intended good, although there's no guarantee that is the good that will get placed there. For example, there is a (small) chance that wall-A markings will be filled with tables, or topiaries, or even spy hallways.
There's also the commands to fill in just one, or fill in one, skip some, fill in one, skip some... for example, you may get the command to fill in wall-B markings with topiary in the pattern "topiary-skip-skip-topiary-skip-skip". Or you might get the command to replace every ninth wall-A with a doorway - and if there's no room on the other side of that wall-A marking, automatically create a closet and mark it with a storage-A mark.
There are also commands to change the nature of markings. For example, "change the last 10 wall-A markings to wall-SECURE markings, and change the door-A markings in affected rooms to locked doors". These sorts of commands allow you to create zones with differing content, rather than simply relying wholly on randomness.
Either way, you'll probably run out of marks before you run out of code. That's the intention, at any rate. If you still have marks left over, start over with the remaining marks, perhaps with some displacement. Don't leave marks unfilled.
Markings can also be useful in creating monsters or items, but in those cases it's often just a matter of detail work rather than this kind of fundamental "where treasure chests get put" stuff.
Anyway... that all sounds pretty far from glitches, right? I mean, generative dungeons and glitches aren't really the same thing...
Well, I think they are. Fundamentally, my enjoyment of a glitch comes from the fact that the computer is interacting with me in a way the developer didn't intend. By giving the computer means to do that, I feel this kind of generative stuff is in the same spirit as hacking a save file to turn yourself into a stack of scrolls.
And you can play it pretty fast and loose. If you prefer to have a more glitchlike experience, use fewer premade elements (such as "torches" or "arms") and instead generate those elements using more interpretation. Personally, I want the generated content to feel like it fits at least vaguely into the world without shattering it, but I still want it be crazy and weird. This is how I accomplish that.
WELL THAT WAS LONG.
Subscribe to:
Posts (Atom)