Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Next
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
Twitch
YouTube
Facebook (EN Publishing)
Facebook (EN World)
Twitter
Instagram
TikTok
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
The
VOIDRUNNER'S CODEX
is coming! Explore new worlds, fight oppressive empires, fend off fearsome aliens, and wield deadly psionics with this comprehensive boxed set expansion for 5E and A5E!
Community
General Tabletop Discussion
*Dungeons & Dragons
Modos Rulebook: the real-time editing thread
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="GMMichael" data-source="post: 6236063" data-attributes="member: 6685730"><p><strong>Chapter 10: Modules</strong></p><p></p><p>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.</p><p><u></u></p><p><u>Rules Modules</u>[sblock]</p><p> 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.</p><p>[/sblock]<u></u></p><p><u>Designing the Rules Module Concept</u>[sblock]</p><p> 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.</p><p></p><p> 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).</p><p>[/sblock]</p><p><u>Designing Rules</u>[sblock]</p><p> 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. </p><p></p><p>Ask yourself:</p><p>- What is the purpose of this rule?</p><p>- Is this purpose already fulfilled by a different rule?</p><p>- Does this rule, after interacting with the rest of the system, fulfill its purpose as intended?</p><p>If a rule still seems necessary after asking these questions, you'll be writing it up shortly.</p><p></p><p> 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.</p><p></p><p> 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.</p><p></p><p> 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.</p><p></p><p> 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:</p><p>XF222 Removed. XF222.2, XF501.</p><p></p><p> 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.</p><p></p><p> Here are some considerations for new rules, based on the purpose of the rule:</p><p></p><p>- New abilities.</p><p>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.</p><p></p><p>- New skills.</p><p>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.</p><p></p><p></p><p>- New perks.</p><p>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.</p><p>[/sblock]<u></u></p><p><u>Implementing Other Roleplaying Systems</u>[sblock]</p><p> 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.</p><p></p><p> 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.</p><p></p><p> 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.</p><p></p><p> 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.</p><p></p><p> 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.</p><p>[/sblock]<u></u></p><p><u>Adventure Modules</u>[sblock]</p><p> 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:</p><p></p><p>1) Concept</p><p>2) Map</p><p>3) Encounters (optional)</p><p>4) Rewards (optional)</p><p>5) Rules (optional)</p><p></p><p>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).</p><p></p><p>1) Concept.</p><p>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.</p><p></p><p>2) Map.</p><p>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.</p><p></p><p>3) Encounters.</p><p>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.</p><p></p><p>4) Rewards.</p><p>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.</p><p></p><p>5) Rules.</p><p>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:</p><p></p><p>1) High-telepath reads the complainant's mind and immediately understands the best solution.</p><p>2) He is temporarily distracted, for the whole day, by an issue on another plane.</p><p>3) The problem is too complex for intelligence, so he goes to play golf.</p><p>4) He must watch chaos-theory in motion by sitting at the local pond, watching fish, for the next 24 hours.</p><p>[/sblock]<u></u></p><p><u>Sample Rules Module: Intermediate Modos</u></p></blockquote><p></p>
[QUOTE="GMMichael, post: 6236063, member: 6685730"] [b]Chapter 10: Modules[/b] 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. [U] Rules Modules[/U][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][U] Designing the Rules Module Concept[/U][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] [U]Designing Rules[/U][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][U] Implementing Other Roleplaying Systems[/U][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][U] Adventure Modules[/U][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][U] Sample Rules Module: Intermediate Modos[/U] [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*Dungeons & Dragons
Modos Rulebook: the real-time editing thread
Top