Wings Over the Pyre

Current Mood: tired
Current Music: Various Artists - Full Metal - The Album - Bret Hitman Hart - Hart Attack

After being involved in a lengthy, ongoing thread on roleplayers that involved some rather egregious examples of bad MU* Admin decisions in the construction of TPs (TinyPlots, in the argot of the age; from now on referred to herein as Plots), it occurred to me that I don't think I've ever seen a system'd MU* core that was based on any principles other than the strict Simulationist, which provides certain problems for me as a game designer, and moreover as a guy who's developed multiple systems for MU* play.

I'm not sure which is worse at the moment, that I've never tried to create a Narrativist system for a MU*, or that I find myself using Edwards' Threefold-Model to talk about it. (In consideration of my love of simpler terms, I think I'll use the more reasonable term Dramatist, not the least reason being its easier to type repeatedly.)

So, yes, Dramatist MU*ing. I'm sure Gen Lang will want to jump in here, somewhere, given our long history of online game design discussion.

I'll take as my model (predictably) Capes, as its possibly the most convenient architecture I've encountered for creating consistently Dramatist results with the lowest cognitive overhead. Others might suggest Universalis as a preferred basis, but since I can't get a copy of the game in my hands for love or money, I'll be forced to acknowledge its potential perfection without actually referring to it.

The essentoal element of Capes play is not, as in more traditional fare, the Character, but the Scene. In a MU*, the general idea is that a virtual location (a "room") really defines a specific place and time. But is this necessarily absolute? I've certainly constructed virtual spaces on a MU*, such that the description of the location and its connection to others were dynamic, definable by the inhabitants and existing only so long as there are inhabitants. Something of this order would seem perfect for a Dramatist MU*, with a few core, constant Scenes serving as a meeting ground for folks to interact and then spin off other Scenes by mutual decision.

Exempli gratia: For the sake of making sense,. we'll proceed to design and structure a MU* in an abstract sense. Doing so lets us explore our ideas in a common context.

We'll take as our premise that the MU* is devoted to Modern Urban Fantasy. After all, the World of Darkness MU* are still hugely popular, and I've never shied from ripping off what works.

We need a few core Scenes, so we'll build The Halcyon Days, a bar and grill for the vampires with twin silvered katanas and the fey with big troll-hammers to hang out in. Plus it makes a convenient center. While we're at it, we'll create the deadland version of the Halcyon as another Scene (for ghosts to be non-perceived by the inhabitants of the real-world Scene). That'll do for now.

Once we've set up the core Scenes, we can create the mechanisms for spawning, displaying, and joining new scenes (probably with commands like +scene Name, +showscenes, and +join Scene), so that folks can get involved with making such.

Unlike table-top Capes, we have the potential for folks to join Scenes in progress already. I think the simplest solution to that is to add the new Players to the end of the list of folks engaged in the Scene, and then, at the start of their first engaged Page, allow them to perform the same series of tasks they would at the beginning of the first Page of a Scene. They'll be cycled to the end of Action declaration, as a result of being added to the end, so that should keep things notionally mechanically balanced.

This brings up an important point, Players are just amorphous potential until they are joined with a Character at the beginning of the first Page of a Scene they're involved with. This works well with our Dramatist intent, since we can use technical means to keep the presence and communication of said Players invisible to those with a Character bound to them. That is to say, we can limit the textual perception of those engaged in a Scene to the presence and output of the others playing in the Scene.

How do Characters get assigned? The best method is likely the idea that every Player can create a privileged Character, one which can only be attached to his Player object. They can also create any number of Characters, but all of them have to undergo Administration review for consistency before they go into the common pool. Its probably a good idea to allow people to create Characters for a Scene that don't get added to the common pool unless requested and which have no objective presence after a Scene ends (the Character object vapes when the Player leaves the Scene). This is the kind of thing that can be yanked as an ability if there are complaints about a Player, but best to start with an initial level of trust.

Eg: Alice, Bob, and Carrie want to run a Scene in the deadland outside town. Alice +scene Deadland Outside Town and both Bob and Carrie +join Deadland Outside Town, so they're all in the same room. Alice thinks about it and then does a quick @desc of the room to the Scene.

Alice and Bob both pull their privileged Characters from the pool (+chara Whatever) while Carrie wants to create a ghost for them to engage with, but nothing particularly permanent, just a throw-away for the Scene (+newchara Ghost). That puts Carrie in the new character creation mode, where she puts together the ghost and its Character is attached to her Player until she leaves the Scene.

Once the Scene is over, Carrie decides the ghost is interesting enough to be added to the common pool, so requests an Admin look at the Character with +review Ghost.

Defining Characters in Capes is easy, and that works well for us when trying to do so online. Once in the mode, there are only a handful of commands you need:

• +name Name
• +ability Ability=Rank
• +ability -Ability
• +style Style=Rank
• +style -Style
• +attitude Attitude=Rank
• +attitude -Attitude
• +description Longish description of the character
• +background Longish background of the character
• +submit

Hitting +submit should validate the character design, then go ahead and create the Character object and attach it to the Player, setting the Player object's description temporarily to that of the Character. It should revert once the Player leaves the Scene.

Pages aren't "objects" in the abstract sense so much as they are constructs, but from a technical point of view, they should probably be built as a physical (but invisible) object created when the Scene is spawned. For Scenes which are actually player-created, the Page should add the creator of the Scene to the Player list first, followed by the other +joiners in the order they arrive. The Page also needs to have two additional commands, one command allowing the use of Story Tokens (hereafter Tokens) to add a Character to the Player's position-slot (+chara Name), and one to add Conflicts (costing one Token per Conflict after the first, just like Characters) (+conflict Conflict).

The Page manages the turn-order of Actions of Characters/Players. Each Character gets one Action per Page for free, any after needing to be paid for by Tokens.

That takes care of Scenes and Characters. The last real Dramatist object of importance is the Conflict. Conflicts are where the meat of the command system really resides, and all but a few of the remaining system issues center on how Conflicts are managed.

But I tire, so I'll take that issue up tomorrow.

Current Mood: creative
Current Music: Steve Mclain - Lemonade Stand - 03 - Cabin Fever

Let me apologize for my descent into the madness of specificity, last night. Like most programmers, sometimes its hard for me to let go of implementation and to just work on design and interface. From a user, and even administrator point of view, it just doesn't matter what the underlying object/technical implementation looks like. Its moot. Only in the roughest sense is it remotely relevant, so I'll try and avoid going too much into programmer-speak and just finish talking design.

So, we've defined the verbs that the Players will use to interact with Scenes, and Pages, and Characters, at least basically. Now we need to talk about Conflicts and how they interact with Players and Characters.

Conflicts can be introduced to the Scene by a Character spending their one Action on a given Page, or by spending a Story Token. Since the Page should know whether the Character has expended its one Action yet, we can just assume that evoking the introduction verb will deduct Tokens appropriately (+conflict Name). There also needs to be a mechanism for taking a Conflict back out of the Scene before its been touched by activity, so that others can contest the introduction of the thing if its an Event or a Goal that drives an objecting Character. Those rules are best supported by social interaction, so all we need is to have a verb to pull it back off (+conflict -Name).

Once introduced to the Scene, a Character can operate on a Conflict in a limited number of ways. The problem is that Conflicts are side-specific, and can have more than one side (with splitting of dice and sides). The most convenient interface is probably to just number the sides, so that when a verb needs to interact with a specific die on a specific side, it can be addressed in the format Side Value. We don't need to distinguish between, say, three 3's on one side of a conflict, any of them will do.

As the result of an Action ...

• A Character can activate one of their traits and target a die associated with a Conflict, rolling it either up or down. Doing so Allies the Character with that side for rolling up or the opposite side for rolling down. (+activate Trait Conflict Side Value, or +activate Trait Conflict Side -Value should work for up or down.)
  
  This is complicated by the fact the result can be accepted or rejected, so requires a second round of verbs to complete (+accept / +reject).
  
  Its further complicated by the fact that activating a trait that is a Power (as opposed to a Skill) generates a point of Debt that has to be assigned to a Drive if the Character has them and not just an undifferentiated debt pool. Best means to do this is probably to just let them drop unassigned Debt into place with +assign Drive.
• After a Character +accepts a die, the other Characters around the Scene, starting with the Character that accepted, can react, activating one of their suitable traits and re-rolling the die. Again, this is probably something best handled by social means in terms of turn order, but the verb structure is straightforward (+react Trait, followed by +accept / +reject to move to the next.
• Either before or after his Action, a Character can stake Debt from their Undifferentiated Debt Pool (UDP, in a rate fit of comedy, from now on) or a Drive (+stake Conflict Side Drive Number, +stake Conflict Side Number). They can split dice on an Allied side, two or more ways as long as sufficient Debt is staked (always evenly) (+split Conflict Side Value Ways).
  
  The Player can also use an Inspiration gained from a previous Conflict. (+inspire Inspiration Conflict Side Value. This will probably require the Inspirations a Player has to be numbered for individual reference.

This pretty much defines the back-and-forth process of the Conflict. There are only two things that needs to be defined now.

Firstly, Conflicts can be Claimed at the beginning of a Page, and Claiming any after the first requires a Story Token. All Claims are reset at the beginning of a Page before Claims are done, so a Claim only extends for one Page. (+claim Conflict Side)

Secondly, once Claimed, if the Claimed side is in control at the end of a Page, the Conflict resolves, and we need verbs for that.

• If the non-controlling side(s) have Debt staked, they get back double the staked debt. It goes back to the Drive or UDP it came from, so no interaction required.
• If the controlling side has Debt staked, the non-controlling side(s) get that as Story Tokens. If the Conflict creator is Allied with a non-controlling side, they get the first Token. The rest are dispensed by the controlling Player (+token {Player|Character}) as they see fit.
• The controlling Player then matches up dice between sides, as defined in Capes. +match Conflict Side Value Side Value is about as simple as that interface can get. This results in folks getting Inspirations. Dice that can't be matched just get converted to Inspirations and distributed automatically.

Once resolved, the controlling Player gets to narrate the Conflict's resolution.

There is one more significant thing a Character can do during a Page that's not directly connected to a Conflict but is an Action, and that's to attempt to roll up an Inspiration the Player already has. +activate Trait Inspiration followed by +accept / +reject will work just fine for that. Pointedly, an Accept here can allow others to react, just like accepting a die on a Conflict.

A Scene should be considered finished if a Page starts and there are no Conflicts in the Scene. (Obviously, this doesn't apply to the first Page of a Scene.)

We'll walk through a couple Pages of a Scene between Alice, Bob, and Carrie:

( Extended Example )

In Part III, I'll go into some of the overall advantages of this kind of Dramatist approach compared to the Simulationist.