Click on the image to see a larger version

As someone who writes about RPGs a lot, I am naturally interested in game design techniques and philosophy. As a former I.T. professional, I have discovered that a lot of the principles of sound program design practice also apply to rules design. With those as my starting point, I thought I would have a stab at defining an approach to the perfect game design – without actually getting too bogged down in actually designing a game.

Iterative Function

By far, the most powerful technique that I have ever found for handling complex systems is the Iterative Function. Applying a set of simple steps, repeatedly, compounds their effects to staggering levels, while keeping any given step manageable.

I’ve used this approach a number of times in different articles over the years, for example:

These are just a few of the more overt examples; the principle has been implicit in many of the articles that I have written here at campaign mastery.

The actual concept comes from Chess: each piece has only a few simple moves open to it, but the compound produces a game of staggering complexity. It also underpins computer software, where everything that occurs is the result of simple instructions executed sequentially, the power of which I learned when I first analyzed a bubblesort algorithm (illustrated by the animation).

In mathematics, the concept is fundamental to what are called “Iterative Functions”, which are at the heart of Fractals and Chaos Theory, and can be used to produce Mandelbrot sets, like the one illustrated at the top of this article. The reasoning in terms of game design is elegant: Simple steps tend to be quick to execute, and if the interaction of those steps is a complex behavior, you get addictive gameplay with unobtrusive game mechanics.

Top-Down Modular Design

The perfect game system would have a very simple design philosophy and be built around the concept of top-down modular design.

Top-Down design means that you start with a summary of an overall function and subdivide the design into a series of logical sub-functions. Each of these is then further subdivided, this process continuing until your design achieves functional instructions, in this case, game mechanics, that are complete and self-contained.

An example of top-down design applied to the topmost level of RPG design might be:

  • character creation
  • adventure creation
  • character operation

It’s only when each of these is broken up into sub-steps and sub-substeps that the power of the approach begins to show itself. Starting with character operation the designer can list all the things that a player might want a character to do.

Defining a simple resolution system for each – and varying it only when necessary – also defines the key parameters that distinguish one character from another. Each of those, logically, must be generated in a sub-step of the character creation process.

The resolution system also defines the parameters describing the game world with which the character is interacting, which are the fundamental building blocks of the adventure creation item. At the top level of each of these actions, the description would be extremely broad: “move”, “explore”, “talk”, “fight”, “manipulate object”, and “learn” would be common to most RPGs. Some might have “cast spell” as well.

The Rules Core

The core system should contain the simplest rules possible to achieve the required functionality, and nothing more. The entirety of these game mechanics should fit on one page, two at the most, in a reasonable font size.

Standardized Subroutines

One of the ways in which this should be possible is the use of “standardized subroutines” – methods which are used over and over, in different systems. “Attempt an action” is would be one such standard. “d20 + modifiers >= target” is an example; this same technique should be employed throughout the game whenever any sort of check is called for.

Plug-and-play optional subsystems

The simplified game mechanics described so far are different from the approach of just about every RPG game out there, but are hardly different enough to be considered groundbreaking. The problem is that any sort of reasonably comprehensive game design can get you to this point even without employing the top-down approach; it is only by extending the technique one step further in game design that anything radically new is achieved.

Each system and subsystem can be viewed as a “black box,” with a defined set of inputs and outputs and a specified function. Explicitly stating the parameters of those black boxes permits the adoption of Plug-and-play optional subsystems.

Instead of the basic combat resolution system, for example, this approach enables the GM to choose to plug in a chapter describing a more detailed and complex system. So long as the basic inputs are the same and the basic outputs are the same and the summary of the functional purpose of the subsystem is unchanged, the bottom line remains unchanged. That means that the internals of the black box can be as complicated as you like, with as many bangs and whistles as are desirable, without altering the basic operation of the system.

What’s more, you can offer a choice of plug-and-play subsystems, each fully self-contained. This one has more complicated rules for ranged attacks. That one takes different combinations of armor and weapon into account in determining damage. A third might have a hit location system, or a critical hit system. And if each of these systems and subsystems is also designed as a black box using top-down design, then combinations are possible. In effect, each GM can customize the game system to the tastes of his players and himself.

Third-Party plugins – the Game Licence

This system is also optimized for the production of third-party plugins – contributions from other game companies. It needs a licensing system that encourages such participation by the broader game community. Something akin to the OGL system, operating in a similar manner to an affiliate scheme, would be ideal.

Instead of paying a license fee to use the logos and trademarks and the like, funneling a fixed percentage of the sales from third party producers back to the publishers of the original source material not only sustains the original publisher but encourages cooperative marketing. It would enable the original producer of the game system to sell copies of third-party “plugin” rules modules through their own storefront, and vice-versa – everyone benefits as a result.

Making it a percentage means that the rules are “open” for home users – people can publish house rules freely. Obviously, there would need to be policy restrictions in place to prevent abuse – and the “black box” approach to defining systems and subsystems enables this to be controlled to a fine degree, by restricting how much of the official rules any single third-party supplement can quote, modify, or refer to. These would be very tight for a free product or sample, and moderately restricted for for-sale publications. Similar restrictions – perhaps broader, perhaps not – would apply to home-users publishing rules on websites and forums, and the like.

The net effect of this policy would be to control the amount of system that can be replaced, encouraging sales of both the optional supplement and the original game system.

I would also include in the OGL the option for a publisher to purchase the rights to any “free” content, no matter where it’s published, for inclusion in “official” sources, at the discretion of those sources, at a fixed fee. If Joe Blogger posts a really killer subsystem that the game designers absolutely love, and want to incorporate officially, they can pay him to use it at a rate fixed in the OGL. It can be bundled with some of the publisher’s own ideas, and (in general) use the fan-base as a freelance R&D department for the betterment of the game. Another term of the agreement would mandate the assignment of credit where it’s due.

By keeping everything packaged in discrete black boxes, such rights purchases can be made on a per-use basis, so that the rights would devolve to the author – so that he has a foundation if he wishes to start his own self-publishing operation, or a different module publisher wants to use the same black-box.

Of course, this might all be pie-in-the-sky pipe dreams. But it seems clear that the OGL was a great success, but didn’t give WOTC sufficient control over the content for their satisfaction, while its replacement has been a comparative failure. It was annoying for game users as well – one publisher’s book on Clerics didn’t interface cleanly with another publisher’s book on deities, and so on. (I’m still peeved at the lack of integration between the 3.x Deities & Demigods and The Epic Level Handbook – if WOTC themselves can’t spare a page or two to integrate their products, what hope do the rest of us have?

Expanding Scales

A key requirement for me is that the design employs an expanding scale for physical phenomena. The Hero system does this for Strength, and I have seen attempts to employ the same approach to determining IQ: An INT of X is equivalent to an IQ of Y.

But by far the best use of this was in TORG by West End Games, still available through Amazon, which used a universal scale for time, distance, weight, and more. This enables game mechanics to work with relatively small and manageable numbers even when dealing with large objects. A value of “32” could be a month, a six-apartment building, or the distance from Paris to Moscow, or 2½ million of anything.

This gave the game a huge flexibility that was exploited mechanically in various ways. This article at Wikipedia has more information for those who may be interested, and Kansas Jim still has goodies at his website which unfortunately hasn’t been updated for some time.

The same system works for the vanishingly small, as well. But the TORG system didn’t really handle area and volume very well, and the category of “energy” was a missed opportunity (or perhaps an avoided argument). There was so much more that could have been built on the foundations of a very clever game mechanic, which continues to set the standard for me long after the publisher has gone belly-up.

Confining Maxima

The other area where games have traditionally not done well – and I can’t point at an example of best practice, there isn’t one – is that of Confining Maxima. This is a reflection of Zeno’s Dichotomy Paradox as it applies to humanoid abilities.

Essentially, if it takes a certain amount of effort to improve some ability by a certain amount, it should require more effort to then improve that ability by the same amount again. This essentially establishes a limit which is increasingly difficult to approach. For example, it might require STR 20 to lift 100kg. It might require STR 30 to lift 200kg. It might require STR 40 to lift 250kg, STR 50 to lift 275kg, STR 60 to add another 12.5kg to that total, STR 70 for a further 6.25kg, STR 80 for an additional 3.125kg, STR 90 for an additional 1.6125kg, STR 100 for an increase over that of 806.25g, and so on. In the example, the limit of ability, requiring infinite strength, is 300kg (which is not very realistic, but is a fair start). To move the limit, or shift the scale, something exceptional is required.

I have never seen a properly-developed game system of this kind, yet it is something that is reflected in real-life sporting prowess all the time. I once heard it expressed about formula 1 thus: “For $100K you should be able to get within a couple of seconds of the leading teams, per lap. For $500K you should be able to get to about a second off the pace. For the next 9-tenths of a second, it will cost about $0.5M per tenth – per year. For each hundredth of a second after that, you are looking at $100K each. In Formula One, you travel at the speed of budget. But cleverness and ability can find priceless shortcuts.” (I’ve probably misquoted the original, but that’s the gist of the comment as I remember it from the later 1990s).

The perfect game system would not only incorporate this phenomenon, it would somehow integrate it with the expanding scales system described in the previous section. The obvious techniques for doing so are scaling and offsets: a race can be stronger than humans by offsetting the scale with a racial modifier. +25k would be a small increase. +100kg would be more substantial, indicating that the race has STR 30 on the human scale (average) and can go 100kg beyond the human maximum. +200kg is extremely substantial, because it means that a member of that race with 20 STR is as powerful as a human with an infinitely high STR score.

Muscle amplification technology – levers and so on – could work on the same principle, and so could high-tech, machines, and magic.

Scope for Extremes

These offsets also fulfill another criterion that I consider essential: the ability to have characters – PCs and NPCs alike – go beyond the extreme limits of what is doable.

Would anyone doubt that a Bull Elephant, or a T-Rex, would be stronger than the absolute limit of human potential? Or that a Cheetah could run faster than the fastest human who has or will ever live?

The game needs scope for Superman as well as Clark Kent.

Controlled Failure Modes

One of the key responsibilities when designing software is ensuring that the program is equipped to cope with every manner in which it can possibly fail.

These vary from the fairly obvious (typing ‘a’ when asked for a number) to the extraordinarily subtle (overflows in data registers which are then parsed as executable instructions to the computer). Subtle ‘division by zero’ errors can cause all sorts of strange results – just ask a maths teacher or professor what “zero divided by zero” equals. If he knows his stuff, you’ll probably get a dirty look.

There has been little in the way of analogous effort put into the failure modes of RPG rules systems. Ideally, you want the system to ‘fail’ in a meaningful way, that is, a way that informs the user that something is wrong and gives some indication of what the problem is. Most rules systems are still at the “it’s an answer but it feels wrong” stage.

It might be that this is a problem with no solution, due inherently to the table-top nature of the game. Certainly it would take a genius far beyond my abilities to devise an answer. But in a perfect game system, there would be some means of verifying the answers a GM gets when he is forced to use his own judgment – at the very least, something that clearly indicates when a subsystem has been pushed too far, some sort of reasonable limit.

Optimization: Addition Of Whole Numbers and other trimmings

Beyond these elements, there are only minor items on my wish list for the perfect game system. One is the use of addition of whole numbers instead of subtraction – it’s easier, faster and less prone to errors. There are a number of other such minor items but they really would be just frosting on the cake.

Without getting into genre-specifics or look-and-feel, that’s my recipe for the perfect game system. What’s yours? What would you like to see?

The images used in this article were sourced from Wikipedia Commons.

Related Posts with Thumbnails
Print Friendly