I have a grudge against the d20 system. I hate it. I could complain about it all day. I hate it so much that I really can't base this article on it, because I would rant forever.
Restricting myself to one reason I hate it: because hundreds of books have come out for the d20 system. Nothing unifies these books. There is no underlying world, no underlying theme. They're just a bunch of books that have "d20" stamped on the corner.
Because of this, they are compromised. Their promise of a fun and interesting setting is stomped on because they are required to use specific stats, specific conflict resolution methods, specific skills, progressions, dice...
It doesn't make a lick of sense to have a wide range of numeric stats and skills in a game about myth. Fundamentally, mythic adventures are about heroes with superhuman capabilities and flaws. They don't get "12 HP" or a con of "10". They are "stronger than ten mortal men but a temper to match" or "the wisest woman in the land, beware her fell magic!"
The idea of carefully listing out stats and skills is a throwback to the era of wargaming. You can get plenty of complexity and simulationist satisfaction without such crap, and the fact that d20 is basically D&D with all the funny-shaped dice replaced with dodecahedrons makes it fundamentally unsuited for most kinds of adventures.
I see this problem with all "shared" systems, including things like GURPS, Hero, Rifts, D&D, and even the almost unknown ones like d6 and Silhouette. Not to mention the huge number of games which basically use the same system, but aren't affiliated. If it's got stats running from 1-20 and a hundred skills, it's really just D&D.
These systems are often good at a particular kind of story. But they do not limit themselves to that kind of adventure, and instead publish add-ons for adventures that make no sense at all. Like D&D's "legendary" level adventures. D&D's system is fundamentally unsuited for legendary-level characters. The GM basically has to work around the system and hope his players aren't smart enough to pry at the cracks.
This is why I'm pushing for people to create their own system when they create their own setting. You have a great idea about the players all playing clerics? Great! Just don't put it in D&D, because their rules are painfully shattered when it comes to that kind of focus. Build your own system, a system with rules that fundamentally support the various kinds of faiths and capabilities of clerics of various gods.
I realize that I'll probably catch some flak. Someone will probably say, "It's not D&D, it's AD&D 3rd ed, which is completely different". Actually, that's the point: an RPG system is not like Street Fighter. You shouldn't have D&D, AD&D, AD&D Alpha Turbo Edition, etc. You should make a game that does precisely what you want it to do.
If your system doesn't support eight clerics in the party, you shouldn't stretch the system. You should create a new system for an "eight clerics" adventure.
Bah!
Sunday, July 29, 2007
Friday, July 27, 2007
Fun With Basics
This is kind of part of the make your own guide to creating role playing systems. This also stands alone, however, and is interesting on its own.
A sure way to make games more fun is to have an underlying principle that drives the game. This will make the game's fiction more coherent, and the rules can often be part of that fiction.
As an easy example, here's a wacky "science" video. A game could be easily made with this as its underlying principle. This would allow for a "convincing" simulation of species, landmasses, etc. Also, as you start to think about what makes the planet grow, you'll have to come up with an interesting set of physical/metaphysical reasons that will drive the biology, technology, magic... whatever parts of the setting you want. The game would feel very cohesive, and a big part of it is incorporated into the rules - the rules for tech work the way they do not because of some arbitrary reasoning, but because it all fits into the underlying principle.
When you're designing any game of any type, above and beyond the rules you use is how coherent yet diverse the "pattern" of the game is. The easiest way to make a pattern coherent is to relate every bit of it to a specific theme. You don't even have to state the theme - actually, it's generally better not to state it, at first. The coherence will still be there, and players will still feel that the game is "well designed". Long experience has taught me that they can still tell that all the content is "pointing" towards something.
Obviously, the principles don't have to be something so dry as a scientific theory. You might explore an emotion, or the meaning of honor, or the fact that transforming robots are way cool, but the basic idea is that everything in that game is related to the principle. Every character, every piece of setting, every game rule... designed to explore the ramifications of the underlying principle.
I can't stress this enough. Even lighthearted games benefit from underlying principles. Even card games, Flash games, drinking games. The theme can be serious, it can be stupid, it can be funny, it can be scary. It's simply a magnet that draws all the pieces of the game together.
Do you know what I mean?
A sure way to make games more fun is to have an underlying principle that drives the game. This will make the game's fiction more coherent, and the rules can often be part of that fiction.
As an easy example, here's a wacky "science" video. A game could be easily made with this as its underlying principle. This would allow for a "convincing" simulation of species, landmasses, etc. Also, as you start to think about what makes the planet grow, you'll have to come up with an interesting set of physical/metaphysical reasons that will drive the biology, technology, magic... whatever parts of the setting you want. The game would feel very cohesive, and a big part of it is incorporated into the rules - the rules for tech work the way they do not because of some arbitrary reasoning, but because it all fits into the underlying principle.
When you're designing any game of any type, above and beyond the rules you use is how coherent yet diverse the "pattern" of the game is. The easiest way to make a pattern coherent is to relate every bit of it to a specific theme. You don't even have to state the theme - actually, it's generally better not to state it, at first. The coherence will still be there, and players will still feel that the game is "well designed". Long experience has taught me that they can still tell that all the content is "pointing" towards something.
Obviously, the principles don't have to be something so dry as a scientific theory. You might explore an emotion, or the meaning of honor, or the fact that transforming robots are way cool, but the basic idea is that everything in that game is related to the principle. Every character, every piece of setting, every game rule... designed to explore the ramifications of the underlying principle.
I can't stress this enough. Even lighthearted games benefit from underlying principles. Even card games, Flash games, drinking games. The theme can be serious, it can be stupid, it can be funny, it can be scary. It's simply a magnet that draws all the pieces of the game together.
Do you know what I mean?
Wednesday, July 25, 2007
We're Having a Party!
I was commenting on Matthew's comment that he would like to see more things like shared card resources in CRPGs. I started to answer when I realized that, as usual, I have a lot to say.
The big problem with CRPGs in my eyes is that individual characters do not feel like individuals. They're obviously cogs: a warrior is more applicable in some areas than a mage, and less in others, but that just means they're cogs with different teeth.
You could argue that this is because their personality doesn't show through into combat situations. The shy magician casts a fireball exactly the same as the gung-ho mad wizard. There are other arguments, but most of them are variations on this theme.
Sure, characters have stats and equipment, but those really don't have anything to do with their personality, and even when they do, it's boring. A personality really shouldn't be wholly about statistical difference, because that produces a wide range of extremely bland personalities. Characterizations are generally a better approach, and they don't have anything to do with statistical differences.
Some people have tried to make their characters more interesting in combat by adding social proximities and friendships and morale and so forth, but these are not usually very effective. If they were, we'd see them more often, because they're not hard to program.
I really like approaching this problem from a rules perspective. If each character had a bit more "memory", I think this problem could be solved adequately. By "memory" I don't mean actual memory, I mean a method of interacting with the rules of the game in a way that has more ramifications than how much damage you do next turn.
Specifically, let's imagine a Jedi game where your party consists of four or five Jedi. Now, if under the iron grip of the actual IP owners, each Jedi would have a few inapplicable statistics that determine how much ass they kick plus a "lightness" rating. In a more indie environment, your Jedi might have stats which are both personality and skill, such as a "foresight" stat or a "determination" stat.
But I've already waived stats, so let's instead go with decks of cards.
Lets deal each of your Jedi five Force cards. These cards are their cards, not some kind of pooled resource like you might normally see in a CRPG ("99 potions in inventory"). They can, however, give and trade cards, although with whom and what kinds of trades will vary based on their relationship. The cards they are dealt are not wholly random: they are heavily weighted, as I'll explain in a few paragraphs.
The idea here is that any Jedi can use any of the Jedi skills. Each Jedi is particularly good at one or two, but only if they play a particular suite of cards on it. Rylgo is an expert saber-fighter, exceptionally talented so long as he drops hearts. So Rylgo might always be hunting for hearts.
However, each Jedi's mood at any given moment is based on the suits of the cards they hold. And, of course, what cards they are dealt is based on their overall personality (when getting a new hand) or on their recent experiences (refilling a hand by drawing from the local Force).
Because this is a simulated card deck, we can add two categories of cards - "blue back" and "red back". They are the same in terms of skill use, but red backed cards are dark Force and twist your personality to the dark side of the suit. Worse, there's no hand limit for red backed cards. (Or something.)
The end result of this is that everything is linked together. When you try to manage your party, you're not just thinking of how to get a few extra strength points. You have to think about power, applicability, personality, and ethos simultaneously. And each character is an individual whose cards restock automatically based on their personality and mood rather than being wholly handled by you.
It has the potential to be irritating if they are given too much freedom in choosing and trading their own cards (damn it, P'le keeps getting dark side cards without me!), but handled correctly, this sort of thing offers a chance to give characters a distinct personality while amping the tension in combat experiences.
What do you think? Can you think of other methods of making a game where the rules and the character's personalities are deeply intertwined?
Oh, notice that this is not a very complex card system. It could be complexified, adding in poker hands or something, but when you have to manage multiple characters, that gets too complex. About as complex as I'd want to make it is to make their light saber or nonJedi skills especially amped if you play a particular card (IE a nine, or a queen). Any more complex, and trying to optimize four or five hands simultaneously will start to eat the player's brain.
The big problem with CRPGs in my eyes is that individual characters do not feel like individuals. They're obviously cogs: a warrior is more applicable in some areas than a mage, and less in others, but that just means they're cogs with different teeth.
You could argue that this is because their personality doesn't show through into combat situations. The shy magician casts a fireball exactly the same as the gung-ho mad wizard. There are other arguments, but most of them are variations on this theme.
Sure, characters have stats and equipment, but those really don't have anything to do with their personality, and even when they do, it's boring. A personality really shouldn't be wholly about statistical difference, because that produces a wide range of extremely bland personalities. Characterizations are generally a better approach, and they don't have anything to do with statistical differences.
Some people have tried to make their characters more interesting in combat by adding social proximities and friendships and morale and so forth, but these are not usually very effective. If they were, we'd see them more often, because they're not hard to program.
I really like approaching this problem from a rules perspective. If each character had a bit more "memory", I think this problem could be solved adequately. By "memory" I don't mean actual memory, I mean a method of interacting with the rules of the game in a way that has more ramifications than how much damage you do next turn.
Specifically, let's imagine a Jedi game where your party consists of four or five Jedi. Now, if under the iron grip of the actual IP owners, each Jedi would have a few inapplicable statistics that determine how much ass they kick plus a "lightness" rating. In a more indie environment, your Jedi might have stats which are both personality and skill, such as a "foresight" stat or a "determination" stat.
But I've already waived stats, so let's instead go with decks of cards.
Lets deal each of your Jedi five Force cards. These cards are their cards, not some kind of pooled resource like you might normally see in a CRPG ("99 potions in inventory"). They can, however, give and trade cards, although with whom and what kinds of trades will vary based on their relationship. The cards they are dealt are not wholly random: they are heavily weighted, as I'll explain in a few paragraphs.
The idea here is that any Jedi can use any of the Jedi skills. Each Jedi is particularly good at one or two, but only if they play a particular suite of cards on it. Rylgo is an expert saber-fighter, exceptionally talented so long as he drops hearts. So Rylgo might always be hunting for hearts.
However, each Jedi's mood at any given moment is based on the suits of the cards they hold. And, of course, what cards they are dealt is based on their overall personality (when getting a new hand) or on their recent experiences (refilling a hand by drawing from the local Force).
Because this is a simulated card deck, we can add two categories of cards - "blue back" and "red back". They are the same in terms of skill use, but red backed cards are dark Force and twist your personality to the dark side of the suit. Worse, there's no hand limit for red backed cards. (Or something.)
The end result of this is that everything is linked together. When you try to manage your party, you're not just thinking of how to get a few extra strength points. You have to think about power, applicability, personality, and ethos simultaneously. And each character is an individual whose cards restock automatically based on their personality and mood rather than being wholly handled by you.
It has the potential to be irritating if they are given too much freedom in choosing and trading their own cards (damn it, P'le keeps getting dark side cards without me!), but handled correctly, this sort of thing offers a chance to give characters a distinct personality while amping the tension in combat experiences.
What do you think? Can you think of other methods of making a game where the rules and the character's personalities are deeply intertwined?
Oh, notice that this is not a very complex card system. It could be complexified, adding in poker hands or something, but when you have to manage multiple characters, that gets too complex. About as complex as I'd want to make it is to make their light saber or nonJedi skills especially amped if you play a particular card (IE a nine, or a queen). Any more complex, and trying to optimize four or five hands simultaneously will start to eat the player's brain.
Friday, July 20, 2007
Shared Resources
I'm always thinking about new mechanics to bond my players to each other. Most games rely on simple "safety in numbers" mechanics - if your cleric dies, you can't be healed. But that leads to very shallow relationships. "Working" relationships. Sure, players can exceed that, but it's kind of erratic when you have to fight the system.
Those aren't really what I like to see, so I try to use mechanics to make different kinds of relationships. Here are some of them.
Someone Else Narrates for You. I originally saw this method in a game that duplicates that Japanese movie about a high school class being shipped off to a deserted island and forced to kill each other. The idea is that you have to specify a best friend and a rival. If you succeed at something, your best friend narrates what happens. If you fail at something, your rival narrates what happens.
When I first saw it, I was rather taken with the idea, but in playtests it didn't work so well. With five players, a certain person ended up on every single other player's sheet as either rival or friend. They spent a considerable amount of time narrating. Awkward. Also, the position of "rival" is an unenviable one, and if done correctly, makes the players hate each other.
While there's something cool about this mechanic, I don't think it can be used like this.
Unique Card Requirements. In a Jedi game I ran, the Force was represented by cards - each player had a "hand" representing their access to the Force in any given location. Players were allowed to trade cards. At the beginning, trading cards was only done to "supercharge" a given Jedi: "Alex needs to stop the droid army! Everyone, give him all your face cards!" (There was also a noble sacrifice mechanic for Jedi who used more Force than they were supposed to, or used Force in a particular way.)
However, as the game went on, each character began to get specific card combinations that they could use more efficiently. One person would get double points if all the cards they played were hearts. Another needed straits, another needed face cards, another was good with deuces...
A chunk of our table time was therefore dedicated to swapping Force cards. While it sounds like this would break immersion, it really didn't. Perhaps because it made sense for Jedi to spend quite a bit of time communing with each other, perhaps just because of the peculiarities of our player base. But what ended up happening is that they all started to rely on each other far more than usually happens - far more than in other Jedi games I've run.
All Fall Down. I've seen a mechanic like this in many games, although I've never used it myself. Basically, the players have a shared set of... something. As they do cool stuff, they have to reduce that resource. At some point - exactly when is unknown - the resource will fall, and the player will die.
An example is using a Jenga tower: every time you need to succeed, you need to remove a piece. If it falls, you die. Another example is a simple card deck: draw two cards, put one back on top of the deck. If you keep a joker, you die.
These mechanics are interesting and work very well, so long as you're doing a relatively short narrative arc - one or two sessions. There's something about the randomness inherent in the system that makes it unsuitable for longer arcs, which generally have a stronger emotional investment on the player's part.
Source Control. In this kind of system, in order to do something, a player must use another character somehow. Generally, this is some kind of karmic link or psychic power source or something. However, it drains the second character somewhat.
This kind of system generally produces very political gameplay, because resources are limited and negotiation is king. When it actually harms you to help someone, players generally start bartering rather than simply being friends.
However, if the mechanic doesn't rely on limited resources, it can produce very interesting, deep relationships. For example, in order to use magic, you need to draw on your relationship to another character by partaking of that relationship. IE, friends have to banter, rivals have to try to out do each other, masters have to be obeyed, etc. If each kind of relationship can also only provide specific kinds of fuels, you can have characters who are actively searching for rivals, or masters, or lovers, or whatever. It's still very political, but in a very... narrativistic way, rather than a statistical way.
...
Can you think of any other methods of shared resources which get players to work together? Have you ever run a game with anything like this?
Actually, I don't think I have any GMs who read this blog. It's mostly computer gamers. I should probably stop posting this RP stuff.
Those aren't really what I like to see, so I try to use mechanics to make different kinds of relationships. Here are some of them.
Someone Else Narrates for You. I originally saw this method in a game that duplicates that Japanese movie about a high school class being shipped off to a deserted island and forced to kill each other. The idea is that you have to specify a best friend and a rival. If you succeed at something, your best friend narrates what happens. If you fail at something, your rival narrates what happens.
When I first saw it, I was rather taken with the idea, but in playtests it didn't work so well. With five players, a certain person ended up on every single other player's sheet as either rival or friend. They spent a considerable amount of time narrating. Awkward. Also, the position of "rival" is an unenviable one, and if done correctly, makes the players hate each other.
While there's something cool about this mechanic, I don't think it can be used like this.
Unique Card Requirements. In a Jedi game I ran, the Force was represented by cards - each player had a "hand" representing their access to the Force in any given location. Players were allowed to trade cards. At the beginning, trading cards was only done to "supercharge" a given Jedi: "Alex needs to stop the droid army! Everyone, give him all your face cards!" (There was also a noble sacrifice mechanic for Jedi who used more Force than they were supposed to, or used Force in a particular way.)
However, as the game went on, each character began to get specific card combinations that they could use more efficiently. One person would get double points if all the cards they played were hearts. Another needed straits, another needed face cards, another was good with deuces...
A chunk of our table time was therefore dedicated to swapping Force cards. While it sounds like this would break immersion, it really didn't. Perhaps because it made sense for Jedi to spend quite a bit of time communing with each other, perhaps just because of the peculiarities of our player base. But what ended up happening is that they all started to rely on each other far more than usually happens - far more than in other Jedi games I've run.
All Fall Down. I've seen a mechanic like this in many games, although I've never used it myself. Basically, the players have a shared set of... something. As they do cool stuff, they have to reduce that resource. At some point - exactly when is unknown - the resource will fall, and the player will die.
An example is using a Jenga tower: every time you need to succeed, you need to remove a piece. If it falls, you die. Another example is a simple card deck: draw two cards, put one back on top of the deck. If you keep a joker, you die.
These mechanics are interesting and work very well, so long as you're doing a relatively short narrative arc - one or two sessions. There's something about the randomness inherent in the system that makes it unsuitable for longer arcs, which generally have a stronger emotional investment on the player's part.
Source Control. In this kind of system, in order to do something, a player must use another character somehow. Generally, this is some kind of karmic link or psychic power source or something. However, it drains the second character somewhat.
This kind of system generally produces very political gameplay, because resources are limited and negotiation is king. When it actually harms you to help someone, players generally start bartering rather than simply being friends.
However, if the mechanic doesn't rely on limited resources, it can produce very interesting, deep relationships. For example, in order to use magic, you need to draw on your relationship to another character by partaking of that relationship. IE, friends have to banter, rivals have to try to out do each other, masters have to be obeyed, etc. If each kind of relationship can also only provide specific kinds of fuels, you can have characters who are actively searching for rivals, or masters, or lovers, or whatever. It's still very political, but in a very... narrativistic way, rather than a statistical way.
...
Can you think of any other methods of shared resources which get players to work together? Have you ever run a game with anything like this?
Actually, I don't think I have any GMs who read this blog. It's mostly computer gamers. I should probably stop posting this RP stuff.
Wednesday, July 18, 2007
MYO: Building a Rule Chain
This is part of the make your own guide to creating role playing systems.
Every game has a rule chain. From the simplest game of Pac Man to the most complicated version of AD&D, it's all built around this same concept. I've gone and refined it a bit to be somewhat clearer.
To make it really easy on you, I've broken it into steps. Basically, you follow these steps until you think your game world has enough complexity to keep your players interested.
This isn't about working out all the rules or the percentages. It's about having a guide that shows you how your game is played. Building a game with too much precision too early is a bad idea - that's how AD&D came into being, and that's why it's such a hodge-podge. This will help you lay the foundation for your game system.
When making a system, I suggest writing stuff down on a blank piece of paper "flowchart" style. I'll give instructions on how to do that, too.
1: The Primary Purpose of Conflicts
All games feature a central purpose - something that the players and GM try to accomplish. In D&D, it's reducing HP. In many more modern games, it's to tell a piece of story. There are thousands of possible purposes, choose one that suits you.
But remember, this is the primary conflict you're designing here, not the primary reason for playing. D&D's rules are built around reducing an enemy's HP, but the actual reason for playing is to have adventures. If "having adventures" is going to be the central conflict, then people would roll dice to have adventures rather than having adventures in which they roll dice.
I draw the purpose of a conflict in a triangle at the bottom of the page.
2: Basic Resolution
Now that you know the basic conflict, you need to know how it is usually resolved. For example, in D&D you roll dice to reduce HP, whereas in, say, FastLane, you bet chips on a roulette wheel for the right to tell a piece of the story. D&D's resolution is parallel - IE, enemies can reduce each other's HP simultaneously. FastLane, on the other hand, is perpendicular, in that if one person wins, another person (often the GM) loses.
This describes what kind of resolution systems you might choose, but anything will work, even rock paper scissors or making funny noises until someone laughs.
I draw resolution methods as circles above whatever they resolve, and connect them to their purposes with lines.
3: Add in a Modifier
A modifier is a method of giving a statistical benefit to one side or another. For example, a weapon in D&D allows players to reduce the HP of the enemy different amounts. In FastLane, having a chip pool allows you to bid various amounts of chips on the roulette wheel, allowing you to modulate your chances of victory and failure.
In D&D, rolling to hit is also a modifier. Instead of offering a sure but erratic bonus (2d6 vs 1d8 + 2 damage) it offers an erratic but sure bonus (you get to hit or not, period). This makes it more interesting than simply hitting, because now a beastie can have low HP but be hard to hit, whereas without this modifier all that mattered was the beastie's HP.
The basic rule is that a modifier lets a player express their intents and personalities more clearly. Having a chip pool lets a player be risky or safe, having a to-hit die allows players to specialize in damage or hits (or bypassing the need to roll hits).
I draw modifiers as boxes above whatever they modify, connected with a line.
4: Split the Approach
It's important to let players approach things in distinct ways by "going behind the back" of a modifier. This can be thought of as assigning modifiers to a modifier.
In D&D, the "weapons" modifier allows you to use different dice and bonuses to deal damage. However, having a weapon is not the only method of doing that. You can use techniques or be a mage. So, the "weapons" modifier has three "paths" - "weapons", "techniques", and "magic". Don't worry about the clumsy naming.
In FastLane, how you change the number of chips in your pool varies. The paths are "Betting/winning", "favor calling/granting", "Ability use", "statistic burn", "life risk", and so on. This is a lot of approaches, but you don't have to come up with thirty approaches at once. You can add more approaches at any time, and it's better to do it in small increments.
While a modifier allows a player to express themselves statistically, an approach allows players to express themselves categorically. They can choose to act like a monk, or a warrior, or a mage, or whatever. An approach can be semipermanent (such as choosing a class) but doesn't have to be.
I make approaches diamonds or rounded squares and put them near the things they modify, connected with a line.
5: Add in a New Conflict Type
Using any of the things you've created, add a new kind of goal it can resolve.
For example, in D&D you can use the "to hit" modifier to resolve noncombat challenges such as picking pockets or applying medicine. You can use the "weapon" modifier to do noncombat things such as healing, seeing in the dark, etc. Putting it under the "weapon" modifier rather than the "weapon" or "magic" approach means that any approach will have these noncombat methods, rather than only one of them. This allows for torches, spells of light, and light related techniques, for example.
In FastLane (or just about any game), the ability to improve your character by spending points is an end goal that gets added at this stage.
Be as specific or general as you like, and choose anything. Don't worry if the resolution method seems dodgy. That will all fall into place.
These give the players who choose different paths different capabilities, making them more unique. They are especially needed in places where you want the gameplay to be more complex than it already is.
I draw new conflicts as triangles beneath whatever controls them.
6: Clean Up
Look over your map. Does anything have an awful lot of connections to the same kind of shape? See if you can condense that into one or two much less specific shapes. An example of this would be the dozens of approaches to your chip pool in FastLane. they can be broken into two basic modifiers: adding chips to/from your pool and adding chips to your bet. Then those can have approaches.
Does anything seem awkward or lonely? See if you can move it to a more root branch. An example of this would be if you wrote "noncombat stuff" as a goal underneath "magic", and decided that it would make more sense if items could accomplish at least some noncombat stuff, such as nets, food, etc. So you roll the goal down to the "weapon modifier" rather than the "magic approach".
If something is misnamed, rename it. For example, the "weapon" approach and modifier allow you to address noncombat issues, so it's best to rename them "item".
This step is pretty important, as it will help you keep your game from getting too flabby and special-caseist.
7: Scrap it?
If what you see doesn't appeal or doesn't make sense, scrap it and start over. Seriously. It's no big loss.
8: Goto 2
Go back to step two and run through them again, but don't focus on whatever part you were focusing on before. Focus on whatever you want to have more depth.
For example, in D&D we can go back and focus on the "weapons" approach (now the "items" approach, since it's not all combat based any more). We don't want anyone to be able to get any weapon, so we add a resolution method: you can have weapons you buy or find. Then we can add modifiers to buying, so that we use gold pieces to try to buy stuff.
In fact, D&D is full of iteration. Range vs melee, saving throws, skills, stats - all of them are these same chains applied in slightly different ways.
This will also happen in game. For example, in the first tests of the first D&D, I'm sure there was no such thing as poisoned weapons. But then someone said, "I should be able to poison my weapon!" and hence poison was introduced. You can go in and add a poison modifier whereever it should be added, then run through the steps to make sure to balance it with approaches and limitations and so forth.
Here's a demo picture because everyone likes demo pictures.
Please notice that "favors" is an approach to the pool, but in the actual game, it's also fed by the pool. It's an approach and a goal simultaneously. To keep things clean, I just leave it as an approach. If you feel the urge, you can make the line a double-headed arrow.
This is mostly for YOUR use, so it only has to make sense to you.
Every game has a rule chain. From the simplest game of Pac Man to the most complicated version of AD&D, it's all built around this same concept. I've gone and refined it a bit to be somewhat clearer.
To make it really easy on you, I've broken it into steps. Basically, you follow these steps until you think your game world has enough complexity to keep your players interested.
This isn't about working out all the rules or the percentages. It's about having a guide that shows you how your game is played. Building a game with too much precision too early is a bad idea - that's how AD&D came into being, and that's why it's such a hodge-podge. This will help you lay the foundation for your game system.
When making a system, I suggest writing stuff down on a blank piece of paper "flowchart" style. I'll give instructions on how to do that, too.
1: The Primary Purpose of Conflicts
All games feature a central purpose - something that the players and GM try to accomplish. In D&D, it's reducing HP. In many more modern games, it's to tell a piece of story. There are thousands of possible purposes, choose one that suits you.
But remember, this is the primary conflict you're designing here, not the primary reason for playing. D&D's rules are built around reducing an enemy's HP, but the actual reason for playing is to have adventures. If "having adventures" is going to be the central conflict, then people would roll dice to have adventures rather than having adventures in which they roll dice.
I draw the purpose of a conflict in a triangle at the bottom of the page.
2: Basic Resolution
Now that you know the basic conflict, you need to know how it is usually resolved. For example, in D&D you roll dice to reduce HP, whereas in, say, FastLane, you bet chips on a roulette wheel for the right to tell a piece of the story. D&D's resolution is parallel - IE, enemies can reduce each other's HP simultaneously. FastLane, on the other hand, is perpendicular, in that if one person wins, another person (often the GM) loses.
This describes what kind of resolution systems you might choose, but anything will work, even rock paper scissors or making funny noises until someone laughs.
I draw resolution methods as circles above whatever they resolve, and connect them to their purposes with lines.
3: Add in a Modifier
A modifier is a method of giving a statistical benefit to one side or another. For example, a weapon in D&D allows players to reduce the HP of the enemy different amounts. In FastLane, having a chip pool allows you to bid various amounts of chips on the roulette wheel, allowing you to modulate your chances of victory and failure.
In D&D, rolling to hit is also a modifier. Instead of offering a sure but erratic bonus (2d6 vs 1d8 + 2 damage) it offers an erratic but sure bonus (you get to hit or not, period). This makes it more interesting than simply hitting, because now a beastie can have low HP but be hard to hit, whereas without this modifier all that mattered was the beastie's HP.
The basic rule is that a modifier lets a player express their intents and personalities more clearly. Having a chip pool lets a player be risky or safe, having a to-hit die allows players to specialize in damage or hits (or bypassing the need to roll hits).
I draw modifiers as boxes above whatever they modify, connected with a line.
4: Split the Approach
It's important to let players approach things in distinct ways by "going behind the back" of a modifier. This can be thought of as assigning modifiers to a modifier.
In D&D, the "weapons" modifier allows you to use different dice and bonuses to deal damage. However, having a weapon is not the only method of doing that. You can use techniques or be a mage. So, the "weapons" modifier has three "paths" - "weapons", "techniques", and "magic". Don't worry about the clumsy naming.
In FastLane, how you change the number of chips in your pool varies. The paths are "Betting/winning", "favor calling/granting", "Ability use", "statistic burn", "life risk", and so on. This is a lot of approaches, but you don't have to come up with thirty approaches at once. You can add more approaches at any time, and it's better to do it in small increments.
While a modifier allows a player to express themselves statistically, an approach allows players to express themselves categorically. They can choose to act like a monk, or a warrior, or a mage, or whatever. An approach can be semipermanent (such as choosing a class) but doesn't have to be.
I make approaches diamonds or rounded squares and put them near the things they modify, connected with a line.
5: Add in a New Conflict Type
Using any of the things you've created, add a new kind of goal it can resolve.
For example, in D&D you can use the "to hit" modifier to resolve noncombat challenges such as picking pockets or applying medicine. You can use the "weapon" modifier to do noncombat things such as healing, seeing in the dark, etc. Putting it under the "weapon" modifier rather than the "weapon" or "magic" approach means that any approach will have these noncombat methods, rather than only one of them. This allows for torches, spells of light, and light related techniques, for example.
In FastLane (or just about any game), the ability to improve your character by spending points is an end goal that gets added at this stage.
Be as specific or general as you like, and choose anything. Don't worry if the resolution method seems dodgy. That will all fall into place.
These give the players who choose different paths different capabilities, making them more unique. They are especially needed in places where you want the gameplay to be more complex than it already is.
I draw new conflicts as triangles beneath whatever controls them.
6: Clean Up
Look over your map. Does anything have an awful lot of connections to the same kind of shape? See if you can condense that into one or two much less specific shapes. An example of this would be the dozens of approaches to your chip pool in FastLane. they can be broken into two basic modifiers: adding chips to/from your pool and adding chips to your bet. Then those can have approaches.
Does anything seem awkward or lonely? See if you can move it to a more root branch. An example of this would be if you wrote "noncombat stuff" as a goal underneath "magic", and decided that it would make more sense if items could accomplish at least some noncombat stuff, such as nets, food, etc. So you roll the goal down to the "weapon modifier" rather than the "magic approach".
If something is misnamed, rename it. For example, the "weapon" approach and modifier allow you to address noncombat issues, so it's best to rename them "item".
This step is pretty important, as it will help you keep your game from getting too flabby and special-caseist.
7: Scrap it?
If what you see doesn't appeal or doesn't make sense, scrap it and start over. Seriously. It's no big loss.
8: Goto 2
Go back to step two and run through them again, but don't focus on whatever part you were focusing on before. Focus on whatever you want to have more depth.
For example, in D&D we can go back and focus on the "weapons" approach (now the "items" approach, since it's not all combat based any more). We don't want anyone to be able to get any weapon, so we add a resolution method: you can have weapons you buy or find. Then we can add modifiers to buying, so that we use gold pieces to try to buy stuff.
In fact, D&D is full of iteration. Range vs melee, saving throws, skills, stats - all of them are these same chains applied in slightly different ways.
This will also happen in game. For example, in the first tests of the first D&D, I'm sure there was no such thing as poisoned weapons. But then someone said, "I should be able to poison my weapon!" and hence poison was introduced. You can go in and add a poison modifier whereever it should be added, then run through the steps to make sure to balance it with approaches and limitations and so forth.
Here's a demo picture because everyone likes demo pictures.
Please notice that "favors" is an approach to the pool, but in the actual game, it's also fed by the pool. It's an approach and a goal simultaneously. To keep things clean, I just leave it as an approach. If you feel the urge, you can make the line a double-headed arrow.
This is mostly for YOUR use, so it only has to make sense to you.
Tuesday, July 17, 2007
Tabletop Review: The Princes' Kingdom
I think my new favorite tabletop RPG designer is a man with the unlikely name of "Clinton R Nixon".
On a recent excursion to the local geek shop, I picked up half a dozen indie RPGs, and the one I left until last was a thin little number obviously geared towards children.
A thin little children's game with a level of clarity and grace and depth of play that I haven't seen much!
It's a game that's a bit like Narnia: the players all play children between 6 and 12 years old, princes of their island chain. The game revolves around them visiting various islands you invent and solving problems like good little princes should.
By page 15, I was pretty uninterested. Premise, premise, premise, all told as if to children. Expected, but still boring. On page 16, I began to get interested.
See, the age of your prince really matters. Young princes get to specify a lot more cool powers than older princes, and older princes get more flat dice. I don't know how intentional the choice was, but it fits beautifully into what a child at a given age is likely to be able to do: at a young age, using whatever's handy as a hammer. At an older age, having to struggle to apply what few tools you have while working out the numbers and tactics of the dice. Essentially, gaining responsibility and the need to look forward as you get older.
In theory, adults who choose a given age of prince can be lured into the same mindset by this, although I can't say for sure.
The laws of the land and the island creation routine are deceptively simple but offer an astonishingly good framework for creating adventures with nuggets of hard choice at their core.
Now, I do think there are too many pieces to everything. It's a slightly flabby design: a bit too structured for my taste. But that's personal opinion. I like my clean simplicity, and I don't see any rules reason that a relationship, a thing, and a capability should be treated differently. They all offer the same die-related effects.
But structure is important to newbies, especially children, so I can see the value in doing it that way. It just... rakes on my nerves a little. My instinct would either be to make them fundamentally different rule-side, or to combine them.
Ha, such a tiny complaint. That's how good the game design is.
So I just went and bought his other two games. On PDF. I almost never buy on PDF.
On a recent excursion to the local geek shop, I picked up half a dozen indie RPGs, and the one I left until last was a thin little number obviously geared towards children.
A thin little children's game with a level of clarity and grace and depth of play that I haven't seen much!
It's a game that's a bit like Narnia: the players all play children between 6 and 12 years old, princes of their island chain. The game revolves around them visiting various islands you invent and solving problems like good little princes should.
By page 15, I was pretty uninterested. Premise, premise, premise, all told as if to children. Expected, but still boring. On page 16, I began to get interested.
See, the age of your prince really matters. Young princes get to specify a lot more cool powers than older princes, and older princes get more flat dice. I don't know how intentional the choice was, but it fits beautifully into what a child at a given age is likely to be able to do: at a young age, using whatever's handy as a hammer. At an older age, having to struggle to apply what few tools you have while working out the numbers and tactics of the dice. Essentially, gaining responsibility and the need to look forward as you get older.
In theory, adults who choose a given age of prince can be lured into the same mindset by this, although I can't say for sure.
The laws of the land and the island creation routine are deceptively simple but offer an astonishingly good framework for creating adventures with nuggets of hard choice at their core.
Now, I do think there are too many pieces to everything. It's a slightly flabby design: a bit too structured for my taste. But that's personal opinion. I like my clean simplicity, and I don't see any rules reason that a relationship, a thing, and a capability should be treated differently. They all offer the same die-related effects.
But structure is important to newbies, especially children, so I can see the value in doing it that way. It just... rakes on my nerves a little. My instinct would either be to make them fundamentally different rule-side, or to combine them.
Ha, such a tiny complaint. That's how good the game design is.
So I just went and bought his other two games. On PDF. I almost never buy on PDF.
Mysterious Mysteries: Using Imperfect Information
In games, it's not all what actions your players can take. Just as important is what makes them take those actions.
Some games are built around the idea of perfect information, but the vast majority of games use imperfect information. By revealing specific bits of information at the right times, the games can make the player try to guess what is really backing that up, and respond appropriately.
For example, a first person game is inherently about restricting information to what you can "see". Sure, there's a whole level programmed into the system, but you can only see bits of it at a time. You don't know for sure whether there's going to be a monster around the corner, or even what kind of room will be through the door. But you can make predictions and prep accordingly: if you're expecting tight little corridors, you equip the shotgun. Large rooms? Equip the sniper rifle.
Your memory of the places you've already been usually plays a big role in helping you navigate. Constructing this internal map is often a big part of these games, because the amount of information they show you at any given time is so restricted.
Of course, depending on how predictable the developers are, you can learn to predict the level better than they intend. For example, in Doom III I could predict where the monsters were going to teleport in so accurately that I would literally be looking at them when they teleported in, even though the level designers obviously (too obviously) intended them to pop in behind you.
This is true in almost every game. An RPG with random encounters quickly trains you to predict what kind of creatures you can expect to run into and equip yourself accordingly. Even though you have no warning as to exactly when you'll be attacked, you're still ready for it.
Building these contextual maps - whether they are what monsters to expect or where your enemy is likely to be or the layout of the level - is a big part of playing games and an integral part of what makes a game fun. Even games with perfect information such as chess or go still revolve around building context maps of the kinds of maneuvers that work best in various situations and what your enemy is likely to do.
To that end, when you're designing a game, think hard about what you're going to hide and what you'll reveal, and when. "Juicy" gameplay is more than just showing an animation whenever the player clicks a button: it's about revealing something in response to the player's action. That reveal might be a feedback loop's response: shoot the bad guy, he dies. That reveal could also just be to reveal another piece of the world: the next little part of the plot, or a temporarily enlarged view radius, or a trajectory prediction.
This facet of game design is too often overlooked in favor of trying to come up with fantastic new game play. But, frankly, you can use stale game play and, if you make the reveals juicy enough, nobody will even think to complain. They'll just call it "the best of its genre."
Good examples of this technique can be found in Psychonauts, Beyond Good and Evil, Halo, Baldur's Gate, Prince of Persia, Civilization... basically any really good game will have a very polished pace that revolves largely around knowing when to reveal new bits of plot, map, gameplay elements, and/or fun side stuff.
How do your favorite games use the reveal?
Some games are built around the idea of perfect information, but the vast majority of games use imperfect information. By revealing specific bits of information at the right times, the games can make the player try to guess what is really backing that up, and respond appropriately.
For example, a first person game is inherently about restricting information to what you can "see". Sure, there's a whole level programmed into the system, but you can only see bits of it at a time. You don't know for sure whether there's going to be a monster around the corner, or even what kind of room will be through the door. But you can make predictions and prep accordingly: if you're expecting tight little corridors, you equip the shotgun. Large rooms? Equip the sniper rifle.
Your memory of the places you've already been usually plays a big role in helping you navigate. Constructing this internal map is often a big part of these games, because the amount of information they show you at any given time is so restricted.
Of course, depending on how predictable the developers are, you can learn to predict the level better than they intend. For example, in Doom III I could predict where the monsters were going to teleport in so accurately that I would literally be looking at them when they teleported in, even though the level designers obviously (too obviously) intended them to pop in behind you.
This is true in almost every game. An RPG with random encounters quickly trains you to predict what kind of creatures you can expect to run into and equip yourself accordingly. Even though you have no warning as to exactly when you'll be attacked, you're still ready for it.
Building these contextual maps - whether they are what monsters to expect or where your enemy is likely to be or the layout of the level - is a big part of playing games and an integral part of what makes a game fun. Even games with perfect information such as chess or go still revolve around building context maps of the kinds of maneuvers that work best in various situations and what your enemy is likely to do.
To that end, when you're designing a game, think hard about what you're going to hide and what you'll reveal, and when. "Juicy" gameplay is more than just showing an animation whenever the player clicks a button: it's about revealing something in response to the player's action. That reveal might be a feedback loop's response: shoot the bad guy, he dies. That reveal could also just be to reveal another piece of the world: the next little part of the plot, or a temporarily enlarged view radius, or a trajectory prediction.
This facet of game design is too often overlooked in favor of trying to come up with fantastic new game play. But, frankly, you can use stale game play and, if you make the reveals juicy enough, nobody will even think to complain. They'll just call it "the best of its genre."
Good examples of this technique can be found in Psychonauts, Beyond Good and Evil, Halo, Baldur's Gate, Prince of Persia, Civilization... basically any really good game will have a very polished pace that revolves largely around knowing when to reveal new bits of plot, map, gameplay elements, and/or fun side stuff.
How do your favorite games use the reveal?
Subscribe to:
Posts (Atom)