Necessary tools for running plots as a non-staff player?


  • Coder

    Hi,

    I was reading @Arkandel's and others' posts in the Arx thread and the Game Death thread concerning the need and advantages to making it easy for non-staff to run plots. This made me interested in what kind of tools, information, resources etc you look for in a game in order for you as a non-staffer to feel comfortable/willing to run a plot the way you like it.

    Coming from the Evennia side, I'm not overly familiar with the various MUSH terminology - so if you love a particular tool or concept, a brief mention of how that tool is meant to function or what the concept means would be appreciated for context. :)
    .
    Griatch



  • I like 'suggested plots' type lists/commands. Especially if they can be used to affect the main plot of the game.

    I was also talking to @Cobaltasaurus the other day and was saying to her that we should encourage players to request if any events they want to do can be tied into main plot things (Maybe a dinner party has someone that gives information on some major event, or a villain NPC interrupts, etc). I don't think this one can be tied into a large game, though.



  • I find public +sheets insanely helpful. This isn't something all games do or that every genre considers workable, but when it's there I find it to be a wonderful tool.

    Maybe players could voluntarily list some stuff they want STs to have access to on games where this is less common, idk.


  • Admin

    @Griatch Hm, good question. Let's see.

    1. Tools to manage participants and juggle timezones are extremely handy. An event-based system where people sign up (and we can see the order they signed up in) where Storytellers can include some details about what they're about to run, what time etc is valuable. The order is important as typically there are more signups than there are slots, but some players might not show up, so you want to be able to run a fair first-come first-served queue.

    2. A fully player-ran +job system is a must. Typically running plot isn't merely a matter of scenes but communicating past them; if we have to involve staff that increases administrative overhead and introduces delays. A common use for it is investigations - the characters survived the dungeon, now they want to see who's behind all this by asking their contacts, making rolls, etc... it's very handy to have all that in a single thread instead of having to shuffle through individual @mails.

    3. Temporary rooms can be great. Sure, you can hijack a place on the grid but that can be problematic (say, you might want to 'freeze' the scene for just the characters in it) or there might not be something exactly as you like.

    4. +Meetme. :) Traveling commands in general. Events take a long time and they're spammy affairs as it is without the Storyteller having to help players figure out how they're supposed to get there.

    5. Combat-assisting aides can be invaluable. As a ST I use a text editor for table-top RPG systems but it can get pretty messy to communicate everything on demand- what's the initiative order again? How much damage has Orc #3 taken so far? And if there's a coded system (such as Arx's) then I'd need a way to spawn and control NPCs.

    6. All sorts of rolling options. Show a roll to just one person, ask a person to roll for specific people, rolling into +jobs.

    I think this about covers it, I can't think of anything else at the moment.


  • Coder

    @Three-Eyed-Crow said in Necessary tools for running plots as a non-staff player?:

    I find public +sheets insanely helpful. This isn't something all games do or that every genre considers workable, but when it's there I find it to be a wonderful tool.

    Maybe players could voluntarily list some stuff they want STs to have access to on games where this is less common, idk.

    I presume the idea being that since the character sheet is visible, the plot-runner can dig into e.g. the backstory or quirks of characters and use that as part of their plot ... how much leeway would a plot-runner have in that regard - or is taking the character in unexpected directions part of the charm?


  • Admin

    @Griatch said in Necessary tools for running plots as a non-staff player?:

    @Three-Eyed-Crow said in Necessary tools for running plots as a non-staff player?:

    I find public +sheets insanely helpful. This isn't something all games do or that every genre considers workable, but when it's there I find it to be a wonderful tool.

    Maybe players could voluntarily list some stuff they want STs to have access to on games where this is less common, idk.

    I presume the idea being that since the character sheet is visible, the plot-runner can dig into e.g. the backstory or quirks of characters and use that as part of their plot ... how much leeway would a plot-runner have in that regard - or is taking the character in unexpected directions part of the charm?

    I wouldn't want to introduce that element unless sheets are open game-wide anyway. If it is then that's great, but making it available only for STs opens a can of worms.

    If people want to reveal details about their characters to the ST they always can, but it should be voluntary (something like +sheet/show <target>).


  • Pitcrew

    A lot of this is already doable in Evennia. On Arx you can see anyone's background, only secret stuff and stats are hidden.

    I'm thinking of:

    A different permission set or alternate ST bit people can log into which will give them access to commands and NPC spawning and such they don't have as players, but NOT give them access to things staffers can see, like secrets and granular system commands.

    Group creation, so you can create groups of NPCs and commands to equip them/make them attack/whatever.


  • Coder

    @Arkandel

    Tools to manage participants and juggle timezones are extremely handy. An event-based system where people sign up (and we can see the order they signed up in) where Storytellers can include some details about what they're about to run, what time etc is valuable. The order is important as typically there are more signups than there are slots, but some players might not show up, so you want to be able to run a fair first-come first-served queue.

    I see, this sounds like a reasonable way to advertise what's coming. How is this maintained efficiently across multiple sessions, is there normally some coded reference of who signed up to a given "plot event" or is this something the ST needs to keep track of manually?

    A fully player-ran +job system is a must. Typically running plot isn't merely a matter of scenes but communicating past them; if we have to involve staff that increases administrative overhead and introduces delays. A common use for it is investigations - the characters survived the dungeon, now they want to see who's behind all this by asking their contacts, making rolls, etc... it's very handy to have all that in a single thread instead of having to shuffle through individual @mails.

    What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

    Temporary rooms can be great. Sure, you can hijack a place on the grid but that can be problematic (say, you might want to 'freeze' the scene for just the characters in it) or there might not be something exactly as you like.

    A "temporary room" meaning that you can create and describe a locale for your plot on a whim? To what extent do you expect to be able to perform coded operations on your room? That is, do you expect players to move between multiple such room or is this mainly a way to sequester players away from the main grid?

    +Meetme. :) Traveling commands in general. Events take a long time and they're spammy affairs as it is without the Storyteller having to help players figure out how they're supposed to get there.

    I've read the thread and discussion on this but from the outside I've not fully discerned what +meetme does. My guess is that it invites someone else to teleport to your location, is that the correct description?

    Combat-assisting aides can be invaluable. As a ST I use a text editor for table-top RPG systems but it can get pretty messy to communicate everything on demand- what's the initiative order again? How much damage has Orc #3 taken so far? And if there's a coded system (such as Arx's) then I'd need a way to spawn and control NPCs.

    What kind of aides would this be? Like a command to show a critical hit table or more like commands to actually do particular rolls for you in a given system?

    All sorts of rolling options. Show a roll to just one person, ask a person to roll for specific people, rolling into +jobs.

    This sounds interesting, I can think of a few different ways to roll, based on the way it can be done by a tabletop GM. What is the purpose of being able to ask a person to roll for specific people though? Because the ST doesn't know the character sheet of them?
    .
    Griatch


  • Admin

    @Griatch said in Necessary tools for running plots as a non-staff player?:

    I see, this sounds like a reasonable way to advertise what's coming. How is this maintained efficiently across multiple sessions, is there normally some coded reference of who signed up to a given "plot event" or is this something the ST needs to keep track of manually?

    The code used in most nWoD MU* these days (it could be @Thenomain's, I'm not sure) works really well.

    Basically the Storyteller does something like +event/create Orcs attack!=<Synopsis>/<datetime> which gives it an id, announces it game-wide and adds it to a list players can review with +events. So if it's #3, they can then sign up for it with "+event/signup 3. Once the date is past it's taken off the list.

    A fully player-ran +job system is a must. Typically running plot isn't merely a matter of scenes but communicating past them; if we have to involve staff that increases administrative overhead and introduces delays. A common use for it is investigations - the characters survived the dungeon, now they want to see who's behind all this by asking their contacts, making rolls, etc... it's very handy to have all that in a single thread instead of having to shuffle through individual @mails.

    What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

    Again explaining it through actual use, but a +job in this context is essentially a single thread into which anyone tagged can post messages and send rolls into.

    In this case I as the Storyteller would first start the thread by giving it a title ("Orc attack investigation") and an initial text ("Hey guys, this is for your investigating needs, tell me what you'll be doing"). Then I CCing my group's characters into it and they can start posting things in there ("Alright, so I'll contact the Mayor and ask if the Orcs ever troubled the village before"), etc - stuff that wouldn't necessarily be good enough to run an entire scene for. If needed I can ask players to make rolls into the +job ("roll empathy to see if the Mayor is lying").

    It's important for this to be something players can do on their own without having to bug staff about it, including to close or leave the +job if it no longer applies to them.

    A "temporary room" meaning that you can create and describe a locale for your plot on a whim? To what extent do you expect to be able to perform coded operations on your room? That is, do you expect players to move between multiple such room or is this mainly a way to sequester players away from the main grid?

    Only that a room exists and that a custom description can be applied to it is needed. If +places can be used that's great but even that isn't too necessary - I've never had to create a multi-room temporary environment before, it's just too much effort for something that's never going to be used again.

    Sometimes they can even be places that already exist on the grid, but which you want to run as a 'snapshot'; say, there may be a museum already on the grid I want to have the PCs break into and try to steal a cursed artifact at 3 am, but I don't want to take over the actual thing because what if someone walks in or is already playing there and it's noon for them?

    I've read the thread and discussion on this but from the outside I've not fully discerned what +meetme does. My guess is that it invites someone else to teleport to your location, is that the correct description?

    Basically, yes. +meetme Griatch sends you a message that Arkandel wants to bring you to their location, do you wanna go?

    Combat-assisting aides can be invaluable. As a ST I use a text editor for table-top RPG systems but it can get pretty messy to communicate everything on demand- what's the initiative order again? How much damage has Orc #3 taken so far? And if there's a coded system (such as Arx's) then I'd need a way to spawn and control NPCs.

    What kind of aides would this be? Like a command to show a critical hit table or more like commands to actually do particular rolls for you in a given system?

    If I'm having 3 Orcs attack the 4 PCs then a way to set their init order (it doesn't need to be automated, it's enough if I can set Orc #1's to be 4, Orc #2's to be 6, etc after I manually roll for them. If I can also set the damage each PC and NPC has taken - and everyone present can view these things - then that's pretty good, as opposed to constantly trying to figure out the init order, etc.

    All sorts of rolling options. Show a roll to just one person, ask a person to roll for specific people, rolling into +jobs.

    This sounds interesting, I can think of a few different ways to roll, based on the way it can be done by a tabletop GM. What is the purpose of being able to ask a person to roll for specific people though? Because the ST doesn't know the character sheet of them?

    Avoiding spam, and because you might not even want everyone to see there is a roll. Say, I rolled secretly to see if anyone might suspect there a trap in the room and only one has, so I ask them to roll awareness to me only; that way the rest of the group doesn't OOC know there is something sketchy to be aware of.


  • Coder

    @Arkandel said in Necessary tools for running plots as a non-staff player?:

    Basically the Storyteller does something like +event/create Orcs attack!=<Synopsis>/<datetime> which gives it an id, announces it game-wide and adds it to a list players can review with +events. So if it's #3, they can then sign up for it with "+event/signup 3. Once the date is past it's taken off the list.

    And the event code is henceforth only available to the ST I take it, as a reference as to who signed up.

    What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

    Again explaining it through actual use, but a +job in this context is essentially a single thread into which anyone tagged can post messages and send rolls into.

    In this case I as the Storyteller would first start the thread by giving it a title ("Orc attack investigation") and an initial text ("Hey guys, this is for your investigating needs, tell me what you'll be doing"). Then I CCing my group's characters into it and they can start posting things in there ("Alright, so I'll contact the Mayor and ask if the Orcs ever troubled the village before"), etc - stuff that wouldn't necessarily be good enough to run an entire scene for. If needed I can ask players to make rolls into the +job ("roll empathy to see if the Mayor is lying").

    I see, so this moves the game from (semi-) real time on-grid to a more abstract GM-Player like thing. Potentially Play-by-post almost, since it can be managed without ST and player being online at the same time.

    It's important for this to be something players can do on their own without having to bug staff about it, including to close or leave the +job if it no longer applies to them.

    I can certainly see the point of that, yes.

    A "temporary room" meaning that you can create and describe a locale for your plot on a whim? To what extent do you expect to be able to perform coded operations on your room? That is, do you expect players to move between multiple such room or is this mainly a way to sequester players away from the main grid?

    Only that a room exists and that a custom description can be applied to it is needed. If +places can be used that's great but even that isn't too necessary - I've never had to create a multi-room temporary environment before, it's just too much effort for something that's never going to be used again.

    Sometimes they can even be places that already exist on the grid, but which you want to run as a 'snapshot'; say, there may be a museum already on the grid I want to have the PCs break into and try to steal a cursed artifact at 3 am, but I don't want to take over the actual thing because what if someone walks in or is already playing there and it's noon for them?

    Aha, so from the perspective of a server coder, allowing the creation of rooms with such limited features is then quite trivial to offer technically.
    The concept of colliding time frames appear in more MUD-style games too, although there there is seldom a possibility to simply make a separate instance of a location and people tend to just awkwardly RP around the fact that people are still RP:ing their evening visit to the bar while the sun rises on the next day in code.

    This sounds interesting, I can think of a few different ways to roll, based on the way it can be done by a tabletop GM. What is the purpose of being able to ask a person to roll for specific people though? Because the ST doesn't know the character sheet of them?

    Avoiding spam, and because you might not even want everyone to see there is a roll. Say, I rolled secretly to see if anyone might suspect there a trap in the room and only one has, so I ask them to roll awareness to me only; that way the rest of the group doesn't OOC know there is something sketchy to be aware of.

    Oh, I see, you are talking about one person rolling on behalf of the whole group. That makes more sense. I first thought you meant you were rolling "for them" in a more code-mechanical way.
    .
    Griatch


  • Admin

    @Griatch said in Necessary tools for running plots as a non-staff player?:

    And the event code is henceforth only available to the ST I take it, as a reference as to who signed up.

    Nope, everyone! There's no need to hide these things (although I guess it could be a possibility if a ST wanted to use it as a coordination tool for specific people, to avoid spamming everyone else). But otherwise you can see who else has signed up for +event 3, since maybe you don't like big scenes or you do like Jim who also signed up, etc.

    I see, so this moves the game from (semi-) real time on-grid to a more abstract GM-Player like thing. Potentially Play-by-post almost, since it can be managed without ST and player being online at the same time.

    Well, the scenes happen in real time as usual. But some things don't warrant scenes, they're mostly back-and-forth exchanges - characters make rolls, the ST gives back information, etc. There's no reason everyone needs to be online at the same time for it. If all you need is to ask the Mayor one quick question it's a waste to wait for a couple of days for both you and the ST to be online and available at the same time, too.

    Aha, so from the perspective of a server coder, allowing the creation of rooms with such limited features is then quite trivial to offer technically.
    The concept of colliding time frames appear in more MUD-style games too, although there there is seldom a possibility to simply make a separate instance of a location and people tend to just awkwardly RP around the fact that people are still RP:ing their evening visit to the bar while the sun rises on the next day in code.

    There's not even the need to care if the room already exists or not. Just make the description editable and all's good - STs can just paste it from the existing one if needed. Hell, often enough STs don't even @desc the room, it's literally just a container for the scene's characters to be in, and any descriptions take place through posing (since the scene might start at a bar, become a car chase and end up in the sewers for the big fight).

    Oh, I see, you are talking about one person rolling on behalf of the whole group. That makes more sense. I first thought you meant you were rolling "for them" in a more code-mechanical way.

    No, although that's also a possibility. Ah, and ideally we shouldn't need to see the exact dice rolls, only the outcome; for instance if you're running Empathy we shouldn't get to see that's 9 dice as it reveals OOC how big your Empathy pool is. We should just see you rolled <X> successes.



  • @Griatch said in Necessary tools for running plots as a non-staff player?:

    @Arkandel said in Necessary tools for running plots as a non-staff player?:

    What is the mechanics behind a +job? You make a post only the ST can see specifying the tools/skills/etc they want to use, and the ST then eventually gets back to you with a result? To get a feel for it, is this more structured than, say, a message board with private sections?

    Again explaining it through actual use, but a +job in this context is essentially a single thread into which anyone tagged can post messages and send rolls into.

    In this case I as the Storyteller would first start the thread by giving it a title ("Orc attack investigation") and an initial text ("Hey guys, this is for your investigating needs, tell me what you'll be doing"). Then I CCing my group's characters into it and they can start posting things in there ("Alright, so I'll contact the Mayor and ask if the Orcs ever troubled the village before"), etc - stuff that wouldn't necessarily be good enough to run an entire scene for. If needed I can ask players to make rolls into the +job ("roll empathy to see if the Mayor is lying").

    I see, so this moves the game from (semi-) real time on-grid to a more abstract GM-Player like thing. Potentially Play-by-post almost, since it can be managed without ST and player being online at the same time.

    It's important for this to be something players can do on their own without having to bug staff about it, including to close or leave the +job if it no longer applies to them.

    I can certainly see the point of that, yes.

    This part of the thread has been very useful for me, since it reminded me a few use cases that I missed. And I don't think @griatch is off the mark here, in thinking that (from a MUD perspective) that it is more like a play-by-post. It wouldn't sound quite right to most MUSHers, since play-by-post is such a different format normally, but handling any kind of off-screen details and furthering story that way is pretty rare outside of MUSHes from what I've seen. While for our games I'd say it's pretty vital that characters have a degree of abstract control over what happens during downtime or offscreen, and stories continue to be developed in between RP scenes.

    Now for Arx, a large concern was that it was easy for 'here's what my characters want to find out off-screen' could quickly become overwhelming, so we made an +investigations system in order to gate and automate the process. Characters put in a long description of things they are trying to find out and how they are going about it, and then this is all handled in an abstract way off-screen and during downtime which is why it draws play-by-post comparisons. And it's a string search for keywords of the topics, and searches for random potential pre-built string results of findings, and then rolls a combination of character stats/skills to determine what string they should get as a result- a clear success with metaplot information, a red herring that's misleading, just a failure, partial progress, etc. And as players ask questions we hadn't considered, we just add more strings of results to allow for easy duplication for the next player trying to find out the same thing. It still requires a lot of GM review, just because it would be easy to have keywords that don't really make sense for some of the results (and using djago's icontain's model could make partial matches that go way way off, so it would need a much smarter search), and GMs have to be ready to jump in and redirect things, but it handles a lot of the problems of GMs potentially being overwhelmed by gating the amount of questions players can reasonably investigate and automating a great deal.

    Now as @Arkandel started discussing +jobs I realized this wouldn't really cover the different use cases for players (without staff permissions) running plots, for a lot of reasons. There's so much staff-only information in there that I don't know if I could make lock type permissions robust enough that would really cover all the cases of a player not seeing something they shouldn't by accident if we would give players access to it. So instead I'd have to be able to bump things down to a player running stories, and probably create something more like what he's familiar with, with a staffer looking at an investigation and going, 'Oh yeah this is for @Arkandel's plot, sending it down to him' and creating a thread for it that could still have dice rolls and automated results in it.


  • Admin

    @Apos said in Necessary tools for running plots as a non-staff player?:

    Now as @Arkandel started discussing +jobs I realized this wouldn't really cover the different use cases for players (without staff permissions) running plots, for a lot of reasons. There's so much staff-only information in there that I don't know if I could make lock type permissions robust enough that would really cover all the cases of a player not seeing something they shouldn't by accident if we would give players access to it. So instead I'd have to be able to bump things down to a player running stories, and probably create something more like what he's familiar with, with a staffer looking at an investigation and going, 'Oh yeah this is for @Arkandel's plot, sending it down to him' and creating a thread for it that could still have dice rolls and automated results in it.

    Although I like where it's coming from you need to be careful; a system like that scales poorly - there is a limited number of staff and a far less limited number of open plot lines stacking up on top of the day-to-day maintenance overhead that comes with running an active game. If the workload spikes a bit or, heavens forbid, staff get more on their plate in real life or are burning out or any of these very common things then it's easy for them to become a bottleneck.

    The advantage of an entirely player-managed system is that it takes all that out of the equation.


  • Pitcrew

    @Arkandel The disadvantage of an entirely player managed system is that there is no quality control and you lose your ability to ensure you are maintaining consistent theme.



  • @Arkandel said in Necessary tools for running plots as a non-staff player?:

    @Apos said in Necessary tools for running plots as a non-staff player?:

    Now as @Arkandel started discussing +jobs I realized this wouldn't really cover the different use cases for players (without staff permissions) running plots, for a lot of reasons. There's so much staff-only information in there that I don't know if I could make lock type permissions robust enough that would really cover all the cases of a player not seeing something they shouldn't by accident if we would give players access to it. So instead I'd have to be able to bump things down to a player running stories, and probably create something more like what he's familiar with, with a staffer looking at an investigation and going, 'Oh yeah this is for @Arkandel's plot, sending it down to him' and creating a thread for it that could still have dice rolls and automated results in it.

    Although I like where it's coming from you need to be careful; a system like that scales poorly - there is a limited number of staff and a far less limited number of open plot lines stacking up on top of the day-to-day maintenance overhead that comes with running an active game. If the workload spikes a bit or, heavens forbid, staff get more on their plate in real life or are burning out or any of these very common things then it's easy for them to become a bottleneck.

    The advantage of an entirely player-managed system is that it takes all that out of the equation.

    Yeah, I think we'd need to have something that wouldn't be able to get hung up and just sit there for forever while a half-dozen players are waiting for stories to go on. Which probably mean going immediate to players that can answer it, with the potential to be escalated to staff if needs be, rather than the reverse. The trick there, from a macro perspective, is making sure that things don't have contradictions or continuity breaks that can force the game into changing into a sandbox due to a lack of staff oversight- but even though that's something I wanna avoid it is definitely the lesser of two evils than plot just dying because it can't move forward at all.


  • Admin

    @Kanye-Qwest it's true but theme consistency isn't something you can codify, it's too fluid and subjective a matter. You can try to exert ever greater amounts of control over it, yes, but then you risk micromanaging your players.

    What does work is establishing good communication and trust both ways; for instance a new, untried Storyteller might be handed small and self contained pieces of the puzzle, such handling a ring of thieves in the suburbs of a large city but someone staff feels more comfortable with could be handed more critical parts of the metaplot to run. Similarly Storytellers could allow themselves to be more micromanaged than the average player by submitting a general outline ahead of time (or adhering to preexisting templates with common sense guidelines such as "you can't blow up the capital") and having to go into more detail as their plots begin to affect a larger portion of the game.

    It's really not very tricky. What's far trickier is finding Storytellers in the first place. People promise to do it all the time and flake out, but that's yet another thing code can't solve.


  • Coder

    @Arkandel said in Necessary tools for running plots as a non-staff player?:

    The code used in most nWoD MU* these days (it could be @Thenomain's, I'm not sure) works really well.
    Basically the Storyteller does something like +event/create Orcs attack!=<Synopsis>/<datetime> which gives it an id, announces it game-wide and adds it to a list players can review with +events. So if it's #3, they can then sign up for it with "+event/signup 3. Once the date is past it's taken off the list.

    Very Important Note:

    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.

    That is all.



  • I would have to agree that ways to manipulate and handle NPCs, without having to have them in like, goggledocs or many bits logged in is wonderful. Especially in games where there is coded combat. We used to use coded 'automatic combat' objects for things like, troops or weapon emplacements, and I've developed and used to decent effect a 'Virtual NPC' code before, where they have stats on the game and interact with all the coded systems, and it worked out well.


  • Coder

    @Apos said in Necessary tools for running plots as a non-staff player?:

    Yeah, I think we'd need to have something that wouldn't be able to get hung up and just sit there for forever while a half-dozen players are waiting for stories to go on. Which probably mean going immediate to players that can answer it, with the potential to be escalated to staff if needs be, rather than the reverse. The trick there, from a macro perspective, is making sure that things don't have contradictions or continuity breaks that can force the game into changing into a sandbox due to a lack of staff oversight- but even though that's something I wanna avoid it is definitely the lesser of two evils than plot just dying because it can't move forward at all.

    Yes, my first thought when reading the original suggestion you wrote was essentially the same as @arkandel's - "that seems like it would be a lot of work for staff". Balancing player-ST agency versus retaining some control over game plot quality is a potentially tricky problem ...

    Having a system where players/STs could, with a special command or tag, escalate certain things to staff if they deem they are stepping into parts of the lore they don't know about sounds like a pretty decent half-way solution. Depending on how restricted the setting is and how often such escalations would happen, obviously. Being able to easily get back previous replies to quickly respond to similar-sounding requests from different players sound like an excellent time saver. I keep feeling there should be some sort of automatic mechanic here as well though, to avoid lockups.

    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.
    .
    Griatch



  • 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.


Log in to reply
 

Looks like your connection to MU Soapbox was lost, please wait while we try to reconnect.