NOW LIVE! Today's the day you meet your new best friend. You don’t have to leave Wolfy behind... In 'Pets & Sidekicks' your companions level up with you!

Reply to thread

Message: <blockquote data-quote="I'm A Banana" data-source="post: 7653000" data-attributes="member: 2067">Sucking is part of getting better! Since you're never done getting better, you're never done sucking. This week, I look into how I sucked it up last week, and how the process of iteration makes things a LOT better![PRBREAK][/PRBREAK][HR][/HR]So, last week I presented an example of something I think would be a solid model for what a "class" is, in a class-based game. In spending the last few weeks looking through <a href="http://www.enworld.org/forum/content.php?1192-What-Is-Worthy-of-a-Class" target="_blank">how "class" and related concepts have been conceived of in D&D history</a>, I identified a struggle between a class as a primarily broad, mechanical concept (ie: "I use spells, which are daily abilities") and a class as a primarily narrow, narrative concept (ie: "I study arcane lore in dusty old tomes"). These concepts aren't necessarily related to each other at all, and the struggle to unite them has been a tension in D&D since the Greyhawk supplement. I made a stab at combining the strengths of both into a system where every class was a narrow, narrative concept, embedded in a broader, mechanical structure that was flexible and accommodating. There were some pretty good reactions to it! Iteration -- taking what you've done and identifying issues, refining it, and putting it out again -- is an essential part of any creative process, and a uniquely vital part of the design process. So lets walk through that process here. Ultimately, there were a few broad categories of reaction, and each of them tells me a little something about the design and the goals.Looks Good!These responses are worthwhile, and definitely show me that there's something worth exploring here. They're the foundation that tells me I'm not wasting my time on this little rabbit-hole, that there's at least a few people out there who are at least curious about an idea something like this. That's more than enough rope to hang myself with! Iteration is fundamentally a process of breaking something apart, so it's good to remember what people like about what you're doing, too, so that you don't chuck out something valuable as you refine your idea. It's also useful to show you if you're off on the wrong path -- if people didn't "get it" or didn't see the point, you might want to at least explain it in a better way. One specific reply showed me that this was something it was possible "get":Funfact: last week's article came out of my thinking presented in <a href="http://www.enworld.org/forum/content.php?955-Class-And-Equipment" target="_blank">my article on dissociating class from equipment</a>. What also emerged from that was the idea that mechanical ideas like durability, attack power, and resistance are independent of a class structure. Presumably, this poster never read that older article, but still identified the proximal source from what I didn't say. While the poster's overall response was a little more lukewarm, their brain followed my thinking, which is a pretty good sign. Isn't This Just A Classless System?The first real "actionable" item seems to lie here. The idea of this system as a system to "roll your own classes" is compared to a system in which there is no class. It's a fair cop, right? If a DM can essentially build their own class, it's also possible for a player to do that, using the same rules. <img src="http://th05.deviantart.net/fs71/PRE/i/2011/004/e/2/___crystal_sword_by_zephx-d36f96n.jpg" alt="" class="fr-fic fr-dii fr-draggable " data-size="" style="" />"Am I a class, or just a collection of points? Or is there much of a difference?"On the one hand, this is me accomplishing one of the design goals: I wanted to have a system where people COULD invent their own classes, and that is essentially the same idea as a classless system: the classes are not hard-coded into the mechanics of the game. No specific class can be essential to play the game if you want to give DMs the power to make their own classes without re-designing the whole thing. So, yeah, comparing it to a classless system makes sense.On the other hand, the intent was to keep many of the virtues of having classes in the game. Like the man says:I wanted, here, to appropriate as many advantages as I could. Generally, my own review of the material suggested that some of the main virtues of classes were:<ol> <li data-xf-list-type="ol"> Grokability: Classes are easy to understand and relate to, because they're fundamentally archetypal. You don't need to be told to try and steal things when you play a thief: You know what you have to do, because it is also what you are called.</li> <li data-xf-list-type="ol"> Streamlining Decision-Making: A class includes all the things you want to do, and none of the things you DON'T want to do. If you're playing a thief, you don't need to worry about picking abilities that are thief-y in order to be a successful thief. The class does this for you.</li> <li data-xf-list-type="ol"> Conflict-Solving: Because a class relates to a conflict in the mechanics of the game and in the world, a class tells you what kinds of situations your character excels in and which they're better off taking a back seat in. If you're playing a thief, you don't try to mix it up in a massive melee with trained warriors. You're not there to kill, you're there to steal...the conflict you excel in is in remaining undetected, gaining access, and absconding with the goods successfully. Leave the dirty work to the meatheads.</li> <li data-xf-list-type="ol"> World-Building: Classes are useful as world elements, because they define the kind of world the character lives in. If there are thieves in play, everyone needs to worry, at least a little, about their stuff going missing all of a sudden. There may be guilds of thieves as well as churches of clerics and colleges of wizards. They appear as NPC's, as helpful allies, as unfortunate enemies. They appear as an identifiable archetype in the world. </li> <li data-xf-list-type="ol"> Mechanical Bucketing: Classes are a way to divide up mechanics so that everyone doesn't need to learn all the moving parts. The archetypal D&D wizard may have to deal with resource rationing, spell planning, and advanced decision-making, but doesn't need to learn much about weapon types and armor weight. The typical D&D fighter is probably much more interested in those elements, but doesn't have to bugger about much with rationing and planning: they can react on the fly. </li> </ol>Looking at that (non-comprehensive) list, I can see a few areas where my experiment didn't quite hold up. While the class was understandable, was part of the world, and gave you everything you needed to hold up that character type, it didn't have a clear "conflict" it was solving, and the system itself homogenized mechanics enough so that the bucketing became irrelevant. So what we're looking at improving would be the mechanical definition of the class, which should improve both of those metrics. The exact thing that I mentioned that was historically in tension with the story definition of the class. As D&D has showed us, there's nothing necessarily inherent in the story idea of a trained warrior that implies that they don't have to ration or plan their ability use (What's up, Martial Dailies?), and there's nothing necessarily inherent in the idea of a thief that implies they roll a die for success (percentile dice, or a skill check). This can be perhaps addressed with a new moving part. Much like how equipment, HD, and saves weren't a part of last week's class automatically, we can tie in a moving part that, for now, we'll call the Core Mechanic. The core mechanic is interchangeable and customizable: a class comes with one, but it's something you can replace about the class.As an example, lets use a mechanic that I probably wouldn't actually use these days: % Chance, the original thief mechanic of "roll less than your % to accomplish a given task from the following list." Gaining levels might give you higher success, or more abilities on your list, or both. So, on a thief, you have things like "Hide in Shadows" or "Tell a Lie" or "Escape Bonds" that let you do your Thief-y things. On a fighter, perhaps you separate out weapons, so you have things like "Sword Attack" and "Arrow Attack" and "Deflect Blow" and "Stay Standing." Because we're using the old "% Chance" mechanics, we're not too worried about your enemy's skill -- succeed on your roll, and you do the thing you rolled to do, maybe the DM makes an ad hoc adjustment, and we're done. Hypothetically, that works. We'll see it in action on the class I presented last week below. I'm Not Sold On SpecificitySpecificity, I knew, was going to be kind of a controversial design principle. D&D has wrestled with specificity over the years in things like kits, prestige classes, and in classes themselves, and it's always been problematic, because a tightly defined character is a character without much inherent flexibility, and the arc of D&D history has been toward flexibility, with things like feats and skills and extra spells and subtypes within types. Going against that flow would rankle some hairs, and I though it would be useful to see where the friction occurred. I'm confident that specificity, as a principle, achieves the goals of making the class understandable, decisive, and part of the world. It solves the problem inherent in calling a class, say, "Fighter." "Fighter" isn't really an archetype, it isn't a specific kind of character, and it tells you very, very little about the world (okay, there's fights in it?). By those criteria, "Fighter" doesn't cut it as a class. "Rogue" falls into the same boat, and "Wizard" does, to a large degree, too. "Cleric" a little less so, but if you view it through the 2e lens, it can become meaninglessly vague, too. Specificity means that there is a certain kind of character you are choosing to be when you grab a class. It has a direct correlation to something in the story of your own game. When your "rogue" can be anything from a spy to a locksmith to a scout to a backstreet thug to a rakish swashbuckler, it doesn't say much about the kind of character you are to call yourself a "rogue." My own likely-misplaced confidence aside, it's clear that "you can make your own class from scratch if these are too narrow!" isn't something that these commentators really embraced as a viable solution to the dilemma of specificity. In truth, all the flexibility and adaptability anyone could want is found in that big "every class ability is compatible with every other class ability" rule -- can't get much more flexible than that! But what about that solution might be untenable for some folks?This problem may be one of perception. In presenting "three traits of a good class," I may have obscured the idea that these good classes are dependent on a good underlying construction system, and hidden some of the adaptability. It was clear to some posters (those mentioning that this made the system nearly classless), but not to others (those mentioning that specificity means you lose significant flexibility -- in this situation, no, you wouldn't, because the system is ALSO a la carte). It may also be an issue with my perception: it's not clear to me how this system would stop people from expanding their character into the story as they go, because you can a la carte abilities to represent only the abilities present in the story, however it develops. They're seeing obstacles I'm not, so one of us isn't talking to the other.In this situation, it's often useful to make the intent much clearer by example, so that way, at least the problems become more...er...specific. A true example of the system in play might be a little too much for this article (though it's good fodder for the future!), but I can perhaps point at it by including an example of how it might play out. This Is Not What A "Class" IsA few posters presented their own ideas for what the traits of a good class are in their minds:This kind of feedback is interesting because it provides me some insight into what people are looking for, and also potential things to highlight in my system. Does this system allow for classes that do something distinct? Something well? Are the characters customizable "enough"? Can my classes be bigger, "cooler", and flexible? Does the system in which their embedded allow for emergent gameplay without over-specialization and a common terminology?Honestly, there's a few of those areas where this system is pretty weak. This doesn't feel like a systemic problem to me, though. The "Core Mechanic" concept and a focus on the conflict the class solves should help provide something more distinct and strong, while the overall system keeps individual characters from being pigeonholed too tightly and allows for people to literally pick abilities as they go if the pre-set option isn't appealing. Boldness in the mechanics are mostly a matter of establishing the binary swing, something tough to do without, and things like common terminology and whether one is "inspired" to play as the class comes as a matter of individual taste and specific campaign world-building. Iteration!And so, that's lead to the version of the class (as an example of what you can make within the system) attached here. Iteration is a literally endless process, so I don't expect this to be perfect. I just expect it to be better and, where it fails, to do so in a way that shows me where I can improve. That's iteration. You can't be perfect -- no such thing. It's always a journey, never reaching its destination. What do you think of this now? How is it better? How does it still not quite meet the needs? Let me know down in the comments![ATTACH]59014[/ATTACH]</blockquote>

Verification