Game Design as Applies to MU and STing

[EmmahSue]

I'm reading The Aesthetic of Play, by Brian Upton. I like it quite a bit so far (I'm only at chapter 4, so there's far more to go). It has prompted thoughts (dun-dun-duuuun) about how to apply some of these concepts to a MU* to improve the experience.

At one point, he lists the following characteristics as parts of a fun-game (note, this is not the be-all end-all, just what's easily enlisted for current discussion):

Definitions: Horizons of Action (the possible actions arrayed before the player) and Horizons of Intent (what the Player believes is possible / appropriate based on previous experience, and understanding of ruleset).

• Choice: Horizons offer a range of possible actions.
• Variety: Horizons aren't repeated.
• Consequence: Actions have outcomes.
• Predictability: Outcomes can be anticipated.
• Uncertainty: Outcomes aren't predetermined.
• Satisfaction: Desireable outcomes are attainable.

Choice: Too little choice makes a game boring. Too much choice makes a game confusing. With too much, a Player will often perform a personal narrowing of options, based on internal criteria, in order to lessen the confusion. On MU: "What my character would do," narrows a too-wide sandbox.

Variety: Doing the same thing over and over again is boring. It can be done if the Player feels the goal/result is worth the repetitiveness, but is rarely fun in its own right. It's possible to use set-pieces in different ways to solve the cost:benefit analysis. On MU: Sabbat Always Attack Head-On is boring. Using the Sabbat as a regular foe when they take different actions, not so boring.

Consequences: Turning the wheel of a car should turn the car. If it doesn't, what's the point? It's no longer a game at that point, it's a movie. On MU: EOTW failed in part because there were no real or lasting consequences for the actions taken.

Predictability: If you turn the wheel of a car to the right, and the car goes in some random direction, what's the point? We can't play if there's no sense of cause-effect. On MU: The ruleset helps with this in micro. In macro, there should be internal story logic driving what happens when a Player takes action. They don't have to know exactly what that logic is, but they have to trust it exists and can be puzzled out.

Uncertainty: A Player needs an external element (whether dice, or other players) to provide some wiggle room. If she knows exactly what's going to happen, again: not a game. On MU: Fellow Players help provide some of this. A ST adjudicating helps provide it too. Random dice results when it's appropriate. In having so many players, we accomplish this much.

Satisfaction: If it's impossible to achieve, what's the point of trying? Being hard to achieve is fine! Impossible is not. On MU: This is easy enough to apply to a story. Where it gets harder is application to the concept of RP. Our goal is to play, right? It's shouldn't ever be impossible to play, even when our specific character has an impossible goal in-game. Yet somehow, satisfaction is still a problem.

Questions to the community at large (as composed of people who know and care that this forum exists) in no particular order other than as they occur, and numbered for ease of discussion:

1. How do we emphasize the characteristics above in order to keep our games fun and entertaining?
2. What is our goal, really? Are we here to play? Are we here to tell a story? Are we here to explore a gritty urban-fantasy-scifi world? All of the above?
3. Are there any other characteristics worth adding to the list? Or any of the above that really don't apply to MU after all?

ES

[2mspris]

1. About the only way that I can think to answer that would be to say that these are key points and "check" the things done from a staff end against those characteristics as guidepoints if those are the ideal.

2. To me, mushing should be a combined goal of all of those things. Even when I am playing, I still want to be entertaining for the people that I am playing with and to help them tell their story. But I tend to want to explore a thorough development of my character from one thing into another thing. I normally have a starting point and "ideal end point" in mind that stems from goals. But if I'm staffing then I want to make sure the opportunities for the same are available for players to take advantage of.

3. I may be reading this list and the discussion intentions wrong, but to me this list is missing: Intention. You made this character, presumably with goals and personality - towards what end? What story are you wanting to pursue, as a player do you expect your character's development to be entirely changed by what an ST puts in front of you or do you have intentions for character development as well?

[Arkandel]

How do we emphasize the characteristics above in order to keep our games fun and entertaining?

Most games I've seen ultimately suffer from creativity suffocation. It's often well-meaning but no less stifling - either staff enforce theme and a game style they see as appropriate and flagship characters attain positions of influence over IC affairs and hog the spotlight. At the same time stories being told by non-staff are often self-contained (essentially ran in a sandbox) so they don't stir the game's direction in any new direction, thus refreshing it.

A game has to remain dynamic and its direction fluid. Some ideas in random order:

• Review PrPs ran on a regular (say, monthly) basis. Allow them to affect the game's direction by integrating them along with staff-ran plot.
• Don't let any small group of PCs to hog the spotlight. Charismatic players will still shine without ranks or basing stories told around the same people all the time. Do not open the big ranks to PCs.
• Recruit and incentivize Storytellers as much as humanly possible, and do everything to get out of their way by eliminating red tape and thinking hard before saying 'no'.
• Allow ways for newcomers to catch up in power to your dinos. Some games are very static since a new character could take a year and still be unable to catch up to oldbies.
• Make the OOC impact of death count for less by allowing XP migration toward new alts. A PC's demise should be incentive to refresh, not an event with game-ending potential for the player.
• Let the game be played, staff must not intervene unless there is absolutely no other way even if players request it. The outcome of IC actions should be determined by characters played on the grid.

What is our goal, really? Are we here to play? Are we here to tell a story? Are we here to explore a gritty urban-fantasy-scifi world? All of the above?

What it comes down to is that different people have fun in different ways. Some want violence and gritty themes, others want to meet at bars and chat, others want erotica, others want more politics etc. Overall direction should be stated and be felt through the game, from its wiki to its history down to its plots, but there's a balance between giving players room to breathe by doing their thing and letting players without any direction until they rely on having a pocket Storyteller or be reduced to doing nothing, because nothing happens spontaneously.

Sometimes a game is perfectly fine, well-coded and ran by good people but it falls flat because it's too open-ended and lacks internal coherence. So whatever the goal, there should be an overall theme if not metaplot, and the environment itself should somehow confront the characters' choices by applying pressure on their outcome. By no means should things be safe or quiet; that's how boredom is generated.

Are there any other characteristics worth adding to the list? Or any of the above that really don't apply to MU after all?

The sense of community, perhaps. The players I see most often being lost in the shuffle are those who feel disengaged from the MU* because they have no ties to it. They may be in a faction in name but how does that translate to RP? They are offered a bboard to search for a pack but what happens if there's no one forming one?

Building communities should be considered an integral part of running a game. Yes, of course players should be responsible for themselves, use the resources at their disposal etc... but they don't. Sometimes - often - they sit in a room and wait for something to happen, and if nothing does they stop even sitting in that room. That is a loss. Plenty of players are good at posing, less great at taking the initiative, generating RP, starting a coterie/pack or too shy to even make a post and I've seen in sphere 4-5 people all complaining at the same time they're unable to find anyone to group with.

A systematized effort to play at match-making can make a ton of difference. Scale it down to the faction level so that it's not all depending on a huge bottleneck by staff (who have enough things to do); prominent characters in a Covenant can be IC handed the obligation to whip their lone wolfs into cohesive unit, for example. Give tangible benefits on top of that (say, a free locus for every pack of 3+ PCs) and try to make sure to either run or offer incentives for PrPs to be run that bring such groups together.

That's all, from the top of my head.

[EmmahSue]

From continued reading at lunch comes this concept:

Winning is better than losing. But an anticipated loss (that is, one you saw coming because you understood the patterns) is better than loss-by-accident. And sometimes an anticipated loss is better than winning-by-fluke.

There's meta-success to be found in seeing the blow coming, so to speak. Even if you lost on the active-level, your ability to forecast on an anticipation-level is still a win. I'd very much like a way to encourage that concept within MU and our community: Loss-for-your-PC isn't terrible if you understand why and saw it coming as-a-Player.

Inre: my own plans, does this mean that when I'm running a Seeking, I ought to discuss the end-goal with the Player ahead of time? "As your ST, this is what I feel your Avatar would want you to aim towards." At that point, they can aim for it or not as they feel their character fits. Does the removal of the 'mystery' lessen the fun? Or is that something I ought to ask each Player individually, to find out if they want to know-or-not?

ES

[Arkandel]

It's important to expose some metadata to the player regarding what they're getting into. Factors such as "type of story", so you know your PC is a worthwhile contributor (not everyone likes playing the sidekick while others save the day) and that he/she has some chance of succeeding (I might not want my newbie hacker nerd walking into the abyssal temple of doom where he'll get one-shot) and maybe even who I'd be playing with (people have baggage, much to the shock of no one at all).

Revealing details about the story itself is a very iffy proposition at first. Mystery is important in the early stages so you can set up the pieces with at least some degree of allowing yourself the use of any traditional storytelling tools - bait and switch, for example. If enough cards are on the table it limits our ability to pull a well-meaning fast one. Later on when your board is set you can reveal your hand (which offers another set of opportunities for tricks).

There are however two notable challenges that often come up in MU at least for me:

• Custom-made plots to satisfy a systemic requirement. "You need a plot to get a Legacy". In this scenario the player requesting it quite likely expects success (so they can get their carrot), so you have to challenge them in a way that doesn't truly jeopardize the outcome.

• Plots which explore part of a character's background (not necessarily in flashbacks) using NPCs of their own making. Without excellent communication and trust it's easy to disappoint some players by having those NPCs behave or speak differently than what they had in mind, or have the plot go in a different direction than they had envisioned. The difficulty here comes from the fact the player 'owns' the story but someone else runs it.

[Ganymede]

@EmmahSue said:

1. How do we emphasize the characteristics above in order to keep our games fun and entertaining?

Communicate effectively.

2. What is our goal, really? Are we here to play? Are we here to tell a story? Are we here to explore a gritty urban-fantasy-scifi world? All of the above?

It depends on who you ask, but they should communicate effectively.

3. Are there any other characteristics worth adding to the list? Or any of the above that really don't apply to MU after all?

Many people who play MUs do not communicate effectively, and should not put themselves in a situation where they must, like, say, being staff.

[Rook]

@Ganymede

[Arkandel]

Also by all means, for all that is holy... it's much better to leave a staff position unfilled than to fill it with someone who's just okay, or whom you don't know very well. Keeping staff lean and efficient is so important in order to have a decent culture to do whatever it is you need to do.

Need job monkeys? Code your game so you can assign code monkeys without making them staff - meaning, without giving them access to your game planning or overall decision-making. Same thing for your Storytellers, same thing for your builders.

It's so much easier to function (or communicate as @Ganymede would have it ) when it happens between a well-bonded team of 3-4 people who know each other well for years than with a ragtag rotating roster of 20, including some who barely get along and where you have to keep resolving conflicts of interest since there are so many fingers for so few pies.

[Coin]

@Arkandel said:

Also by all means, for all that is holy... it's much better to leave a staff position unfilled than to fill it with someone who's just okay, or whom you don't know very well. Keeping staff lean and efficient is so important in order to have a decent culture to do whatever it is you need to do.

Need job monkeys? Code your game so you can assign code monkeys without making them staff - meaning, without giving them access to your game planning or overall decision-making. Same thing for your Storytellers, same thing for your builders.

This is dumb because it presupposes that being on Staff gives you some sort of innate authority over an aspet of the game that isn't in your "job description".

If I hire a job monkey, they are staff. They are staff because they are doing something that is a staff job: i.e. processing player jobs.

That doesn't mean they automatically get more say regarding game policies, house rules, or plot direction. I don't know where that came from (other than TR putting everything to a non-existent vote that never got anywhere).

"Being staff" should not convey authority over things that aren't within the purview of what you were hired to do. Why would it?

[Arkandel]

Because it does, and because (as noted elsewhere) people are promoted to the level of their incompetence - it happens everywhere, and it absolutely happens on MU*. Of course it's dumb but the world is full of excellent number-crunchers and workhorses who rose to become managers only to fail utterly.

But aside from all that... you have this person who's your builder, right? Just by being listed on +staff, talking on the staff channel and having access to staff-only boards - which they don't need to dig exits in rooms or check how descriptions conform to game-wide standards - they are exposed to conflicts of interest. People (rightfully or not) see them as staff, rulings in their favor are viewed in a negative context, etc. Plus it's one more person to manage; it's always easier to not hire someone than to fire them if they screw up or just aren't doing their jobs.

And for what? What is the upside of a builder having access to more resources than their function requires?

[Coin]

@Arkandel said:

Because it does, and because (as noted elsewhere) people are promoted to the level of their incompetence - it happens everywhere, and it absolutely happens on MU*. Of course it's dumb but the world is full of excellent number-crunchers and workhorses who rose to become managers only to fail utterly.

But aside from all that... you have this person who's your builder, right? Just by being listed on +staff, talking on the staff channel and having access to staff-only boards - which they don't need to dig exits in rooms or check how descriptions conform to game-wide standards - they are exposed to conflicts of interest. People (rightfully or not) see them as staff, rulings in their favor are viewed in a negative context, etc. Plus it's one more person to manage; it's always easier to not hire someone than to fire them if they screw up or just aren't doing their jobs.

And for what? What is the upside of a builder having access to more resources than their function requires?

You're still assuming that it's easier to "fire" them if you don't give them a staff name. People are still going to make a huge fuss if you one day tell them "you can no longer do this". Also, other people's misconceptions is pretty much the worst reason not to do something. No, hire a builder and then you tell them: "you are a builder, if people ask you about things other than build, you pass the buck. Don't read +jobs; read +jobs/mine which is what your staff job entails".

Let's stop reacting to undesired behavior by trying to avoid it and start acting upon it and forming the sort of structure we want. If we do what you're suggesting, we're not actually advancing and progressing towards a better structural system for MU Staff, we're outsourcing Staff functions to players without actually giving them the authority to do things within their field.

It's also easier to divide what you do when you have a separate bit to do it in. Even if you're a job monkey, you don't want all those jobs showing up in your player bit, so you get a Staff bit you log on when you are doing jobs, and that you can log off when you play.

But seriously, my issue with this lies almost entirely in that your suggestion basically plays into people's insecurities and undesirable behavior instead of addressing them in any productive way.

[ThatOneDude]

@Coin said:

@Arkandel said:

Because it does, and because (as noted elsewhere) people are promoted to the level of their incompetence - it happens everywhere, and it absolutely happens on MU*. Of course it's dumb but the world is full of excellent number-crunchers and workhorses who rose to become managers only to fail utterly.

But aside from all that... you have this person who's your builder, right? Just by being listed on +staff, talking on the staff channel and having access to staff-only boards - which they don't need to dig exits in rooms or check how descriptions conform to game-wide standards - they are exposed to conflicts of interest. People (rightfully or not) see them as staff, rulings in their favor are viewed in a negative context, etc. Plus it's one more person to manage; it's always easier to not hire someone than to fire them if they screw up or just aren't doing their jobs.

And for what? What is the upside of a builder having access to more resources than their function requires?

You're still assuming that it's easier to "fire" them if you don't give them a staff name. People are still going to make a huge fuss if you one day tell them "you can no longer do this". Also, other people's misconceptions is pretty much the worst reason not to do something. No, hire a builder and then you tell them: "you are a builder, if people ask you about things other than build, you pass the buck. Don't read +jobs; read +jobs/mine which is what your staff job entails".

Let's stop reacting to undesired behavior by trying to avoid it and start acting upon it and forming the sort of structure we want. If we do what you're suggesting, we're not actually advancing and progressing towards a better structural system for MU Staff, we're outsourcing Staff functions to players without actually giving them the authority to do things within their field.

It's also easier to divide what you do when you have a separate bit to do it in. Even if you're a job monkey, you don't want all those jobs showing up in your player bit, so you get a Staff bit you log on when you are doing jobs, and that you can log off when you play.

But seriously, my issue with this lies almost entirely in that your suggestion basically plays into people's insecurities and undesirable behavior instead of addressing them in any productive way.

Agreed, I've always hated how most Mu*'s are run. One thing I think should be addressed as well is who a game is designed for. I've seen a number of games that seem to think they are not there for the player. The player becomes "unimportant" which seems strange to me.

[Misadventure]

The Staff flag is the psychological equivalent to a clipboard and a white lab coat.

Please continue.

[Ganymede]

@Arkandel said:

What is the upside of a builder having access to more resources than their function requires?

Division of labor is great in an industrial sense, but it is terrible for customer service. That's why that model ought to be abandoned on a MU, save for particular issues regarding game mechanics.

On an ideal game, everyone should be assisting in processing XP jobs, build requests, and other administrative matters. Players should feel comfortable to going to anyone on staff to get something done. I would prefer any game where I knew that if I went to any staff member with a quick, mundane issue, they would help me without shunting me to another person. Wouldn't you?

[Arkandel]

Of course I would. But the question isn't what we get from this (or any one) decision in a game but what the net result is.

So would I not like being able to get my +job handled by one of many, many people rather than wait for a specific one? Absolutely.

Would I like the inconsistency of that +job's result based on who happens to handle it? The double threat of either deadlocked jobs due to conflicts of interest or them being handled with perceived bias? The lowered standards which come when suboptimal people are hired just because they can do one thing well but not another, which they also end up handling? Saddling good staff members with drama and politics when they have to handle and manage conflicting personalities in a large, uneven roster? No.

It's a give and take, not just take.

[Ganymede]

@Arkandel,

You're presuming an awful lot, but there's some truth in what you say. On a game like Reno, which has few spheres, it's more reasonable to have expansive staff coverage than on a game like The Reach, which has many spheres.

[Arkandel]

@Ganymede I will however say that having staff sphere seems to not have worked. It might be the implementations we've seen and not a problem by design but it's led to staff looking after 'their' turf instead of looking to serve the game's interests as a whole and to spheres ran as islands in multi-sphere games.

[Sponge]

@Arkandel said:

@Ganymede I will however say that having staff sphere seems to not have worked. It might be the implementations we've seen and not a problem by design but it's led to staff looking after 'their' turf instead of looking to serve the game's interests as a whole and to spheres ran as islands in multi-sphere games.

This is often a function of expertise. You wouldn't want me weighing in on your Demon, Changeling, Wraith, or Mage requests because I approach all of these with varying levels of incompetence. Vampire I'm pretty solid, Shifter I'm smarter than your average invertebrate but not an expert.

Expertise aside, it's totally reasonable to require book references for things and even without sphere expertise I can look at a request, look at the book reference, and try to sanity check things that may not jive. That at least lightens the load for the experts a little bit and grants me a few points in Sphere Ability: Foo.

Sphere-specific staff is an obvious solution to limited expertise, but it doesn't age well. To survive, a game doing that really needs procedures for handling requests outside of one's realm of expertise.