• The window for editing your posts has been extended from 48 hours to about two weeks or so. Please report any problems with this in Trouble Tickets.

[Nobilis] The Monarda Surround

Levi

Of The Canadian Levis.
Staff member
Moderator
RPGnet Member
Validated User
#1
For those of you not in the know on what the hell I'm on about, there's a game called Nobilis, in which the GM is instructed to "never say no" - in that game, this is called the 'Monarda Law'. There's a list of options, other things the GM can do, instead, like asking "how?", and requiring a good explanation.

With me so far? Okay, this law does not yet make sense to me. Because I don't know the context it operates in. Lemme give you a counter example:

In Dogs in the Vineyard, a GM is instructed to "say yes or roll the dice". However, the counter to this is that the whole group is expected to call for explanations or to simply call something out as 'weak' when it is. Thus, in that game, the GM doesn't have to focus on challenging junk actions any more than anyone else - instead, they need to focus on whether the good actions are worth making a conflict out of, or just letting them slide through.​

So, "Say yes or roll the dice" doesn't stand alone. It has backup, in the form of the group challenging junk.

What does the Monarda Law have that lets it make sense in the same way? How does the game "weed" itself?
 
Last edited:

The Yann Waters

Under Someone Else's Bed
#2
What does the Monarda Law have that lets it make sense in the same way?
It's a piece of GM advice against railroading, essentially, and not intended to bring about any great shift in the power dynamics within the group. Besides, I had been running games according to the same principle for more than a decade by the time I first heard about Nob. It simply makes sense to me.

(For comments by Borgstrom herself, see here.)
 
Last edited:

Levi

Of The Canadian Levis.
Staff member
Moderator
RPGnet Member
Validated User
#3
It's a piece of GM advice against railroading, essentially, and not intended to bring about any great shift in the power dynamics within the group. Besides, I had been running games according to the same principle for more than a decade by the time I first heard about Nob. It simply makes sense to me.

(For comments by Borgstrom herself, see here.)
Hmm. I get the reason for it - to encourage a free flow of 'stuff' from everyone.

But the thing is, to me, that when a group gets rolling, throwing ideas around wild and crazy-like, everyone will still occasionally toss out a total dud without realizing it.

It seems like in Nobilis, the first response of a GM playing along with the style would be to question the dud idea, hoping that the person that had it can redeem it or will discard it on their own. Is it?

If so, that seems a little more sensitive, and a lot more time consuming, than just dumping such ideas straight off.
 

Neel Krishnaswami

Registered User
Validated User
#4
What does the Monarda Law have that lets it make sense in the same way? How does the game "weed" itself?
People will tell you all about how Nobilis works.

I'll do something different, and tell you why "always say yes" is a good idea, even when there are no caveats and no limits. Now, you're saying that you want the right to block sometimes. That is, you want to say "Man, what?" when someone says something stupid or out-of-genre. That's a very reasonable desire, so why would I suggest not accomodating that?

That's because if no one can block, then your game is now fail-fast.

In engineering, a system is called fail-fast if it completely stops working as soon as something goes wrong, rather than trying to recover from errors. Fast failure is considered such an incredibly valuable property that engineers will often go to great lengths to ensure that their system falls over dead as soon as anything breaks. Why would someone do extra work to make their system less robust? The reason is that it's much easier to figure out what went wrong, because in a fail-fast system you always know that the very last thing that you used is broken. That makes it vastly easier to repair and redesign.

So, as a gamer, if you adopt the improv philosophy of always say yes, then you've done the same thing to your game. Now, when someone does something that will break the game, you let it break the game. Then, you start over from the beginning. This increases the visibility and cost of doing dumb things. Greater visibility makes it easier to learn what is dumb and what isn't, and rgreater cost creates a greater incentive to avoid doing dumb things. And who knows? Maybe what you thought was dumb doesn't actually mess things up -- and in that case, you're the one who has learned something.

You're going to be failing some of the time as long as you're trying new things, and always saying yes is a strategy for maximizing the value you get out of those failures.
 
Last edited:
#5
People will tell you all about how Nobilis works.

I'll do something different, and tell you why "always say yes" is a good idea, even when there are no caveats and no limits. Now, you're saying that you want the right to block sometimes. That is, you want to say "Man, what?" when someone says something stupid or out-of-genre. That's a very reasonable desire, so why would I suggest not accomodating that?

That's because if no one can block, then your game is now fail-fast.

In engineering, a system is called fail-fast if it completely stops working as soon as something goes wrong, rather than trying to recover from errors. Fast failure is considered such an incredibly valuable property, and engineers will often go to great lengths to ensure that their system falls over dead as soon as anything breaks. Why would someone do extra work to make their system less robust? The reason is that it's much easier to figure out what went wrong, because you always know that in a fail-fast system you know that the very last thing that you used is broken. That makes it vastly easier to repair and redesign.

So, as a gamer, if you adopt the improv philosophy of always say yes, then you've done the same thing to your game. Now, when someone does something that will break the game, you let it break the game. Then, you start over from the beginning. This increases the visibility and cost of doing dumb things. Greater visibility makes it easier to learn what is dumb and what isn't, and rgreater cost creates a greater incentive to avoid doing dumb things. And who knows? Maybe what you thought was dumb doesn't actually mess things up -- and in that case, you're the one who has learned something.

You're going to be failing some of the time as long as you're trying new things, and always saying yes is a strategy for maximizing the value you get out of those failures.
I am surprised: not only have I found a worthwhile post in a thread such as this, but I have had my conception of roleplaying best practices changed by a convincing argument.
 

The Yann Waters

Under Someone Else's Bed
#7
It seems like in Nobilis, the first response of a GM playing along with the style would be to question the dud idea, hoping that the person that had it can redeem it or will discard it on their own. Is it?
It's more that if the course of action seems to have unusual complications or consequences, the GM will often request more details on how the PC might go about doing whatever it is that the player wants done: "All right, how?" or "You could do that, sure, but then..." That's not determined by whether the idea in itself is a "dud", though, but rather by the capabilities of the character. In the spirit of the Monarda Law, the GM shouldn't block someone's attempts for no valid in-game reason: for me, "You can try!" is probably the most important aspect of the principle. As long as you roll with the natural results, the game cannot really be broken.
 
Last edited:

DannyK

His Dream Lives On
Validated User
#8
It's the Neel moment: he says something amazing, and everyone stumbles away from their keyboards to rethink everything.
 

Frank Sronce

Bad Intentions Paving
Validated User
#9
Of course, from an engineering standpoint, there are plenty of times when fail-fast is a very undesirable trait*, so I definitely wouldn't espouse that as an absolute rule.



*bridges, for example. ;)
 
#10
Of course, from an engineering standpoint, there are plenty of times when fail-fast is a very undesirable trait*, so I definitely wouldn't espouse that as an absolute rule.



*bridges, for example. ;)
Fail-fast is, however, an excellent attribute in model bridges, to make certain that the failures don't make it into the final product.
 
Top Bottom