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.
Thursday, April 18, 2013
Social NPCs in Games (Design)
Still thinkin' about social NPCs. The short version of yesterday's post: social NPCs aren't about getting them to like you X amount, it's about how they interact with the world alongside you. In some respects, a character's social algorithm is similar to a character's combat class. It shapes how they engage, how they maneuver, how they act, how long they last, what role they play. But instead of being about combat, it's about some kind of social framework.
If an NPC is simply given a "like" axis for you, it generally implies the designers are treating them as a token or hazard for the players to use or navigate around. This is fine for gameplay, but death for social stuff. Being social fundamentally assumes the other person is in the same basic category as you. IE, an active member of the world.
So most attempts to create social NPCs fail largely because there's no reason for the social NPC. The character only matters if they matter. Their actions only matter if their actions matter. So you have to build the game's framework to allow the NPCs to matter, and then build the social engine to influence that.
As an example, we'll outline two basic games, and discuss how we might implement social NPCs in that framework.
The first game is a horror movie game. The idea of this game is that you are directing a horror movie. So you add whatever cast members you want, pick a scenario and a monster, and begin filming. There's no script, it's all ad-libbed by the cast in response to the threat.
This is a good system to start with because 99% of the meat of this game is the way the characters act and interact. It's also a good place to start because it puts ever-increasing pressure on the characters, which is something most social games leave out. RPGs put ever-increasing pressure on the party, FPS games put ever-increasing pressure on your gunnery skills... if you want to be able to get the real measure of a character, you have to be with them as the pressure mounts.
We'll simulate this with a simple modular structure for each character. The characters have a "physical" mind which is simply a glob of modules connected to each other in 2D space. When the characters "touch", the nodes which impact react. Sometimes they'll react positively, bonding together with a strut and locking the characters together until the strut is shattered. In the movie, this would be represented by a scene where they have a moment related to those nodes and noticeably bond. Other times, the nodes might not get along - for example, two "alpha dog" nodes that impact will result in both characters being hurled away from each other. This can also break struts depending on the force applied. The scene would reflect the two fighting for dominance and then grumping away from each other in different directions, along with any other affected characters subtly relaying their shattered bond.
This is a very simple physics system, which is made more possible by the addition of pressure. Horror movies happen in an isolated space, and as the director, you can apply more and more pressure, shrinking the space with stalking monsters, fires, and so on. This pushes the characters together more forcefully and can even snap bonds. There might be a few other things you can do - like sic the monster on any given character whenever you want, or click on a character to force them to have an active scene where they do something unrelated to the monster.
This is a simple physical system for creating social interactions. It's going to vary a lot depending on a lot of factors - can the characters rotate? What nodes are there? And so on. It's a toy at this level, but it could be turned into a game, especially if the monster is actually automated and your job is to try to jiggle the characters into a solid enough formation that they can escape or survive before the monster kills them all.
The second game is an open-world RPG, kind of a single-player MMORPG where other party members are played by social NPCs.
This offers us several ways to witness the NPCs' personalities and preferences.
1) How they act and react in combat.
2) They can spend time with you on unimportant gameplay, creating a sense of camaraderie. This could be "kill 800 badgers" missions or just hanging out at someone's virtual home.
3) They can get together with you for important raids (both joining you and proposing them while asking you to join).
4) They can message/whisper you what's going on if they are gaming but not in your party, negating the "out of party, out of mind" problem and also allowing you to perform more complex multi-pronged raids.
5) They can email you if things happen in their downtime, further negating the "out of party, out of mind" problem by flat-out telling you what things have developed. Conversation trees here can allow you to develop a deeper understanding and connection as you respond to their emails.
6) How they equip themselves with luxury items, costumes, lay out their homes, and so on. What parts of the world they like, which static NPCs they like... all communicate preferences and let you communicate your judgment/response in return. Of course, they can judge you and other social NPCs based on your own preferences on these matters.
The focus of this design is giving the player as many ways to witness and respond to a character's personality as possible. Unlike the previous design, the focus here is not on simulating the character in an interesting manner, but instead it is on creating an interesting character and allowing you to get to know them. You could structure the gameworld in a lot of distinct ways, and you could make the character algorithms work in a lot of different ways. But none of these components are mysterious: some require a lot of work, some could be made easier or harder, but they are all plausible.
Anyway, that's the sort of thing I'm thinking about.
If an NPC is simply given a "like" axis for you, it generally implies the designers are treating them as a token or hazard for the players to use or navigate around. This is fine for gameplay, but death for social stuff. Being social fundamentally assumes the other person is in the same basic category as you. IE, an active member of the world.
So most attempts to create social NPCs fail largely because there's no reason for the social NPC. The character only matters if they matter. Their actions only matter if their actions matter. So you have to build the game's framework to allow the NPCs to matter, and then build the social engine to influence that.
As an example, we'll outline two basic games, and discuss how we might implement social NPCs in that framework.
The first game is a horror movie game. The idea of this game is that you are directing a horror movie. So you add whatever cast members you want, pick a scenario and a monster, and begin filming. There's no script, it's all ad-libbed by the cast in response to the threat.
This is a good system to start with because 99% of the meat of this game is the way the characters act and interact. It's also a good place to start because it puts ever-increasing pressure on the characters, which is something most social games leave out. RPGs put ever-increasing pressure on the party, FPS games put ever-increasing pressure on your gunnery skills... if you want to be able to get the real measure of a character, you have to be with them as the pressure mounts.
We'll simulate this with a simple modular structure for each character. The characters have a "physical" mind which is simply a glob of modules connected to each other in 2D space. When the characters "touch", the nodes which impact react. Sometimes they'll react positively, bonding together with a strut and locking the characters together until the strut is shattered. In the movie, this would be represented by a scene where they have a moment related to those nodes and noticeably bond. Other times, the nodes might not get along - for example, two "alpha dog" nodes that impact will result in both characters being hurled away from each other. This can also break struts depending on the force applied. The scene would reflect the two fighting for dominance and then grumping away from each other in different directions, along with any other affected characters subtly relaying their shattered bond.
This is a very simple physics system, which is made more possible by the addition of pressure. Horror movies happen in an isolated space, and as the director, you can apply more and more pressure, shrinking the space with stalking monsters, fires, and so on. This pushes the characters together more forcefully and can even snap bonds. There might be a few other things you can do - like sic the monster on any given character whenever you want, or click on a character to force them to have an active scene where they do something unrelated to the monster.
This is a simple physical system for creating social interactions. It's going to vary a lot depending on a lot of factors - can the characters rotate? What nodes are there? And so on. It's a toy at this level, but it could be turned into a game, especially if the monster is actually automated and your job is to try to jiggle the characters into a solid enough formation that they can escape or survive before the monster kills them all.
The second game is an open-world RPG, kind of a single-player MMORPG where other party members are played by social NPCs.
This offers us several ways to witness the NPCs' personalities and preferences.
1) How they act and react in combat.
2) They can spend time with you on unimportant gameplay, creating a sense of camaraderie. This could be "kill 800 badgers" missions or just hanging out at someone's virtual home.
3) They can get together with you for important raids (both joining you and proposing them while asking you to join).
4) They can message/whisper you what's going on if they are gaming but not in your party, negating the "out of party, out of mind" problem and also allowing you to perform more complex multi-pronged raids.
5) They can email you if things happen in their downtime, further negating the "out of party, out of mind" problem by flat-out telling you what things have developed. Conversation trees here can allow you to develop a deeper understanding and connection as you respond to their emails.
6) How they equip themselves with luxury items, costumes, lay out their homes, and so on. What parts of the world they like, which static NPCs they like... all communicate preferences and let you communicate your judgment/response in return. Of course, they can judge you and other social NPCs based on your own preferences on these matters.
The focus of this design is giving the player as many ways to witness and respond to a character's personality as possible. Unlike the previous design, the focus here is not on simulating the character in an interesting manner, but instead it is on creating an interesting character and allowing you to get to know them. You could structure the gameworld in a lot of distinct ways, and you could make the character algorithms work in a lot of different ways. But none of these components are mysterious: some require a lot of work, some could be made easier or harder, but they are all plausible.
Anyway, that's the sort of thing I'm thinking about.
Wednesday, April 17, 2013
Social NPCs
I've been thinking - again! - about social NPCs.
Recently I've started to think of them in a slightly different way. When we talk about social NPCs, what is it that we really want?
Do we want NPCs that react to the player's game choices interestingly? Do we want NPCs that the player can interact with socially in a compelling way? Do we want NPCs which can shape our world - or at least their own lives - based on their personal preferences?
A lot of this is about the game you're designing. For example, you might create a game where you run a starship, and you want the social elements of the NPCs to be about how well the crew can get along during the long quiet time between stars... and also how they react to your various moral choices on missions.
Or maybe you're doing a classic RPG, and your social NPCs are more about getting to know the people who are on this mission with you, and getting that feeling of camaraderie.
Or maybe you're doing a Minecraft game, and you want randomly created villagers that form meaningful relationships with each other while shaping the village's inhabitated lands.
These all call for different kinds of social algorithms.
In general, I've started to think of NPCs as having three tiers you may want to make algorithmic or script, depending on your need.
The lowest level is what sort of situations the NPC seeks to be part of, and what sort of situations they seek to avoid. This will determine the low-level activities they generally perform. In a space ship crew game, this might simply be where they hang out off-shift. In a fantasy RPG, this might be their moral alignment and the kinds of outcomes they would prefer from the various kinds of quests. In a village game, this might govern the sort of friends the NPC has, which kinds of buildings he prefers to inhabit, and so on.
The middle level is how the NPC seeks to steer situations they have become part of. This will determine how they try to resolve or take advantage of game situations as they unfold.
A starship crew would voice their thoughts about how an away mission should be handled or who should date who. A fantasy RPG character will use this to position themselves in the unfolding battles, and govern how they treat loot and danger. A villager would use this to determine how they act when day-to-day concerns arise, such as storms or visiting peddlers.
The topmost layer is how the NPC judges and interacts with people (and things) moment to moment. In all the situations listed so far, this would be the tone of voice they take, whether they jockey for dominance, whether they judge you for your clothes, and so on. In theory, it is really about how well people get on moment-to-moment, regardless of how well they mesh or clash on a larger scale. In practice, this would probably involve a lot of generative dialog and confusing emergent behavior, so this may be something which is better to script or simplify down to arbitrary values.
Each of these levels seems largely independent to me. You could script one and create an algorithm for another. The exact algorithm would vary based on your game world, of course, but none of them are particularly mysterious.
But... notice what's missing from this equation?
I didn't talk at all about things like how much they like you or trust you or whatever.
Obviously, memory plays a big role in socialization, and there will be some kind of like and/or trust values going on. But the meat of a character is not in whether or not they like you: it's in how they act and react.
The heart of the social gameplay is not in leveling up your relationship with them, but in how they interact with the world alongside you. Instead of treating the character as a target, treat them as a tool. Characters do stuff. Sometimes they do stuff on their own. Sometimes because you tell them to, or on your behalf. And sometimes they will oppose you. It is the contours of these activities that make interacting with them interesting - not whether you can get another point on the buddy-buddy axis.
Recently I've started to think of them in a slightly different way. When we talk about social NPCs, what is it that we really want?
Do we want NPCs that react to the player's game choices interestingly? Do we want NPCs that the player can interact with socially in a compelling way? Do we want NPCs which can shape our world - or at least their own lives - based on their personal preferences?
A lot of this is about the game you're designing. For example, you might create a game where you run a starship, and you want the social elements of the NPCs to be about how well the crew can get along during the long quiet time between stars... and also how they react to your various moral choices on missions.
Or maybe you're doing a classic RPG, and your social NPCs are more about getting to know the people who are on this mission with you, and getting that feeling of camaraderie.
Or maybe you're doing a Minecraft game, and you want randomly created villagers that form meaningful relationships with each other while shaping the village's inhabitated lands.
These all call for different kinds of social algorithms.
In general, I've started to think of NPCs as having three tiers you may want to make algorithmic or script, depending on your need.
The lowest level is what sort of situations the NPC seeks to be part of, and what sort of situations they seek to avoid. This will determine the low-level activities they generally perform. In a space ship crew game, this might simply be where they hang out off-shift. In a fantasy RPG, this might be their moral alignment and the kinds of outcomes they would prefer from the various kinds of quests. In a village game, this might govern the sort of friends the NPC has, which kinds of buildings he prefers to inhabit, and so on.
The middle level is how the NPC seeks to steer situations they have become part of. This will determine how they try to resolve or take advantage of game situations as they unfold.
A starship crew would voice their thoughts about how an away mission should be handled or who should date who. A fantasy RPG character will use this to position themselves in the unfolding battles, and govern how they treat loot and danger. A villager would use this to determine how they act when day-to-day concerns arise, such as storms or visiting peddlers.
The topmost layer is how the NPC judges and interacts with people (and things) moment to moment. In all the situations listed so far, this would be the tone of voice they take, whether they jockey for dominance, whether they judge you for your clothes, and so on. In theory, it is really about how well people get on moment-to-moment, regardless of how well they mesh or clash on a larger scale. In practice, this would probably involve a lot of generative dialog and confusing emergent behavior, so this may be something which is better to script or simplify down to arbitrary values.
Each of these levels seems largely independent to me. You could script one and create an algorithm for another. The exact algorithm would vary based on your game world, of course, but none of them are particularly mysterious.
But... notice what's missing from this equation?
I didn't talk at all about things like how much they like you or trust you or whatever.
Obviously, memory plays a big role in socialization, and there will be some kind of like and/or trust values going on. But the meat of a character is not in whether or not they like you: it's in how they act and react.
The heart of the social gameplay is not in leveling up your relationship with them, but in how they interact with the world alongside you. Instead of treating the character as a target, treat them as a tool. Characters do stuff. Sometimes they do stuff on their own. Sometimes because you tell them to, or on your behalf. And sometimes they will oppose you. It is the contours of these activities that make interacting with them interesting - not whether you can get another point on the buddy-buddy axis.
Tuesday, April 16, 2013
Avatars with Layers
This is a technical implementation post.
I'm slowly creating a Unity avatar generator, so this is a post about avatar generation.
There seem to be a lot of different opinions about how to do it, but most of them seem to be either mired in the past or extremely limited. I plan to use three methods to allow users to construct their avatars. Keep in mind that users will be able to submit content and use it on their avatars, so this is a framework rather than a specific set of options. This means that we can't use any of the cheap outs like you get in the various superhero MMORPGs.
First: you can stack texture layers. Or, more accurately, material layers.
This would be used for skin tight stuff, such as tank tops, necklaces, socks, and so on. These simply require a texture with transparency, a bump map, and an optional set of material parameters if you want to make it have different shader parameters (for example, to get the look of a spandex bodysuit). This is simply stacked on top of the underlying materials, allowing underlying materials to show through.
In addition, you can use this for simple decal work - scars, tattoos, robo-skin, whatever.
The little secret to this is the use of bumpmap blending.
It's quite easy to calculate out a single, final bumpmap by layering each bump map on top of the preceding bumpmap and fading it. This allows us to get a real feel for layers. For example, if you wear a chunky necklace and then a light shirt, the normals for the necklace will be used on the part of the shirt overlaying the necklace. So even though the necklace is partly hidden beneath the shirt, it doesn't vanish, it creates a little mound under the fabric.
This trick isn't critical or anything, but it's easy and adds a bit of fun realism. It also paves the way for more advanced techniques, both those listed below and things like wet or damaged clothes, nonhuman skin types, and so on. It's also important because Unity doesn't seem to support bump map transparency, so that has to be calculated by us anyway.
Second: your outermost "tight" layer determines your base mesh.
The human body is split into three mesh segments: head, upper body, and lower body. When you wear a piece of clothing, it overrides the default mesh with the correct mesh. So if you wear a T-shirt, the upper body is overridden with a mesh that has the correct sleeves. However, if you then put a long-sleeve shirt over the T-shirt, the upper body mesh becomes the long-sleeve-shirt mesh. The texture for the mesh is just like above, where there is lots of transparencies to allow the underlying skin texture to show through where needed.
These meshes are simply customizations of the base mesh, and have the same shape keys attached to them. This means that if your "muscle" slider was set to max and you put on a T-shirt, you'll still have a muscly body. Obviously it would be possible to have a mesh which didn't descend from the same topology - you could theoretically do some really crazy stuff and completely override the defaults. That's fine, that's kind of the point.
The UV mapping of these meshes has to match the original UV mapping. The reason is that we need to be able to use the underlying layers correctly, and also use this layer as an underlying layer. For example, you have a neck tattoo. You put on a T-shirt. Your mesh changes, part of your tattoo is hidden beneath the shirt texture. You put on the long sleeved shirt, your mesh changes again. While the T-shirt's mesh is gone, the T-shirts texture and normal map are not. So the neck of the shirt shows in the V of the button-up shirt, and there are subtle hints of wrinkles and mass at the neck, hem, and shoulders where the T-shirt had bump mapping.
Obviously, this has a few restrictions. For example, if you put a T-shirt on over the long-sleeved shirt, the long-sleeved shirt sleeves will be painted on your bare arm rather than having mass. I think that's fine.
Third: non-tight layers are layered meshes.
If you wear something which is poofy or doesn't adhere to your body, it's a separate mesh mapped to the same skeleton. So if you put a jacket on over your long-sleeved shirt, your shirt mesh remains your shirt mesh, and the jacket is a separate mesh. This can lead to issues if your sleeves are particularly poofy or something, but it's far less problematic than most alternatives.
Similarly, your hair is an add-on mesh. Your chunky arm pouch. Your skirt. Your boots. Your wings. These are all just add-on meshes. There's no guarantee they'll all get along, but that's part of you designing your avatars. If you stick wings on and put a coat on, you're going to have wings magically sticking through your coat. Live with it, or make a new kind of coat.
Of course, you could apply decals to these as well. Put a patch on your leather jacket.
Final thoughts
This is what I'm intending to make. It's actually not complicated, I've tested the feasibility of each of these with proof of concepts. It's just a lot of work.
A lot, especially because it's all database-based.
I really need to take maybe two weeks off work and just do this.
I'm slowly creating a Unity avatar generator, so this is a post about avatar generation.
There seem to be a lot of different opinions about how to do it, but most of them seem to be either mired in the past or extremely limited. I plan to use three methods to allow users to construct their avatars. Keep in mind that users will be able to submit content and use it on their avatars, so this is a framework rather than a specific set of options. This means that we can't use any of the cheap outs like you get in the various superhero MMORPGs.
First: you can stack texture layers. Or, more accurately, material layers.
This would be used for skin tight stuff, such as tank tops, necklaces, socks, and so on. These simply require a texture with transparency, a bump map, and an optional set of material parameters if you want to make it have different shader parameters (for example, to get the look of a spandex bodysuit). This is simply stacked on top of the underlying materials, allowing underlying materials to show through.
In addition, you can use this for simple decal work - scars, tattoos, robo-skin, whatever.
The little secret to this is the use of bumpmap blending.
It's quite easy to calculate out a single, final bumpmap by layering each bump map on top of the preceding bumpmap and fading it. This allows us to get a real feel for layers. For example, if you wear a chunky necklace and then a light shirt, the normals for the necklace will be used on the part of the shirt overlaying the necklace. So even though the necklace is partly hidden beneath the shirt, it doesn't vanish, it creates a little mound under the fabric.
This trick isn't critical or anything, but it's easy and adds a bit of fun realism. It also paves the way for more advanced techniques, both those listed below and things like wet or damaged clothes, nonhuman skin types, and so on. It's also important because Unity doesn't seem to support bump map transparency, so that has to be calculated by us anyway.
Second: your outermost "tight" layer determines your base mesh.
The human body is split into three mesh segments: head, upper body, and lower body. When you wear a piece of clothing, it overrides the default mesh with the correct mesh. So if you wear a T-shirt, the upper body is overridden with a mesh that has the correct sleeves. However, if you then put a long-sleeve shirt over the T-shirt, the upper body mesh becomes the long-sleeve-shirt mesh. The texture for the mesh is just like above, where there is lots of transparencies to allow the underlying skin texture to show through where needed.
These meshes are simply customizations of the base mesh, and have the same shape keys attached to them. This means that if your "muscle" slider was set to max and you put on a T-shirt, you'll still have a muscly body. Obviously it would be possible to have a mesh which didn't descend from the same topology - you could theoretically do some really crazy stuff and completely override the defaults. That's fine, that's kind of the point.
The UV mapping of these meshes has to match the original UV mapping. The reason is that we need to be able to use the underlying layers correctly, and also use this layer as an underlying layer. For example, you have a neck tattoo. You put on a T-shirt. Your mesh changes, part of your tattoo is hidden beneath the shirt texture. You put on the long sleeved shirt, your mesh changes again. While the T-shirt's mesh is gone, the T-shirts texture and normal map are not. So the neck of the shirt shows in the V of the button-up shirt, and there are subtle hints of wrinkles and mass at the neck, hem, and shoulders where the T-shirt had bump mapping.
Obviously, this has a few restrictions. For example, if you put a T-shirt on over the long-sleeved shirt, the long-sleeved shirt sleeves will be painted on your bare arm rather than having mass. I think that's fine.
Third: non-tight layers are layered meshes.
If you wear something which is poofy or doesn't adhere to your body, it's a separate mesh mapped to the same skeleton. So if you put a jacket on over your long-sleeved shirt, your shirt mesh remains your shirt mesh, and the jacket is a separate mesh. This can lead to issues if your sleeves are particularly poofy or something, but it's far less problematic than most alternatives.
Similarly, your hair is an add-on mesh. Your chunky arm pouch. Your skirt. Your boots. Your wings. These are all just add-on meshes. There's no guarantee they'll all get along, but that's part of you designing your avatars. If you stick wings on and put a coat on, you're going to have wings magically sticking through your coat. Live with it, or make a new kind of coat.
Of course, you could apply decals to these as well. Put a patch on your leather jacket.
Final thoughts
This is what I'm intending to make. It's actually not complicated, I've tested the feasibility of each of these with proof of concepts. It's just a lot of work.
A lot, especially because it's all database-based.
I really need to take maybe two weeks off work and just do this.
Monday, April 08, 2013
Mechanics for a Theme
I keep seeing people chat about the various kinds of rules you can use for magic systems in tabletop or video games. While I don't mind this kind of conversation, it always strikes me as a bit weird, kind of like asking "I wrote 'the'. What word can come next?"
To me, the rules in a game should support the theme of the game. I don't mean anything particularly deep or precise, but just in general. For example, the Dark Sun setting has a very different feel than Mass Effect. They are completely different, and their themes are different. Dark Sun is about a world collapsing under the weight of environmental apocalypse, while Mass Effect is about heroically fighting to make the universe a better place even if those in power are not interested in helping you.
Well, I'm sure most people would phrase it differently, and both settings have had enough re-interpretations and changing writers to wander away from whatever the original theme might have been. But the basic idea is that the themes of these worlds define a lot about how their rules work, and how their rules work determines a lot about how their in-world societies work.
I think most people who create worlds just want to create something of their own, and that's fine. But when I see them aping the clumsy D&D recipe, it makes me uncomfortable. D&D is fractured and incoherent from most perspectives, largely due to the number of iterations. For example, with the rules they use for magic, societies cannot be structured the way they are. Magicians and clerics would dominate. Later on they tried to fix this by making warriors into mages (but calling their spells things like 'feats'). This doesn't help. It may help combat balance, but it makes the world make even less sense, and doesn't change the fact that mages and clerics, with their excessive noncombat utility, would still dominate society.
When you make this kind of argument, most people handwave it. "You're thinking too much, it's just got to be fun."
But that's the thing that annoys me. Having a theme does not make things unfun, it makes things resonate better, stick in your head better. That's why people like Warhammer 40k despite it not being significantly better or worse than the hundreds of other miniatures games: it has an extremely clear theme. To the point where we non-fans make fun of it. The fun-ness of a game is unrelated to how well themed it is - no reason not to have both. Have a game which is fun to play but also resonates well.
The most powerful tools to create theme are mechanics and setting. Those are the two things that the players touch most often. Obviously a heavy authorial touch will make them feel preachy or one-note, but there's no reason to leave them completely generic.
So, when I see a question asking for a list of all the different kinds of magic systems, my first instinct is to say "what theme?"
Are you trying to create a grungy steampunk setting, full of industrial oppression? Then your magic system should either support the rise of industrial steam (golem/device magic) or it should have been supplanted by that rise (some kind of slow nature magic). Whether it involves spellbooks or limited casts per day or some kind of material or whatever - those are specifics that fall into place pretty quickly when you know what role the magic plays in your world.
One problem is that magic, in particular, tends to dominate these kinds of settings. It's rarely a good idea to separate your classes into "this one can warp the fundamental stuff of the universe and this one can't". IE, the classic "mage/fighter" divide. That's a lazy default that doesn't really make any sense. Every iteration of every fantasy game since the original D&D has struggled to boost the nonmagic classes and nerf the magicians, because fundamentally "magic" is more powerful.
I recommend just accepting that. You can have a wide variety of classes that use or fail to use magic in many different ways. Once you start to invent your mechanics, the class options start to unfold.
For example, if you decide your steampunk game is going to include both a device style magic and a much older nature magic, you can start to lay down classes. First, there's obviously the oldschool nature magician, someone who can call upon life and storm. They are weakened when they can't - being inside is generally bad for them.
On the other end of the spectrum are the steam warriors and engineers. The warriors carry around the big devices - steam drills and pressure cannons and pneumatic armor. The engineers are masters of their craft, which is more like metalbending than anything directly related to steam, so maybe they carry around miniaturized devices that use high-power springs and coils rather than actual steam. It's much lighter... but also has less power.
Since it's basically metalbending, we could have a classic mage of that variety to match our classic nature mage. This would be a blademaster who uses metalbending not to create devices, but to create superhumanly sharp swords and a screen of flying knives. Also, good at picking the huge metal locks people use, so I guess this is our rogue.
As you can see, the classes kind of fall into place. We could continue to create more and more unusual classes if we wanted. For example, a class which has plant fibers woven through their flesh using a variant on the nature magic. However, it's often good to keep the classes pretty obvious, because otherwise you need to do a lot of exposition and explaining about how things work. It's better for it to just be intuitive, at least initially. All these basic, intuitive classes are likely to be the ones that the NPCs are, so therefore they are also powerful social forces that shape the society.
What I mean is that you can build the framework of your industrial oppression on these four basic classes. The nature mages are being oppressed, both by the encroaching industrial cities and systematically by the industry that hates how they get in the way. The engineers are dominant, creating the factories and machines that the industrial cities require. Warriors - and, more generally, users of any kind of steam technology - are the meat of the setting, the middle class. Oldschool metalbenders would come off as obsolete, maybe a religious group or something. You can build your world from these blocks, and it all works out because we kept our eye on the the theme from beginning to end. So even though we didn't create the classes with the society in mind, since both the society and the classes descend from the theme, they still work together.
So... um... that's it, I guess.
To me, the rules in a game should support the theme of the game. I don't mean anything particularly deep or precise, but just in general. For example, the Dark Sun setting has a very different feel than Mass Effect. They are completely different, and their themes are different. Dark Sun is about a world collapsing under the weight of environmental apocalypse, while Mass Effect is about heroically fighting to make the universe a better place even if those in power are not interested in helping you.
Well, I'm sure most people would phrase it differently, and both settings have had enough re-interpretations and changing writers to wander away from whatever the original theme might have been. But the basic idea is that the themes of these worlds define a lot about how their rules work, and how their rules work determines a lot about how their in-world societies work.
I think most people who create worlds just want to create something of their own, and that's fine. But when I see them aping the clumsy D&D recipe, it makes me uncomfortable. D&D is fractured and incoherent from most perspectives, largely due to the number of iterations. For example, with the rules they use for magic, societies cannot be structured the way they are. Magicians and clerics would dominate. Later on they tried to fix this by making warriors into mages (but calling their spells things like 'feats'). This doesn't help. It may help combat balance, but it makes the world make even less sense, and doesn't change the fact that mages and clerics, with their excessive noncombat utility, would still dominate society.
When you make this kind of argument, most people handwave it. "You're thinking too much, it's just got to be fun."
But that's the thing that annoys me. Having a theme does not make things unfun, it makes things resonate better, stick in your head better. That's why people like Warhammer 40k despite it not being significantly better or worse than the hundreds of other miniatures games: it has an extremely clear theme. To the point where we non-fans make fun of it. The fun-ness of a game is unrelated to how well themed it is - no reason not to have both. Have a game which is fun to play but also resonates well.
The most powerful tools to create theme are mechanics and setting. Those are the two things that the players touch most often. Obviously a heavy authorial touch will make them feel preachy or one-note, but there's no reason to leave them completely generic.
So, when I see a question asking for a list of all the different kinds of magic systems, my first instinct is to say "what theme?"
Are you trying to create a grungy steampunk setting, full of industrial oppression? Then your magic system should either support the rise of industrial steam (golem/device magic) or it should have been supplanted by that rise (some kind of slow nature magic). Whether it involves spellbooks or limited casts per day or some kind of material or whatever - those are specifics that fall into place pretty quickly when you know what role the magic plays in your world.
One problem is that magic, in particular, tends to dominate these kinds of settings. It's rarely a good idea to separate your classes into "this one can warp the fundamental stuff of the universe and this one can't". IE, the classic "mage/fighter" divide. That's a lazy default that doesn't really make any sense. Every iteration of every fantasy game since the original D&D has struggled to boost the nonmagic classes and nerf the magicians, because fundamentally "magic" is more powerful.
I recommend just accepting that. You can have a wide variety of classes that use or fail to use magic in many different ways. Once you start to invent your mechanics, the class options start to unfold.
For example, if you decide your steampunk game is going to include both a device style magic and a much older nature magic, you can start to lay down classes. First, there's obviously the oldschool nature magician, someone who can call upon life and storm. They are weakened when they can't - being inside is generally bad for them.
On the other end of the spectrum are the steam warriors and engineers. The warriors carry around the big devices - steam drills and pressure cannons and pneumatic armor. The engineers are masters of their craft, which is more like metalbending than anything directly related to steam, so maybe they carry around miniaturized devices that use high-power springs and coils rather than actual steam. It's much lighter... but also has less power.
Since it's basically metalbending, we could have a classic mage of that variety to match our classic nature mage. This would be a blademaster who uses metalbending not to create devices, but to create superhumanly sharp swords and a screen of flying knives. Also, good at picking the huge metal locks people use, so I guess this is our rogue.
As you can see, the classes kind of fall into place. We could continue to create more and more unusual classes if we wanted. For example, a class which has plant fibers woven through their flesh using a variant on the nature magic. However, it's often good to keep the classes pretty obvious, because otherwise you need to do a lot of exposition and explaining about how things work. It's better for it to just be intuitive, at least initially. All these basic, intuitive classes are likely to be the ones that the NPCs are, so therefore they are also powerful social forces that shape the society.
What I mean is that you can build the framework of your industrial oppression on these four basic classes. The nature mages are being oppressed, both by the encroaching industrial cities and systematically by the industry that hates how they get in the way. The engineers are dominant, creating the factories and machines that the industrial cities require. Warriors - and, more generally, users of any kind of steam technology - are the meat of the setting, the middle class. Oldschool metalbenders would come off as obsolete, maybe a religious group or something. You can build your world from these blocks, and it all works out because we kept our eye on the the theme from beginning to end. So even though we didn't create the classes with the society in mind, since both the society and the classes descend from the theme, they still work together.
So... um... that's it, I guess.
Wednesday, April 03, 2013
Complicated Games
I recently took to thinking about complicated games.
Being complicated really limits your player base. For example, Dwarf Fortress is very complex. While its fans are very pleased with it, most people won't play it. Not out of disinterest, but because it's too damn complicated. It's not really a learning curve so much as a learning brick wall.
So most designers make simpler games... or do they?
The things we perceive as simpler games often aren't. For example, the gameplay of a first person shooter is usually taken in stride. But in actuality, this is extremely complex, featuring several kinds of health, cover management, ammunition, weapons with variants, zoom modes, special powers, secondary fire modes, health kits, weapon swapping...
The reason we don't see this kind of game as complex is because the genre has grown it. Any one game is just a little bit more complex than the game before it.
The downside to this is that anyone new to the genre will find the barrier to entry growing higher and higher. They don't have the history of the early games.
Now, one way around this problem is to make a game that is fairly simple at the low level but the player can create complexity. This is Minecraft's approach. Minecraft's early-game difficulty is mostly artificial. Once you understand the very basics of the game (the concept of gathering basic resources and a cheat sheet list of recipes) it's a pretty smooth learning curve as you figure out how to stay alive, build bases, and so on.
Once you understand this, you can start to expand your efforts - taking on monsters, creating traps, digging deeper, training dogs, trading with villages... these are optional tasks you can take on at your own pace and add complexity only as you see fit. The curve isn't perfect, and things frequently get bumpy, and the whole thing is derailed by creative mode, but fundamentally the idea is good. Add in complexity as you feel comfortable.
So I got to thinking: what if we designed our games that way for a while, but without the ugly bump at the beginning? One hidden gotcha to be aware of is that community actually drives a lot of this kind of thing - while some players will certainly experiment with the more complex and difficult elements of the game, far more players will do so if they see someone talking about how awesome it is. As an easy example, in Dwarf Fortress you can pump magma and create excellent magma traps... but it probably wouldn't even occur to many players to do that unless they read about someone else's magma escapades. Not because they're dumb or oblivious, but just because different players notice different things and draw different connections.
My most recent design is for a Power Rangers-style game, where you play geek and team manager. Your primary job is to create the gear that the rangers use with a fun pseudo-mechanical Turing-complete construction kit. The theory can be pushed really far - for example, having each suit able to direct power across to any other suit if they are in dire straights, or automatically kicking into overdrive when injured, or even pumping the right type of light into a ranger to calm them down if they start to lose it. And more that I haven't thought of, I'm sure.
But that makes it really complicated.
Rather than have a tutorial where I try to explain every element and how to use it, what if we embraced the idea of starting simple and letting players choose what complexities to tackle?
So you could start the game off just as a team manager. You don't even do any item creation - you choose the rangers, assign them colors and stock equipment. Set their training regimen, give them advice on how to deal with today's crazy situation.
You can get access to better stock equipment as seasons progress: you get better components, more funding, reverse engineer technologies, and acquire new power sources and devices during plot events. So it's just a wacky team management game.
But you can choose to tackle gear creation. Suits are the easiest - customizing the stock suits to fit each ranger's stat layout would be an easy first step, as would reconfiguring the suits to cause less stress to a particular character.
From here it's a relatively easy descent into more and more complex tasks, until suddenly you find you're building a starship for humankind's exodus, powered solely by the spirit guardians of ancient Mars or whatever.
In this case, part of the lure is just that the gameplay is waiting for you. However, I would actually make a big element of this the difficulty setting you choose to play on. Play on easy? You can keep going with just stock gear, it's okay. On normal you'll need to innovate some, because the the stock gear just isn't perfectly suited to your situation. On hard, you need to wring every iota of performance you can out of every device.
This can be reflected in the enemies. On easy, the enemies generally don't escalate. Even a few seasons in, if you fail to stop them, the repercussions will be relatively minor. On the other hand, on harder difficulties they race ahead to ever more threatening and terrifying levels. Still, those more powerful enemies are associated with weirder and more advanced resources, so if you want to play with the weird stuff, you've got to play on the harder difficulties.
A big part of this would have to be the community. Not only would people be able to share their rangers, devices, and episodes easily, but they also get to share their enemies. Show the most crazily overpowered randomly-generated enemy you encountered, and how he completely trashed your eleven-season 40-ranger team-up using their own children from an alternate future.
Anyway, the point is that I think it'd be a good exercise in design: designing a complicated game that doesn't have a big-ass tutorial or a giant barrier to entry.
Being complicated really limits your player base. For example, Dwarf Fortress is very complex. While its fans are very pleased with it, most people won't play it. Not out of disinterest, but because it's too damn complicated. It's not really a learning curve so much as a learning brick wall.
So most designers make simpler games... or do they?
The things we perceive as simpler games often aren't. For example, the gameplay of a first person shooter is usually taken in stride. But in actuality, this is extremely complex, featuring several kinds of health, cover management, ammunition, weapons with variants, zoom modes, special powers, secondary fire modes, health kits, weapon swapping...
The reason we don't see this kind of game as complex is because the genre has grown it. Any one game is just a little bit more complex than the game before it.
The downside to this is that anyone new to the genre will find the barrier to entry growing higher and higher. They don't have the history of the early games.
Now, one way around this problem is to make a game that is fairly simple at the low level but the player can create complexity. This is Minecraft's approach. Minecraft's early-game difficulty is mostly artificial. Once you understand the very basics of the game (the concept of gathering basic resources and a cheat sheet list of recipes) it's a pretty smooth learning curve as you figure out how to stay alive, build bases, and so on.
Once you understand this, you can start to expand your efforts - taking on monsters, creating traps, digging deeper, training dogs, trading with villages... these are optional tasks you can take on at your own pace and add complexity only as you see fit. The curve isn't perfect, and things frequently get bumpy, and the whole thing is derailed by creative mode, but fundamentally the idea is good. Add in complexity as you feel comfortable.
So I got to thinking: what if we designed our games that way for a while, but without the ugly bump at the beginning? One hidden gotcha to be aware of is that community actually drives a lot of this kind of thing - while some players will certainly experiment with the more complex and difficult elements of the game, far more players will do so if they see someone talking about how awesome it is. As an easy example, in Dwarf Fortress you can pump magma and create excellent magma traps... but it probably wouldn't even occur to many players to do that unless they read about someone else's magma escapades. Not because they're dumb or oblivious, but just because different players notice different things and draw different connections.
My most recent design is for a Power Rangers-style game, where you play geek and team manager. Your primary job is to create the gear that the rangers use with a fun pseudo-mechanical Turing-complete construction kit. The theory can be pushed really far - for example, having each suit able to direct power across to any other suit if they are in dire straights, or automatically kicking into overdrive when injured, or even pumping the right type of light into a ranger to calm them down if they start to lose it. And more that I haven't thought of, I'm sure.
But that makes it really complicated.
Rather than have a tutorial where I try to explain every element and how to use it, what if we embraced the idea of starting simple and letting players choose what complexities to tackle?
So you could start the game off just as a team manager. You don't even do any item creation - you choose the rangers, assign them colors and stock equipment. Set their training regimen, give them advice on how to deal with today's crazy situation.
You can get access to better stock equipment as seasons progress: you get better components, more funding, reverse engineer technologies, and acquire new power sources and devices during plot events. So it's just a wacky team management game.
But you can choose to tackle gear creation. Suits are the easiest - customizing the stock suits to fit each ranger's stat layout would be an easy first step, as would reconfiguring the suits to cause less stress to a particular character.
From here it's a relatively easy descent into more and more complex tasks, until suddenly you find you're building a starship for humankind's exodus, powered solely by the spirit guardians of ancient Mars or whatever.
In this case, part of the lure is just that the gameplay is waiting for you. However, I would actually make a big element of this the difficulty setting you choose to play on. Play on easy? You can keep going with just stock gear, it's okay. On normal you'll need to innovate some, because the the stock gear just isn't perfectly suited to your situation. On hard, you need to wring every iota of performance you can out of every device.
This can be reflected in the enemies. On easy, the enemies generally don't escalate. Even a few seasons in, if you fail to stop them, the repercussions will be relatively minor. On the other hand, on harder difficulties they race ahead to ever more threatening and terrifying levels. Still, those more powerful enemies are associated with weirder and more advanced resources, so if you want to play with the weird stuff, you've got to play on the harder difficulties.
A big part of this would have to be the community. Not only would people be able to share their rangers, devices, and episodes easily, but they also get to share their enemies. Show the most crazily overpowered randomly-generated enemy you encountered, and how he completely trashed your eleven-season 40-ranger team-up using their own children from an alternate future.
Anyway, the point is that I think it'd be a good exercise in design: designing a complicated game that doesn't have a big-ass tutorial or a giant barrier to entry.
Tuesday, April 02, 2013
Bioshock Infinite: Story Analysis
Okay, I finished Bioshock Infinite. It was a lot shorter than I expected, which was good. It was the right length.
Here I'm going to talk in some detail about Infinite's story, full analysis mode. If you haven't played Infinite all the way through, I recommend you stop reading. To say there are spoilers would be an understatement.
...
...
Okay, let's dive into the story and what went right and what went wrong.
The story is very Vonnegut. People talk about how it bears a resemblance to Beauty and the Beast, but actually the story is much more reminiscent of Slaughterhouse 5.
That is to say that the story is full of magic and fairy tale bullshit, but that's just a coping device for the main character. More forgivingly, it's an analogy: I'm not saying that the game takes place entirely in the main character's head, but I am saying that, like many good stories, the events and setting of the story exist to highlight the core conflict of the main character.
This makes it sound like a bit of a masterpiece, but unfortunately the story is riddled with problems, both in terms of structure and in terms of execution.
Let's start with the structural problems.
The story was flabby. Really, really flabby.
The story's theme seems to be "escaping from your cage", with the female lead having a literal cage while the male lead has the cage of his past. It should be clear within just a few short levels that the female lead's literal cage is a reflection of the male lead's figurative cage, which is one of the things that spoiled the ending for me.
However, the theme veers to the side, crashes into a barn, and explodes. The end of the game has nothing to do with escaping cages, and is instead about assassinating you before you can put anyone in a cage.
Now, from a technical perspective it holds together well enough. Everything is logical inside the game world. But it doesn't support the theme as established. Instead of dealing with the idea of the cage, the writers just flip the chessboard over and walk away. Solving the character arc with magic is a big cop-out.
However, here's my thought. I think that the theme was really intended to be "parting with your daughter".
This holds true really well, because now the story is about the feeling of flinging her out into the world into the hands of a strange man versus keeping her locked in a tower all her life.
That would have been a great story. The ending would have worked well with only minor dialog changes: the daughter taking your ability to decide her future away from you and choosing it for herself. That would have been a fucking masterpiece and I literally get chills just thinking about how good it could have been.
However, that is not the theme. The theme is clearly established as being about escaping cages. You can't have two themes, and the first theme wins. You can have a twist ending, but it has to be a twist within the theme, not just randomly shooting off into the weeds.
Either way, there are several other flabby elements to the story. For example, the male lead's history has two pieces: war 'hero' and father. But these two elements compete rather than get along.
The "war" history justifies the character's ability to kill everyone with guns, but that's not something that needs to be explained. It clearly establishes the character's wish to be free of his cage... and it eventually "pays off" in that it explains why he became Comstock. But here's the thing: becoming Comstock only matters if the theme is "parting with your daughter", and the backstory only matters if the theme is "escaping from your cage". So the backstory collapses, supporting neither theme well enough to be worth it.
The "daughter" history would be really good if the theme was "parting with your daughter", but that's the theme the story should have had, not the theme it did. It was "revealed" quite late in the story, long after the theme was established. So this backstory could have stood on its own, but instead it was left too long in the shadow of the wasteful "war" history that consumed half of all the game's plot points.
Furthermore, the floating city should have been a very tight analog for the character's internal struggles... and it wasn't. No matter which theme you prefer, the city's theme was "racism is bad and cults are crazy". Those themes could have also made excellent games... but you have to pick one theme.The Vox Populi's actions don't reflect either of the story's themes, so they are simply wasted words.
Lastly, the ending with all the lighthouses was pretentious twaddle. If the theme had been "roads untravelled", it would have been fine, if a bit on the nose. It does vaguely fit into the "escape your cage" theme, except that the theme has clearly been talking about the metaphysical cage of your past and your family. The escapism of infinite doors leading to infinite possibilities just comes off as sounding like shallow desperation, a betrayal of the idea that there are consequences.
I can imagine different dialog which could have done a better job, but even so it seems like a poor fit for either theme. I can think of better fits.
Now... those were the structural errors. Let's talk about the execution errors. I'll be brief; this is already too long.
The problem with execution lay primarily in two places. The first is the secondary NPCs. None of them felt real. Perhaps that was on purpose, since the city exists solely as a thematic backdrop for the characters' troubles. But I feel they were just poorly executed. They were shallow, had bad dialog, and often took inexplicable actions that only would have made sense if there was a different theme.
But what really pisses me off about them is that they could have fit the theme so well. So well. Talk about escaping cages? The old general chooses to die in his cage. The freedom fighters choose to smash their cage. It could have been excellent. But the connections were never really established, it all just felt wonky and poorly written.
The other problem is with the main character.
An unlikeable main character is a mainstay of short stories. But a video game can't afford it, especially a first-person game where the player feels so much more in tune with the hero. He was just too unlikeable, and I was forced to take responsibility for actions he took, which felt annoying and unfair.
This is not a problem with the fundamental story - it's just an execution faff that left me cold.
Anyway, them's my thoughts.
Here I'm going to talk in some detail about Infinite's story, full analysis mode. If you haven't played Infinite all the way through, I recommend you stop reading. To say there are spoilers would be an understatement.
...
...
Okay, let's dive into the story and what went right and what went wrong.
The story is very Vonnegut. People talk about how it bears a resemblance to Beauty and the Beast, but actually the story is much more reminiscent of Slaughterhouse 5.
That is to say that the story is full of magic and fairy tale bullshit, but that's just a coping device for the main character. More forgivingly, it's an analogy: I'm not saying that the game takes place entirely in the main character's head, but I am saying that, like many good stories, the events and setting of the story exist to highlight the core conflict of the main character.
This makes it sound like a bit of a masterpiece, but unfortunately the story is riddled with problems, both in terms of structure and in terms of execution.
Let's start with the structural problems.
The story was flabby. Really, really flabby.
The story's theme seems to be "escaping from your cage", with the female lead having a literal cage while the male lead has the cage of his past. It should be clear within just a few short levels that the female lead's literal cage is a reflection of the male lead's figurative cage, which is one of the things that spoiled the ending for me.
However, the theme veers to the side, crashes into a barn, and explodes. The end of the game has nothing to do with escaping cages, and is instead about assassinating you before you can put anyone in a cage.
Now, from a technical perspective it holds together well enough. Everything is logical inside the game world. But it doesn't support the theme as established. Instead of dealing with the idea of the cage, the writers just flip the chessboard over and walk away. Solving the character arc with magic is a big cop-out.
However, here's my thought. I think that the theme was really intended to be "parting with your daughter".
This holds true really well, because now the story is about the feeling of flinging her out into the world into the hands of a strange man versus keeping her locked in a tower all her life.
That would have been a great story. The ending would have worked well with only minor dialog changes: the daughter taking your ability to decide her future away from you and choosing it for herself. That would have been a fucking masterpiece and I literally get chills just thinking about how good it could have been.
However, that is not the theme. The theme is clearly established as being about escaping cages. You can't have two themes, and the first theme wins. You can have a twist ending, but it has to be a twist within the theme, not just randomly shooting off into the weeds.
Either way, there are several other flabby elements to the story. For example, the male lead's history has two pieces: war 'hero' and father. But these two elements compete rather than get along.
The "war" history justifies the character's ability to kill everyone with guns, but that's not something that needs to be explained. It clearly establishes the character's wish to be free of his cage... and it eventually "pays off" in that it explains why he became Comstock. But here's the thing: becoming Comstock only matters if the theme is "parting with your daughter", and the backstory only matters if the theme is "escaping from your cage". So the backstory collapses, supporting neither theme well enough to be worth it.
The "daughter" history would be really good if the theme was "parting with your daughter", but that's the theme the story should have had, not the theme it did. It was "revealed" quite late in the story, long after the theme was established. So this backstory could have stood on its own, but instead it was left too long in the shadow of the wasteful "war" history that consumed half of all the game's plot points.
Furthermore, the floating city should have been a very tight analog for the character's internal struggles... and it wasn't. No matter which theme you prefer, the city's theme was "racism is bad and cults are crazy". Those themes could have also made excellent games... but you have to pick one theme.The Vox Populi's actions don't reflect either of the story's themes, so they are simply wasted words.
Lastly, the ending with all the lighthouses was pretentious twaddle. If the theme had been "roads untravelled", it would have been fine, if a bit on the nose. It does vaguely fit into the "escape your cage" theme, except that the theme has clearly been talking about the metaphysical cage of your past and your family. The escapism of infinite doors leading to infinite possibilities just comes off as sounding like shallow desperation, a betrayal of the idea that there are consequences.
I can imagine different dialog which could have done a better job, but even so it seems like a poor fit for either theme. I can think of better fits.
Now... those were the structural errors. Let's talk about the execution errors. I'll be brief; this is already too long.
The problem with execution lay primarily in two places. The first is the secondary NPCs. None of them felt real. Perhaps that was on purpose, since the city exists solely as a thematic backdrop for the characters' troubles. But I feel they were just poorly executed. They were shallow, had bad dialog, and often took inexplicable actions that only would have made sense if there was a different theme.
But what really pisses me off about them is that they could have fit the theme so well. So well. Talk about escaping cages? The old general chooses to die in his cage. The freedom fighters choose to smash their cage. It could have been excellent. But the connections were never really established, it all just felt wonky and poorly written.
The other problem is with the main character.
An unlikeable main character is a mainstay of short stories. But a video game can't afford it, especially a first-person game where the player feels so much more in tune with the hero. He was just too unlikeable, and I was forced to take responsibility for actions he took, which felt annoying and unfair.
This is not a problem with the fundamental story - it's just an execution faff that left me cold.
Anyway, them's my thoughts.
Monday, April 01, 2013
Unbioshock (Idea)
So, let me pitch you some vaporware. Let me describe a game concept. We'll call it "Unbioshock".
For once and only for this essay, I'm not ragging on Bioshock. I am talking about a completely different game idea that I thought was interesting. One inspired by Bioshock. It's still set in the same place, still thematically centered around escaping from cages.
In this game you play a woman who has been locked up in a tiny apartment with a big library. The game starts off there, allowing you to get used to the controls and get a feel for the life of the character. It also lets you get familiar with her hands: she's right handed, but her right index finger is partially missing, replaced by a classy thimble. It's her index finger in our version because we need to have a good reason why she's fit enough to leap fifty feet and zoom along a rail one-handed, but can't fire a gun.
After you summon and send away your bird guardian with the whistling pipe song, the player learns to lockpick and tries to escape. The same pipe song plays and summons the guardian, who takes you back to your cell. You try to run or hide, but it has no problem catching you.
Shortly after this, a man comes and breaks you out of your apartment. This is where the game proper begins.
The game is all about finding a way off the city. Nobody wants to kill you, but they all want to capture you, and you're a frail person who's never been outside her apartment. So you rely heavily on this guy who rescued you. He does all the combat stuff. But there's two problems.
One is that he's dumb as a brick. This means not only is he constantly taking on more than he can chew in combat, it also means he can't actually figure out how to get off the city. You have to help him in combat by tossing him supplies that you find while scrounging around, and patch him up after combat in a doctor minigame. You also have to find the way through the city, picking locks, finding maps, working machinery.
The other problem is that he's a villain. He's violent and wants to take you someplace just as bad as you came from. So there's a big part of the game which is about handling this guy. If you lead him into fights, he gets upset with you and short-tempered, but on the other hand he'll realize he's out of his league in this city. If things go smoothly, he'll be polite and happy... but he'll also be very controlling and dismissive. His opinion can also be affected via other means, such as how you behave towards him, what weapons you insist he use, how you dress, and how you interact with other people. How much money you toss him vs how much money you keep for yourself to spend wisely.
But you notice, there is not really a "good" side to this axis. The brute is either bitter but begrudgingly respectful, or pleasant but extremely controlling. The last choice in the game is whether you free yourself from the thug to live a dangerous life on your own, or whether you trust the thug's judgment and stay with him in a now-hopefully-well-meaning cage.
So the theme here is one of safety and control. It's very much a matter of escaping a cage, just like Bioshock Infinite, but here instead of being a walking death machine, you're someone who is actually in serious trouble. Escaping the cage isn't simply a matter of walking out and then life is hunky-dory: escaping the cage puts you in an incredibly dangerous situation.
You don't even need the magic powers to make this game float. It floats well enough on its "thug management" mechanics. You just have to make sure that the thug can't actually die: he always wins his fights, but the more torn up he is at the end, the less polite he's gonna be. (If the thug can die, the game becomes a particularly nasty escort mission.)
The gameplay itself is half about immersing yourself in the world. There's no fighting mechanics for you: while you're wandering the world, nobody will shoot at you and you can't shoot at anybody. You may occasionally have to hide or run, but by and large you just wander as you please (as long as your thug doesn't object). In the world is a scrounging/supply mechanic, where you look for things and toss your thug things.
The other half of the gameplay are the minigames. Mechanical puzzles, lock picking, and patching up the wounded. These are what allow you to manipulate the world, sometimes to move forward, but sometimes for other advantages. For example, dropping a crate so your thug has cover, or healing an injured soldier that later helps you bypass a fight. Sealing doors, lighting or blacking out hallways, making noise, overloading an energy conduit to make it explode...
The minigames are not always as tension-filled as a first-person shooter would be, but they can be quite tense. As you can see, during combat your primary role is to manipulate the world so that the thug doesn't get too shot up. Sometimes this means doing something to the combat situation (catching some of their attention and leading them on a chase, or sealing a door, or whatever). Sometimes this simply means picking a lock while your thug holds off the hordes.
Anyway, it's an interesting thought. I'd love to play a game like that.
For once and only for this essay, I'm not ragging on Bioshock. I am talking about a completely different game idea that I thought was interesting. One inspired by Bioshock. It's still set in the same place, still thematically centered around escaping from cages.
In this game you play a woman who has been locked up in a tiny apartment with a big library. The game starts off there, allowing you to get used to the controls and get a feel for the life of the character. It also lets you get familiar with her hands: she's right handed, but her right index finger is partially missing, replaced by a classy thimble. It's her index finger in our version because we need to have a good reason why she's fit enough to leap fifty feet and zoom along a rail one-handed, but can't fire a gun.
After you summon and send away your bird guardian with the whistling pipe song, the player learns to lockpick and tries to escape. The same pipe song plays and summons the guardian, who takes you back to your cell. You try to run or hide, but it has no problem catching you.
Shortly after this, a man comes and breaks you out of your apartment. This is where the game proper begins.
The game is all about finding a way off the city. Nobody wants to kill you, but they all want to capture you, and you're a frail person who's never been outside her apartment. So you rely heavily on this guy who rescued you. He does all the combat stuff. But there's two problems.
One is that he's dumb as a brick. This means not only is he constantly taking on more than he can chew in combat, it also means he can't actually figure out how to get off the city. You have to help him in combat by tossing him supplies that you find while scrounging around, and patch him up after combat in a doctor minigame. You also have to find the way through the city, picking locks, finding maps, working machinery.
The other problem is that he's a villain. He's violent and wants to take you someplace just as bad as you came from. So there's a big part of the game which is about handling this guy. If you lead him into fights, he gets upset with you and short-tempered, but on the other hand he'll realize he's out of his league in this city. If things go smoothly, he'll be polite and happy... but he'll also be very controlling and dismissive. His opinion can also be affected via other means, such as how you behave towards him, what weapons you insist he use, how you dress, and how you interact with other people. How much money you toss him vs how much money you keep for yourself to spend wisely.
But you notice, there is not really a "good" side to this axis. The brute is either bitter but begrudgingly respectful, or pleasant but extremely controlling. The last choice in the game is whether you free yourself from the thug to live a dangerous life on your own, or whether you trust the thug's judgment and stay with him in a now-hopefully-well-meaning cage.
So the theme here is one of safety and control. It's very much a matter of escaping a cage, just like Bioshock Infinite, but here instead of being a walking death machine, you're someone who is actually in serious trouble. Escaping the cage isn't simply a matter of walking out and then life is hunky-dory: escaping the cage puts you in an incredibly dangerous situation.
You don't even need the magic powers to make this game float. It floats well enough on its "thug management" mechanics. You just have to make sure that the thug can't actually die: he always wins his fights, but the more torn up he is at the end, the less polite he's gonna be. (If the thug can die, the game becomes a particularly nasty escort mission.)
The gameplay itself is half about immersing yourself in the world. There's no fighting mechanics for you: while you're wandering the world, nobody will shoot at you and you can't shoot at anybody. You may occasionally have to hide or run, but by and large you just wander as you please (as long as your thug doesn't object). In the world is a scrounging/supply mechanic, where you look for things and toss your thug things.
The other half of the gameplay are the minigames. Mechanical puzzles, lock picking, and patching up the wounded. These are what allow you to manipulate the world, sometimes to move forward, but sometimes for other advantages. For example, dropping a crate so your thug has cover, or healing an injured soldier that later helps you bypass a fight. Sealing doors, lighting or blacking out hallways, making noise, overloading an energy conduit to make it explode...
The minigames are not always as tension-filled as a first-person shooter would be, but they can be quite tense. As you can see, during combat your primary role is to manipulate the world so that the thug doesn't get too shot up. Sometimes this means doing something to the combat situation (catching some of their attention and leading them on a chase, or sealing a door, or whatever). Sometimes this simply means picking a lock while your thug holds off the hordes.
Anyway, it's an interesting thought. I'd love to play a game like that.
Subscribe to:
Posts (Atom)