Classes/resource mechanics

[Red_Rob]

When I was thinking about diverse resource mechanics in D&D the wall I kept hitting was the incompatibility between "some class concepts are low level" and "no multiclassing". If a Swashbuckler is inherently a low level concept but locks you on rails until level 20, how do you square that circle?

[deaddmwalking]

I don't think that it is bad to have a resource mechanic in mind, but I still think you need to have what the class DOES in mind before you figure out how they do it.

How many classes have you written, and what are your favorite classes?

This sounds like appeal to authority, but the fact is, I've developed a number of classes both for 3.x but more importantly, for my heartbreaker in collaboration with my friends. Three of us have been working on the development and have been playing it for more than 3 years. We have classes using a single resource mechanic we refer to as mana. As a 3rd level character, I have 10 mana. Mana regenerates in hours, not minutes, so in general the amount you have to start an encounter provides a cap on how many 'special moves' you can make. We also use Fate Points, which can be converted into mana or hit points with the use of a standard action, so during combat it is not terribly uncommon to 'recharge'.

Everybody has ways to learn spells if they choose. Most classes don't automatically get spells, it's a choice they have to 'opt-in' for. Our 'feat equivalent' often has abilities that require activation through a mana expenditure so martial classes use it for that reason. Having 'always on' magic items also costs mana, so our Warrior, for example, if they haven't opted to learn magical spells has more 'slots' available for items than, say, a wizard.

Currently, our classes are: Berserker, Knight, Rogue, Warrior, Wizard. Because of the way we developed the wizard class, the same chassis is used for every specialty variant, but thematically they end up like 'Beguiler' or 'Necromancer'.

We allow open-multiclassing. Most class abilities are class-level dependent (for example, a Rogue's Sneak Attack), but access to the feat equivalent and spells is primarily Character-Level Dependent. Ie, a Rogue 1/Knight1/Warrior 1 is a 3rd level character and depending on their choices could potentially cast 2nd level spells. They would have only the 1st level class abilities of each class.

Classplosion isn't a design goal. We are currently running two campaigns. In the one we played yesterday I am a 'Knight1/Wizard2', but effectively, you'd recognize me as a cleric. My character wears Bronze Chainmail, carries a shield, wields a warhammer (sometimes empowered with spells). He can cast earth/fire magic well but has limited access to other spells. At 3rd level he just gained access to 1st level healing spells.

The way the classes work in practice, it has been possible to build a variety of characters without needing to have 'bandit' or 'archer' or 'pirate' - those are things any character COULD do. On the other hand, since classes are not restrictive, advancing a character involves some broad choices. Reading through the lists of advancement options could be overwhelming for some players. Similarly, building a spell list involves making choices from essentially all of the available spells, which can be somewhat daunting. In general, it works best to primarily focus on what is available through your speciality(ies) and then 'round out' with anything missing from other lists. For example, my fire/earth wizard just picked up a healing spell from his non-specialty list to increase the amount of magical healing we had available. I will almost certainly do this again to pick up 2nd level healing spells.

While I like the idea of multiple resource schemes, I don't think it is strictly necessary. Of course, what you mean by 'resource scheme' can be difficult to parse. I consider the Pathfinder Barbarian to have a resource (Rage Points) that they must manage, but I wouldn't consider the 3.5 Barbarian (x/day) abilities to be quite the same. In 3.x, most every PHB class has abilities that are x/day or spell slot (which essentially are x/day by spell level). I think 'spell slots/day' is a relatively commonly used resource and could be applied to a number of thematic classes effectively. Before making a class use a card draw or dice mechanic, I would at least consider if you can achieve the same design effect using a 'common method'.

If nothing else, I think it is good to aim for classes to be 'blendable' in some form or another. While having 100 classes isn't strictly necessary, having 100 CONCEPTS is non-negotiable.

[Kaelik]

So what you are saying is that you, personally, DeadDM, developed a resource management scheme first, and then make all your classes conform to that predetermined resource management scheme.

And you think it's wrong to design the resource management scheme before the class fluff.

Oh woops, you done fucked up and proved yourself wrong.

Almost like instead of an appeal to authority, I was asking a question that no matter what the answer would have proven me right.

[RobbyPants]

When I was thinking about diverse resource mechanics in D&D the wall I kept hitting was the incompatibility between "some class concepts are low level" and "no multiclassing". If a Swashbuckler is inherently a low level concept but locks you on rails until level 20, how do you square that circle?

You don't include class concepts that don't scale with level. It's why I'm not adding any sort of "fighter". The rogue class should do what I want for a swashbuckler, and the class will have built in magical tricks that scale with level. It will have little, if any, magic at low level, so a "low level swashbuckler" will have no magic, but a high level one will be teleporting on the other side of opponents or obstacles, and similar things.

[DSMatticus]

When I was thinking about diverse resource mechanics in D&D the wall I kept hitting was the incompatibility between "some class concepts are low level" and "no multiclassing". If a Swashbuckler is inherently a low level concept but locks you on rails until level 20, how do you square that circle?

Well, when people say open multiclassing they are referring specifically to the 3.5 thing where you can grab levels of whatever you want whenever you want. You can make a game where everyone is expected to prestige (i.e. graduate to a new tier of classes) at a certain level. That is a form of multiclassing, but it's not open, and it doesn't pose the same problems. You can also take that the Pathfinder/5E archetypes thing (hotswapping class features based on the "kind" of X you chose to be) - except standardize the shit out of it and carve the archetypes into tiers, so you graduate from Rogue (Swashbuckler) to Rogue (Master Ninja) to Rogue (Trickster Demigod) or whatever. Basically baking the tiers of classes into the base classes themselves, which seems reasonable in this case since the power lists are probably going to be very similar if not identical between most rogue "prestige" classes.

Or you can do none of that at all, and just stick to concepts which can feasibly exist at all level ranges, and leave a character's ascension to trickster demigoddom a matter of fluff and ability selection. "Martial character who tricks people" scales pretty damn high, if you are willing to give martial characters nice things. But ultimately I think if you wanted more customizability than that, the ideal would be slapping archetypes on your base class.

[deaddmwalking]

So what you are saying is that you, personally, DeadDM, developed a resource management scheme first, and then make all your classes conform to that predetermined resource management scheme.

And you think it's wrong to design the resource management scheme before the class fluff.

Oh woops, you done fucked up and proved yourself wrong.

Almost like instead of an appeal to authority, I was asking a question that no matter what the answer would have proven me right.

No. That is not what I said.

We developed concepts for the classes first. The number of classes has varied up and down. For example, we originally included 'cleric' as a base class before later folding it into 'wizard'. Originally, wizard was the only class that was really using mana. Effectively the resource management scheme was developed along with how we wanted wizards to play. Effectively, we started with 'narrative conceits' and developed a resource mechanic that achieved them. For example, we wanted to reflect the concept that casting spells was somehow draining - a wizard that just cast their most powerful spell might need a few moments to mentally prepare to cast another powerful spell. We also wanted to limit a caster 'full buffing' and still having their full complement of spells. By requiring spells to have an ongoing cost (effectively reducing your overall maximum mana level) we seemed to have avoided that.

The actual resource mechanic was modified multiple times to ensure we achieved our desired results. There were times where the playtest showed that we failed, so adjustments were required. I still very much consider it a 'work in progress', but that particular element has been stable for probably 2+ years - it has worked for a wide variety of classes.

Now, I don't think that having a resource mechanic in mind and then finding ways to fit a class to it is necessarily a bad thing - especially if the mechanic is ITSELF good for what you're trying to do. If you've math-hammered it and it provides the play experience you want - great. If it thematically fits the class, even better.

For example, if I want to play an Old-West w/ Magic game like Deadlands, there is no problem with starting 'I want the magic rules to play like a hand of poker'. Trying to get that concept to work regarding how you draw cards, how you discard cards, whether you can cast ANYTHING depending on the cards you draw (ie, if you go for a flush but don't get it, can you cast something with a 'high card') is going to involve some changes. Once you have it worked out and you like your system, when you introduce a NEW magical system, does it make sense to use the same system? While having a Chinese magical system using poker cards might feel thematically inconsistent, you might be able to use the same concept using dice or mah-jongg tiles. Perhaps in trying to expand the working concept, you determine that you're better off with a more universal concept that still achieves your intent. Ie, a dice rolling magic mini-game to help determine which spirits you can compel to assist you may function just as effectively as the poker one, but you can use it in just about every magical tradition. If you do, you don't have to come up with 17 different systems and try to figure out how to balance them.

I mean, you could, if you want, but why would you? Playing around with resource schemes can be fun, but there are also gains to be made by having a robust system that is consistent. I mean, if your goal is to get as many resource schemes in as possible, it stands to reason that some will be better than others. Now, if the circumstances that one is better than another are variable, you might have reason to include all of them, but what usually happens is that '5th tier ideas' get included when they should be scrapped, because ultimately you have a system that doesn't work even if thematically it's pretty cool (I'm looking at you, 3.x Warlock).

[Kaelik]

So what you are saying is that you, personally, DeadDM, developed a resource management scheme first, and then make all your classes conform to that predetermined resource management scheme.

And you think it's wrong to design the resource management scheme before the class fluff.

Oh woops, you done fucked up and proved yourself wrong.

Almost like instead of an appeal to authority, I was asking a question that no matter what the answer would have proven me right.

No. That is not what I said.

And yet it is totally what you did.

[deaddmwalking]

I must be living in Bizzaro World.

Me: My friends and I discussed what we wanted a wizard to be and came up with narrative descriptions. From there we developed a mechanic that achieved those aims.

Kaelik: You totally just said you came up with a mechanic first.

In any case, my personal recommendation is describe what you want a class to do and develop a mechanic for it. Then when you describe another class, see if the resource scheme works. If it doesn't, you should consider building a new resource scheme. If you build a new resource scheme, you should see if it works for your ORIGINAL class. Repeat as necessary.

[Leress]

Dead, the way you describe it at first was this:

This sounds like appeal to authority, but the fact is, I've developed a number of classes both for 3.x but more importantly, for my heartbreaker in collaboration with my friends. Three of us have been working on the development and have been playing it for more than 3 years. We have classes using a single resource mechanic we refer to as mana. As a 3rd level character, I have 10 mana. Mana regenerates in hours, not minutes, so in general the amount you have to start an encounter provides a cap on how many 'special moves' you can make. We also use Fate Points, which can be converted into mana or hit points with the use of a standard action, so during combat it is not terribly uncommon to 'recharge'.

It makes it sound like you made the mechanic first, then made classes that use that one as well as fate points that could be converted.

[Username17]

If you put all your classes on the same resource schedule, which you did, then obviously you fit the classes to the resource schedule rather than conceive of a resource schedule having already decided what you wanted your class to do. Because fucking obviously.

Now DDMW, stop being an idiot and eat your fucking crow.

-Username17

[Kaelik]

I must be living in Bizzaro World.

Me: My friends and I discussed what we wanted a wizard to be and came up with narrative descriptions. From there we developed a mechanic that achieved those aims.

Kaelik: You totally just said you came up with a mechanic first.

In any case, my personal recommendation is describe what you want a class to do and develop a mechanic for it. Then when you describe another class, see if the resource scheme works. If it doesn't, you should consider building a new resource scheme. If you build a new resource scheme, you should see if it works for your ORIGINAL class. Repeat as necessary.

"We have classes using a single resource mechanic we refer to as mana."
"Currently, our classes are: Berserker, Knight, Rogue, Warrior, Wizard."

Even if I believed that you totally invented all of the Wizard's abilities before you invented the concept of hour based casting, you still, by your own explicit statement, made 4/5ths of your classes from resource method first.

Again, the point is that your entire concept is fucking stupid and is always going to produce one goddam resource schedule as an a priori good because any fucking class can be written for any resource management scheme. They all won't be equally as good. But I can write an at will Wizard, an encounter wizard, a spell preparation wizard, a mana wizard, a WoF wizard, a shifting token pool Wizard, and really just anything else. In fact, literally all of those already exist.

You can do the same thing with a Rogue. You could do the same thing with Warrior if it had any coherent space at all based on just the name, instead of being a blank slate.

[deaddmwalking]

In any case, my personal recommendation is describe what you want a class to do and develop a mechanic for it. Then when you describe another class, see if the resource scheme works. If it doesn't, you should consider building a new resource scheme. If you build a new resource scheme, you should see if it works for your ORIGINAL class. Repeat as necessary.

Okay. Crow eaten?

[PhoneLobster]

In any case, my personal recommendation is describe what you want a class to do and develop a mechanic for it. Then when you describe another class, see if the resource scheme works. If it doesn't, you should consider building a new resource scheme. If you build a new resource scheme, you should see if it works for your ORIGINAL class. Repeat as necessary.

Okay. Crow eaten?

That isn't the acknowledgement they want from you.

They want you to say you built your mana system THEN came up with your class concepts based on them using your mana system rather than based on the abilities you wanted those classes to have.

Thus by extension somehow proving their point (though it still doesn't) that a, if not the, primary thing you should do when adding a new class is design a unique resourcing mechanic.

Your acknowledgement there, is that you would design a class based on things you want it to DO, and see if it fits an existing standard resourcing systems used by some/all other classes, and that if it required a newer better resource mechanic for some reason that you might just check if that newer better resource mechanic would be an upgrade that would be beneficial if used as a standard system by some/all other classes.

The problem is that for them your final destination is supposed to be large numbers of entirely unique classes with entirely unique resources. Your methodology essentially is "just keep the resource mechanics that are best/needed" and will not lead to that outcome.

Your methodology and your current outcome sounds pretty sane. If I were inclined at all to a class based system low numbers of classes is certainly the place I would want to be at to gain the benefits of a class based system as defined in ye olde threads on "why class system at all?", while large numbers of classes undermine those benefits thoroughly. And having your resource system be "the best one you can think of" or "the minimum (but best) required" seems like the obvious rational methodology to support that rather than "each class needs a unique resourcing system for the sake of difference alone even when nothing it does would actually require it".

A pity your method wasn't the convenient conclusion to reach back in the day when a new "killer" argument against multi-classing/classless mechanics was required thus resulting in the brain fart of "er, but you need vast numbers of unique resourcing systems, suddenly, for no reason!" being pulled out of someones ass without much forethought, and now it made it's brief appearance for that purpose it of course cannot be walked back to something more sensible.

[Kaelik]

PL stop projecting. You are the only person with the one demanded endpoint that must be reached.

The people you are arguing with acknowledge that a game can be based on other systems, in fact, some of them have in fact designed games based on other systems.

When we point out that building the classes abilities comes after the resource management system, we really mean just that, not that this is step one in our demand that all games must conform to a single standard (that not even all our games conform to).

[GnomeWorks]

And having your resource system be "the best one you can think of" or "the minimum (but best) required" seems like the obvious rational methodology to support that rather than "each class needs a unique resourcing system for the sake of difference alone even when nothing it does would actually require it".

Isn't 4e a pretty solid argument against a "one size fits all" resource system, though?

Shitty power design aside, I think the complaint that all the classes in 4e felt the same due to using the exact same mechanics and power schedule is a valid one.

Resource mechanics aren't really a "this one is better than all others" thing, they tend to have benefits and drawbacks, and you can simultaneously balance mechanical concerns (essentia fits necromancers, because it's a solid way to handle minion mechanics) and flavor concerns (berserkers use a rage bar because it's a flavorful mechanic that reinforces the story concept of the class) when you bring multiple to the table.

[Kaelik]

Isn't 4e a pretty solid argument against a "one size fits all" resource system, though?

In general I don't think a bad implementation of something is a very strong argument that the idea is bad. The very minimum you would need is an argument that future attempts would be doomed to the same type of failed implementation.

In the case of 4e, so much of the dumb class sameness was a factor of other things (like not giving real abilities at all because balance or whatever dumb thing) that I don't think that argument can be made about it's resources management system.

[GnomeWorks]

Hmm... fair enough.

[PhoneLobster]

PL stop projecting. You are the only person with the one demanded endpoint that must be reached.

Interesting thing to say in direct reply to the post in which I actually said...

Your methodology and your current outcome sounds pretty sane. If I were inclined at all to a class based system low numbers of classes is certainly the place I would want to be at to gain the benefits of a class based system

Anyway. Onto the "nuh uh WE are the reasonable open minded ones!" bit...

The people you are arguing with acknowledge that a game can be based on other systems, in fact, some of them have in fact designed games based on other systems.

So. Are you walking back from the "you can't do multiclassing because you need 17+ unique resourcing systems" thing?

Even removing the multiclassing thing are you walking back from "You SHOULD have an open ended ever growing huge number of classes and they should all have unique resourcing mechanics"?

Are you even walking back from "Having an open ended ever growing huge number of classes all with unique resourcing mechanics is totally not a clusterfuck waiting to happen."?

Because I somewhat suspect you are not and even if you might do any let alone all of that walking back, going on past history I doubt any such walk back would be accepted by the others who put forward that position here or elsewhere.

[Kaelik]

PL while in general your ability to live inside your delusions is impressive, it's not so impressive that I want to join you, so I'll just be content to point out that you are still just making up lies to try to pin on other people, and that's not more convincing in this last post then it was in any of your others.

[PhoneLobster]

So you (and according to you without asking them a number others who seem to have said otherwise) totally have a very rational less extreme position that isn't anything I've interpreted from anything you or anyone else has actually said but you refuse to I don't know specify what it is just everyone should trust you that I'm a naughty mean lying liar lying for the sake of lying and that you are trustworthy and rational and have a (secret) super rational position on this issue that you are angry at me for misrepresenting, but that you don't want to talk about.

[Kaelik]

So you (and according to you without asking them a number others who seem to have said otherwise) totally have a very rational less extreme position that isn't anything I've interpreted from anything you or anyone else has actually said but you refuse to I don't know specify what it is just everyone should trust you that I'm a naughty mean lying liar lying for the sake of lying and that you are trustworthy and rational and have a (secret) super rational position on this issue that you are angry at me for misrepresenting, but that you don't want to talk about.

Alternatively, anyone who actually is interested in good faith discussion can read the things people actually said, instead of your caricatures, and you can rail at strawmen all you want.

[deaddmwalking]

So here's the thing - even if my resource came first in some type of chicken and the egg analogy, this was a long aside on why 17+ (or some arbitrarily large number) of resource mechanics was desireable.

Why wouldn't you want one if you were able to get every class on it and it was both flavorful to that class (ie, thematic) and effective?

[Username17]

So here's the thing - even if my resource came first in some type of chicken and the egg analogy, this was a long aside on why 17+ (or some arbitrarily large number) of resource mechanics was desireable.

Why wouldn't you want one if you were able to get every class on it and it was both flavorful to that class (ie, thematic) and effective?

First of all, your claim that all resource management systems or any resource management systems are equally flavorful for all classes is horseshit. It's so obviously horseshit that it is genuinely insulting that you'd make the argument.

Any class can be fit into any system. Every system is necessarily an abstraction, and every system will by definition be more or less of a cognitive stretch to represent different narrative constructs. There are certainly reasons to use systems with less moving parts: simplicity is a valid goal, and it makes things easier to balance and judge interactions. But you don't make things the same because you want to better capture the flavor of things that are different. You just fucking don't. That is not a good faith argument made from a position of sanity.

-Username17

[PhoneLobster]

But you don't make things the same because you want to better capture the flavor of things that are different.

Unless by making one thing the same you open up your complexity budget to make something else and something better different instead.

Your problem is your remarkably arbitrary myopic focus that resourcing systems specifically must always be part of where the differentiation between classes happens.

Difference for difference's sake should rationally lose out for any component of a class that would be better represented by using a common mechanic shared with other classes. And difference for it's own sake can lose out on any given component that makes up a class, including and especially basic resourcing mechanics, and the class can still over all be different to all the other classes to a more than adequate degree.

[deaddmwalking]

So here's the thing - even if my resource came first in some type of chicken and the egg analogy, this was a long aside on why 17+ (or some arbitrarily large number) of resource mechanics was desireable.

Why wouldn't you want one if you were able to get every class on it and it was both flavorful to that class (ie, thematic) and effective?

First of all, your claim that all resource management systems or any resource management systems are equally flavorful for all classes is horseshit. It's so obviously horseshit that it is genuinely insulting that you'd make the argument.

Any class can be fit into any system. Every system is necessarily an abstraction, and every system will by definition be more or less of a cognitive stretch to represent different narrative constructs. There are certainly reasons to use systems with less moving parts: simplicity is a valid goal, and it makes things easier to balance and judge interactions. But you don't make things the same because you want to better capture the flavor of things that are different. You just fucking don't. That is not a good faith argument made from a position of sanity.

-Username17

I didn't claim that they were - I posited that if they COULD BE, that would be superior. I also said:

If you're considering a unique mechanic, you should be clear about what benefit it provides to the class. If you could have all of your classes on the same resource mechanic and they all feel DISTINCT, then you probably don't need them to use different mechanics. Now, I believe that trying to get everyone on the same resource mechanic won't allow your classes to feel distinct, but you should be sure of that, first.

That's my first post in this thread.

Since this is RobbyPost's thread, my question is why is he considering multiple resource mechanics. Is giving different classes a mechanical representation of that the only reason?

Sometimes you can make something thematic with a simple name change. If you call mana 'chi' then all the combat stuff works just fine. As a game term, you can still use mana but just include a throwaway line that martial traditions often refer to it as 'chi' or 'ki' and you're golden.


Edit - What I mean to say is that mechanically distinct characters is definitely something to aim for. It's possible that you can make them mechanically distinct by resource mechanic, but it seems that it is EQUALLY POSSIBLE to make them mechanically distinct in other ways. For example, two wizards that have the exact same resource mechanic (for example, spell slots) will play differently if one has access to only necromancy spells and the other only has access to Enchantment spells. I don't think that anyone has made a compelling argument for why resource scheme should be the first place you look to make your classes unique. If anyone is making that argument, I'd like to know why they think that's the best place to start? Why not through access to unique abilities REGARDLESS of resource scheme?