Tab-Neo Design Goals

From Tab Wiki

For quite some time now I have been working on my new house system: Tab-System Neo. It's mostly written at this point; I've ran a number of sessions in it; and I feel it's near ready to move into heavy play-testing. That being the case, it may be useful to make explicit what I was going for in the system's design; this way people have better insight into why certain design decisions were made, as well as in the future having a better understanding of why some suggested fixes may be used while others are not.

The various design goals of Tab-System Neo are as follows.

In Context

First, to state the obvious, it is important to make explicit the context the system has been designed in, and how it will probably be used. I am an amateur game designer. I run games. When the system has been all play-tested and polished up, I'll probably put it up for sale on my web page. I have no delusions of grandeur. Chances are it'll ever sell like only a dozen copies. It'll probably only ever get run by me, and if I'm lucky, maybe a small handful of times by people I know.

Being aware of this is useful. It means I know my audience. It also means that the GMing and play styles the game has to mesh the most with, are those of my own and the people that I'm likely to play with. And granted, the aforementioned pool of people bring a variety of different, and often conflicting, opinions on play style to the table. But trying to find the right stylistic balancing point for a known and finite pool of people is an easier task than doing so for an indefinitely large, unknown pool of people.

Be Fun

That aside, the foremost design principle and aim of the system is to be fun. If presented with two different implementations of something: go with the one that seems the most fun. That trumps all. I'd rather have an entertaining Frankenstein of a game which a mishmash of inconsistent subsystems than a system which is sleek, elegant but ultimately boring. (Which is not to say that I particularly want a Frankenstein of a game, just that fun ultimately trumps other goals like consistency or simplicity.) Similarly, I am not all that concerned about how gamist or simulationist, cinematic or realistic, or whatever, the system ends up being. Let that be something that is figured out in retrospect. I'd rather just try to figure out what seems fun to people, whatever that ends up being.

Now I know that what constitutes fun is necessarily subjective and somewhat vague. And people have differing opinions. And sometimes a particular subsystem is going to end up being more fun for some people than others. That can't be helped in any game system. But if the game ends up being fun for people most of the time, and at least tolerable the other times--even which times it is fun is different for different people--then it's a pretty good game.

Simple to Hold in Mind

Open a rulebook to reference tables, effects or how things work slows down play a lot. This doesn't matter so much during character creation, where pacing isn't an issue. But during a game it sucks. Ideally, a group who is familiar with the system should never have to open the book at all during the game, baring extremely unusual circumstances. For this reason the system should avoid if possible relying on tables, charts, matrices or long laundry lists of status effects in game. If several effects are possible, the number should be kept small enough that a player could be expected to remember after using the system a few times.

A good metric is 7±2. That is, a person can hold 7±2 things in their short term memory at a time. Lists of possible outcomes built into the system shouldn't exceed this threshold. Similarly, when using any particular subsystem, like say Combat, there should be multiple meaningful options (making choices is fun) but a player shouldn't be overwhelmed with options. That also slows play down, as the player grapples with the paradox of choice. 7±2 useful options is a good number.

Finally, this guideline can apply to modeling characters. A typical character build shouldn't be expected to have so many traits that a player is overwhelmed in play. For example, a typical character build may have 7±2 skills. (This was kept in mind when I was deciding how many skills to break the game down into--games with a longer skill list generally demand that characters have a greater number of skills.) Similarly, a typical Mage build might have 7±2 powers or a typical warrior build might have 7±2 fighting traits. If this ends up varying a little to the low side at lower levels and a little to the higher side at higher levels, of if atypical builds are out of this range, I'm okay with that. It's still a useful number to keep in mind.

Modular

Tab-System Neo is designed to be a modular game. That is, ideally it should have a simple and flexible set of baseline rules that could be used on their own; then, if less abstraction is desired for a particular area of play, there can be a module (a subsystem or set of related subsystems) that plugs in and provides that. The idea is, this adds to the system's ability to be widely encompassing (see below) by allowing Game Masters to pick and chose which modules are in use for a campaign. This helps keep the game from being bogged down in unnecessary rules. Running a game about feuding kindergartens? Probably don't need the full-fledged combat module--opposed rolls to see who shoves who down ought to suffice. In this sense, the aim is for Tab-System Neo to be a sort of toolbox design, and to minimize dependencies between modules.

Widely Encompassing

As was just alluded to, a significant goal is for Tab-Neo to be capable of running games in a variety of genres and styles of play. This being the case, it is useful to minimize stylistic assumptions in the game. That is, when in doubt, take the middle ground. How realistic or cinematic? If in doubt, pick something in the middle (keeping in mind the fun goal, of course). By doing this the system should be easier to adapt to a more realistic or cinematic style of play simply by introducing a small handful of campaign rules or a module that nudges the game in the chosen direction.

If there's still a tie in deciding an implementation, however. If push comes to shove, remember: It's easier to scale up than to scale down. That is, it's easier to make something less powerful a baseline assumption and scale up by adding XP or whatever, than to try to make something more powerful ma baseline assumption and scale to lower levels by hacking the system. Just look at the housecat-commoner issue in D&D.

As a final note, remember the target audience. The system at the very least should be widely encompassing enough to handle what is likely get be ran in it.

Character Representation

Ideally a character's stats should reflect them in some way as a person rather than boiling their statistics down a set of combat (or other subsystem) numbers and abilities. If, for example, the character is an anthropologist, I should be able to see the world anthropology written down somewhere on the character's sheet (and scrawled in the margins doesn't count). A character's stats are a representation of what they are capable of in the game world. This helps immersion and characterization.