Wednesday, April 17, 2013

Object Oriented Principles in RPGs

Being a programmer, I like to think programming concepts with regard to games and rules systems. Sometimes I go a bit further, like the time I built a .NET Silhouette vehicle design program or built a SQL database out of the Mekton Zeta Plus construction rules. Today's topic is object oriented principles in roleplaying games. Before we get into that, a couple caveats:

First, I wouldn't be surprised if this post has one of the lowest view counts of any post on this blog. I'm fine with that - it's more of a philosophical pondering than anything else.

Second, for anyone who's not familiar with object oriented programming languages this is a really good article (it is long, I'll wait while you read it): What Is OOP. If you don't want to read it (or just want to hit the salient parts) I will only be discussing these three things:
  • Abstraction: Stripping something down to its basic elements or characteristics.
  • Inheritance: The reuse of abstractions to build new ones.
  • Polymorphism: The ability to use the same interface but with a different implementation.
Now almost all game systems do these to some degree (as well as many of the things the article's author says "isn't OOP").  A good example of abstraction is a weapon. In the real world,  the subtle differences between weapons probably have an impact, but it's too hard to keep track of that stuff in an RPG. Instead, the system abstracts out the basic elements: damage, range, accuracy or balance, etc. Some of them go into more detail than others - such as durability or quality - but all weapons have the same basic characteristics. They use inheritance to create, say, a magic weapon. It uses the base weapon class but then adds a attribute such as "+1" to it.

Polymorphism can typically be seen in mechanics. Fate Core is a perfect example of this. Each of the four basic actions you can perform with a skill (overcome, create advantage, attack or defend) has the same interface (the die roll), but the implementation within each of them is different (the rules inside them are different). The output - failure, tie, success or success with style - is also the same. As an aside this is also an example of encapsulation - the inputs and outputs are the same, but the interior "code" of the action is a "black box" (at least in terms of the output not caring what happened inside the action).

Fate does an excellent job of embodying these concepts. Take the "Fate Fractal" for example. Anything can have an aspect, or a skill, or a stress track - up to and including the setting itself. I recently implemented survival rules where as the players run out of Resources, the setting gains an aspect representing their Struggle For Survival. As their Resources go into the negative, the setting picks up three skills: Hunger, Thirst and Exposure. These skills can be used to "attack" the characters. This implementation is fundamentally object oriented in nature.

Most systems can accommodate something like this, but Fate Core (and other Fate games) facilitate it through design, and are especially good at it. This isn't to say that an rpg based on  OOP principles is "good" and one that doesn't is "bad". Game systems aren't code or operating systems in the most technical terms. But I think some games, like Fate Core, definitely do it better than others. There is at least one game, Alternate Realities, that claims to "object oriented". I've taken a look at it and think it's much more complicated than it needs to be.

Also, on a related topic to object oriented principles is a rather lengthy PDF called Design Patterns of Successful Roleplaying Games by John Kirk. Kirk identifies various design elements and then uses those to try to determine the design patterns in various rpgs, through a lens similar to software design patterns. It is highly detailed and I think it's successful in a lot of ways. Obviously, because of the sheer variety of rpgs there are likely to be some that slip through the cracks (and I predict at least one comment saying how such-and-such rpg doesn't fit any of those patterns). I wouldn't say it's required reading for all game designers, but just as it can be helpful to have an eye toward high level object oriented principles when designing an rpg, being aware of the possible design patterns can't hurt either.