Thinking About A Homebrew Game System?

 Posted by on June 7, 2012  Filed as: Editorial  Add comments  Topic(s):
Jun 072012
 

If you’re thinking of making your own RPG, you probably have an idea of what dice you want to use, what characteristics you want to model and how heroic you want the characters to be. Those are important to think about, but where do you go from there? Let’s look at some guiding principles that will help you make a system that flows.

Simple
RPG systems can get complex really quickly. When designing a system, you want to keep things as simple as you can while still keeping the level of function where you want it to be. There are a few tools that will help you to do this. The first and most obvious is the unified mechanic, if you want every interaction in the game to be handled by one set of rules. Once the players learn that set, they can do everything the game is designed to do. The main consideration is to keep things consistent so the players don’t have to look up how something is handled, they just know because they’ve learned the core mechanic. GMs will tolerate looking up material, but the more you can reduce the GM’s mental load – the more creative they can be.

Now think about how many individual steps you have in your mechanic. From the start of a round to the end of a round, count up how many dice rolls, equations, calculations and steps the players will have to slog through. Are all of them needed? Can you cut some of them out and still keep the same functionality? Is a slight reduction of function still enough to get you where you want to go? Your first answer is probably going to be that they’re all needed or that taking some of them away will take away some feature of the game you like.  However, if you allow yourself to kill your darlings and reconnect the dots without them, you may just end up with a stronger system.

Do your numbers have to be so big? If characters have 10 hit points and most weapons do at least 5 damage, couldn’t you make it so that characters have 2 HP and weapons do 1 damage? If payers roll 1d20 and the average difficulty is 10, is there a difference if you reduced things to 1d6 and the average difficulty is 3? There very well could be a reason for the higher numbers, but try to reduce them if it’s practical.

The last thing to consider is your math. “Do you need all that math?” would be the obvious first question. Could you provide a non-math approximation of what you’re trying to accomplish? If that’s not practical, try to change the type of math you have to do. Mentally, not all math is equal. Comparing two numbers is about as simple as you can get. This means looking at a number and saying if it is more, equal or less. Adding small numbers is the second simplest math operation you can have. Subtracting small numbers is actually slightly harder for your brain. Multiplication and division are probably not acceptable in the middle of play, unless you’re doubling or halving numbers. Small changes here add up over the course of a game. As a player’s mind is taxed to do repeated equations, they’ll slowly tire and become less creative. The more load you have on them, the more they’ll just follow the most obvious path.

The other question about math to consider is when will the players have to do it? A player that is going to get a big payoff from the math will more happily crunch numbers or at least more happily reach for the calculator. If the math is for something mundane or even harmful to them, it’s going to impact their enjoyment of the game.

This doesn’t mean you have to have a rules-lite system. The emphasis here is reducing the number of steps that have to happen in each round and reducing the mental load of the players. Extra steps are often acceptable for special effects that add spice to the game, but happen only occasionally.

Flexible
Now that you have your core mechanic, try to think of how many ways it can be used. Does the same system that you used for combat apply to social conflict? Could it be used in a survival situation? What about when computer-hacking? How does a doctor heal characters using the system? Can a character maintain a troop of minions with the system and still have turns go quickly? Try to push the boundaries and find exceptions.  If you haven’t found them, you haven’t looked hard enough.

Once you find the exceptions, examine what’s causing them. Is it the lack of a rule, or the existence of a rule? Either way, try not to add a new rule or step – see if you can modify the existing rules to encompass the exception. Sometimes when you’re able to do this, you blow open a whole new set of things your game can do, so really go after this whenever you can.

Think about the steps and rules you currently have. Can they be expanded to cover circumstances that you didn’t originally intend them to? If you’re already play-testing, a way to get some feedback on this is to pay attention to when a player misuses or misapplies a rule. They’re making a connection you may not have been thinking of as being a good thing. The player obviously thinks it is, so can you adjust things to fit the rest of the game?

Bullet Proof
Next think about how the mechanic can be abused. Is there an exploit that will make a character unstoppable? This may not happen right away; it often does happen as the PCs gain experience. Is it a bad thing? Can the challenge be moved somewhere else so that the PC is still fun to play? If you are going to migrate the challenge, make sure it happens slowly and that the players and the GM know that this is the direction the game will move in. This is vital so the players don’t get blindsided by the change and not understand how to keep enjoying their characters.

If you can let a PC max out any stat of their choice and the game is still fun and challenging, you have a robust system. If you can give them any piece of equipment they want and it doesn’t break the game, you’re doing pretty good. If the PC can be unstoppable in one aspect, but still vulnerable in another, you’re on to something.

Whenever a player tries something that has no effect in-game, you have a problem. When a player wants to do flips into a fight and the system doesn’t handle that, there’s a hole between what the player wants to do and what the system can handle. When the player wants to jump on the back of a beast and stab it in the neck, and nothing special happens, there’s a problem. When the player wants to start off with a horse and is willing to sacrifice other things for it, but they can’t, there’s a problem. Let them know how the change could effect the game and ask them for input on how the issue could be handled. It may require a lot of rethinking, but you’ll have happier players for it.

More awesomeness...

Emmett O'Brian

Emmett O'Brian is a science fiction role player, GM, imbiber of dark-hued beverages and father of two. Before he was even a teenager he'd been looking for and trying to design that perfect system that scratches all his itches (he'll let you know when he finds it). As his boss is fond of saying, "Don't worry, he looks scary but he's harmless." You can find his projects at theartifact.net and steampunkfitters.com

  5 Responses to “Thinking About A Homebrew Game System?”

  1. Not everything needs game mechanics. Remember that every element in the game needs to be compared with every other element that it can interact with. The more mechanics you add, the complexity grows exponentially.

    For example, stabbing somebody in the neck brings up the old “called shots problem”. Games with called shots almost always have one of two issues. 1) Called shots are worthless. The extra difficulty in pulling them off is not worth the in game benefit. Players never use them 2) Called shots are too good. The benefits you get from the called shot overwhelms the added difficulty. Players always use called shots.

    It’s not that you can’t build a balanced called shot rule. It’s just that almost any combat modifier will tip the balance one way or another. Clever players will try and stack the things that help them. Soon you end up with an character with a precision crossbow with spirit scope wearing only a full helm, breastplate and codpiece.

  2. Hi, Philo
    You’re right, not everything needs a mechanic. However if your players really WANT to be carrying around a precision crossbow with spirit scope wearing a full helm, breastplate and codpiece, well then, why not? Especially in a homebrew system, you really only have to cater to YOUR players. Theoretical other gaming groups really don’t have any sway in the decision.

  3. I have been working on a system that is trying to focus mainly on the roleplaying aspect, instead of the whole dice-rolling, power-gaming aspect. I am going to be including a system that rewards the player for being creative and explain what they are doing in as great of detail as possible. They could make a called shot, but they need to make it as fancy and descriptive as possible to be able to get the absolute best possible. I’m hoping that this will help with the whole power-gaming thing, but i will create mechanics so that the group that loves to do it, can do it.

  4. Hi Brock,
    Sounds cool, let us know when you’ve nailed it down. I’d like to see what you come up with. Remember, narrative mechanics are still mechanics so the concepts still apply. Usually narrative mechanics are pretty universal, I think the difficulty is often defining where they should stop. Mature players tend to get the idea of what they should be able to do and work with the other players, so it’s not so bad for most groups. It’s just that rotten apple that I always worry will try and abuse the system which is what I worry about.

  5. Nice, this is very useful. I have some questions specifically related to combat though and how to create a good combat system that is rules light and aids in story telling rather than simulation.
    More on this question at 1km1kt.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)