Sadly, it had been almost 2 years since I posted a volume of my main Tellurian Tales line. After being inspired by a post over at Head Injury Theater about spending more time posting excuses about not posting than actually doing something productive, I decided after my afternoon nap to do something about it. Yay!
Lately, Tellurian Tales has involved simply slogging through a long dungeon. Running this solo, now that I'm comfortable with the D&D rules, is not quite as exciting as it once was. Also, I've moved on to hacking on Zludge rules as my primary form of entertainment, rather than building D&D characters that need a story to shine in. I guess this partly explains why it's been 2 years.
I'm looking forward to the end of the current story cycle. I'd like to dust all the characters off while I level them up and (as already planned) break the party into smaller groups for more story-focused adventures. I'll probably leave things running as D&D though. The characters I have (some of whom haven't even entered the story yet) represent countless hours pouring over D&D rule books and supplements, squeezing out the max advantage from combining diverse feats and prestige classes. Seems a shame to lose all that history by switching to Drudge. Also, it's a good idea to keep one foot in d20 while I contemplate translating it to Drudge.
Besides, I already have plans to alpha-test Drudge with Ailithorn, and I'm currently toying with a Western D&D setting for beta-testing games (with either S., B., or even a gaming group). I'm also wondering about a Zludge adaptation of Dark Heresy...
Time's at a premium though, so we'll see how it goes. I really need to focus...
Oh, and the slowest point in this evening's game was the pause to determine whether a ranged touch attack counts as a simple or natural weapon. My conclusion: No. Which makes sense if you think of it as just an attack and not a weapon. But there's confounding issues such as unarmed attacks sometimes being equivalent to simple weapons and the ability to take Weapon Focus for magical rays.
Monday, April 6, 2009
Wednesday, April 1, 2009
Notion: Modifiers suck
Modifiers are the essence of an RPG: some things are easier to do than others, and some people are generally better at certain tasks than others. Modifiers to the roll (or even without the roll, in a diceless game) represent innate skill or external circumstances that may aid or hinder your action. Even if modifiers are applied to a target DC rather than the roll itself, the Game Master still needs to track them.
However, modifiers tend to suck when there's a lot of them. They're easy to overlook: "Oh, wait, I forgot the +1 from the Bless spell! And I would have hit last turn if I'd remembered it; can we back up?" If you remember them, they take time to tally: "Let's see, that's a +4 from the Bull Strength and another +2 because I got Enlarged last turn; I'm raging right now, so that's +4 more..." And then there's issues of which apply when: "Oh, wait, I'm wearing a Belt of Giant Strength, so that means I don't get the +4 from the Bull Strength after all, since they don't stack." And then there's those modifiers that affect the calculations of the numbers already on your character sheet (rather than just adding or subtracting from them): "Okay, so that's a total of +6 to strength. That means +3 to melee attacks, +3 to damage, but only +1 to off-hand damage... oh, but considering my normal strength of 12, that's actually +2... now I can carry a heavier load and, since I was right on the edge, I'm no longer encumbered, which means I can move 10 feet further this round!" And all this d20 headache comes from only three spells, one magic item, and one class ability in effect!
Actually, I'm talking about more here than just a modifier: a + or - number. I'm talking more broadly about all effects--which can also include spell or magic effects, character abilities (including feats, maneuvers, powers, etc), and conditions (flanked, paralyzed, fatigued, etc). Even damage taken--especially to attributes/abilities--can be seen as an effect. Some effects (such as conditions or states) do not affect rolls but instead determine what actions are even possible.
So, with this broad definition in mind, the problem remains: how to streamline the tracking of all the active effects during a game? The first step is to look at what exactly comprises an effect:
Now that we've had a look at what goes into an effect/modifier, we can start thinking about how to simplify the tracking process.
However, modifiers tend to suck when there's a lot of them. They're easy to overlook: "Oh, wait, I forgot the +1 from the Bless spell! And I would have hit last turn if I'd remembered it; can we back up?" If you remember them, they take time to tally: "Let's see, that's a +4 from the Bull Strength and another +2 because I got Enlarged last turn; I'm raging right now, so that's +4 more..." And then there's issues of which apply when: "Oh, wait, I'm wearing a Belt of Giant Strength, so that means I don't get the +4 from the Bull Strength after all, since they don't stack." And then there's those modifiers that affect the calculations of the numbers already on your character sheet (rather than just adding or subtracting from them): "Okay, so that's a total of +6 to strength. That means +3 to melee attacks, +3 to damage, but only +1 to off-hand damage... oh, but considering my normal strength of 12, that's actually +2... now I can carry a heavier load and, since I was right on the edge, I'm no longer encumbered, which means I can move 10 feet further this round!" And all this d20 headache comes from only three spells, one magic item, and one class ability in effect!
Actually, I'm talking about more here than just a modifier: a + or - number. I'm talking more broadly about all effects--which can also include spell or magic effects, character abilities (including feats, maneuvers, powers, etc), and conditions (flanked, paralyzed, fatigued, etc). Even damage taken--especially to attributes/abilities--can be seen as an effect. Some effects (such as conditions or states) do not affect rolls but instead determine what actions are even possible.
So, with this broad definition in mind, the problem remains: how to streamline the tracking of all the active effects during a game? The first step is to look at what exactly comprises an effect:
- Size (or condition)
- First is there is usually some positive or negative modifier to a die roll. Alternatively, if a condition, the effect may instead limit or allow certain actions, or else represent a number of different modifiers. For example, being entangled might impose a -1 to all physical actions, reduce speed to half, and prevent all spellcasting.
- Applicability
- A modifier is usually applied to only a certain subset of rolls, such as only a certain skill or skill group. For example, a modifier might apply to all Jump checks, all saves, all combat rolls, or all STR-based skill checks. (As mentioned above, this applicability can be simple to add on to existing inherent character modifiers, or it may require recalculating other modifiers.)
- Type (Stacking/Overlapping)
- Modifiers are not always cumulative. Some may have a type or category that determines how they stack or overlap with similar modifiers. For example, in d20, natural armor stacks with mundane armor, resistance bonus do not stack (the highest applies), and damage or energy resistance overlaps.
- Duration
- Effects can either be inherent/permanent (determined at creation time from things such as skills, attributes, or even worn magic items) or circumstantial/temporary (determined at play time based on the current surroundings, spells in effect, relative positions of the characters, etc.) Temporary modifiers usually expire after a certain number of rounds, minutes, hours, or days. Or (even more of a headache) the modifier may vary over time, such as gradually degrade. (In general, it is temporary effects that require effort to track.)
- Source
- Effects usually have a source that determines how the effect can be canceled or manipulated. For example, magical spell effects can often be dispelled or nullified in anti-magic fields. Or certain defenses may exist if an ability damage effect comes from an undead creature but not if it comes from disease or poison. (Knowing a source often implies its type, applicability, and duration, but only indirectly.)
- Visibility
- Finally, there is the question of whether other characters/players can tell if an effect is currently in place. First, there's the question of how apparent effect is in the game world. Secondly, there's a question of how other players track global effects, even if those effects are not apparent to their characters. For example, one character may be exuding some 30-foot healing aura that other players must be made aware of whenever their characters enter the range.
Now that we've had a look at what goes into an effect/modifier, we can start thinking about how to simplify the tracking process.
Labels:
design,
gming,
modifiers/effects,
notion
Tuesday, December 16, 2008
Notion: Creation-time versus Play-time
In computer programming, there is the difference between compile-time and run-time. To create a program, the author first writes the instructions in a particular programming language. But a computer does not understand those instructions directly; they must be translated into binary machine code relevant to that particular computer hardware. The translation from the author's source code to executable machine code is called compiling. Once an executable program has been compiled, it can then be run. It is during run-time that the program actually does what it was written to do.
While compiling, the compiler can do a lot of error-checking--making sure that the syntax is correct, confirming that the data types for different variables are correct, etc. It can also link in other libraries or modules. It can optimize the program so it runs more efficiently. Generally, the more error-checking done at compile-time, the fewer errors encountered at run-time.
Not all programs are compiled in a separate stage like this, however. Some are interpreted: translated into machine code line-by-line from the source code at run-time. (This is a spectrum, of course: many modern languages compile to an intermediate form and are then interpreted from that form at run-time.)
The point of all this is: there's stuff you can validate at compile/creation time, and then there's stuff you validate at run/play time.
This is the same for RPGs. Something like D&D is like a compiled language: it takes hours to translate levels and skill ranks and equipment lists into all the particular modifiers listed on a character sheet. This is not necessarily a bad thing: character creation and optimization can be a very enjoyable activity, especially for power-gamers. And, as with programming, the more error-checking of modifiers you can do beforehand means fewer errors during play time.
On the other hand, a game like Risus is rather interpreted. There's still some authorship beforehand, but characters are represented as cliches. How those cliches then translate into particular skills or feats is actually determined during game time.
Overall, I'm a fan of compiled over interpreted, both for my programming languages and my RPGs. There's an initial overhead, but things seem to run smoother if as many details as possible are composed and validated beforehand. But this is just a preference.
Hopefully this difference/metaphor proves useful when considering RPG design.
While compiling, the compiler can do a lot of error-checking--making sure that the syntax is correct, confirming that the data types for different variables are correct, etc. It can also link in other libraries or modules. It can optimize the program so it runs more efficiently. Generally, the more error-checking done at compile-time, the fewer errors encountered at run-time.
Not all programs are compiled in a separate stage like this, however. Some are interpreted: translated into machine code line-by-line from the source code at run-time. (This is a spectrum, of course: many modern languages compile to an intermediate form and are then interpreted from that form at run-time.)
The point of all this is: there's stuff you can validate at compile/creation time, and then there's stuff you validate at run/play time.
This is the same for RPGs. Something like D&D is like a compiled language: it takes hours to translate levels and skill ranks and equipment lists into all the particular modifiers listed on a character sheet. This is not necessarily a bad thing: character creation and optimization can be a very enjoyable activity, especially for power-gamers. And, as with programming, the more error-checking of modifiers you can do beforehand means fewer errors during play time.
On the other hand, a game like Risus is rather interpreted. There's still some authorship beforehand, but characters are represented as cliches. How those cliches then translate into particular skills or feats is actually determined during game time.
Overall, I'm a fan of compiled over interpreted, both for my programming languages and my RPGs. There's an initial overhead, but things seem to run smoother if as many details as possible are composed and validated beforehand. But this is just a preference.
Hopefully this difference/metaphor proves useful when considering RPG design.
Labels:
character creation,
computing metaphor,
design,
dnd,
notion,
risus,
rule interpretation
30 Years of Stupid D&D Monsters
While I may not agree with the lameness of every monster listed here (I have a soft spot for owlbears), this author does have a very good point:
Dungeons & Dragons: Celebrating 30 Years Of Very Stupid Monsters (note that there are 2 parts)
Just a humorous reminder to keep your critical evaluative functions engaged while reading your next RPG supplement--even if it does come from a big-name publisher.
Dungeons & Dragons: Celebrating 30 Years Of Very Stupid Monsters (note that there are 2 parts)
Just a humorous reminder to keep your critical evaluative functions engaged while reading your next RPG supplement--even if it does come from a big-name publisher.
Subscribe to:
Posts (Atom)