Wings Over the Pyre - Capes as Dramatist MU* Core: A Design

05:13 am - Capes as Dramatist MU* Core: A Design

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: tired