In all the years I’ve been MUSHing, there has been little change to the medium. Sure, there are more players, more games, and the array of clients that have sprung up over the years are a vast improvement over raw telnet, but overall, the basic premise of MUSHing remains the same. We log in, we make a character, which usually goes through some kind of approval process, and then we play. There is a certain level of code use that doesn’t vary that much from game to game, and the staff structure of most games is pretty much the same wherever you go.

I’d like to think this is because the medium sprang, fully formed, from the forehead of online gaming in a perfect state. It would be nice to believe that little has changed in MUSHing over the years because there are simply no flaws in need of improvement. In a sense, that’s true enough. The games are usually enjoyable, and the system works well enough to keep us coming back. It’s just that, aside from small aspects here and there, MUSH hasn’t really evolved. I wouldn’t go as far to say that it’s stagnating, but I wonder if we’ve really explored the medium’s potential.

Code

A controversial topic is the idea of automated encounters. The goal of MUSHing is to role-play, one might say. There is no place for MUD-like encounters where ‘kill monster get treasure’ is the goal, right? Sure, MUSH is RP-centric, and that’s well and good, but there is potential for coded interaction – to a point. Something as simple as a bartender object that allows you to leave messages for other patrons could be useful without disrupting the flow of RP taking place around it. Sure, you can simulate something to that effect with @mail, but if the coder added in a few quirks, it could end up like a game of telephone where there is a chance that names could get mismatched, or part of the message could be lost, or the bartender might forget the message entirely. The random factor could shake up RP a little in ways @mail wouldn’t.

The automated interaction wouldn’t even have to revolve around an NPC. There is a game where the sewers are coded with non-NPC encounters. For example, there is an area with scalding steam vents. The coder behind it was of the idea that if sewers are supposed to be dangerous places IC, then there should be risk. Just because there is no staff member there to throw something at a player doesn’t mean something can’t happen. The funny thing is that, despite there being several OOC warnings that if one proceeds one could get seriously injured, players still wander through those tunnels, then throw fits OOC when they end up with a few levels of burn damage. Next time they wander through the sewers IC, they pay attention to descriptions and OOC warnings. I am reminded of the parable of the hot stove; the mother warns her child that the stove is hot, but the child still puts his hand on it, gets burned, and is more careful next time.

Another area of code that goes unused is automated combat. I don’t think all combat needs to be enforced by code. I just think there is potential in offering the option. It would be difficult to blame a biased arbitrator for a poor outcome if the arbitrator was a string of code going strictly by the numbers. To avoid a MUD atmosphere, the automated combat code could determine the results in advance, inform the parties involved via a @pemit, and they could pose it out. Sure, it’s somewhat mechanical, but I don’t see how this is any worse for RP than a nine hour time-stop that degrades into a screaming match. Most combat requiring arbitration just doesn’t go smoothly, and I would rather opt for quick and efficient over long and drawn-out.

While on the topic of automation and the role of arbitrators in RP, I would also like to mention the idea of automating as much of what currently constitutes player/staff interaction as possible. Though I staff, and I’d love to have more free time on my hands, I am enamored of this idea primarily from a player’s perspective. I don’t like dealing with staff when I don’t have to. I would rather talk to a piece of code – that may sound sad, but it’s true. Code works more or less instantaneously. Code doesn’t take more than a month to get back to me over a simple yes or no question. Code doesn’t have an ego that needs to be placated. I’m not saying all staff are lazy egomaniacs, but I’ve had so many frustrating experiences that I’d love to minimize contact as much as possible.

One example of code that could obliterate an unnecessary bit of bureaucracy is something that automatically creates and links an apartment for a character, with a basic description that can be changed. I’ve been on a MUSH where this code was in place, and it was wonderful. One might make the argument that a player could abuse the privilege, but that same player could jump through all the hoops of dealing with building staff in order to get an apartment approved, and the moment it’s approved, change everything drastically once the staffer’s virtual back is turned. Cheaters are going to cheat. Making things a hassle for honest players doesn’t do anything but add to the frustration. I say let go of the micro-managing and have code do it. Have that same code auto-mail the building staff once the apartment is created so they can keep track of who owns what.

Staff Structure

The structure of staff is pretty much universal in MUSHdom – I say ‘pretty much’ because having not been on every single game that exists, I wouldn’t know for sure, but this has been the case for every game I’ve logged in to. Granted, most of my experience is WOD-centric, so bear with me. In my experience, there is someone in charge who ‘owns’ the game, usually at the level of god-staff. This person, or people, usually pays for the site, determines the theme and setting, and their word is law. God-staff usually has wizards staffing under them to cover specific areas, and wizards occasionally have administrators to help them out. Sometimes, there are player-helpers available to answer basic questions and help orientate newbies to the game. This hierarchy has been in place since I first logged in, in 1993, and it continues today.

I’ve seen attempts made to try different approaches to staffing, such as a round-table approach on a plotting level – wizards and administrators handled character approval and experience points while a team of plotters handled the storylines of the game. Where this broke down is that wizards didn’t want plots, over which they had no control, interfering in their spheres. Poor communication became a problem, and conflicting goals caused confusion and disagreements. Eventually, the role of staff slid back into the god > wizard > admin > helper formula we’ve all come to know and love.

I’m not sure there is a better way to arrange the staff hierarchy, but I’m interested in the possibilities. The idea of the round-table plot team I’ve described was sound. It fell down in execution, but there was a lack of communication, about who was to fulfill which role, that created unnecessary confusion. I think the idea of a round-table plot team is good because I like the idea of cross-sphere/faction storylines. If various spheres and/or factions aren’t going to interact, why have them?

Role-Play

Players have their quirks when it comes to role-play. I’ve seen heated debates rage over things like using third person narrative versus second person, and the touchy subjects of pose length and pose order. Some of us cling passionately to our preferences to the point of declaring all others substandard, or even the ‘wrong’ way of going about it. All in all, though, role-play tends to follow a simple formula. One person poses, then another person poses, and so forth. Each player poses the action and dialog of his or her character, and together they create the scene. Occasionally NPCs might be incorporated, mentioned in passing, but they’re essentially backdrop.

I don’t know how it works in other circles, but occasionally players in my group of regulars will run stories for their cohorts, taking on the role of an NPC for a scene, or running some kind of encounter the way a staff member might while running a plot. We trade off, and everyone in the group gets to experience playing and running. It’s a neat arrangement, and it breaks up the tedium of chatter-RP when there isn’t a staff member around throwing plot hooks at us.

One of the problems with trading off NPCs and telling stories for one’s cohorts is that at least one person knows where the story is going, and they pretty much end up eased into the role of storyteller – the element of surprise for that player is lost. I’ve thought about this, and one idea I came up with involves passing an NPC or an event around, letting each player incorporate and invent the nature of it into their poses, so that no one really knows what’s entirely going on, but the story unfolds. For example: one person incorporates into a pose that there is a clatter at the window, the next player adds in that there is the sound of footsteps hurrying away. The third player poses going to the window and finding some strange device ticking, etc.

The advantage is that it really is cooperative storytelling – each person is adding an element to the story besides their character’s presence. No one player is stuck setting the scene and dictating the action, and everyone gets a chance to contribute. The disadvantage is that each player would have to let go of any preconceived notions as to the nature of the NPC or event, because it doesn’t ‘belong’ to any one player, and its actions could change unexpectedly. It would require a mature group of players who respect each other enough to ensure everyone has a good time. If I ever have a chance to try this, I’ll let people know how it works out.

Overall, I’m satisfied with MUSHing as it stands. I just think there is so much more that could be done, more than one article could encompass. There is a wealth of code that goes unexplored either because game designers don’t realize its potential, or they don’t want to deal with the hassle of learning to code, or getting someone to do it for them. Staff structure doesn’t get experimented with all that often because it works, and if it isn’t broken, don’t fix it – but is it the only way? Is it even the best way? Role-play itself follows a basic premise, but how much of our creativity goes unused, and how much better could RP be if conventions were broken? Maybe I just like to shake things up, and if you give me a stick and point me at a hornet’s nest, I think you can guess what would happen. Still, I wouldn’t mind seeing a good medium become even better.

Recent Discussions on The Medium: