Daily Archive for September 23rd, 2006

Design Feature: The Fundamentals

I suppose that the beast way to start the features is to start from the core aspects of what we will be talking about. Nearly all of the features in one way or another will deal with either the 7/13 generic engine itself or with the CoE perception of reality.

This first feature is about designing role-playing games in general. After this many years being around everything, I’ve always observed that people who play RPGs generally, at least one time or another, put some thought into designing their own game. I’ll tell you first off, it’s not as easy as it sounds and there are probably many of you out there who already understand this. The key there is actually the inverse: it’s not that the design aspect is really all that difficult (or at least it shouldn’t be) – it’s
that getting the simplistic aspect to a game engine, the flow of the game, is what poses the greatest amount of difficulty.

For any of you out there who have aspirations about designing your own game I strongly urge you to do it. I know there are a lot of folks in the industry who are actually pretty negative on this point (I’ve seen them beating down new designers often on forums or otherwise), but I think there is a lot to be had from new designers. I was privileged to have played in the demo of a new game out in Austin Texas that was a fabulous, very original concept that worked very well and this would never have been possible
if those creating it had bowed down to the concept of writing for d20 or another game system. If you want to do that, to write for another system then that’s fine, but designing your own game system is important I think at least to truly understand the mechanics of game design – the technical work.

There is actually quite a bit of insight into design hidden here and there in 7/13:CoE…I’m not secretive at all about how I designed the game engine – I’m always up for a new game engine to read or play. What I’m working on here is a bit of insight for you, the players, into some good practices for game design. As a secondary factor, this feature (and the ones I will write in relation to it) refer to how seven13 was created. If you can’t tell by now, I’m fairly long-winded in my writing, but I get fairly thorough
to my credit, so bear with me.

The first and most important thing to consider about any game system is the Big Three: Action Resolution (AR), Effect Resolution (ER) and Special Cases (SC). Action resolution refers to the systems that help determine the results of characters taking actions in the game, effect resolution refers to what happens as a result of the action succeeding or failing, and special cases effect both based on situations and factors effecting the action or effect. It’s really not that complicated at the core, but it can get
really complicated fast – so it’s always important to remember those big three and that at the absolute core, that’s all there is to the system. Simplicity is the key to designing a game system that will do well – it’s easy for people to build on the rules, but you may find often that players are for some reason less likely to remove rules. I’m not sure why that is, but trust me, it’s true.

Now, to tangent, there are a lot of paradoxes and balance to everything I will say here, but there is a point to it. While I’ve just talked about simplicity being the key, it is a final goal. Your game system should be thorough enough to include rules for most foreseeable situations that will affect the game, but with so many considerations to take into account that idea can come crashing down and overpower the game with rules very quickly. The key is to design based on centralized core concepts. The best programmers
in the world often are not determined by whether or not they can make something great, but how precise they are in doing it. The difference between a program written by a novice and a master that are virtually the same is usually found in the master’s code: it is much more direct, crunched down and simplistic and there is less of it.

But let’s get back to the fundamentals. Our first and primary consideration for a game system has nothing to do with rules at all; it has to do with style. The first thing you have to figure out before you even consider the system aspects of the design are what you as the designer want to create. The easiest decision here is whether or not you want a diceless system (one that requires no rolling and determines AR and ER by character aspects and story alone) or the classic dice-rolling based system. Personally
I prefer dice-based systems so I’ll be using that concept as we move on. I’ll create at least one feature in this chain that involves diceless design, but for now I’m going to start on the traditional angle. The next thing to consider is what your core mechanic will be. This will determine almost every aspect of your system related efforts. Let’s go through some of the classical game mechanics:

  • Target Number: Relevant character aspects are combined with the roll of a die (or dice) and added all together against a Target Number to determine success. This is seen currently in the d20 system among others.
  • Dice Pool: Character aspects determine a number of similar dice (d6 or d10 usually to roll), requiring a number of rolls tat are higher than a certain value (successes). This is seen in the World of Darkness game system among others.
  • Percentile: Character aspects are ranked up to 100 and percentile dice (d100 or d%) are used with the concept of rolling beneath the character’s value or target value of 1-100 (% chance). Seven13 uses this method, as well as Call of Cthulhu and many other games.

Now these are only three core mechanics, but they are the most common and most stable. Also, I should note that these are only ideas. While 7/13 uses the Percentile mechanic for resolution, it has many other aspects that differ from standard percentile system. None of these methods are better than the others, it is simply a matter of taste. All can be made into perfectly functional game systems. In my opinion at the heart of it all Target Number is a mechanic that serves more strategic, technical games best,
Dice Pool serves heavily narrative games best, and percentile sits somewhere in between. Then again, all could be used to any purpose with the proper design and each could be combined with the others for certain situations in game.My recommendation is to start with the form you are comfortable with and work from there. I have a heavy background in Call of Cthulhu and 1st Edition Warhammer Fantasy Roleplay, so the Percentile mechanic came easily for me.

Secondly you should consider what type of game you are designing as this creates a good basis for what types of rules you will need. This, primarily, means determining your setting. I personally do not recommend starting on the basis of creating a generic game engine, as the work and tweaking there is very heavy and involved and can easily be worked up to later. Personally I started with high fantasy long before Seven13 was anywhere near it’s current self, but you might be more inclined toward a modern setting
or one of Science Fiction. Once you have this figured out, you have already done a lot of work toward your design layout.

So let’s rehash: The fundamentals of the game system design are basically the mechanic and the style. The mechanic will determine the basis of how the game will run from the technical side, and the style will help in the future with understanding what the rules need to do. For example, a high fantasy style will not require rules for automatic firearms. Once you have these set in mind, you have a good place to start designing your own game, or at least for understanding the way systems are being designed.

In the next section of this feature, I’ll start tackling character aspects and systems for actions, but for now mull over this for a while. Your questions, comments and suggestions are always welcome here.

- Ashe