If you were to try to graph all of the interactions of various players over the course of the game, you would end up looking like the insane guy who scribbles nonsense math all over the walls.
While it's important to understand the basics of how players will interact, trying to map it is a nightmare. Not only do players join and unjoin various groups at various times, but "group" isn't even something that really exists... it's just a vague, ever-changing bunch of people who tend to interact.
So, instead of thinking about players as players, I think about them as liquids.
Instead of having Anne and Bob, and having Anne be the good guy and Bob be the geek, I take a different approach. I say that I have a liter of Anne and a liter of Bob.
Like liquids, players adapt to fill whatever situation they are in. They rush towards any gap, regardless as to whether it's at all related to their character. They carry other players along and are carried along, intermingling. They can be smooth or choppy, depending mostly on the situation rather than the player. They slosh around, separate, splash out of the containers and all over the floor...
Obviously, you can take this analogy too far, but the point is that players cannot be thought of as "units". You are grossly oversimplifying if you represent a small game in such a way, and grossly undersimplifying if you represent a large game in such a way. So think of a player as a quantity, not a single unit.
This is important because any game, regardless of size, tends to form a specific number of "groups". "Group" is the wrong word, now that we've taken on liquids as our visual. Instead, these are "whirlpools".
The number of whirlpools depends on the way the game is designed. A game with a lot of careful politicking and secrecy will have a lot more groups than a game built around slapstick and short-sighted violence.
Generally, the games with the fewest secrets and politics will have two whirlpools, whereas games with a lot of secretive politics will often have seven or eight. The average appears to be four, with occasional temporary whirls here and there.
This is completely independent of the number of players in the game. I've played in games with five players that had six or seven distinct groups. I've played (and run) games with two dozen characters that only had three or four groups. I ran a twelve-person game just a few weeks back that only had two groups.
The difficult part in thinking in terms of groups/whirlpools is that we have an instinctive urge to identify them. "This group is psi-cops, that group is rebels..."
But whirlpools are not units any more than players are. The edges are fuzzy, and the center roams around. Plus, they are formed by the motion of the players, not by the intentions of the designer. The designer can build the game to promote whirlpools around and between specific players and things, but depending on how the players splash around, you will end up with whirlpools that don't act like you expect, or don't even exist where you thought they would. Over the course of the game, smaller whirlpools will form here and there, and sometimes they will even collapse the original, designed whirlpools...
There is a lot of chaos to the way that people play games, and as a designer you really need to accept that: fight it, and you end up with terribly dry, boring games. Instead of fighting the chaos, you need to build a game which is robust enough to handle the chaos. If your rebels and your psi-cops end up together, fighting against their common friend, your game still needs to be able to handle that without collapsing in on itself.
The funny thing is, if you design your game to be able to handle this kind of chaos, it usually doesn't have to: if the players deviate from the route you expected, the inherent robustness you've put into the game will guide them back on track, even if you don't intervene. This is because of what forms whirlpools.
Although players themselves can form small whirls pretty much at random, the stable whirlpools always form around keys. Keys are points of focus and, usually, conflict.
For example, if you have a game where the Woodgie-Boodgie of Koof can be used to either save or destroy the world, you will probably end up with two or three whirlpools around that alone: the group that wants to save the world, the group that wants to destroy the world, and probably a third group that wants to save pieces of the world.
It doesn't have to be a thing. For example, if two characters hate each other, that forms a barrier that pushes aligned players apart. If Anne hates Bob and visa-versa, then Charlie will tend to side with one or the other, rather than all three collapsing into a single whirlpool. The strength of this barrier depends mostly on (A) how much social force Anne and Bob can exert to stay separate and (B) whether Anne and Bob play their hatred up or diminish it in favor of getting things done. Both A and B can be tweaked by how you write up their characters in the game, so it's primarily your decision as to how the whirlpools form.
The name of the game is barriers, as you might be able to see. Whirlpools form when two groups of players try to stay separate and conflicting. In the first case, they're arguing over a widget. In the second case, they're favoring one or the other player. Any time you add a conflict or some inability to work together, it builds an invisible wall that can form whirlpools.
There are two basic methods that most designers choose from when it comes to building these walls.
One is to build a convoluted maze of walls: Anne hates Bob, Bob hates Charlie, Charlie hates Donald and Anne but loves Eugene...
The other is to build clear "rooms": Anne, Bob, and Charlie work together. Donald, Eugene, and Fey work together. Oh, and Charlie's a traitor.
The latter has the advantage that it will tend to fall out in similar ways each game. However, that lack of complexity is also a significant problem: when the "teams" are so clear-cut, you'll need to have the rest of the system be very interesting and powerful to keep them thinking and acting, rather than just being bored with a straightforward progression.
In Zombie: The Brain Eatening there were two groups: zombies and humans. It was very clear cut, and that meant that the rest of the game had to be complex enough to keep the players thinking. To that end, the horde were kept constantly distracted by their revolving characters and quest for upgrades. The zombies were driven to actually complete the game, so they were desperately trying to herd the other group...
The maze method of construction is also useful. However, I will tell you what happens: once the waters start to flow, some of the walls will simply crumble under the strain. Anne is supposed to hate Bob, but they really need to work together, so she'll stay in the same group as him. She'll just complain about it.
This isn't bad at all. It adds a lot of spice. But it is less predictable, more subject to the whims of the players. Usually, the same whirlpools will always form, but how much of which players are in which pools will vary hugely. Usually you can tell that a player will probably end up mostly in one of these two major, non-diametrically-opposed groups... but which?
This can lead to imbalance, so it's important for the GMs to keep an eye on the situation and add some extra bulk to the losing side if needed.
...
This theory has more advanced applications.
One thing you have to remember is that whirlpools don't have to be stable. Often, the most fun in a game is watching the whirlpools collide. Not even necessarily in conflict!
To this end, it's often a lot of fun to having moving or disappearing-reappearing walls. For example, if your game has an A plot (the widget can save or doom the world ) and a B plot (aliens are trying to steal human brains), it can be fun to slide the parameters around. The widget can only save the world if the aliens get fed brains... the aliens will leave if you give them the widget... the complexity creates new conflicts and alliances between whirlpools that were not, until that moment, adjacent.
A classic example of how to do this is in any game where you get memory packets as the game goes on. Reading a memory card will make you feel some way about somebody or something.
The downside of memory cards is that the walls they build are generally pretty fragile: if people are working together wholeheartedly, it will take one hell of a memory to break them up. Still, the more experienced players are usually happy to stir the pot, so they will often make mountains out of molehills, at least temporarily.
Another thing I like to do is the sacrificial whirlpool.
In this method, which I used and refined in my 6-7 runs of METEOR!, you build the game so that a lot of small whirlpools form... and one big one. The bad guys form up quick, teaming up rapidly into a whirlpool many times the size of any of the small ones. Even if some of the bad guys aren't participating in that same pool, they are still involved because of how their characters are written and all the information in the game clearly points to them as being involved.
So I basically force them together. But, you know, it doesn't take much force. I kind of push them together with feathers. Even if none of the bad guys talk to each other, their activities will still end up acting in concert...
This one whirlpool is very strong and dangerous, and the bad guys run around taking on the little whirlpools. The heroes are forced together, into one (in later runs, two) giant hero-pool, at which point they go and crush the bad guys. The walls between the heroes are torn down, any problems they have with each other, any incompatibilities are surmounted.
In the end, it produces a fun situation. Fun enough that they wouldn't let me stop running it until I moved away.
But the real weird thing about this is that METEOR! was a game of chaos. At the beginning, I literally handed out random superpowers. I stand around with a stack of superpowers and hand them out, one to each player, at random.
The design of the whirlpools had nothing to do with powers or capabilities. It wasn't done through revealed memories. It was done entirely through the character sheet. It was done entirely through who they remembered and what they thought of people.
And it worked fine. It began chaotically, but quickly smoothed out in every run.
It doesn't take a hammer to arrange your players to form interesting groups. It just takes a feather.
Showing posts with label LARP. Show all posts
Showing posts with label LARP. Show all posts
Saturday, April 12, 2008
Friday, April 11, 2008
LARP Writing, Choice Architecture
So, I've talked about how careful you need to be not to have second-tier characters, to make sure every player will have enough interesting things to do. Now I'm going to talk about the exact opposite: every player has different preferences, so there need to be a variety of unique characters. I'm not saying one character is a spy and another is a cook: I'm talking about the nature of the choices they will make.
As a clear example, let's think about three players. Anne plays a boff-weapon LARP religiously, almost every weekend, even during the winter. Bob has never played a LARP before, and is a bit shy. Charlie has played LARPs and is brilliant, but he's tired as hell because this is the second day of the con and he didn't bother to sleep at all last night.
Each of these players is an asset to the game, but in very different ways. Any player who isn't going out of his way to screw up your game is an asset, because even poor players and imbeciles can be used as sticky widgets and information blockades... but that's getting ahead of myself. We're talking about characters, not play topology. Wheee! Made up words!
Anyway, each of these players is suitable to a different category of character.
Anne is likely to be quite aggressive, and is very well suited to a character with a lot of active, outgoing links. The character who knows everyone, or the character who wants to get things done. Anne's character can definitely be one that gets surrounded by complexity and stress.
Bob is going to be a timid little animal, so his character should be a bit simpler than the others in terms of motivations. Additionally, he isn't going to be aggressive, so instead of having very many outgoing links (people he wants to talk to), he should specialize in incoming links (people who want to talk to him). But, most important, he needs a character with very clear motivations, a character who can safely ignore most of the chaotic intrigue.
Charlie is normally a sparkling, brilliant player, but it's important not to underestimate how much "tired" screws up a player. Tired is generally most relevant in the beginning of the game, because as the game goes on, he'll either wake up a bit or finish falling asleep, and either way the problem is solved. So, while in the late game Charlie is happy to have outgoing connections and be surrounded by complex situations and choices, in the beginning he needs to be pulled into the game using someone like Anne and a cup of coffee.
There are a lot of different kinds of player, of course. There's players that like drama, players that like humor, players that are fine with being in a romance plot or crossdressing or being gay, and there's players that aren't. And, of course, there are the super-players that are good at everything under the sun. Not every game will worry about every kind of player: for example, in a comedy game, if there is a drama plot, it's probably a really silly one that even a newbie could get behind.
If you're designing your game around specific players (or are tweaking characters to fit them), you can usually figure out what kinds of players they are by asking the right questions and begging them to answer honestly. I generally use a multiple-choice questionnaire, including questions about how many LARPs they've played, whether they've ever done any acting, if they're comfortable with romance, whether they're funny, whether they like being confused...
Of course, if you actually know the players, these questionnaires are irrelevant. You should be able to tell what kind of capabilities someone has within ten minutes of meeting them.
The more difficult problem is when you're writing a game "for posterity". You don't know who the players will be.
In this case, you can make your job easier by issuing a few restrictions: "For experienced LARPers only" or "serious drama!" or "a great first LARP!" This will limit the kinds of players that will play.
However, whether you restrict it or not, your real job is to make the characters in the game run the range. You can then cast in much the same way - a simple questionnaire - but the players are assigned to these pre-existing characters.
This is where a lot of LARP writers get sidetracked. They start thinking of characters and writing them down, and they forget the first rule: every character must be worth playing. There should be no second-string characters.
This is not about stapling in a character for the newbie, it is not about adding in shallow, pointless characters that have no longevity or complexity. It is about making your characters have a wide range of suitability. The characters are all integral to the game, the characters are all delightfully complex with roles you can get into. It's just that some are more amenable to experienced gamers, others to new gamers. Some to shy people, some to drama queens. Some to sinister genius, some to hilarious punnery.
If you know that your audience is going to be a specific way - for example, everyone's new, or everyone's tired - you can build your characters to more exactly fit your target audience... of course, if it's ever played by people who aren't in those categories, it will fit poorly...
Anyway, something to keep in mind.
As a clear example, let's think about three players. Anne plays a boff-weapon LARP religiously, almost every weekend, even during the winter. Bob has never played a LARP before, and is a bit shy. Charlie has played LARPs and is brilliant, but he's tired as hell because this is the second day of the con and he didn't bother to sleep at all last night.
Each of these players is an asset to the game, but in very different ways. Any player who isn't going out of his way to screw up your game is an asset, because even poor players and imbeciles can be used as sticky widgets and information blockades... but that's getting ahead of myself. We're talking about characters, not play topology. Wheee! Made up words!
Anyway, each of these players is suitable to a different category of character.
Anne is likely to be quite aggressive, and is very well suited to a character with a lot of active, outgoing links. The character who knows everyone, or the character who wants to get things done. Anne's character can definitely be one that gets surrounded by complexity and stress.
Bob is going to be a timid little animal, so his character should be a bit simpler than the others in terms of motivations. Additionally, he isn't going to be aggressive, so instead of having very many outgoing links (people he wants to talk to), he should specialize in incoming links (people who want to talk to him). But, most important, he needs a character with very clear motivations, a character who can safely ignore most of the chaotic intrigue.
Charlie is normally a sparkling, brilliant player, but it's important not to underestimate how much "tired" screws up a player. Tired is generally most relevant in the beginning of the game, because as the game goes on, he'll either wake up a bit or finish falling asleep, and either way the problem is solved. So, while in the late game Charlie is happy to have outgoing connections and be surrounded by complex situations and choices, in the beginning he needs to be pulled into the game using someone like Anne and a cup of coffee.
There are a lot of different kinds of player, of course. There's players that like drama, players that like humor, players that are fine with being in a romance plot or crossdressing or being gay, and there's players that aren't. And, of course, there are the super-players that are good at everything under the sun. Not every game will worry about every kind of player: for example, in a comedy game, if there is a drama plot, it's probably a really silly one that even a newbie could get behind.
If you're designing your game around specific players (or are tweaking characters to fit them), you can usually figure out what kinds of players they are by asking the right questions and begging them to answer honestly. I generally use a multiple-choice questionnaire, including questions about how many LARPs they've played, whether they've ever done any acting, if they're comfortable with romance, whether they're funny, whether they like being confused...
Of course, if you actually know the players, these questionnaires are irrelevant. You should be able to tell what kind of capabilities someone has within ten minutes of meeting them.
The more difficult problem is when you're writing a game "for posterity". You don't know who the players will be.
In this case, you can make your job easier by issuing a few restrictions: "For experienced LARPers only" or "serious drama!" or "a great first LARP!" This will limit the kinds of players that will play.
However, whether you restrict it or not, your real job is to make the characters in the game run the range. You can then cast in much the same way - a simple questionnaire - but the players are assigned to these pre-existing characters.
This is where a lot of LARP writers get sidetracked. They start thinking of characters and writing them down, and they forget the first rule: every character must be worth playing. There should be no second-string characters.
This is not about stapling in a character for the newbie, it is not about adding in shallow, pointless characters that have no longevity or complexity. It is about making your characters have a wide range of suitability. The characters are all integral to the game, the characters are all delightfully complex with roles you can get into. It's just that some are more amenable to experienced gamers, others to new gamers. Some to shy people, some to drama queens. Some to sinister genius, some to hilarious punnery.
If you know that your audience is going to be a specific way - for example, everyone's new, or everyone's tired - you can build your characters to more exactly fit your target audience... of course, if it's ever played by people who aren't in those categories, it will fit poorly...
Anyway, something to keep in mind.
Thursday, April 10, 2008
LARP Writing, Resolution Mechanics
For anyone who wants a LARP more complicated than a six-person melodrama, conflict resolution is a big part of the game. In LARPs that go on for more than one session (such as Vampire LARPs or various boff-weapon LARPs) the conflict resolution is the game, and the rest is just a momentary scenario.
In essence, the difficulty is in keeping the resolution simple enough that it can be done without being burdening while still being complex enough to make it thought-provoking.
There are a lot of methods of resolving conflict in a LARP, most of which are transparent. Usually there's some kind of tiered system which, if the two in conflict are close enough, devolves to some kind of chance (typically Rock-Paper-Scissors). Some LARPs use a more subtle system, such as giving each player five cards, and letting them choose which to use up in a conflict...
But those are just simple tools to make the game run smoothly. The real issues in conflict resolution don't lie in how you make your decision, but the results of the decision and how it stretches to include other mechanics.
For example, I ran Zombie: The Brain Eatening. I used a simple rock-paper-scissors mechanic, but unlike virtually every other LARP ever, a tie meant that both parties hit the other. This meant that the game had a lot more dying, especially in team situations, where anyone on the other team that you didn't beat in RPS hit you. In essence, any challenge could result in injury unless you were immune to their level of damage (which wasn't very common).
Similarly, everyone had three states: okay, wounded, and dead. This made tracking death fairly straight-forward. There was no HP counter, no doing X damage of Y type.
I'm not saying this is the way to go. You have to consider the results you're aiming for.
For me, I wanted a horde game with an awful lot of dying in it. So, obviously, I chose a ruleset which resulted in people dying. This ruleset is not what you would want if you were running a LARP with longer-lived characters.
Higher complexity is acceptable, especially in games where every character is intended to be complex. The idea with this is that characters should have longer-term effects from their encounters, but not be out of the game unless something extraordinary happened.
Also, not all conflicts are physical. There are a wide variety of conflict types. You might have one for arguing philosophy, or influencing voters, or changing the past, or sneaking. You can choose to centralize, use the same mechanic for all your conflict types. This will make the game feel very conflict-driven. Alternately, you can decentralize, and use various conflict types.
An example of this would be from a vampire LARP, where obfuscate renders you invisible and auspex lets you see invisible people. Instead of explicitly stating things and maybe rock-paper-scissoring, the obfuscator is careful to show his level in the number of fingers he holds up. The auspexor can simply compare for himself. This is a very passive-aggressive method of conflict, and both sides of the equation will often find themselves screwed over pretty much at random from time to time. Sort of what vampire is known for.
I hate vampire LARPs.
Anyway, the point is that you want your game to have a given feel. The types of conflicts you have and what happens when they are resolved will give your game the feel you want. In addition, it can also provide you with grist for entertaining your players if it is deep enough. If it is shallow, that's fine, but you'll have to find some other method to keep them entertained.
There are plenty of fun LARPs that go both ways.
In essence, the difficulty is in keeping the resolution simple enough that it can be done without being burdening while still being complex enough to make it thought-provoking.
There are a lot of methods of resolving conflict in a LARP, most of which are transparent. Usually there's some kind of tiered system which, if the two in conflict are close enough, devolves to some kind of chance (typically Rock-Paper-Scissors). Some LARPs use a more subtle system, such as giving each player five cards, and letting them choose which to use up in a conflict...
But those are just simple tools to make the game run smoothly. The real issues in conflict resolution don't lie in how you make your decision, but the results of the decision and how it stretches to include other mechanics.
For example, I ran Zombie: The Brain Eatening. I used a simple rock-paper-scissors mechanic, but unlike virtually every other LARP ever, a tie meant that both parties hit the other. This meant that the game had a lot more dying, especially in team situations, where anyone on the other team that you didn't beat in RPS hit you. In essence, any challenge could result in injury unless you were immune to their level of damage (which wasn't very common).
Similarly, everyone had three states: okay, wounded, and dead. This made tracking death fairly straight-forward. There was no HP counter, no doing X damage of Y type.
I'm not saying this is the way to go. You have to consider the results you're aiming for.
For me, I wanted a horde game with an awful lot of dying in it. So, obviously, I chose a ruleset which resulted in people dying. This ruleset is not what you would want if you were running a LARP with longer-lived characters.
Higher complexity is acceptable, especially in games where every character is intended to be complex. The idea with this is that characters should have longer-term effects from their encounters, but not be out of the game unless something extraordinary happened.
Also, not all conflicts are physical. There are a wide variety of conflict types. You might have one for arguing philosophy, or influencing voters, or changing the past, or sneaking. You can choose to centralize, use the same mechanic for all your conflict types. This will make the game feel very conflict-driven. Alternately, you can decentralize, and use various conflict types.
An example of this would be from a vampire LARP, where obfuscate renders you invisible and auspex lets you see invisible people. Instead of explicitly stating things and maybe rock-paper-scissoring, the obfuscator is careful to show his level in the number of fingers he holds up. The auspexor can simply compare for himself. This is a very passive-aggressive method of conflict, and both sides of the equation will often find themselves screwed over pretty much at random from time to time. Sort of what vampire is known for.
I hate vampire LARPs.
Anyway, the point is that you want your game to have a given feel. The types of conflicts you have and what happens when they are resolved will give your game the feel you want. In addition, it can also provide you with grist for entertaining your players if it is deep enough. If it is shallow, that's fine, but you'll have to find some other method to keep them entertained.
There are plenty of fun LARPs that go both ways.
Monday, April 07, 2008
LARP Writing, Basics
Hey there!
So you have a great idea for a LARP. But you can't seem to get it to work out as well as you like. What's wrong?
Writing LARPs is a skill, just as complicated as building a boat or painting a portrait. Sure, it's not exactly a respected skill, but just like boat-building and portrait-painting, you will do significantly better if you learn the basics before trying to do it for real.
The basic, fundamental truth of LARPing is that you are not telling a story. You are not building a world. You are not creating beautiful experiences. You are entertaining players.
Imagery, story, worlds, and all the other cool things in your head are methods to entertain, but they are not the foundation. No matter what you're building, you'll want a foundation to build on. So forget the cool ideas you have for a minute and think about players being entertained.
LARPing is an interactive experience, more for some than others. You, as the designer of the LARP, need to give the players ways and reasons to interact. Moreover, you have to give them ways and reasons that will keep them interested over the whole of the game: too many games have "second-string" characters that don't have enough of interest to fill a thimble.
There are two basic "kinds" of ways to put interesting things into the game. The first is called "preloading": this is the character sheets, rules, and so forth. Essentially, you tell the players some things and let them get on with trying to figure out what it all means.
The other method is to introduce content over the course of the game. This is fairly effective because it allows you to pace the game: in theory, you could include everything right at the beginning, and rely on players' natural prevarication to prevent it from spreading and getting solved. In practice, it works better to keep it off the board entirely until a given time or event.
Most games take a solid middle ground, but some games go to extremes.
A short dramatic game often has very little "late content" - many drama games focus on letting the players clash without any kind of significant interference. Note that, while the rules for a drama game might be simple, the game is still very complex due to the personalities and situation involved.
On the other hand, a humorous horde game will usually have a very simple mechanics and content, but spice it up by rapidly swapping out simple content for new simple content, often at random.
No matter whether you write the complexity into your world, your characters, or your timeline, you need to remember that all the players are going to have to interact for as many hours as you run your game. This means that every player is going to need quite a lot of stuff to do and feel.
Generally, if I'm working on a more moderate game with a balanced amount of complexity in character, world, and timeline, I follow this rule:
Every character needs to have at least four connections - people who he has interesting relationships with, plots he needs to accomplish, doohickeys he needs to obtain, things other people want from him, aspects of his personality that give him a reason to feel strongly about in-game events... Usually, I try for five or six.
Not all of them are listed on the character sheet. Usually, only two or three are explicitly listed. The rest are hidden in his character background, his personality, his pockets, his contingency cards, or on the character sheets, backgrounds, personalities, pockets, and contingencies of other characters. If it's a small game, I generally stick to 2-3 to start with, and introduce most of them later. If it's a large game, I generally show most of them up front and have very few late releases.
This level of complexity allows for a player to always have something to do, which is especially important in the early game.
It's not really this straight forward: depending on how things go, you may find that something you thought was going to take a player two hours takes them thirty seconds, or visa-versa. It's also likely that certain players will prefer certain kinds of cues while ignoring others. So it's important to make your game robust, whether you write that robustness into the game or whether it's a GM tweaking on the fly. There are upsides and downsides to both.
Maybe I'll talk about that next.
But, remember: every character, every single character, needs to be connected to a lot of interesting things. Every player must be entertained.
Failure check: If you can separate your characters into main characters and secondary characters, you have failed this module.
So you have a great idea for a LARP. But you can't seem to get it to work out as well as you like. What's wrong?
Writing LARPs is a skill, just as complicated as building a boat or painting a portrait. Sure, it's not exactly a respected skill, but just like boat-building and portrait-painting, you will do significantly better if you learn the basics before trying to do it for real.
The basic, fundamental truth of LARPing is that you are not telling a story. You are not building a world. You are not creating beautiful experiences. You are entertaining players.
Imagery, story, worlds, and all the other cool things in your head are methods to entertain, but they are not the foundation. No matter what you're building, you'll want a foundation to build on. So forget the cool ideas you have for a minute and think about players being entertained.
LARPing is an interactive experience, more for some than others. You, as the designer of the LARP, need to give the players ways and reasons to interact. Moreover, you have to give them ways and reasons that will keep them interested over the whole of the game: too many games have "second-string" characters that don't have enough of interest to fill a thimble.
There are two basic "kinds" of ways to put interesting things into the game. The first is called "preloading": this is the character sheets, rules, and so forth. Essentially, you tell the players some things and let them get on with trying to figure out what it all means.
The other method is to introduce content over the course of the game. This is fairly effective because it allows you to pace the game: in theory, you could include everything right at the beginning, and rely on players' natural prevarication to prevent it from spreading and getting solved. In practice, it works better to keep it off the board entirely until a given time or event.
Most games take a solid middle ground, but some games go to extremes.
A short dramatic game often has very little "late content" - many drama games focus on letting the players clash without any kind of significant interference. Note that, while the rules for a drama game might be simple, the game is still very complex due to the personalities and situation involved.
On the other hand, a humorous horde game will usually have a very simple mechanics and content, but spice it up by rapidly swapping out simple content for new simple content, often at random.
No matter whether you write the complexity into your world, your characters, or your timeline, you need to remember that all the players are going to have to interact for as many hours as you run your game. This means that every player is going to need quite a lot of stuff to do and feel.
Generally, if I'm working on a more moderate game with a balanced amount of complexity in character, world, and timeline, I follow this rule:
Every character needs to have at least four connections - people who he has interesting relationships with, plots he needs to accomplish, doohickeys he needs to obtain, things other people want from him, aspects of his personality that give him a reason to feel strongly about in-game events... Usually, I try for five or six.
Not all of them are listed on the character sheet. Usually, only two or three are explicitly listed. The rest are hidden in his character background, his personality, his pockets, his contingency cards, or on the character sheets, backgrounds, personalities, pockets, and contingencies of other characters. If it's a small game, I generally stick to 2-3 to start with, and introduce most of them later. If it's a large game, I generally show most of them up front and have very few late releases.
This level of complexity allows for a player to always have something to do, which is especially important in the early game.
It's not really this straight forward: depending on how things go, you may find that something you thought was going to take a player two hours takes them thirty seconds, or visa-versa. It's also likely that certain players will prefer certain kinds of cues while ignoring others. So it's important to make your game robust, whether you write that robustness into the game or whether it's a GM tweaking on the fly. There are upsides and downsides to both.
Maybe I'll talk about that next.
But, remember: every character, every single character, needs to be connected to a lot of interesting things. Every player must be entertained.
Failure check: If you can separate your characters into main characters and secondary characters, you have failed this module.
LARP Writing, Intro
I went over to Brandeis for a bit last weekend to play some LARPs. Brandeis is nice enough, lots of space, not really anywhere decent to eat. Kind of the opposite of WPI. Lots of very interesting people, definitely less homogeneous than WPI's gaming crowd.
I actually don't like playing in LARPs. I always regret whatever I did in-game, because I tend to short-circuit the game, even if I try to avoid doing so. I can't stop solving problems whenever I see them, rather than waiting until the end of the LARP... I don't know if it's just me, or what. I play many fewer than I run, but I make sure to play a few every year.
Anyway, I want to write a guide to how to write LARPs. I may not be the best writer of LARPs, and I don't think I've ever made a game without flaws, but I think I've learned enough over the past decade that my viewpoint should be interesting.
So I'm going to spend the week posting a how-to-write-LARPs series of essays. Starting with the fact that Live Action Role Playing Games are very different from other kinds of games, so you have to break out of thinking about them as a world, or a story, or a central party surrounded by NPCs.
If you have any interest in LARPs or in learning a bit about a kind of game you don't have any interest in, keep your eyes open this week. If you're stumbling across this post in the future, click the tag below.
I actually don't like playing in LARPs. I always regret whatever I did in-game, because I tend to short-circuit the game, even if I try to avoid doing so. I can't stop solving problems whenever I see them, rather than waiting until the end of the LARP... I don't know if it's just me, or what. I play many fewer than I run, but I make sure to play a few every year.
Anyway, I want to write a guide to how to write LARPs. I may not be the best writer of LARPs, and I don't think I've ever made a game without flaws, but I think I've learned enough over the past decade that my viewpoint should be interesting.
So I'm going to spend the week posting a how-to-write-LARPs series of essays. Starting with the fact that Live Action Role Playing Games are very different from other kinds of games, so you have to break out of thinking about them as a world, or a story, or a central party surrounded by NPCs.
If you have any interest in LARPs or in learning a bit about a kind of game you don't have any interest in, keep your eyes open this week. If you're stumbling across this post in the future, click the tag below.
Sunday, March 30, 2008
Zombie: The Brain Eatening
This weekend was my old college's Gaming Weekend. Whenever I'm fairly nearby, I always try to run a game or two. Plus, it's a great opportunity to hang out with people who haven't seen you in long enough that they've forgotten how irritating you are.
The big game I ran this year was Zombie: The Brain Eatening. A farcical take on Vampire: The Masquerade, it was a "horde LARP". What this means is that there were five zombies and a large number of people playing walk-on roles as various humans. And, of course, getting eaten by zombies.
The zombies all had clans, like vampires do, and they all had "undisciplines" such as arrrrghiturgy and midbossamalism and amateurian. Potence made you smell really bad, and presents let you put special items down as rewards for quests... instead of spending blood points, you spend brains. And, of course, dying is strictly temporary.
The zombies had their own variant of the Masquerade called the Disco. If a zombie acted unzombielike (or really powerful), the hordelings could shout "DISCO!" and run for it. If they survived, they could respawn as hunters - more powerful, more dangerous, more useful characters. Also, the zombies could dance for health and brains, so it's one of the few games where choreographed team dancing was a major component of the game...
The game was testing a few limits. Every game I run tests aspects of gaming I want to know more about, and this one had a few things I wanted to test.
It went well enough. The room was too small, which was actually a huge problem that totally screwed up one element I was testing: I built it so that the hordelings (the human walk-ons) were supposed to run around pretending to be in a movie, but with a small room they didn't really have enough space to improv properly.
The next test would have involved more complex management of this kind of unguided improv, but the data are dirty because of the small room. I don't know whether I want to do the more advanced test without knowing more about the more limited situations.
The other bits came away clean, though.
One bit was inspired by the fact that I never have enough GMs. I always underestimate how many GMs I need. This game, I made all the zombies GMs:
The zombies were trying to save the world from the six forces trying to make it uninhabitable for zombie-kind. However, to do this they needed to guide the humans into saving the world. Therefore, the zombies were all about putting down quests and trying to finagle the humans into being willing and able to do them.
However, the humans were also the power source of the zombies - they needed brains to do these things, which meant they had to eat humans... and, of course, hunters had more skills to win quests with, but were also significantly more dangerous to zombies...
So, in essence, the zombies were those stereotypical 12-year-old GMs who need you to get through the plot line, but also just want to torture you and kill you a lot.
It worked out pretty well, although it was just a test, so the questing dynamics were a bit oversimplified.
I also wanted to see how much nonverbal communication could be brought to the fore. Although zombies were perfectly capable of talking, if anyone heard them talking, they would call "DISCO!" and turn into a hunter. Almost all of the interactions - combat, special abilities - were done through a limited number of hand gestures. Whole combat sequences could be run without needing any kind of spoken word at all.
This worked out fairly well, but my instructions were muddy at times, so there was more OOC communication than I would have liked. The zombies did develop a nice, subtle method of communicating with both each other and humans (without being clear enough to call Disco).
Also, I wanted the zombies to dance, because I wanted to see how comfortable players were with doing physically dumb stuff in teams. Normally, if you give someone the ability to dance in a game, they'll under-utilize it. Even if they're not the shy sort, dancing is too aggressively outside the normal actions in the LARP. So, I moved normal: I figured, if everyone's dancing, nobody will have any problems with joining in.
This worked absolutely spectacularly: many zombies who probably wouldn't have ever danced on their own were perfectly happy dancing in a team, to the point where they choreographed it. While in the first hour or two attendance was spotty, by halfway through the game zombies would rush over to any dancing zombie to join in and reap the rewards of acting like a silly person.
Actually, it worked really well, because even the humans - who gained no benefit from dancing - would break into dance as well.
The last thing I really wanted to test was the idea of a game that couldn't be LOST. It was physically impossible to lose the game, which makes it almost unique among LARPs. I wanted to see whether or not this significantly affected the way people played the game.
The answer is: no, it doesn't. So long as people have a goal, they'll play to achieve that goal even if there is no force acting against them and no time limit. Which is good to know.
A lot of emergent behavior I had hoped to see came out perfectly clear. For example, although an innocent (normal hordeling) calls Disco when he sees a zombie being weird or uber, once he's a hunter (super hordeling) he can't do that any more. Which gives the zombies no real reason to be careful around him. Over the course of the game, zombies became more cavalier about breaking Disco in front of hunters.
Also, something I had thought might be necessary but wasn't sure: the zombies would purposefully break Disco at endgame to turn innocents into hunters. The greater skills the hunters had were required to achieve the better quests, so one of the zombies would perform a "moster hug" - sprint up to a group of players, trump their combat (waaay overpower for a zombie), and then pat them on the head and run away.
I had allowed for a mechanic where humans could get stronger by searching for equipment. This very simple system would allow humans, if not being eaten by zombies, to power up and power up and power up. The zombies quickly learned that if they were over in a corner trying to figure out what to do, the humans were probably all over in another corner getting power armor, rocket launchers, and bandoliers of grenades.
Anyway, the game accomplished what I wanted it to. I'll have to run the improv test again (probably in a different game), but the others told me a lot. I count it as a success!
The big game I ran this year was Zombie: The Brain Eatening. A farcical take on Vampire: The Masquerade, it was a "horde LARP". What this means is that there were five zombies and a large number of people playing walk-on roles as various humans. And, of course, getting eaten by zombies.
The zombies all had clans, like vampires do, and they all had "undisciplines" such as arrrrghiturgy and midbossamalism and amateurian. Potence made you smell really bad, and presents let you put special items down as rewards for quests... instead of spending blood points, you spend brains. And, of course, dying is strictly temporary.
The zombies had their own variant of the Masquerade called the Disco. If a zombie acted unzombielike (or really powerful), the hordelings could shout "DISCO!" and run for it. If they survived, they could respawn as hunters - more powerful, more dangerous, more useful characters. Also, the zombies could dance for health and brains, so it's one of the few games where choreographed team dancing was a major component of the game...
The game was testing a few limits. Every game I run tests aspects of gaming I want to know more about, and this one had a few things I wanted to test.
It went well enough. The room was too small, which was actually a huge problem that totally screwed up one element I was testing: I built it so that the hordelings (the human walk-ons) were supposed to run around pretending to be in a movie, but with a small room they didn't really have enough space to improv properly.
The next test would have involved more complex management of this kind of unguided improv, but the data are dirty because of the small room. I don't know whether I want to do the more advanced test without knowing more about the more limited situations.
The other bits came away clean, though.
One bit was inspired by the fact that I never have enough GMs. I always underestimate how many GMs I need. This game, I made all the zombies GMs:
The zombies were trying to save the world from the six forces trying to make it uninhabitable for zombie-kind. However, to do this they needed to guide the humans into saving the world. Therefore, the zombies were all about putting down quests and trying to finagle the humans into being willing and able to do them.
However, the humans were also the power source of the zombies - they needed brains to do these things, which meant they had to eat humans... and, of course, hunters had more skills to win quests with, but were also significantly more dangerous to zombies...
So, in essence, the zombies were those stereotypical 12-year-old GMs who need you to get through the plot line, but also just want to torture you and kill you a lot.
It worked out pretty well, although it was just a test, so the questing dynamics were a bit oversimplified.
I also wanted to see how much nonverbal communication could be brought to the fore. Although zombies were perfectly capable of talking, if anyone heard them talking, they would call "DISCO!" and turn into a hunter. Almost all of the interactions - combat, special abilities - were done through a limited number of hand gestures. Whole combat sequences could be run without needing any kind of spoken word at all.
This worked out fairly well, but my instructions were muddy at times, so there was more OOC communication than I would have liked. The zombies did develop a nice, subtle method of communicating with both each other and humans (without being clear enough to call Disco).
Also, I wanted the zombies to dance, because I wanted to see how comfortable players were with doing physically dumb stuff in teams. Normally, if you give someone the ability to dance in a game, they'll under-utilize it. Even if they're not the shy sort, dancing is too aggressively outside the normal actions in the LARP. So, I moved normal: I figured, if everyone's dancing, nobody will have any problems with joining in.
This worked absolutely spectacularly: many zombies who probably wouldn't have ever danced on their own were perfectly happy dancing in a team, to the point where they choreographed it. While in the first hour or two attendance was spotty, by halfway through the game zombies would rush over to any dancing zombie to join in and reap the rewards of acting like a silly person.
Actually, it worked really well, because even the humans - who gained no benefit from dancing - would break into dance as well.
The last thing I really wanted to test was the idea of a game that couldn't be LOST. It was physically impossible to lose the game, which makes it almost unique among LARPs. I wanted to see whether or not this significantly affected the way people played the game.
The answer is: no, it doesn't. So long as people have a goal, they'll play to achieve that goal even if there is no force acting against them and no time limit. Which is good to know.
A lot of emergent behavior I had hoped to see came out perfectly clear. For example, although an innocent (normal hordeling) calls Disco when he sees a zombie being weird or uber, once he's a hunter (super hordeling) he can't do that any more. Which gives the zombies no real reason to be careful around him. Over the course of the game, zombies became more cavalier about breaking Disco in front of hunters.
Also, something I had thought might be necessary but wasn't sure: the zombies would purposefully break Disco at endgame to turn innocents into hunters. The greater skills the hunters had were required to achieve the better quests, so one of the zombies would perform a "moster hug" - sprint up to a group of players, trump their combat (waaay overpower for a zombie), and then pat them on the head and run away.
I had allowed for a mechanic where humans could get stronger by searching for equipment. This very simple system would allow humans, if not being eaten by zombies, to power up and power up and power up. The zombies quickly learned that if they were over in a corner trying to figure out what to do, the humans were probably all over in another corner getting power armor, rocket launchers, and bandoliers of grenades.
Anyway, the game accomplished what I wanted it to. I'll have to run the improv test again (probably in a different game), but the others told me a lot. I count it as a success!
Thursday, June 21, 2007
LARP: Mixing and Matching
One of the basic methods of keeping players entertained in a LARP is to have them "switch off" their friends and partners: spend half an hour with the elf king, spend an hour with the space robot. Switch it up!
This has two results. First, it allows each character to have less plot, since they're only going to be exposing it to any other given character for a few minutes. Second, it allows the various plots and themes to be mixed together as the players problem-solve across a dozen meetings with half a dozen people. "The space robot needs a power source... and the elf king has that magic stone of power..."
Every LARP leans heavily on this "automixing" system, because it (A) feels efficient and (B) means you don't have to get your players to memorize a book before starting.
But there are downsides to this method.
First, it's not really very intuitive. Experienced LARPers know to talk to someone new every time they run out of things to do, but first-time (and even third-time) players tend to stand around looking flummoxed. While this can be reduced by pointing specific people to specific people at specific times, that makes the game feel less like a game and more like a play.
Second, it's extremely hard to predict. Who a player decides to get involved with next depends on proximity, charisma, energy, and whether a given player is busy. As far as I can tell, if you give them specific people to talk to, the game can be modeled to some extent... but the moment you rely on them going out and finding something to do on their own, CRASH.
Lastly, some people work really well together - they have a kind of chemistry.
If you're not forcing mixing, then these two or three players will bond together like glue, totally throwing off the factioning of your game. "Why the hell are the psi-cops working with the rangers?"
If you're forcing mixing, then you're going to lose out on their potential - players with chemistry can produce more immersive content (primarily for themselves) than any writer.
I've run a lot of "strong-story" games to explore this topic, and I don't think I've ever really gone into any detail on them before. So, this weekend: "players are better at playing your game than you, so shut up and let them."
But this post was to highlight a basic (but usually overlooked) component of LARP design. If you've ever played, designed, or run a LARP, take a look: did you see what I described?
This has two results. First, it allows each character to have less plot, since they're only going to be exposing it to any other given character for a few minutes. Second, it allows the various plots and themes to be mixed together as the players problem-solve across a dozen meetings with half a dozen people. "The space robot needs a power source... and the elf king has that magic stone of power..."
Every LARP leans heavily on this "automixing" system, because it (A) feels efficient and (B) means you don't have to get your players to memorize a book before starting.
But there are downsides to this method.
First, it's not really very intuitive. Experienced LARPers know to talk to someone new every time they run out of things to do, but first-time (and even third-time) players tend to stand around looking flummoxed. While this can be reduced by pointing specific people to specific people at specific times, that makes the game feel less like a game and more like a play.
Second, it's extremely hard to predict. Who a player decides to get involved with next depends on proximity, charisma, energy, and whether a given player is busy. As far as I can tell, if you give them specific people to talk to, the game can be modeled to some extent... but the moment you rely on them going out and finding something to do on their own, CRASH.
Lastly, some people work really well together - they have a kind of chemistry.
If you're not forcing mixing, then these two or three players will bond together like glue, totally throwing off the factioning of your game. "Why the hell are the psi-cops working with the rangers?"
If you're forcing mixing, then you're going to lose out on their potential - players with chemistry can produce more immersive content (primarily for themselves) than any writer.
I've run a lot of "strong-story" games to explore this topic, and I don't think I've ever really gone into any detail on them before. So, this weekend: "players are better at playing your game than you, so shut up and let them."
But this post was to highlight a basic (but usually overlooked) component of LARP design. If you've ever played, designed, or run a LARP, take a look: did you see what I described?
Wednesday, May 23, 2007
Simulating LARPs
LARPs - big and small, serial and one-shot - use the same two basic dynamics to drive the overall actions of the players. 1) They use simple logic progressions (I want A, B has A, B wants C for A, D has C...). 2) they use opportunism (Someone's fighting over there! Let's check it out!)
These two basic methods can be simulated fairly easily. The problem is that they exist solely to provide grist for the banter mill: a LARP is all about Role Playing, after all. Sometimes, that's person to person RP. Sometimes, that's person to environment RP. Either way, new situations allow you to have new RP, and that's what the logical progressions and opportunism fuel.
That's not something we know how to simulate. Sure, some of the RP is straight forward: "Give me the dongle or I'll keeeeeeeeeell you!" But the best is far more nuanced, funny, self-referential, and situational. RP isn't about running around mindlessly spouting catch-phrases as you pursue an agenda. RP is about exploring a character as the situation around you changes.
While the overall progression of a LARP can be simulated, it's really not a very interesting thing to do unless you're trying to balance your LARP. The good stuff is the moment-to-moment RP, which we haven't really figured out how to simulate yet.
A computer game that tries to make active NPCs is usually, essentially, trying to simulate a LARP. It's the wrong half of the equation to focus on, in my opinion.
What do you think?
These two basic methods can be simulated fairly easily. The problem is that they exist solely to provide grist for the banter mill: a LARP is all about Role Playing, after all. Sometimes, that's person to person RP. Sometimes, that's person to environment RP. Either way, new situations allow you to have new RP, and that's what the logical progressions and opportunism fuel.
That's not something we know how to simulate. Sure, some of the RP is straight forward: "Give me the dongle or I'll keeeeeeeeeell you!" But the best is far more nuanced, funny, self-referential, and situational. RP isn't about running around mindlessly spouting catch-phrases as you pursue an agenda. RP is about exploring a character as the situation around you changes.
While the overall progression of a LARP can be simulated, it's really not a very interesting thing to do unless you're trying to balance your LARP. The good stuff is the moment-to-moment RP, which we haven't really figured out how to simulate yet.
A computer game that tries to make active NPCs is usually, essentially, trying to simulate a LARP. It's the wrong half of the equation to focus on, in my opinion.
What do you think?
Subscribe to:
Posts (Atom)