Reply to thread

Message

<blockquote data-quote="Wil" data-source="post: 2792592" data-attributes="member: 3502">From a design perspective, the inclusion of &quot;Rule 1&quot; in any roleplaying game is to let the GM and players, who may feel that they only have the rules in the book to work with, know that it is perfectly acceptable to introduce new rules or break existing ones.&nbsp; Whether these are rules to handle an ad-hoc situation that is not specifically covered by another rule or to replace a rule that is viewed as &quot;broken&quot;, it's not the province of the game designer to dictate. Thus, most applications of &quot;Rule 1&quot; will include that the rules be discarded if the players don't like them.&nbsp; It has to be broad like that, given it's somewhat contradictory intent of providing a rule to break the rules.Rules and mechanics are not synonymous.&nbsp; Rules are business logic, mechanics are code.&nbsp; The business logic dictates how the code is to be used, but does not change the code itself.&nbsp; You are entirely correct that the mechanics should at least not interfere with the goal of the&nbsp; game's design, and should facilitate it if necessary - and the rules should support the application of the mechanics.</blockquote>

[QUOTE="Wil, post: 2792592, member: 3502"] From a design perspective, the inclusion of "Rule 1" in any roleplaying game is to let the GM and players, who may feel that they only have the rules in the book to work with, know that it is perfectly acceptable to introduce new rules or break existing ones. Whether these are rules to handle an ad-hoc situation that is not specifically covered by another rule or to replace a rule that is viewed as "broken", it's not the province of the game designer to dictate. Thus, most applications of "Rule 1" will include that the rules be discarded if the players don't like them. It has to be broad like that, given it's somewhat contradictory intent of providing a rule to break the rules. Rules and mechanics are not synonymous. Rules are business logic, mechanics are code. The business logic dictates how the code is to be used, but does not change the code itself. You are entirely correct that the mechanics should at least not interfere with the goal of the game's design, and should facilitate it if necessary - and the rules should support the application of the mechanics. [/QUOTE]

Verification