Steps in deciding to run and setting up a MUSH



  • This look about right? (Written for a good friend)

    To-Do list for MUSH Establishment

    1. Name MUSH. Pick Setting, Theme (Write the Newsfiles) choose staff theme names (Mountains in our case.)

    2 Decide what Spheres will be allowed. All-Sphere is inclusive, but it can in reality be too unwieldy and hard to staff. 3 Super Sphere plus Mortal may be the best way to go. Or we can try all-sphere. Your call, this is your money!

    1. Find staffers for the appropriate Spheres. These people must NOT sit idle, they need to immediately write the News files for their Sphere. Dedicated Wiki staffer may be a good idea.

    2. Hire Coder. Give coder all needed "We need this common code, we need this customized code." information, including code specs. Coder can immediately begin gathering code from Github/other coders they know, and writing any custom code we need. Make sure to include in your negotiations with them who -owns- the custom code. The polite thing to do is ask them to share it widely under the Crative Commons license.

    3. Get everyone to write a substantial amount of News and help files. This can all get done before a site is purchased. to save money. Make sure all the RP staff understand the Theme and Setting. Get people planning initial plots. Make sure everyone's down with the staff structure and the basic rules of operation that will be used. Buildwizard(s) Can begin writing grid and planning layout.

    4. Aquire site. Three people need the PW for this: Coder, Sitewiz, Owner. No one else ever will need access.

    5. MUSH goes up. All staffers get staffbits. Coder and Wiki staff go to work slamming code in and setting up Mediawiki. Sitewiz assists. Newsfiles go in, Help files go in, Wiki person starts making the Wiki nice. Forums go up. If the MUSH is going to offer Job archiving to Forums, now is the time to set that up. Give everyone on staff a Wizbit, because paranoia about it is so 1970's.

    7 Once the +news. +help, Grid, code, Wiki and all that jazz is assembled, test the fuck out of everything, seriously. Test it twice.

    1. Ads go up. Short period of soft-open to handle initial apps and introductory play.

    2. Game on.



  • I don't think staff theme names are a necessary thing. Otherwise seems to make sense to me.



  • If you're going to put that annoying first letter ansi thing for staff names, put it on the entire name. Best thing I've seen, and I thank Reno for it.



  • Item 4 is pretty big, too.

    Don't just tell your coder, "I want vampire code. You know, so vampires can do stuff" and only say if it does or doesn't fit your vision down the road.

    For bonus points, say exactly what you'd like the person to have to type, a mock-up of what it's supposed to look like, and exactly what's supposed to happen (both internally, with it crunching the data and externally, with the output the game'll produce).


  • Pitcrew

    @icanbeyourmuse said:

    I don't think staff theme names are a necessary thing. Otherwise seems to make sense to me.

    Necessary, no. Nice, yes. Well, theme, whatever. It's just that staff should have names that don't look like character names.



  • @il-volpe said:

    @icanbeyourmuse said:

    I don't think staff theme names are a necessary thing. Otherwise seems to make sense to me.

    Necessary, no. Nice, yes. Well, theme, whatever. It's just that staff should have names that don't look like character names.

    Anything can look like a character name, though. It is why, at least from what I can tell, @moniker is typically locked to staff.


  • Pitcrew

    @icanbeyourmuse said:

    Anything can look like a character name, though.

    Depends on the game, really. Unless it's a superheroes game, a character will not typically be named 'Spiderman.' Similarly, if it's not a Middle Earth game, 'Elrond' is a funny name.

    Actually, themed staff names help with this. Sure, any game is liable to have a player or twelve who comes up with a reason to have a funny name, but if I go for 'marine mammals' as my staff name theme and the staff are called Whale, Dolphin, Seal, Otter and Walrus, people won't likely think that Dolphin is a PC who had hippy parents. If the staff names are Shakespeare, Dolphin, Thing, Olympus and Wuggly-Ump the odd name's power to hint 'this is a staffer!' is less.

    It's a tiny issue, though, because, sheesh, +staff. Probably games should have themed staff names if the creators happen to like them, and not have them if they don't.



  • @il-volpe said:

    It's a tiny issue, though, because, sheesh, +staff. Probably games should have themed staff names if the creators happen to like them, and not have them if they don't.

    I'm a big fan of the 'there's a +staff command ' answer, as well as having staff names get special marking in +who/+where (like, all-caps or an asterisk or something) and a mention in +finger about it.

    Mind, I might be biased since I've helped out on a game OOCly for a while before asked to do staff-stuff and didn't want to confuse folks with a name-change, and I also can imagine someone stuck in the situation of they'd like to help as staff, but can't come up with a name that fits the name-theme that they don't hate.



  • Giving everyone a wizbit is not a good idea at all. It is the same reason you don't give anyone other than owner and possibly sitewiz/coder the server login: That level of access isn't needed to fulfill their duties.

    It may be easier than setting up powers, but it certainly isn't recommended or good starting advice.



  • @Glitch said:

    Giving everyone a wizbit is not a good idea at all. It is the same reason you don't give anyone other than owner and possibly sitewiz/coder the server login: That level of access isn't needed to fulfill their duties.

    It may be easier than setting up powers, but it certainly isn't recommended or good starting advice.

    Luckily on Rhost, you can give everyone near Wizard Powers and still keep them well under control, yay for multiple wizard/staff flags.



  • I have less to say about this but to add some comments, and shorten it. My additions in bold.

    @Corruption said:

    1. Pick Setting, Theme (Write the Newsfiles)

    2. Decide what Spheres will be allowed. (1a. Pick which WoD.)

    3. Find staffers for the appropriate Spheres.

    This one is vaguely contentious. Find experts. Find people who want to buy into this game. Sphere staff have a horrible tendency to form their own Kingdoms. Do not let them. Tell them they can quit if they don't want to share their position.

    Do not hesitate to fire a staffer who is not going along with the game's theme or culture. To leave this person in power is to tacitly approve their actions and authority.

    1. Hire Coder. Give coder all needed "We need this common code, we need this customized code."

    Be careful about asking a coder if it's okay that their code gets shared. Tell them that the code is for the game, regardless what happens later, even if you won't share it. Staffers are contractors; build and code staff doubly so.

    1. Get everyone to write a substantial amount of News and help files. Make sure everyone understands the Theme and Setting. Get people planning initial plots. Make sure everyone's down with the staff structure and the basic rules of operation that will be used. Buildwizard(s) Can begin writing grid and planning layout.

    Builders are just as important to your RP staffers as setting is important to your theme. Some of us coders don't get along with the theme, but a coder with buy-in is a dedicated coder.

    1. Aquire site. Three people need the PW for this: Coder, Sitewiz, Owner. No one else ever will need access.

    The lead coder does not, at any time, need access to the shell. Only give access to the shell to people who need to set up things that can only be set up at that level, and whom you trust implicitly. Do not give anyone else access to your shell.

    If you trust your lead coder that much then sure, but do not lump them in this list. Only one person needs access: You. (Your site host already has access.)

    1. Open game. Finalize code, finalize wiki.

    Nothing else needs said here. Do not give wizbits to anyone who doesn't need them. Not because of paranoia, but because of what can be broken.

    Don't trust just anyone to do shortcuts available to wizbits.

    1. Once the +news. +help, Grid, code, Wiki and all that jazz is assembled, test the fuck out of everything.

    This should be before 6.

    1. Ads go up. You are open. Wait a week or two before introducing heavy plots. Otherwise, go, go, go!

    Hope that helps.


  • Pitcrew

    I was going to say some things to this, but @Thenomain said pretty nearly every point that I was going to mention. So I'll just ad a couple of thoughts:

    Presumably then this is a "Steps in deciding to run and set up a WoD MuSH"? Because there are other kinds of mu*es, other game systems and settings. But your points do sort of lean in that direction.

    I've now been involved in the day-one to opening of 3 different games on the end of staff (and early-early on in 2 other games). I think a lot of these things depend upon the core staff group you have, be it a headstaff group or a single headstaffer with a core group of founding staff, as well as what specifically you want this game to be. If those core people know the systems/spheres you are going to use - I recommend that those people do the news files/game setting information writing. Those are the people with the vision and plan, more staff can be added later and there is such a thing as having too many people with too many opinions/perspectives that can make the game not what you initially mean for it to be. And if you are in the middle of trying to set things up, that is not the time you want to derail yourself by having to manage drama associated with removing someone from staff.



  • @Thenomain said:

    @Corruption said:

    1. Hire Coder. Give coder all needed "We need this common code, we need this customized code."

    Be careful about asking a coder if it's okay that their code gets shared. Tell them that the code is for the game, regardless what happens later, even if you won't share it. Staffers are contractors; build and code staff doubly so.

    I don't generally like this comparison. There is no actual contract, so treating coders and builders like contractors fails almost immediately. When people throw their time and effort into your game, they or you can quit at any time, there are no real timelines, it's all a dance of falling in and out of passion with the work by all people involved. There are expectations and hopes and fights and drama, but there are no contractors, just people working on the things they're passionate about until such a time as their interests no longer align.


  • Pitcrew

    Throughout the process, continue to be very, very grateful for those people with a passion that matches yours for your project. Those who contribute time and effort should be thanked, not treated like contractors - be they theme, code, or buildstaff.



  • I don't generally like this comparison.

    There is only so much thought and extra explanation I can give over my lunch break on an iPad. The impression I was trying to make is that the work they are doing for the game is work for the game. If they enjoy it, if they're invested, if they're doing it on a whim every third Tuesday, it doesn't matter. The code they are offering is defacto part of the game, not something they can offer to yank at a later time.

    The contract is a social one, but it exists. Anyone who has tried to take their work back from a game has been nothing but laughed at, no matter what that work is. Work that is done for a game is for the game. There's your contract. Live by it or don't offer your work. Don't accept the work of someone who thinks anything else.

    This goes well beyond code, yet code is generally the one area that people try to pull this crap on.



  • @Glitch - We are paying Coder real Money. She's a contractor. She may or may not play, probably depending on if she can get a were-Otter, but she's going to be cashing a paycheck,



  • I've never met a codeotter. Interesting.



  • @Chime I really like her. She got exiled from TR for annoying the staff, but I still really like her.



  • Corruption,

    You have omitted three points that must be considered before your own list.

    1. Look at your life to determine whether you have the time necessary to create and operate the game you intend. Do you have it? If not, don't start. Factors include, but are not limited to: (1) your work schedule; (2) your spouse or significant other(s); (3) your family; and (4) whether you intend to carve large chunks of your time to devote to other hobbies, like macrime.

    2. Look at the people you want to bring on-board as staff. Presuming you like, respect, and can work with them, examine their life to determine whether they have the time and motivation necessary to participate and assist you. Do they? If not, don't start.

    3. Look at the people you want to bring on-board as players. Presuming you like, respect, and want to entertain them, examine their life to determine whether they have the time and motivation necessary to devote their time to your game to make it better. Do they? If not, don't start.

    Ignoring these three points will likely result in your losing any motivation for running a game.


Log in to reply