Modos Rulebook: the real-time editing thread

[GMMichael]

Appendix A: Fast Play Rules

Too busy to read the whole rulebook? Here's what you'll need to know as a player, in steps.

1) Create characters (chapter 3).
Give your character a name and a quick explanation of why he's a hero (or will be a hero). He'll start as a professional, level 2.

2) Add ability scores (chapter 3).
Your character gets three ability scores, physical, mental, and metaphysical: 10 in each. If you'd rather roll, put 3d6 in each. Add two points to one score, or one point to two scores.

3) Add skills (chapter 4).
Pick two things that your character does well, and give him a point in each. Choose these from the list of common skills in the Skills chapter. There are three primary defensive skills: parry, concentration, and willpower.

4) Add perks (chapter 5).
Pick two things that make your character interesting, but aren't an ability or skill. Choose these from the list of common perks in the Perks chapter.

5) Get hero points (chapter 3).
Hero points allow you to do things better. You get two per day, and using them means you roll 1d6 before the thing you want to do better, and add it to the contest (roll) result.

6) Buy some gear (chapter 6).
Ask the GM for whatever gear your character would have. In general, his gear should allow him to do as much damage and protection as the other PCs can.

7) Get special abilities (chapter 7).
If there's still something cool that your character can do, that hasn't been covered yet, trade one of your skills for one of the spells in the Magic chapter. The new skill is called "cast spell (X)" where the X is the spell you've chosen.

8) Roleplay.
Tell your group what your character says and does, and remember that Modos RPG rules are vague enough to allow you lots of room to interpret different elements. Decide what each element means in terms of your character as you play the game.

9) Conflict (chapter 8)!
When the GM doubts a character's ability to do something, he'll ask for a contest. Roll d20, add the skill points you have in the closest skill to the task (zero if you don't have the skill), and add your ability modifier of the ability relevant to that skill. The result is your contest. If it's higher than the GM's opposing contest, you'll succeed.

10) Battle (chapter 8).
If you're getting into a conflict that will take more than one contest, roll initiative (d20 + your highest ability modifier) to see who goes first. When your turn comes, you can use up to three actions against your enemies. Attack (with a spell or one of the fight skills) if you like, but if you want to defend yourself, you'd better save some of your actions for it.

11) Damage enemies (chapter 8).
If you've succeeded on a fight contest, or if your opponent was too busy to parry you, you'll deal damage. Roll the damage die of your weapon. Your opponent will roll his protection die to reduce your damage, but you'll always do at least one damage if your opponent fails to defend.

12) Take damage (chapter 8).
If you fail a defense contest, reduce the damage with your armor's protection die. Add the remainder to your damage pool that corresponds to the type of damage dealt. If the damage in that pool exceeds your ability score, the GM will give you a time-out.

13) Cast spells (chapter 7).
If you took a spell in step 7, you can cast that spell. During your turn, spend the actions listed in the spell's "actions" entry. Roll a cast spell contest for each action, keep the highest, and apply the "difficulty" amount to your result. If your result is below 10, the spell fails. If your result is over 10, roll 1d8 and add the spell level. This is the metaphysical damage you take in exchange for making the spell manifest. Then your spell happens.

14) Defend against spells (chapter 8).
If someone casts a spell at you, the GM will tell you which defense to use. If you have an action tied to the corresponding ability, you can use it to defend against the caster's cast spell contest. If you succeed against a damaging spell, you avoid one action's worth of damage. If you succeed against a non-damaging spell, you don't suffer the spell's effect; you suffer the half-effect. If the caster maintains his spell, you can end the half-effect with a total number of successful defenses equal to the spell's level.

What about taking half, combat postures, maintaining spells, difficulty, ranged weapons, level-ups, and all that other cool stuff? Read the whole rulebook!

 

[GMMichael]

Chapter 10: Modules

Community-designed content, new, sturdy rules for next week's game, and plug-and-play adventures are all made possible with Modos RPG's modular system. Although the only limits are your imagination, there are two main types of module: rules and adventure.

Rules Modules[sblock]
Modos RPG is a core rules system. It's designed to be short and simple for a reason: so it can adopt and adapt to any new rules you want to use. A set of these rules is called a rules module, and they follow some pretty simple rules of their own. These revolve around designing the module concept, designing the rules, and incorporating other RPG rules. A sample rules module is included at the end of the chapter.
[/sblock]
Designing the Rules Module Concept[sblock]
Congratulations, you're about to become an RPG designer! It's a glitzy, glamorous world, but there's some hard work to do. The first thing to do, as with most things in Modos RPG, is to create a concept.

The rules module concept is a guide for you and an introduction for users of the module. It should explain the theme and intent of the rules that you're adding to the game. It doesn't have to be lengthy as long as the reader knows, after reading your concept, why he would want to use your module. When your concept is ready, be sure to give it a flashy, marketing-friendly name (you'll abbreviate this when you code your rules).
[/sblock]
Designing Rules[sblock]
The rules in a rules module do three things: they add new rules, alter existing rules, or remove rules. Despite having different purposes, these three functions always have the same considerations.

Ask yourself:
- What is the purpose of this rule?
- Is this purpose already fulfilled by a different rule?
- Does this rule, after interacting with the rest of the system, fulfill its purpose as intended?
If a rule still seems necessary after asking these questions, you'll be writing it up shortly.

Before writing, look at how your rule will interact with existing rules. The easy way to do this is to look at the rule dependencies in the rules catalog. Each core rule is followed by rule dependencies, or the rules that are required to make that rule work. When writing a new rule, look up any rules that might interact with your rule and also check each dependent rule, because even though the first rule you look up might not be affected by your new rule, there might be an interaction with its dependent rules. For example, you want to create a rule that allows characters wearing no armor to receive specific organ damage. Looking through the rules catalog, you decide that armor, damage, and parrying rules might interact with your new rule. So you look up each of those rules in the catalog and read them over to decide if you should take them into consideration, and list them in your new rule's dependencies. Further, you see that physical, conflict, and skill rules are included in the dependencies of the first rules you looked up, so you check those as well to consider how your rule will affect those.

If your rule has no interactions with other rules, consider it a new or additional rule, and give it a catalog number that follows the rest of the numbers in a section, or tack it on after the most relevant rule to it. For example, your rule is most likely a new core rule, and the last core rule is coded R142. Your rule will begin with your module's prefix (pick an original one, based on your module name) and follow the last rule, so you'll code it XF143 (Xtreme Fantasy). Or if your new rule is an extension of the last core rule, you'll code it XF142.1.

If your rule's effect is to alter an existing rule, you'll need to make a full list of its dependencies. To do this, find the code of the rule you're altering. This is the part that starts with R (meaning core Rule), followed by a number. Put this rule in your list, and then search for each rule listing this code in its dependencies (the code list that follows each rule). Note that dependent rules can be found in different rules catagories. For example, you're altering R110.2, and a dependent rule is found in the 400s, coded R402 (which lists R110.2 in its dependencies). Not all dependencies will need alteration, but you should check to maintain rules stability. Once you've altered every rule that will be affected by your new rule, list each one in your rules module under your new prefix, but with the previous code number. So from the above example, your module will include rule XF110.2, and the dependent rule, XF402.

If your rule's effect is to remove an existing rule, you'll follow the same rules-listing procedure as when you alter rules. In this case, you'll read each dependent rule and decide if it should also be removed, or simply altered. Altering the dependent rules will promote rules stability, but you should look at the overall effect of altering or removing rules to see what best meets the purpose of your new rule. Renaming the affected rules follows the same procedure as altering rules, but a removed rule should state that the rule was removed, and give a list of any remaining (non-removed) dependent rules. For example, if you remove R222, but alter or keep its dependent rules R222.2 and R501, and remove the dependent rule R502, then your new rule will look like this:
XF222 Removed. XF222.2, XF501.

Writing new rules isn't always a clean process. If your new rule is at odds with other rules that can't simply be removed, put some conditions in your new rule. These will state when the game should follow the new rule, and when it should follow the old rule.

Here are some considerations for new rules, based on the purpose of the rule:

- New abilities.
Abilities are fundamental to Modos RPG. A new ability is easy to add, provided that only new rules depend on it. For example, you want to add a Comeliness ability. If the only purpose of this is to determine how attractive a character is, then adding the rule is easy. But if it will interact with existing skills or a new skill, you'll have to alter those skills, and possibly further rules dependencies. Expect the alteration of an ability to have far-reaching effects as well. For example, if you want to divide the physical ability into speed and strength, you'll have to alter all the skills that depend on physical, the longstrider perk might be affected, and you'll be affecting the dynamics of level-ups, since gaining one ability point per level just got watered down a bit.

- New skills.
Adding new skills is a fairly straight-forward process. It's important to determine whether your new skill isn't covered by the existing skills, or is actually a sub-skill (or specialization) of an existing skill. If the skill isn't covered, add it to the list, include its relevant ability, opposing skills (if any), and consider what combat or conflict uses it might have. If your new skill is actually a specialization of an existing skill (like fight-bow would be a specialization of fight-missile), you'll need a reason for characters to want to spend skill points in the specialized skill instead of the general one. One reason is that you're dividing the general rule so there will be no general rule, only specializations. In this case, you'll want to revisit the level-up rules and consider awarding more skill points at each level.


- New perks.
These are the jelly beans of Modos RPG. They can come in any flavor, but they all must be the same size. The key to adding new perks is to ensure that their rule interactions are limited. A perk like armor training is very limited in scope: it makes one suit of armor better, and doesn't change any other rules. But a perk like small size is trickier: it has a major effect on how a character gets along in combat. To put a cap on a perk like small size, the key is balance: it has penalties that weigh down its benefits. Write a perk like this as well as possible on paper, but be sure to refine it through playtesting and after-session reviews.
[/sblock]
Implementing Other Roleplaying Systems[sblock]
There are lots of roleplaying games out there, which means there are lots of great roleplaying rules out there. Modos RPG is other-RPG-friendly. There are four types of features that you might want to include in your game of Modos RPG: setting features, equipment, powers, and meta-game rules.

Setting features are the easiest features to implement. If you want your Modos RPG to resemble a vampire RPG, all you need to do is include lots of vampires in the story! Or if you want to play a "modern" game instead of fantasy, all the GM has to do is call his "dungeon" a "warehouse." Or change the name of fight-missile to "ballistics training." Speaking of ballistics, you might want to include some firearms.

Equipment, including personal gear and vehicles, is another good candidate for importing. Modos RPG doesn't have an equipment (non-weapons and armor) list, because anything is fair game. When it comes to the name, price, and general function of equipment, a GM can just drop it into Modos RPG, no questions asked. Equipment can become a little complicated when importing weapons and armor, but a good rule of thumb is to classify the item by the weapon or armor type: tiny, light, medium, or heavy. Other equipment can grant a few bonus points to skills, but if the equipment does more than this, it should be considered special equipment (see Equipment chapter) and its impact on character level should be considered.

Powers are a popular and diverse feature of many RPGs. These are the alien mind control, vampire seduction, and superhero eye-blasts that make specialized games so much fun. Now you can write your own. But before including new rules for powers in your rules module, consider that the existing rules may already support the new powers. For example, the fire spell has short range, defeats partial cover, and is defended by parry (physical defense). You could rebrand this spell as a mental blast, bio-powered blood laser, or optical heat-ray, and there would be no rules writing necessary. If the existing mechanics for weapons, armor, equipment, perks, or spells do not already support the powers you'd like to import, you'll need to design new rules.

The most complicated, and possibly most rewarding, feature of other RPGs to import into Modos RPG are the game mechanics, or meta-game rules. These will almost always require alteration of existing rules. An example of a simple rule to import is the exploding die. Whenever a PC rolls well, or gets the highest result on a die roll, he keeps that result and adds an additional die roll to the total. One effect of this is to make good rolls into great rolls. The effect on the game seems obvious and easy, but it should still be discussed in the after-session review. A more complicated rule to include would be magic spell preparation. You might want magic spells to be unaffected by MP health, and require spellcasters to prepare them all at one time, instead of during casting. Your best option is to compromise: can this feature be roleplayed instead of modified? But if you want it in black and white, that's why there is a rules-design section.
[/sblock]
Adventure Modules[sblock]
The other type of Modos RPG module can include new rules, but instead of focusing on presenting rules, it focuses on using the rules. This adventure module is a self-contained adventure, complete with maps, characters, new rules, and treasure. Creating an adventure module can be done however you like, but each module should have the following features:

1) Concept
2) Map
3) Encounters (optional)
4) Rewards (optional)
5) Rules (optional)

These elements combine to present players and GMs with an unlimited supply of adventures, powered by every Modos community supporter (who doesn't mind doing a little typing).

1) Concept.
Besides a name, every adventure module needs a statement of what it is and why it's interesting. The adventure concept is essential for turning the other required adventure module component, a map, into something worth playing.

2) Map.
Adventures must happen somewhere. With a limitless game at your disposal, an adventure map could be a 20 miles square hex grid, a 400 feet square dungeon, a flowchart of story events, or a series of improv scenes. Whichever form the adventure takes, the map is the skeleton, or more specifically, the backbone of the module.

3) Encounters.
Players want something interesting to happen in an adventure. You could skip encounters and just put a monster or two in each room on your map, but more interesting is the encounter. This is a decision-making or roleplaying opportunity that gets the players' interest. An encounter could be running into a desperate polar bear, negotiating with the earl to keep a PC from marrying his daughter, or examining a crime scene for clues. Since space is generally limited in modules, you should include as many details as are necessary to run the encounters, but include only encounters that provide the best decision-making and roleplaying opportunities.

4) Rewards.
This is the most time-tested feature of adventures. Players like to get stuff. This stuff can be material, like money, jewelry, or gear. It can be social, like titles, honors, or status. It can be meta-game, like more ability points, skill points, or perks. Whatever the reward, it's a good idea to include plenty of it in an adventure module.

5) Rules.
Adventure module rules come in two varieties: rules affecting the game system, and rules that make up sub-systems. Rules affecting the game system, the same ones found in rules modules, can add flavor to an adventure module. It can be more memorable if PCs adopt, if only for one adventure, a slightly different way of playing the game. Then there are sub-systems, which are most commonly used to navigate between encounters, and even to run the encounters themselves. Sub-systems stand alone, and don't require the close attention that rules mods do. An example of a sub-system is the high-telepath's decision process. Roll 1d4 to determine how he solves problems on any given day:

1) High-telepath reads the complainant's mind and immediately understands the best solution.
2) He is temporarily distracted, for the whole day, by an issue on another plane.
3) The problem is too complex for intelligence, so he goes to play golf.
4) He must watch chaos-theory in motion by sitting at the local pond, watching fish, for the next 24 hours.
[/sblock]
Sample Rules Module: Intermediate Modos

 

[GMMichael]

Appendix D: Rules Catalog

This is the catalog of core rules in Modos RPG. Each rule begins with a code (in this case, R for core Rules), followed by that rule's number. The numbers are classified by rule-type:


R000 Roleplaying
R100 Core Mechanics
R200 Skills
R300 Perks
R400 Physical (rules for the physical world)
R500 Mental (rules for the mind)
R600 Metaphysical (rules for the magical realm)
R700 Modules

Modos Rules Catalog[sblock]
R000 The GM is always right.
R000 (campaign theme)
R000 (roleplaying awards)
R000 (segmenting)
R100 (contests)
R100 (contest modifiers for skill, ability, difficulty)
R100 (abilities)
R100 (damage)
R100 (max damage)
R100 (protection)
R100 (hero points)
R100 (rolls)
R100 (levels)
R100 (modifiers)
R100 (difficulty)
R100 (actions)
R100 (actions tied to abilities)
R100 (ability bonus actions)
R100 (initiative)
R100 (rounds)
R100 (turns)
R100 (combined actions)
R100 (reserve actions)
R100 (delay action)
R200 (skills)
R200 (skill points)
R200 (max skill points/ level cap)
R200 (specific knowledge)
R200 (common skills)
R300 (perks)
R300 (perk substitutions)
R300 (perk trees)
R300 (common perks)
R400 (physical)
R400 (mostly dead)
R400 (range)
R400 (reloading)
R400 (posture)

R500 (mental)
R500 (unconscious)
R500 (awareness)
R600 (metaphysical)
R600 (catatonic)
R700 (modules)

[/sblock]

 

[GMMichael]

Phase 1, complete

There's a playable adventure module in the core rulebook. I've made multiple small changes, so if you're looking over this thread for Modos RPG rules, please consider them generalizations. The official details are all in the attached rulebook file.

The sample rules module has changed. It is now called the Gauntlet, and will be a short ruleset designed to make Modos RPG feel and play like the 1980s arcade game. However, since rules modules consist of precise and categorical changes to the core rules, all I can write for the Gauntlet is its concept. The rest will have to wait until I have the (core) rules catalog complete.

Anyone want to join play-by-chat? Or...write up some spells or monsters to be featured in the core rules?

 

[GMMichael]

The rules catalog is written through section 000: roleplaying, section 100: core rules (mechanics?), section 200: skills, and section 300: perks.

Made a significant change to action economy: the only perk you can take to immediately get extra actions is Spell Maintenance, and that extra action just lets you maintain spells (give them greater than 1 round duration). All other bonus actions are tied directly to ability scores; every 5 points gets you another action. The perks just allow you to use a different skill with that bonus action.

The Parry skill has emerged as the biggest loser - or most interesting tactical choice, depending on how you look at it. Parry is still critical for reducing physical spell effects, but otherwise it's most likely to be used if you're on death's door (and can't run away), or if you're holding the front line for your ranged-attack allies.

If you haven't wanted to look at the rules because, well, they're going on 60 pages now: the rules catalog (appendix D) is the short-hand version that lets you get to the nuts and bolts of the system. And the even shorter version are the fast-play rules (appendix A), if you're really pressed for time. I promise, everything will be neatly covered in the table of contents and index when I put the polish on version 1.1.

 

[GMMichael]

Rules catalog and index are in place. Table of contents is rollin'. If you want to find something in this document, it should now be really easy. If you want to modify something, it should be really easy.

A few more "finishing" touches, and the rough draft, version 1.1, will come crying into the world.

 

[Neonchameleon]

You asked me to take a look I'm seeing a game with a lot of passion and thought put into it, and some good ideas. I'm also seeing a game that seems deeply embedded within the d20 family of games and that looks as if you've not played anything outside the d20 family - in short I'm seeing a d20 Fantasy Heartbreaker. Which, to be honest, isn't that bad a place to start with game design. I'm also reading something close to an attempt to reinvent Fate Core - which isn't a bad place to be going. Fate Core is quite simply the best simple and modular system I know - but it already exists and is on a much simpler chassis than the d20 one you're using as well as having had ten years of development and refinement. I'd therefore read Fate Core to see what you can borrow - and also for a game that does things a very different way while still being familiar to D&D players I'd read Dungeon World and see what you can get out of there.

It's also worth noting that Fate Core is, as far as I know, only the second generic game to make a dent in the RPG market (with the first being GURPS - and a case being possible for d20 Modern) - and Fate Core came out after Spirit of the Century, Dresden Files, Icons, Strands of Fate, and people hacking all of the above to do anything and everything. People normally buy games that will inspire them, and tend to be more inspired by settings and mechanics than games that are purposely setting-less.

I hope that that didn't all sound too negative.

 

[GMMichael]

D20 has a handful of problems. So while I have taken some inspiration from D20, I did not end up writing an OGL game, and I'll appreciate it (snark) if you refer to my heartbreaker as an Agnostic Heartbreaker.

Fate Core looks great, and I think I have a few inspirations from that system in Modos RPG as well. However, I wasn't about to try and use unique dice (d3s, basically?) for my system, nor a deck of cards (which has great flavor potential), and I'm sure that I have a few other issues with Fate that I'm not remembering currently.

Fate and GURPS can sell all the games they want - part of my motivation to write an RPG was to empower gamers more, provide (another) free option, and give them an alternative to buying the next 10 books that D&D is about to spit out.

Point taken about the inspiration though - and I think I was already planning on it. Modos RPG is the ground-level. The free core. I'll be sure to slap a nice, shiny coat of High Fantasy on the body of future Modos editions, along with a shimmering Beyond Thunderdome option, and probably a glossy wax of Super Covert Agent to garner interest.

Thanks for checkin' it out!