Open and Licensed Rules Systems: The APIs of RPGs

Today’s Razorwise Report comes courtesy of our technically minded Kristian. We hope you enjoy it. Until next time, I bid you, dear readers, adieu! ~Sean

While perusing my Google Buzz stream of users I follow, I stumbled across a YouTube video comparing open application programming interfaces (APIs) to a deck of playing cards.

The demonstration is a simple contrast of board games to a deck of playing cards, the latter of which represents the open possibilities of endless options. I realized immediately that the same values of APIs can be applied to open or licensed RPG systems. In essence, such a system can be considered an API with which a game developer or GM can design a custom game or setting.

  • An open or licensed system such as Savage Worlds, FATE, D20, Pathfinder, etc. presents some significant advantages for a game designer or developer.
  • The system is already designed for you. All you need to do is come up with the creative concepts to make the setting unique.
  • The system can be tweaked. For example, if you don’t want power points in your Savage Worlds setting because it doesn’t fit the scope of your world, you can augment the system with your own version of the powers subsystem. If you don’t like the rule that states you can only use a small firearm to fire at an adjacent an opponent, change it in your setting rules. If you want to eliminate rank requirements for Edges to make your setting feel more epic, feel free.
  • The system acts as a common language through which all settings designed with that system can be understood and played.

The great thing about this idea is that despite using the same system as a foundation, publishers and GMs can create very different settings that offer very different experiences with each setting, whether they are published or homebrewed. Ravaged Earth is a very different experience from RunePunk, which is very different from Realms of Cthulhu, which is very different from Iron Dynasty. Each of these uses the same system, but provides a different experience.

How is this analogous to a software API? Let’s use social media as an example. There is a vast number of social media platforms available, some designed for specific purposes (location-based services with checkins) while others are more general (status updates and content sharing). However, we see dozens of clients for accessing those services such as Hootsuite, Seesmic, and Tweetdeck for accessing Twitter, Google Buzz, Facebook, et. al. Additionally, there are different platforms from which a user can access these services such as a web application, a mobile app, or a desktop client. As a developer, I might have an idea to create an application for a specific purpose. APIs reduce some of that work so that I can focus on the user experience and interface of my product. With an API, I might take the following steps:

  1. I come up with an idea for an application that can fulfill a need (e.g. – an Android app for sharing content or posting status updates).
  2. I choose an existing service to which I want the user to be able to publish those checkins (e.g. – Google Buzz, because Twitter is too limiting.)
  3. I design and develop my application, selecting the API components with which I want to interface. I might only be interested in posting and not at all in reading or commenting, so I only need to worry about the part of the API that posts to the user’s account.
  4. I offer my Buzzter app in the Android Market.

In this process, I didn’t have to worry about building the social medium itself. Google already invented that wheel for me. I could have chosen a different system, but Buzz was more fitting for what I wanted to accomplish.

Notice that in my example, I cover the availability of several social media services from which I can choose just as there are a number of RPG systems available. We constantly see arguments about which system is better, but the truth is that it’s all a matter of choice and preference. In some cases, it’s a matter of what system best suits the game concept. The benefit of having several open systems is that I can do the following:

  1. I come up with an idea for a game I want to run, play, or publish. I want to create a game set in the 21st century after a virus and environmental disasters wipe out the majority of the population.
  2. I choose the existing system I think best fits the experience I want to convey. I like the high-action feel of Savage Worlds, but I also feel it’s flexible enough to allow for suspense and drama. This saves me a ton of work as I don’t have to build my game from scratch, and it saves players a ton of work by using something with which they’re already familiar.
  3. I create my setting using components of the system to drive the setting, tweaking them where needed. I don’t need magic, but I might want rules for infection.
  4. I publish my setting.

Pin It on Pinterest