Outside the Box MU* Design/Theory

[Pyrephox]

@Thenomain said:

@Groth said:

One way would be to take the popular RPG and liberally rewrite all the mechanics to better work on MUSH.

Thereby alienating everyone who knows that popular RPG.

Mind you, this is out-of-the-box thinking, so I shouldn't naysay it out of the box.

It seems to work reasonably well for Mind's Eye, and probably a lot better than trying to LARP with a whole bunch of dice in your pocket. I suspect it'd be a good idea to take a look at LARP (not just WoD) mechanics and systems when looking at MU*s, since they have the exact same design problem, although a different set of conditions to accommodate.

[Lithium]

@Pyrephox

Larp rules are horrid.

They're even worse than pure consent imho.

Way to easy to cheat at rock paper scissors.

[Pyrephox]

@Lithium said:

@Pyrephox

Larp rules are horrid.

They're even worse than pure consent imho.

Way to easy to cheat at rock paper scissors.

Which proves that it's hard, I guess. But at least they are trying to match the system to the environment, so the process might still have value, even if we have different resources (such as code) to help promote a more robust outcome.

[Lithium]

@Pyrephox

Fair enough.

.

[Thenomain]

There are other LARP systems out there. The Cthulhu LARP rules seem popular. I've made some, myself.

@Ide, I quasi-summon thee to opine about Larp systems for Mush?

[Lithium]

@Thenomain

Oh? The only LARP systems I've ever heard of were those based around D&D and WoD, didn't know Cthulhu LARP was a thing.

Learn something new every day.

[Bobotron]

@Lithium
And this is why you code the randomizer at the most basic level. It's what I've done for TheatreMUSH.

Or in the case of NWoD, use the NMET rules, which are 'make a tabletop pool, roll 1d10, add that, get total, at <X> base is a success and eevery <X> increment after <X> is an additional success.' But I've talked about this ad nauseum before regarding hyper-competency 'I get eleventy-billion successes on a 2 and only fail on a 1', something I've run into bunches in NMET.

[Lithium]

@Bobotron

That's actually pretty elegant. One of the systems I was tossing around was very simple:

Add your attribute + skill + equipment + 1d# (I was uncertain on using 6's, 8's, or 10's) in opposing rolls. Highest wins, with differential applied to damage/success.

[Bobotron]

@Lithium
Yeah. NMET defaults to a base 10 is 1 success, and every 5 thereafter is a success. However, I have never been in a LARP that used the default scale. One I ran used 8/4, which worked out nicely; and the Mind's Eye Society uses 8/3, which just increases the hypercompetency. But overall it's quick and elegant (though I admit, I'm also playing in a Requiem LARP using the actual tabletop dice roll rules, with STs using a phone die roller, and it has worked out pretty well as long as people know their fucking pools).

[Groth]

@Pyrephox said:

It seems to work reasonably well for Mind's Eye, and probably a lot better than trying to LARP with a whole bunch of dice in your pocket. I suspect it'd be a good idea to take a look at LARP (not just WoD) mechanics and systems when looking at MU*s, since they have the exact same design problem, although a different set of conditions to accommodate.

When designing RfK, Shavalyoth looked heavily on LARP mechanics and how they could be implemented on MU*. On MU* there are a few aspects that most LARPs don't have to account for that need to be kept in mind.

1. MU* is heavily asynchronous. Each time you log into the game tons of things might have happened while you were asleep, it's extremely difficult to stay up to date with recent events.
2. MU* are constantly running. LARP rules tend to assume a more seasonal/session based format.
3. In MU* there's no problem actually roling dice or using other coded systems.

[Bobotron]

@Groth
It can, though. In a lot of the interconnected LARP orgs, stuff can happen like it might on a MU*, though not all of it might be linked to one city. However, I agree; there are a lot of things that MU* need to account for that LARP won't by default (it's been one of my challenges using MET:VtM, particularly in how feeding and blood mechanics work in it).

I think picking and choosing the best options from all, or making logical extrapolations works out well, though many probably need fine-tuning once seen in use (for example, if you have a Feeding Downtime, you come into game at full Blood; my logical extrapolation of this is 'if you have a Feeding Downtime, you spend time here and there getting a nip, and you get <X> blood to draw from for a particular period'.)

[BobGoblin]

This is a thought I have for the community at large:

How much 'code' is too much code? Is there a point where using code to do 'things' (Economy, Space, etc etc etc) becomes too much? I know this is a long standing debate in my circles, that too much code causes people to 'game' rather than roleplay but on the flipside it also can put the burden of activity on the players moreso than the GMs. Thoughts?

[Coin]

@BobGoblin said:

This is a thought I have for the community at large:

How much 'code' is too much code? Is there a point where using code to do 'things' (Economy, Space, etc etc etc) becomes too much? I know this is a long standing debate in my circles, that too much code causes people to 'game' rather than roleplay but on the flipside it also can put the burden of activity on the players moreso than the GMs. Thoughts?

i think that this, like the vast majority of design considerations, depends almost entirely on two things: 1) the kind of game you want to run and stories you want to tell; 2) the kind of players you want to attract and keep.

I can be very malleable when it comes to this sort of thing as a player, but as a storyteller and game runner, I prefer narrative-focused games that don't pay too much attention to the minutiae (economics, resource management, etc). This is either largely because I don't have patience or because it doesn't interest me when I'm the one in charge.

I can see the appeal as a player (even though I haven't played in games like that in a while) and would probably enjoy them a great deal once I got into them. But it's about what your players and you want for the game.

As a community we're almost always discussing what's better and the claim of it "depending on the context and what the players and staff want from the game" is often dismissed as a platitude without no argumentative merit. I think this is a huge mistake. I think we should be encouraging different types of games, with different goals and different player demographics, to exist simultaneously, so that the community at large can have access to a gamut of gaming experiences and everyone has something they can play and enjoy.

[BobGoblin]

@Coin

I agree completely with the concept of the gambit of games. Things (imo) have become very stagnant; but there's also the diminishing returns of spreading things out (a discussion for another time). The spur of this thought line is that I see on games quite often players 'waiting' for things to happen. So what kinds of tools could we as game designers employ to encourage players to go and 'do' things. Story Hook design? Automated monsters to fight? Cargos to ship? Again; within the realm of what type of game you want but I'm looking for a 'list' of ideas so that as we get into the design phases we have a toolbox to pick and choose from.

[TNP]

There used to be a few games based on McCaffrey's Crystal SInger books. The two games I know of (and played on one) were very code heavy. The Singers would take their cutter, get into their sled, and go out into the mountain ranges to find and cut crystal. Finding a claim could take a while. Cutting the crystal could take a while. Just as in the books, the amount and color of crystal was kept track of and compared to other Singers.

Really, it took a lot of time for those inclined to play the game within the game and took it away from RP which was supposedly the point of a Mu.

[BobGoblin]

@TNP

Was the 'mini game' a required part of the game? Did it become the focus of the game? Was it set up in a way to encourage RP while undertaking the crystal gathering or was it just a sort of 'grindy' activity that was there?

[Ide]

@BobGoblin said:

The spur of this thought line is that I see on games quite often players 'waiting' for things to happen. So what kinds of tools could we as game designers employ to encourage players to go and 'do' things. Story Hook design? Automated monsters to fight? Cargos to ship?

Improv classes.

Giving your players code is like putting your kids in front of the TV. It's not 'bad'. It's fine. But it can be better.

[ThatGuyThere]

@BobGoblin said:

How much 'code' is too much code?

When it interferes with rp rather then facilitates rp is my answer, granted i know that is horribly imprecise and will differ for each game but that is also the truest answer I can think of.

[Misadventure]

In my mind, mini games may be great at suggesting theme, but they should have a limited resource used to track efforts, and be used during off screen time unless something sparks an idea for a scene.

[Thenomain]

@Ide said:

Improv classes.

As a Mu* coder, I have to say: Dear god yes more co-op improv fewer mini games please! When you have someone coding full time for a game, or several people, mini-games are okay, but this is nearly impossible anymore.

I do think mini-games are fun distractions and immersions. Language code, for instance. Weather systems. Hunt code. The systems we in WoD-land are subsumed in lately are bureaucracy. This does facilitate RP by freeing staff up from creating more bureaucracy.