Defining 'compatibility' (Forked Thread)

[Reynard]

Forked from: I’m not dead yet…..sticking with 3.5

The word "compatible" seems to cover a range from "similar" to "synonymous" depending on who you ask though I know that the latter definition is more likely to please more people.

This post got me thinking: just what is compatibility. I mulled it over for a while, thought about various editions of D&D and D&D like games and how they interact (just how easy is it to use KotBL with 4e; can I run Scales of War in 1E?; etc...) and think I hit upon the very definition of compatibility when it comes to d20/OGL and related games:

It doesn't matter how much you change the rules, so long as the terminology remains the same and the meaning of that terminology remains the same. I know, that's going to sound contradictory, but allow me to attempt to explain by way of example.

Let's say that you want to create a d20 variant with gritty, granular combat. At first blush it would seem you've just stepped outside the realm of "compatible" with typical D&D/d20. However, the combat rules in D&D are terminology dependent. You have Attack Bonus and Armor Class and Hit Points and all the terms used to define how and when characters and creatures act. In addition, all of these terms have values and meanings that interact with one another. Damage is related to Hit Points and the relationship between the two in quantifiable.

So it stands to reason that if you wanted to change the flavor and flow of the d20 combat system, yet maintain compatibility (in both directions), then you'd keep the terms and the numbers and change their meaning within the context of the new system, and make sure those values have the same relative values as they do in the core system.

Hmmm... need to think on this more.

 

[Mustrum_Ridcully]

I think this kind of compatibility can work, too, but it was never tried.

For me, compatible usually means that you have something that either plugs into the system and works - like a new class - or that you have something that you can overlay over the existing system (which might be your idea of an alternate combat system).

For example in 3E, you might introduce the Ghost Rider class that uses BAB, Saves, Hit Dice and so on as usual, and has a few extra abilities.
You might introduce a 7th ability score (maybe Education, Honor or whatever) and use it for a new subsystem.
You might create a template that can be applied to classes and characters.

What I think leaves the area of compatibility is if you change how an existing ability works and you have to "relearn" it as a player. That doesn't mean it's unusable with the old system, but it changes things around. If Evasion switched from "deal no damage on a successful save" to "add +5 to saves of this kind" for example, or if Fighter Bonus Feat means he gets +4 skill points, or a Wizard would change his spells per day.

From a software point of view, compatibility means an application runs on the hardware and operating system it is supposedly compatible too - without breaking anything else. I know that there were actually computer games that didn't do that - apparantly, one version of Final Fantasy (IIRC) tried to "patch" (read: replace) the Windows Kernel during installation. That's not compatibility! (Don't ask me how this was legal regarding copyright, but that's actually a scenario Microsoft wrote a "shim" for - pretending that the operation the installer did worked while actually not doing anything, just so that it would install and run.)

Of course, somethings you can't avoid "breaking" compatibility.

 

[hong]

The prime requisite for compatibility in p&p rests with the zeitgeist, not the rules. That's the beauty of having everything be moddable, unlike in videogames.

If you want to make something work, you can make it work.

 

[EricNoah]

For me it has a lot to do with the basic "numbers game" - if 5th level basically means the same thing in each version, if +6 to hit basically means the same thing, if 20 hit points basically means the same thing, then to me it's compatible. I can work around many differences (a new derived stat such as the Combat Maneuver Bonus; a different rate of feat acquisition for PCs; a few spells maybe moved around to different levels).

On the DM's side of the screen, if I only have to make one or two stat adjustments for each monster or opponent, then it's pretty compatible. From what I have seen of Pathfinder, on the DM's side of the screen I'll be able to toss both SRD monsters and Pathfinder opponents at the PCs and they'll be pretty much interchangable.

On the players' side of the screen, my instinct is that you would want to have all SRD or all Pathfinder PCs to make them more equal amongst themselves.

And finally, personal quirk here, but I only really look carefully at the first 10 levels or so of the game - I don't care about how it shakes out in the higher levels because I just don't play that end (no matter what version of the game).

 

[pawsplay]

Compatibility is about information moving through the point of interface. If A produces output that goes to B, then Z is compatible if it can also produce output that goes to B and B functions as expected.

 

[Reynard]

Some more thoughts on this as the coalesce in my brain:

I guess what I am talking about is "functional compatibility". That is, being able to open the book and use the material with no or minimal fiddling. The most basic illustration of this would be an "edition neutral" D&D adventure or supplement. For example, in such an adventure there might be an encounter with 8 orcs, designed for 3rd level PCs. "Orc" is a known quantity, a defined term in D&D, as is "3rd level". The adventure, then, is "functionally compatible" with any edition of D&D in which 8 orcs versus a party of 3rd level PCs is an equivalent encounter or challenge. No stat blocks are needed, either, since "orc" is a defined term. This compatibility may even extend to other fantasy games where the relationship between "8 orcs" and "3rd level" is equivalent.

The other end of the spectrum would be using stat blocks as they are presented in a given edition but changing the definitions of the terms in a stat block. If, for example, an orc has a stat block of AC 15, HP 6, Attack +4 in a given version of the game, it is "functionally compatible" with any other version of the game, or other game entirely, which uses the same stat block with the same relative meaning. Even if your system is noticeably different -- say an opposed roll is used for combat where the target rolls under their AC and attacker tries to roll over it, and the one with the greater result is successful, or some such -- it is still compatible so long as the relative values and relationships are similar.

It would be an interesting exercise, I think, to try and redefine all the terms in a typical D&D stat block (pick an edition) and change the rules surrounding those terms and values to create a different play experience but maintain functional compatibility.

 

[Mark]

Forked from: I’m not dead yet…..sticking with 3.5



This post got me thinking: just what is compatibility.

Best not to read me on an empty stomach. Or a full one, for that matter.

 

[Lanefan]

I guess what I am talking about is "functional compatibility". That is, being able to open the book and use the material with no or minimal fiddling. The most basic illustration of this would be an "edition neutral" D&D adventure or supplement. For example, in such an adventure there might be an encounter with 8 orcs, designed for 3rd level PCs. "Orc" is a known quantity, a defined term in D&D, as is "3rd level". The adventure, then, is "functionally compatible" with any edition of D&D in which 8 orcs versus a party of 3rd level PCs is an equivalent encounter or challenge. No stat blocks are needed, either, since "orc" is a defined term. This compatibility may even extend to other fantasy games where the relationship between "8 orcs" and "3rd level" is equivalent.

All this does is transfer the workload from the module writer to the DM, as for play you'll still need to stat out those orcs to suit the edition your game is using. Which means there's still going to be lots of fiddling.

The other end of the spectrum would be using stat blocks as they are presented in a given edition but changing the definitions of the terms in a stat block. If, for example, an orc has a stat block of AC 15, HP 6, Attack +4 in a given version of the game, it is "functionally compatible" with any other version of the game, or other game entirely, which uses the same stat block with the same relative meaning. Even if your system is noticeably different -- say an opposed roll is used for combat where the target rolls under their AC and attacker tries to roll over it, and the one with the greater result is successful, or some such -- it is still compatible so long as the relative values and relationships are similar.

Which would be wonderful *if* the different editons were that compatible. They're not. A 6 h.p. orc is perfectly viable in 1e but pretty helpless in 3e and nigh-useless in 4e. Now take just about every other number the game uses and look closely; you'll see a similar problem: a raw number (e.g. 43 h.p., +7 damage) that fits edition-x well is not going to fit editions y, z or a.

It would be an interesting exercise, I think, to try and redefine all the terms in a typical D&D stat block (pick an edition) and change the rules surrounding those terms and values to create a different play experience but maintain functional compatibility.

Huh? Now I'm lost. What are you after here?

Don't get me wrong; inter-edition compatibility (more precisely, lack thereof) has always been one of my biggest annoyances. I want to be able to take a good x-e adventure and drop a y-e party into it with a minimum of work, and still have the adventure play out about the same and be just as enjoyable as if it was being played by characters of the same edition it was written for.

And while it's certainly possible to write an adventure that'll end up working for any edition (maps and plot, after all, really are edition-neutral; as are monsters in a generic sense), there's no getting around the fact that *someone* has to do the gear-grinding to stat up the opposition. Unless, fo course, stats are given for each monster in about 3 different formats (roughly equating to 1e/old school, 3e/d20, and 4e; most things can be shoehorned into somewhat resembling one of those).

Lanefan

 

[Reynard]

All this does is transfer the workload from the module writer to the DM, as for play you'll still need to stat out those orcs to suit the edition your game is using. Which means there's still going to be lots of fiddling.

Not in the example given. "Orc" is a monster straight out of the MM and for 1e, 2e and 3e, at least, no more work needs done than flipping open the appropriate MM to the appropriate page. I won't speak to 4e because I have no idea whether a) 8 orcs would be a good fight for 3rd level PCs, and b) whether "orc" is a useful or complete term in 4e.

Now I'm lost. What are you after here?

Don't get me wrong; inter-edition compatibility (more precisely, lack thereof) has always been one of my biggest annoyances.

My fault, I am sort of talking about 2 things at once, though they are related.

On the one hand, I am talking about a sort of edition-neutral lexicon, the terminology that is common through editions of D&D and related games that have inherent equivalent meaning, even if the details vary between editions ("orc" and "3rd level" being the terms in the example given). It doesn't matter that 1e orcs and 3e orcs are different when compared to one another, it is that they are equivalent when compared to 3rd level characters in their respective editions.

On the other hand, there's this though experiment floating around half formed in my mind in which you take both the terminology and numbers from any given edition (doesn't matter which one) and change the meaning and use of those terms and numbers to fir a different set of rules, but maintaining equivalency. It's more an extension of the idea of compatibility being a function of terminology and numbers than anything else. It's hard to use 1e adventures with 3e, for example, because the numbers change between editions, even if in many cases the terminology remains the same. One could conceivably maintain both the numbers and terminology, but change play.

I apologize for having a hard time coming up with a concrete example, mostly because the idea is still nebulous. I'm not even sure it is possible, in fact. But what I mean is rather than adding or changing a whole bunch of system information, which then requires conversion, one uses the system information differently.

For example, let's say I want to create Reynard's Fantasy Heartbreaker, but I want to be able to sell to the existing market. So the RFHB Core Rulebook comes out, detailing a whole different system for going in holes and killing things and taking stuff, built around opposed rolls and percentile dice and the occasional game or rock-paper-scissors. However, I not only use terms like Hit Points and Attack Bonus and Saving Throws, I apply numbers to those terms in a way that is consistent with their values in D&D, relative to the other terms and numbers in the game. So while 30 hit points in RFHB might serve as a wound check value versus a damage total (just to pull an example out of thin air) it is, in relation to the rest of the system, the equivalent of 30 points of damage attrition points as it is in D&D. Therefore, when I start pumping out adventures and monster books, those publications still have value to and are balanced for use with D&D (to catch the widest possible potential market, not just fans of RFHB).

Again, it is more of a thought experiment: is such a thing even possible, with no real concern as to whether such a thing is desirable.

 

[Beginning of the End]

To me there are two relevant kinds of compatibility:

MECHANICAL COMPATIBILITY: In other words, I can use the mechanics from Product A with the mechanics in Product B without changing them.

STAT BLOCK COMPATIBILITY: In other words, I can use a stat block from Product A with the mechanics in Product B without changing them.

Products that claim to be "compatible!" when what they really mean is "conversion is (relatively) easy!" annoy me a lot.