RPG Design vs. Language Design

[resistor]

I was reading a textbook on programming language design, and realized that many of the issues it examines as criteria for evaluating a language are similar to the criteria involved in evaluating an RPG system.

Writability: For a programming language, this means how easy for a programmer to express exactly what he wants to happen in that languages. Its parallel in RPG's might be better termed expressiveness, in that it is to what degree the system makes it easy you to describe any given entity in game terms.

Readability: The converse of writability, readability is how easy a programming language is for a human to read and understand. In RPG systems, this is the relative ease with which one can look at a mechanical description and understand what it does.

In both programming languages and RPG systems, writability/readability is somewhat of a tradeoff. A more writable language makes it easier to specify exactly what you mean, but that same capacity for detail usually makes it harder for a reader of the language. The case is almost exactly the same for RPG systems: more detailed mechanical descriptions are almost always harder to read.

The final concept in language design is that of orthogonality. An orthogonal language is composed of a very small number of constructs that can be combined by a very small number of operations, but which can still express complex ideas through large combinations of these smaller base units.

Orthogonality in RPG system design usually means a reduction in special-case rules. The 3e multiclassing system is a fairly orthogonal system: there is a small number of class, and only one operation on them (adding a level of one to existing levels of any others), and yet it is capable of generating remarkably complex characters.

In language design and in RPG systems, orthogonality is a double-edged sword. While when used in moderation it can vastly simplify languages and rules by reducing special-cases, it can also lead to unexpect side-effects. In languages, allowing every construct to respond to every operation may lead to unexpected behavior when someone tries to perform math on a piece of text. In RPG systems, problems (balance issues, unintended side interactions) may occur when new material (new classes, for instance) is added, since the original design never accounted for them.

What do you think of this view on system design?

 

[J_D]

I think you've got part of the idea, but you're missing a vitally important aspect.

First, let me state my bias - I'm a software engineer by profession, so I'm strongly inclined to view the subject in those terms. I'm fully aware that many gamers will vehemently disagree with the views I state below.

A roleplaying game can be split into two parts - setting and system. Setting is the map, lands, cities, NPC's, history, myths and legends - in short, the people, places and things. The system is the set of mechanics by which events within the setting are adjudicated. Both are needed for a roleplaying game. With no system all you have is collaborative storytelling - you don't have a game at all. With no setting at all, all you have is an flavorless and abstract board game akin to checkers.

The system itself can be split up into two sub-parts - rules and data. Your post addressed only the rules part - the collection of statements of the general form "if situation X, then do Y to produce the resolution Z". For example, X might be "to see if an attack hits", Y would be "roll d20, add modifiers, and compare to the target's AC", and Z would be "if the AC is equalled or exceeded then the attack hits". In essense, all the rules can be reduced to this form, and comprise the conditionals and operators that make up the "language".

What I want to address here is primarily the data part. The rules - the conditionals and operators - need something to compare and operate on or they're pointless. That something is, obviously, the data. This data is comprised of a number of game objects or 'entities' - classes, characters, skills, feats, spells, monsters, etc, and those objects are defined by some set of values. For example, classes have names, levels, BABs, saving throws, special abilities. Characters have names, attributes (STR, etc.), height, weight, age, skills, feats, etc. I think the data part is the foundation of a roleplaying game, because the rules need the data operate on to produce results. The "ToHit" rule example is useless without the data - the modifiers and AC - to operate on, just as in a computer or mathematical language the "greater than" comparison is devoid of meaning without two numbers to apply it to.

This structure of game data - entities and attributes - is essentially a relational database. This is where game design must start - what data model will the game be built upon? What are the entities, what attributes do those entities have, and how do the entities relate to each other? The data model is the foundation of the game system because you can't design rules to operate on data until you know how the data itself relates with each other.

I would go so far as to use this idea as the fundamental basis on which to judge the value or 'goodness' of a game system or any particular mechanic within it. A good game system is one in which the data model is clean and elegant and (non-software people please bear with my use of technical jargon) is normalized to the Third Normal Form. The farther away the game system's data model is from the Third Normal Form, the lesser is its quality.

Some who object to this might say that a pen-and-paper roleplaying game is not a computer game. I readily agree with that but it's irrelevant to the point at hand. Data is data and follows the same rules whether it's electronically automated or not. The cleaner and more elegant the design of the database, the simpler and more orthogonal the rules for using that data will be, and I think most people would agree that this makes for a simpler and easier to learn game system. That this will simultaneously make the game easier to implement in a computer application is just icing on the cake.

Players or even DM's don't have to be aware of the details of data modeling or relational databases to gain this benefit. If the rules are simple and the information about classes, characters, etc. is given in easy to use tables, then the players and DM's will learn it quickly and use it efficiently, just like a driver doesn't need to be a mechanical engineer or understand the workings under the hood of his car.

The 3rd edition of D&D is a significant improvement over previous editions precisely because the data model underlying the system is more easily implemented in a normalized database. It's not perfect, of course, but it is an advance over 1st and 2nd editions.

As an aside, this principle is why I hate loathe and despise the very concept of the "substitution level" and consider it one of the most deplorable of the recent additions to the D&D rule set. I've yet to figure out a way to cleanly fit it into the data model, and if I were going to write a computer application to implement D&D I'd have to resort to nasty kludges to get it done; that deeply offends my sense of design. Even without any computer in use, in any pen-and-paper game I DM substitution levels will be banned outright.

It's been my observation that the development of the setting and system parts of a roleplaying game - "fluff" and "crunch" as it's called - require distinctly different skill sets and that it is rather rare to find people who are good at both. Setting design needs people who are good at the "artsy" type things like history, mythology, politics, etc., while system design needs people who are good at data analysis and number crunching. For this reason, if I were in charge of a game company I would divide the design and development department into two distinct and separate sections. I'd put the "artsy" type people in one office to work on the world, hire database architects and data analysts to engineer the game system, and not let the "artsy" people get anywhere near system design.

The setting developers can tell the game engineers "it'd be really cool if a character could do this", then the game engineers would take the idea and engineer a data model and rule mechanic to support it. If a particular "do this" idea is simply impossible to elegantly fit into the game system, then the game engineers will tell the "artsy" folk "it doesn't work; it'd make a stupid and kludgy world - find another idea." This should be rare, though; good engineers should be able to find a way to fit most things in, and if they truly can't then the idea probably really is a stupid idea that doesn't belong.

 

[FireLance]

J_D, for what it's worth, I agree with almost everything you said except for substitution levels, which I happen to like. They do create an additional complexity which is difficult to code into a program, but they are not too difficult for a human mind to wrap around. From that perspective, they could actually be a feature and an advantage that pen-and-paper games run by a human could have over a computer-run RPG.

 

[Abe.ebA]

(Note: I'm a physicist with a heavy math background, so my reading of the word 'orthogonal' may deviate significantly from the sense in which it's being used. If applying the term 'orthogonal' to abstract objects I would say that they satisfy orthogonality if they share no common features. In the case of rules: Rule A is orthogonal to Rule B if and only if for any Situation X, application of Rule A will yield an outcome which is not identical to the outcome yielded by the application of Rule B.)

I'm not sure that orthogonality is always a desirable trait in a game system. It's certainly good to keep the system reasonably orthogonal in that you don't want rules constantly overriding one another, but I think that it should be possible to create the same outcome in some (or even many) situations by applying different rules. Take as a case the situation of a locked door encountered by the PCs.

In a truly orthogonal system, there would be only one rule by which the door could be opened. The Door Opening Rule would require a certain input (a skill check or something) and would result, depending on the input, an output of an open door or a closed door.
In D&D we have several rules which can be applied. Picking Locks, Melee Attack, Casting Spells, Using Items, and probably more depending on the specifics of the situation. It's exactly this versatility that draws me to RPGs. There are no set responses to a given situation... Maybe an ideal response, but never a fixed one which has to be applied to move forward (at least not in a well-run adventure).

But I might just be taking this far too literally or using a completely different interpretation of orthogonality. It's late and I'm tired, so excuse me if I ramble

 

[resistor]

I agree with the importance of a normalized data set, but I think that the issues I described originally are still present, and are fundamental design decisions that need to be worked out before defining the data model. For instance, it is advisable to decide, before beginning work on the system, where it stands on the readability/writability spectrum, i.e. the descriptiveness vs. simplicity spectrum.

The degree of orthogonality that is desired is also an important thing to decide in advance. Highly orthogonal systems tend to be very flexible, but have few safeguards against unintended rules interactions. Less orthogonal systems will have lots of safeguards which may come off as arbitrary restrictions.

Once those issues are settled, the design of the data model can begin. I think the language/game design continua serve more as design principles which then guide the development of the data model.