Reply to thread

Message: <blockquote data-quote="Crazy Jerome" data-source="post: 5877271" data-attributes="member: 54877">Sorry, I'm jumping ahead to the conclusion, without spelling out how I got there. Let me fill in: 1. Some people have used GURPS (or Hero System) to "play D&D." They've done it several ways, actually, but the way I mean here is use the point system framework of the parent system (e.g. GURPS or whatever) to make some "classes" with "abilities" that are balanced in the parent system. Typically, the GM and maybe one or two mechanically savvy players in the group does this.  2. From then on, they "play D&D" with these constructs. Certainly, they may add on new monsters (built the same way) or tweak things that have been found to not work quite as well as preferred. To do that, instead of ad hoc changes, go back to the parent system and rework. 3. If you take the view that the early D&D classes were built as they were to provide a specific type of play, this can be a very powerful technique. How do you know what to use from the parent system? Well, how do you want the game to play? Build classes that do the things you want, and that's what you'll get. (With magic, this part is even more true in Hero than GURPS, at least through GURPS 3E.) If you want your spellcasters to be by school, have spells that are usable 1/hour, you can do that, balanced with the melee guys. Or anything else. Meanwhile, in play everyone is shielded from this. (This part is more true in GURPS than Hero, though there are tricks you can pull in Hero presentation to bridge most of the gap.) So what's wrong with all that? Let us count the ways: 1. It makes the underlying framework very complex and subject to all kinds of special balancing issues. That is, there are all kinds of things that you can do to screw up your campaign, many of which are not obvious. Circa Hero 4E and later or GURPS 3E or later, the products had matured enough that you navigate the worst of this with a bit of advice and circumspection, and later versions have refined it. This is many years of hard-won tuning and refinement that a D&D version will not have. 2. But assume that the designers can somehow come up with such a framework in one D&D version, and get around the corner cases by simply leaving that stuff out of the public documents. Meanwhile, they won't publish the framework, but gives us the more polished pieces, whatever those happen to be. That's all great in some sense, but "security by obscurity" does not work. If there are underlying patterns, gamers will discover them, published or not. You can buy a little time with "security by obscurity"--sometimes, but never much. So the real choices are a framework overtly published or a framework discovered patchwork.  3. If you go for patchwork framework route, you'll have all kinds of furor over this or that, misunderstandings, things built improperly, etc. About the only advantage to that is that it will give internet posters something to argue over instead of directing their ire elsewhere. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f61b.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":p" title="Stick out tongue    :p"  data-smilie="7"data-shortname=":p" /> This however pales to the, err, "irritation" that will result when various people that wanted X discover that X was readily available in the framework, but not provided because it had minor flaw Y--or even worse, because the "high priests" trusted with the framework hadn't got around to it yet.  4. If you release the framework right away, it will have huge problems or holes in it--either stuff not covered, or stuff covered imperfectly. The only real honest way to handle this is to "stub things out"--"Hey, the summoning rules don't really work, and we intend to replace them later. For now, you can use this stuff, which works sometimes, but breaks under pressure. Use at your own risk." The problem with honesty here is that you'll get legions of "fans" with reading comprehension and logic problems that will treat this as "unfinished work".  5. So with 3 and 4, you are "darned if you do; darned if you don't." So maybe you can sort of have a "framework" that that evolves as you need it. It's not consistent enough to be readily reverse-engineered, and everything, by definition, is a bit of a "stub out." This too will have all kinds of problems, but maybe it will seem slick enough in the meantime for those to be worked out in 6E. Better plan on 7E instead, since it usually takes 3 published versions to nail down all the problems.  6. In the meantime, while you are doing all the "game engineering," what is happening with smooth play, flavor, interesting and evocative abilities, etc? Not a whole lot, because all of the above is a lot of work. Your artists are free to do their usual thing. That had better be some smashing art.  7. But mainly, the purpose of an underlying game framework is not to swap out options, but to let each group build the flavor and interest themselves--that is, what they bring to the game. This is why, BTW, that GURPS and Hero can seem bland to a lot of people, and why GURPS sells those supplements with some of the work already done while Hero concentrates on giving you a ton of examples. Yet, the goal of 5E is not to let you play anything you want. Rather, it is to let you easily play D&D in one of several popular and historical styles. Thus, their design intent does not align with the suggested method of building up abilities by points--which is a framework. Had they wanted to do that, then the proper starting point would have been to take 3E/3.5, which already went a long way towards "regularizing D&D," and build the framework first so that it could roughly produce 3E/3.5, smooth off some of the rough edges, then start adding other options. It's still doubtful that this would have produced something that catered to other playstyles, as framework games inevitably play with their own style, not the genre emulated.</blockquote>

Verification