@WTFE Shang has that for its rental rooms -- and I think there's a room parent out there somewhere that even uses that command name and structure. How to set it up on a game these days... I wouldn't even begin to have a clue; building permissions are nothing at all like I remember with most setups.
It would be nice if games other than Shang introduced this then. 
@WTFE said in Necessary tools for running plots as a non-staff player?:
Something I've always wanted for player plots is an "overlay" system of some sort; a way of making a locale change according to events playing out.
For example, my crime family uses a dance studio as a money laundering facility. The description is … well, it's a dance studio. Normal dance studio shit. The wall of mirrors. The wooden bar. The padded flooring. Depending on time of day the students, the teachers, etc.
But …
Today the Ruprecht gang has decided to take on my funding and attacks the dance studio with flame throwers. This would tend to, you know, modify the site's @desc. But of course it can't. Because players don't have the ability to modify the grid. (WITH GOOD REASON I might add!)
What I'd really like, though, is some way to supply modified descs for rooms. Perhaps a way even of storing them locally and swapping them in and out like various clothing code some MUSHes have. +rdesc/change holy-shit-its-on-fire or something like that. This would give player plots some actual presence on the grid. It would still permit the use of rooms for other purposes (playing out time-bending scenes; background events, etc.) while making it such that player plots can have actual impact on the setting. Visible impact. People can go to their favourite corner bar and find that it's been trashed and vandalized. Or go to their classroom at the university only to find the chalk outline on the floor with the bloodstain over by where the head of the figure is. That kind of stuff.
Of course there's room for abuse with this kind of stuff, so you'd probably want to make it such that you need a permission attribute on the charbit to use it. Perhaps if people register a PRP they can temporarily get the permission bit. Perhaps you just give it to everybody but take it away from players who abuse it. Perhaps you give it to everybody after they've established themselves as decent players.
But this, to me, would be the dream feature for player-run plotting.
Some MUDs use "room poses" or "moods" for this: The main description of the room is fixed and settable only by staff. But then there is an extra field that can be set to appear after the main description. This "mood" is settable by anyone and represents the current state of the room, from a tavern being full/empty to fires and local damage. Some systems let the mood "time out" after a certain time, reverting the room to its base description.
As long as the person setting the mood is stored for staff for see it should be fine. I've not seen it abused at least.
.
Griatch
@Griatch said in Necessary tools for running plots as a non-staff player?:
Regex-based auto-replies is a good idea but maybe hard to regularize. Another idea may be to have a policy of default timeouts from staff replies. If an ST escalates a request to staff and staff doesn't get back to it in due time, the timeout will auto-reply to the ST that no information was found. A more extreme policy would be an auto-reply telling the ST that they can now make up the answer on their own since staff haven't fulfilled their end by replying in a certain time ... maybe that would put more stress on staff, but it would avoid bottlenecks on that end at least.
I don't like the suggestion I'll make here but I'll do it anyway: Unless someone comes up with a brilliant idea, don't reinvent the wheel.
The reason I don't like that is we can really use a paradigm shift; just because we've been doing a thing for a long time it doesn't mean it's the best (let alone the only) way it should be done... but so far in the thread I haven't seen something that qualifies as a lightbulb moment, including of course my own takes on it. It's not so much that plot, investigations and assorted details can't be automated to some degree so queries reach the right person as that the interface for players to ensure things get filed properly will start getting increasingly more complicated - which is only a small step away from intimidating. A system people won't use is not a good system.
For example @Griatch's timeout suggestion won't work. Imagine I run that Orc invasion story and players ask to talk to the village Mayor - he's my NPC, the entire village is part of this one story, right? Then when players fire off an investigation which goes to staff and waits there while both I and the players are twiddling our thumbs, we'll end up realizing we're better off handling it ourselves without involving staff, through pages, which is the exact opposite of what a system should do. It ought to facilitate and improve, not get in the way. A system people need to circumvent is not a good system.
Etcetera etcetera.
Quality control is important, I don't want to belittle the matter. I used to get annoyed on TR when people ran the most inane things, right down to that now-infamous UFO landing in the middle of Aleswich. I just don't think the trade-off is worth it - not unless the paradigm does shift as described above because one of us (maybe in this thread ) comes up with something brilliant and innovative. If you guys got something, please don't listen to oldbies bitch about these things, just go ahead and suggest new approaches.
@Thenomain said in Necessary tools for running plots as a non-staff player?:
This code belongs to @Cobaltasaurus, from start to finish. Her concept, her code, her updates. I've added comments and suggestions and when she disappeared for RL I've done some bug-fixing and Thenoisms, but events code is Cobalt's contribution to the hobby.
Just to make it clear if it wasn't, no slight was intended for Cobalt. There's no convenient way to know who's coded or had a hand in what - but it's appreciated no less.
For example @Griatch's timeout suggestion won't work. Imagine I run that Orc invasion story and players ask to talk to the village Mayor - he's my NPC, the entire village is part of this one story, right? Then when players fire off an investigation which goes to staff and waits there while both I and the players are twiddling our thumbs, we'll end up realizing we're better off handling it ourselves without involving staff, through pages, which is the exact opposite of what a system should do. It ought to facilitate and improve, not get in the way. A system people need to circumvent is not a good system.
This is very true. You might indeed be correct that a simple one-level system is what people would actually use - a superior solution, staff control be damned. At any rate, I pictured the timed-out alternative something like this:
... But anyway. I was just theorizing based on what I read in @Apos' post. Some games use extremely contrived systems (such as rumor systems) that get used just fine. It doesn't seem obvious to me where the simplicity-vs-features balance lies without starting to analyze the particulars of a given game, theme, style and player base.
Edit:
@Arkandel
Your mention of the need of a paradigm shift is interesting in itself though. This need suggests problems with the "old" paradigm. Maybe it might be instructive to list bad things about the way things are most often currently handled? No disrespect to those that created those systems of course - just in the interest of constructively identifying where things could improve.
.
Griatch
I skimmed some of the biggers ones, and this might be in there ...
A tool that isn't code based but is necessary is policy or understanding of what non-staff players can actually run on their own versus stuff Staff are likely to retcon (and thus lead to falling out and game death in the other thread).
Setting up a TP/PrP policy saying 'this is all okay to run as you will' and 'if it gets to this tier (city politics, clan/gang/turf fighting between player factions/global level destruction), you must +request for prior approval' is an easy step to allowing players willing to run little things spur of the moment for friend and strangers alike the first step (by removing a hurdle) to running things and spurring some creativity and activity.
That said, I also see a necessary tool for non-staff players as having things that can be done that staff won't get upset about, so they can run ideas that strike them that doesn't upset the game balance/meta but creates fun and allows individuals to run story for personal character development.
@Griatch I like that escalation system - as long as the interface for the players can be non-nightmarish. It can be a simple flag, marking a particular post as needing staff intervention.
The process then would be like this?
)Assuming staff and STs are working together it's not a big shift from what we have in most MU* I've played - in those we just have a manual step between 3a and 3b where the ST makes a separate +job for staff then waits to hear back from them.
To answer your addendum though about needing a paradigm shift, the current +job system doesn't always work optimally. For example on Fallen World we ran into several issues and in the end had to get @Thenomain's intervention to help out; for instance we couldn't CC players to a job without staff doing it, then the comments we made had to be manually published else they were invisible to non-staff (which is what he fixed for us). In the end that was obviously not very optimal.
There are additional things that could be improved - there's no obvious way to flag a +job as being potentially interesting to staff for example. Or to mark them as private (maybe staff have alts, and they wouldn't want to see information that might be sensitive, both for their benefit and other players'). A common issue, too, is if one player runs an investigation and I give them the results - now there's no systemic way for me to announce them to just that player, which means they can't (for example) fake the results, or only report partially on their findings. Finally, the fact this is over telnet itself is a limitation - a thread can get pretty long, but if it's over the web maybe we can have nested comments and sub-threads, making it far more convenient for future reference.
A tool that isn't code based but is necessary is policy or understanding of what non-staff players can actually run on their own versus stuff Staff are likely to retcon (and thus lead to falling out and game death in the other thread).
Yeah, clarity from staff is undoubtedly something that must be assumed before going into the mechanical contrivances.
@Arkandel said in Necessary tools for running plots as a non-staff player?:
@Griatch I like that escalation system - as long as the interface for the players can be non-nightmarish. It can be a simple flag, marking a particular post as needing staff intervention.
The process then would be like this?
- ST runs stuff, it resolves, people have off-screen things to do about it.
- Someone (the ST or a player) creates a thread, tagging everyone else into it.
- If possible all things happen internally, the ST asks for relevant rolls, people pose questions, it's done and the original owner can close it (plus anyone can leave the thread at any time to stop getting spammed if they lost interest). It'd be ideal if the ST can make posts visible to just a subset of the players tagged in the thread.
3a. Someone asks a question that's not the ST's call to make on post #13 on that thread. The ST answers that and flags post #13 (which staff can see - I don't know how Evennia's staff interface works so I can't help there
3b. Staff has whatever time to answer it. They can answer to the ST only or make it visible to everyone tagged. If staff do not answer in the default time, the ST gets a notice about it and acts accordingly
Yes, sounds like what I had in mind. Since you mention Evennia, I would likely consider the "thread" here as a type of "channel" (I presume you don't mean quite the same thing?). A channel is, the way I use the term, nothing more than a message re-distributor; you could use a channel to send a mail to multiple recipients as much as you could use it for chatting.
A "message" in Evennia is a rather generic object that can represent mail as much as a line in a channel chat or a tell. Each message can in principle have its own meta properties and tags as well as be database-persistent. Thus you could easily create a message object with any set of recipients, from channels to groups of players/staff. You could for example have a message that goes to an admin-only channel at the same time as it goes out to a small sub-group of players or to the main plot channel.
To answer your addendum though about needing a paradigm shift, the current +job system doesn't always work optimally. For example on Fallen World we ran into several issues and in the end had to get @Thenomain's intervention to help out; for instance we couldn't CC players to a job without staff doing it, then the comments we made had to be manually published else they were invisible to non-staff (which is what he fixed for us). In the end that was obviously not very optimal.
There are additional things that could be improved - there's no obvious way to flag a +job as being potentially interesting to staff for example. Or to mark them as private (maybe staff have alts, and they wouldn't want to see information that might be sensitive, both for their benefit and other players'). A common issue, too, is if one player runs an investigation and I give them the results - now there's no systemic way for me to announce them to just that player, which means they can't (for example) fake the results, or only report partially on their findings.
To continue the Evennia example above, if one didn't want to use the strict sender-recevers paradigm, one could instead use tagging, where messages are stored in a pool that is filtered by the tags set on each message. It'd be a simple thing to make a command for viewing the "job pool" based on the permissions of the players/staff and the tags/locks set on individual messages by STs. Players would have permissions to view only messages with the tag of the plot they are in and/or messages particularly tagged to them while admins would default to seeing only those particularly flagged for them to handle. Such a system sounds like it should be general enough to handle most custom cases mentioned - it's just a matter of allowing more tags to be set in combination with more ways to filter the pool.
Finally, the fact this is over telnet itself is a limitation - a thread can get pretty long, but if it's over the web maybe we can have nested comments and sub-threads, making it far more convenient for future reference.
The telnet text limitation is something that can be worked around with OOB telnet instructions using a client aware of, say GMCP or MSDP to put such things in separate windows with custom GUI elements. Mushclient supports this as far as I know. Mudlet is another example. Easiest is of course to handle it in a web client customized for the purpose, then you as the game developer has the control over both client and server at the same time ...
.
Griatch
@Griatch said in Necessary tools for running plots as a non-staff player?:
Yes, sounds like what I had in mind. Since you mention Evennia, I would likely consider the "thread" here as a type of "channel" (I presume you don't mean quite the same thing?). A channel is, the way I use the term, nothing more than a message re-distributor; you could use a channel to send a mail to multiple recipients as much as you could use it for chatting.
What I mean by 'thread' in this context is anything a group of players can look at asynchonously then add to. It should probably be write-only (if someone's being abusive we don't want them changing what they wrote before) - the idea is STs might not be online at the same time as everyone else, or some OOC research or communication with third parties might be needed, etc.
Also remember the same tool can (and should) be used for other purposes such as example timezone and schedule coordination for the next scene - so it needs to be flexible for new people to be added and old ones to drop out at will.
To continue the Evennia example above, if one didn't want to use the strict sender-recevers paradigm, one could instead use tagging, where messages are stored in a pool that is filtered by the tags set on each message. It'd be a simple thing to make a command for viewing the "job pool" based on the permissions of the players/staff and the tags/locks set on individual messages by STs. Players would have permissions to view only messages with the tag of the plot they are in and/or messages particularly tagged to them while admins would default to seeing only those particularly flagged for them to handle. Such a system sounds like it should be general enough to handle most custom cases mentioned - it's just a matter of allowing more tags to be set in combination with more ways to filter the pool.
I think what will make or break this system - which otherwise seems feature-rich enough to cover all cases I can think of at least - is the interface. Sometimes systems require arcane incantations with a ton of arguments for common things and ... well, the point was made earlier that if it's intimidating players won't use it. The basic syntax at least, reading existing visible comments by everyone else tagged and posting new ones visible to all, must be really very easy.
Finally, the fact this is over telnet itself is a limitation - a thread can get pretty long, but if it's over the web maybe we can have nested comments and sub-threads, making it far more convenient for future reference.
The telnet text limitation is something that can be worked around with OOB telnet instructions using a client aware of, say GMCP or MSDP to put such things in separate windows with custom GUI elements. Mushclient supports this as far as I know. Mudlet is another example. Easiest is of course to handle it in a web client customized for the purpose, then you as the game developer has the control over both client and server at the same time ...
As a SimpleMU user I'm naturally suspicious of protocols that require a specific client to be used but as long as it works for basic telnet as well as richer clients it should be fine. The problem here usually is the massive wall of text that comes up when you view something people have been posting and/or rolling to for a while; you can still paginate it over telnet, I guess, but that can make things worse rather than better.
@WTFE Arx has this, wherein players can append a red paragraph onto a perm room description via the event system, so you can note what is changed, or what is going on during the event : décor, partiers, fire. Whatever.
@Arkandel said in Necessary tools for running plots as a non-staff player?:
What I mean by 'thread' in this context is anything a group of players can look at asynchonously then add to. It should probably be write-only (if someone's being abusive we don't want them changing what they wrote before) - the idea is STs might not be online at the same time as everyone else, or some OOC research or communication with third parties might be needed, etc.
This is entirely (and fairly easily) doable via wiki. While it isn't write-only, it keeps track of edits that can be compared/checked/etc. with no loss of data, so there's instant accountability.
The only thing it isn't is private, so everything is open to everyone's view. (Which has upsides and downsides.)
Oh fucking well.
@surreality Yeah, I've considered the wiki for stuff like that before but it was privacy options that stopped me. Plus there's no easy way to roll into a wiki page.
@Arkandel I know I plan to set some things like this up. People are just going to have to deal with everything being more or less in the open. Anything that by necessity MUST MUST MUST be private is going to have to be stuck in a +job of some kind, but everyone being able to have eyes on as much as possible is a net positive, IMHO.
Granted, this also applies to the various bits and pieces of information that normally would be staff only (in large part, anyway) re: setting/world/etc. as they're resources that should, IMHO, be open to the game at large if aiming for a highly collaborative environment.
There's a lot that can be handled with the use of spoiler tags to help people avoid info they don't want to see if they want to preserve suspense.
Oh fucking well.
@surreality It could work, it's mostly technical limitations that might prove pesky.
For example, other than the dice-roller I mentioned above (which it has to be tied to your in-game stats since STs can't be expected to go check if the 9 dice you rolled were actually your strength+melee sum), you also wouldn't have notifications when someone posts something new but you'd need to keep hitting the refresh button, people would need an account per character or I'd need to remember 'surreality' is playing 'Leia', there is still no nested view for those walls of text unless you get really fancy with templating, etc.
Oh, and are there modules which would show lists of such 'discussion' pages per character? If I'm on a bunch of separate PrP threads I would want to see them all in one place, but only the ones I'm on, not every one in a big long list.
In other words there will be a point where you'll need to consider what you are gaining this way and if it's worth the tradeoff, just like any other system you're introducing. What are you hoping the benefits are?
I really really got a lot of mileage out of TR's clone of the +jobs system for players. I used it extensively for running, coordinating, and investigating things. It gave me all the tools I needed to really make it work, and once the switch got flipped to let us leave jobs, it was pretty ideal, actually.
@Arkandel said in Necessary tools for running plots as a non-staff player?:
@surreality It could work, it's mostly technical limitations that might prove pesky.
For example, other than the dice-roller I mentioned above (which it has to be tied to your in-game stats since STs can't be expected to go check if the 9 dice you rolled were actually your strength+melee sum)
This is super easy on an open-sheet game. The roller part, no, but the checking, yes. The roller code for wiki is craptastic, but there are still viable options there.
you also wouldn't have notifications when someone posts something new but you'd need to keep hitting the refresh button, people would need an account per character or I'd need to remember 'surreality' is playing 'Leia', there is still no nested view for those walls of text unless you get really fancy with templating, etc.
Already have a log template with calculations that spits out commands for XP awards on a per-participant basis, shows up in a list of logs pending XP awards by staff for review, and turns off that tab on the log page and removes itself from the pending list in three clicks once it's handled and processed. CSS flow stuff is not even a thing to worry about. 
Oh, and are there modules which would show lists of such 'discussion' pages per character? If I'm on a bunch of separate PrP threads I would want to see them all in one place, but only the ones I'm on, not every one in a big long list.
Not sure. I'd have to look at what extensions are there. Thing is, there are other ways of doing that, and doing that fairly easily. You can even have them set up so the only ones that display are within a certain date range/etc. really -- nothing older than 4 weeks, for example.
In other words there will be a point where you'll need to consider what you are gaining this way and if it's worth the tradeoff, just like any other system you're introducing. What are you hoping the benefits are?
I think you need to not worry about what was and think about how to replicate it elsewhere, but at what is possible and work from there. It's just a different approach. What exists and how to interpret it into something else is already a limited framework compared to what's possible.
I know Fallcoast as +comm which is like +job only designed for player use for plots. I know players can add other players to it and that +comms can be merged since for one recent thing two players in the group started +comms on the same issue nearly simultaneously.
Having thought a little bit more about what tools might be extremely useful for organizing plots, it occurred to me that a lot of the common issues facing staff and non-staff storytellers aren't really all that dissimilar from a design perspective as version control, like in coding. The games usually aim to have one big central continuity and story state, so characters can interact with one another, but there can be any number of contributors each starting their own branch with a story that potentially forks it off when things become mutually contradictory.
So it seems like we could use the same principles in creating overview tools that would let any storyteller have a much, much easier time of seeing what all story elements are currently in play in plots (and would present potential collisions/contradictions), what all is being decided, and just when a plot is being resolved and could be merged/pulled back into the overall plot of the game. So not unlike what @surreality was thinking about with wikis, but for my case, would just be using django to create a hierarchy tool with the current existing plots, sorted by their different plot category elements, whether they are resolved or ongoing, who's running them/who is participating, and whether any elements need resolution due to conflicts with other plots. Hell, could even automate it with categories for plot elements, like in a wod game if someone put in a plot that was involving the police or an antagonist group, the tool would just check what other ones currently were ongoing, to see if there would be potential story conflicts. Just things to make communication between storyrunners a lot easier and simpler.
some fucking idiot who people only like because he's good at taking credit for the work of everyone under him, just like every other fucking L&L headwiz.
@Apos said in Necessary tools for running plots as a non-staff player?:
Having thought a little bit more about what tools might be extremely useful for organizing plots, it occurred to me that a lot of the common issues facing staff and non-staff storytellers aren't really all that dissimilar from a design perspective as version control, like in coding. The games usually aim to have one big central continuity and story state, so characters can interact with one another, but there can be any number of contributors each starting their own branch with a story that potentially forks it off when things become mutually contradictory.
So it seems like we could use the same principles in creating overview tools that would let any storyteller have a much, much easier time of seeing what all story elements are currently in play in plots (and would present potential collisions/contradictions), what all is being decided, and just when a plot is being resolved and could be merged/pulled back into the overall plot of the game. So not unlike what @surreality was thinking about with wikis, but for my case, would just be using django to create a hierarchy tool with the current existing plots, sorted by their different plot category elements, whether they are resolved or ongoing, who's running them/who is participating, and whether any elements need resolution due to conflicts with other plots. Hell, could even automate it with categories for plot elements, like in a wod game if someone put in a plot that was involving the police or an antagonist group, the tool would just check what other ones currently were ongoing, to see if there would be potential story conflicts. Just things to make communication between storyrunners a lot easier and simpler.
This sounds very interesting in principle. I can see the overall gist of using a version control paradigm but I have a harder time seeing how to efficiently break up a plotline in a way to make it easy for players to branch and merge without a lot of manual management. Could you give some example of how this could work, in practice?
.
Griatch
When I think of things I'd like to help run plots...
Something like a +plots command which is tied to the MUSH and not a wiki. So, you can send a job to have something added to it. Something like a brief description and some potential hooks. This may need to show up when people log in because, in my experience, a lot of players do not read bboards.
A way for people to express interest to be contacted. I tend to run things and find out after the fact that there were people who were interested but I never reached out to them (because they never told me they were interested). So, some way of letting people shoot off a quick indicator like 'hey, I think I'd like to be involved' would help.
A more GM appropriate bit. It's small but I hate running things through any of my PCs. It feels kind of cheap, particularly if I want my PC to do something during it. Even just a way to mask my PC's name as GM or Storyteller for the duration of the scene. Otherwise, I have PCs who never really do anything.
@WTFE Shang has that for its rental rooms -- and I think there's a room parent out there somewhere that even uses that command name and structure. How to set it up on a game these days... I wouldn't even begin to have a clue; building permissions are nothing at all like I remember with most setups.
