Storytellers - First Cut

[Kinaed]

Opinions?

Code: Select all

Syntax: story prepare
        story list 
        story join # <-- log to wiznet
        story leave # [reason] <-- log to wiznet
        story accept <name> <message>
        story reject <name> <reason> <-- log to wiznet
        story # open
        story # close
        story # review
        story # delete

STAFF SYNTAX:
        request <vnum> approve/reject <reason> <-- existing command
        request remove # <-- existing command

Players type story prepare to enter a POLCA to type up their story's
framework.  It looks like this: 
                Story Preparation

Story_ID   : <autogenerated numerical vnum>
Storyteller: <autofilled with the preparer's name>
Title      : <text field for player to enter title>
Description: <text field describing the plot>

Note: At a later date, more fields will be added to the POLCA to handle
other aspects of storytelling, but this will do for the beginning.

Send whilst in POLCA will put the prepared story into the staff request queue
to review.  Once a staff member has approved/rejected the storyteller's
request, the storyteller can story # open to flag themselves on the wholist
with [ST] to indicate they are running a story.  They can type story # close
to close the story.  When they close the story, the [ST] flag will be
removed from them in who. Send is logged to wiznet.

Upon typing 'send' in the menu, STs will receive the following message:

   Your request has been sent to staff for review. 
   Please read HELP POLICY STORYTELLING. STs are 
   accountable for everything that happens in
   their story.

Story join # will send a message to a storyteller saying: 

   "<Name> wishes to join <story title>."

Story accept/reject <name> <message> will either accept the player's 
entrance into the scene with, and transfer them into the scene. 

On accept, the ST sees:

   "You accept <name>'s request to join <story title>."

The accepted player will sees the ST's message:
   "JOIN: <Message>"

On reject, the ST sees:

   "You reject <name>'s request to join <story title>."

No transfer occurs in this instance.

Story list will show the list, by number, of stories in the system
as such:

ID             STORY TITLE                ST   
000001: The Beast Within The Tree         Kinaed
Joined: Azarial, Takta, Temi, Jaeela

000002: Some Other Quest Title            Azarial
JOINED: Kinaed

Story leave # [reason] will allow a player to exit a scene and the
ST's authority, as well as post why (not required) to a history
story channel that staff can review. 

Story review # will allow any player or staff to see the 'Story
Prepare Menu' to see if they like what it says, or for staff to decide
if they want to accept/reject the request in the queue.

Story delete # is a staff or ST command to delete their story from
the story list.

CODE NOTES:
- Don't let people join more than one story.
- Strip the story being opened or a player being joined to a story on
  logout.
- We will be adding a lot more than this basic stuff in the long run
  if this takes off. If not, we'll leave it just at this point.
- Story_ID is autogenerated as a six digit number, prefixed with 0s.
- Storyteller is always the request preparer.
- Title should be limited to 66 characters in length
- Description should be limited to 2400 lines. Can we put people into
  the standard editor to do this whilst in POLCA the way we do room
  descs? That'd be great.

[Empheba]

Conceptually I love this. As far as I understand, this is a sort of "temporary GM role", am I right?

I have no real comment on the command definition itself (the code field is a bit hard to read, but it looks okay).

I get that the "temp-GM" can create a story ("adventure/scene?") that staff needs to approve, then people can sign up for that. What I am a bit unclear about is the scope of the temp-GM:s powers once a story has been approved and is set into motion.

Is the "plot runner" marker only an OOC marker to show that people should follow their lead, or does it imply actual (limited) world-changing powers, maybe in the style staff used during the flood?

If not already considered, would think it would be appropriate to allow a "budget" for creating plot items and NPCs (depending on the size of story), as well as puppeting abilities for those NPCs. Also a command to give "non-attributed" caption texts to the group sounds like a reasonable addition to that role.

Anyway, empowering people to run their own mini-quests/stories is a great idea.
.
Empheba

[Kinaed]

Hi Empheba,

Just to try to answer some of your questions...

The idea is that a storyteller of a scene, within the bounds of the storyteller policy, would be a similar to a Tabletop DM at an irl gaming table. That means, like the Flood, they'd have absolute, godlike authority (up to the point of aforementioned storyteller policy).

The drawback is that in the initial pass, we won't have the ability to give them staff powers. We'll need to rework some things for this. As you say, we do intend to give them limited abilities to load objects/mobs and a 'budget' to do so based on their feedback status with other players (Eg, if they run excellent plots and the pbase wants more, then they'll get more ST powers, but if they turn out to be poor STs with naughty habits, they won't get as much 'budget'). However, we do need to think about how to rate STs and what the limits ought to be in that ST policy.

Suggestions would sure be welcome!

[Empheba]

Thanks for the clarification! Being primarily a tabletop GM since a long time, I find this concept all kinds of fascinating.

Since my impression of GM:ing an online game is often more similar to GM:ing a LARP than GM:ing a tabletop roleplaying game, I would suggest you give multiple players the option to collaborate as co-ST:s for larger stories. Especially ones with many Players having one main responsible ST and a second "help-ST" would probably save some sanity.

I can understand that actually adding a system for limited staff powers could be a lot of work if the codebase does not support limited player-building costs out of the box. For an initial launch one would not need very much though.

I think the ST should at least have access to a "stemote" command, for relaying information without having their name attributed to it. I favour this "speak-as-ST" to be (maybe optionally?) in a different colour so as to make it easier for a, potentially large, number of players in a fast-moving scene to distinguish the ST:s emote texts.

A similar thing should probably be available for OOC emotes - give the ST a different osay colour (say, bright cyan) to make it clear their ooc instructions are special (or give them a special "stosay" command for that).

Together with the group's implicit consent to accept the ST:s rolls and imposed challenges (as well as accepting the vNPCs the ST introduces), I think one could run a very full roleplaying game this way without much extra behind-the-scenes code (it's basically a time-limited form of MUSH I guess).


As said elsewhere, I see this useful not only for traditional "adventure" scenarios, but for any Player-hosted event, adding the ability to spice up parties and performances without Staff having to micro-manage things!
.
Empheba