@Jaunt said:
@surreality said:
First, it's generally not an "I" creating a game. This may be assumed but it's worth noting it shouldn't necessarily be. I'm doing a fairly absurd amount of work putting one together now, but I am absolutely not doing it alone. (It's also worth noting that the people who are also contributing their time and energy to the project are folks I've met here for the most part, all of whom have contributed in equally important ways, from my perspective, just for the asking and some volunteered. Others provided advice and tutorials that helped get everything started.)
This is actually pretty big, and it's something that shouldn't be discounted.
That's pretty cool. I've always tended to create games, even MUSH, with a singular partner, not because I dislike working with a larger team, but because it's difficult to find folks who work at the same (crazed) pace that I do. I think that the idea of joint creation/responsibility is one of the cooler defining features of the MUSH community.
I'm pretty much in the same boat on the crazed pace. I'm just... hyper-detail-oriented to the level that most others can keep up pretty easily. (I need three more of me to document everything, I really do, just to get everything out of the brain and into an accessible format.)
The reason I say it's a fusion of both is that, after swapping in 'staff's' for I in the first statement, it tends to be the case. I wouldn't, for instance, put this much time and energy into creating a game I had no interest playing on at some point as well.
This is very true in the other genres of MU*s, too. Not always true, but very often. While it's probably a bit less of a problem with MUSHes because of their social and (usually) non-automated combat systems, I do think it causes problems in other genres (like RPIs): when administrators are also players, I have seen the two following problems eventually destroy many games:
- They are more dedicated to playing than programming/designing/creating. This is probably less of an issue with MUSHes, since the content creation is more of a communal aspect of the game.
That's a problem on MUSH/MUX as well, or can be. The trick to solving either is hiring people with a sense of responsibility who won't shirk their duties.
- Because they are so invested in their player characters, and they have the ability to do so, they cheat to get ahead. Cheating has always been a huge problem with MU*s, because there is an important trust-based relationship between player and admin. When that trust is destroyed, it very often ends up in an eventual player exodus, and it's really difficult to re-build.
This definitely happens in both, too -- but again, it has a lot to do with picking the right staff. One of the things I noticed on the MOO was, frankly, a lot of this. It would have been very easy for staff with certain permissions to adjust the damage rating of their weapons, tweak their stats, and so on, in ways that were entirely invisible and thus, people absolutely did it. Advancement was an 'invisible' process there, while it's typically more firmly recorded and noted in many modern MUXes. (Advancement is logged, and if what's logged doesn't match what's there, it becomes obvious enough.)
That's why staff on my games don't play PCs. We test PCs for gameplay purposes, and we observe others' play, and we GM --- but that's something that I always feel strongly about. Even the perception of cheating (even when it might not be true) can ruin the trust between players and administrators in other MU* sub-genres.
It can, and I've seen it happen. I don't think that's a good enough reason to forbid it, primarily because I refuse to allow one paranoid asshole shrieking about how 'cheating could be happening!' even when it's not ruin my experience on a game ever again. Games need staff that aren't burnt out and miserable. What they don't need are paranoid assholes. The former are essential, the latter are toxic in more ways than that. You just need to state up front how things work and be transparent about things, and allow people to make their own decision about whether to play there or not.
But, I also built tools to stop the spawning, or to freeze combat so that we could roleplay scenes together. There was automated player agency to keep players engaged, and there was the ability for scenes of nothing but roleplay, and there was the ability for the later, followed by the former.
This is something we didn't really have access to as an option; but we are talking about a game originally built in... 1993 I think?
If you use automated combat as a feature, and your game cares about roleplay, it's definitely worth it to add in tools to stop automated combat, stop spawning, so that you can engage your players with the same sort of in-depth roleplay that they'd get without those automated systems.
YES.
@surreality said:
The primary benefits I can see in the MUX approach are that a broader range of stories can be told in the same grid space, even if it takes work to provide the hooks to allow for this. It also means the players can find creative solutions at times to problems the code hasn't taken into account, and an automated system may not provide for.
True often, but I don't think it has to be true. RPIs also have dice-rolling mechanics for players to handle situations that automated code might not be able to take into account. And if GMs are good, they will be working to help players bring their plots to realization. I think that the main difference is that players get building tools on MUSHes, whereas on RPIs, players get in-character building crafts/scripts that GM Administrators support by helping those things come to realization, and player-developed plots require collaboration with a GM when something has to happen that goes beyond the player's toolset. It works very well when there is a great, active relationship between the staff and the player-base. It is obviously an annoying bottleneck for games that don't have an active staff.
The bottleneck happens in both, then, yep -- the 'I need a GM/ST!' moment is hard when folks aren't around or available.
It's probably more similar than you might imagine, though. What you describe about players needing staff aid for things that go beyond their toolset is the same -- it's the toolset itself that varies. Most WoD MUSHes lately don't allow build/create access at the player level, for instance, while other games do (or they allow one and not the other, etc.).
And that's why the big difference between the two genres goes back to philosophy, I think:
MUSHes are created more communally. There is less of a divide between staff and players.
It depends on the MUX, in part. Some do allow players to come up with plot -- not all do. It isn't a codebase-long trend, from what I've seen. (I started off on the MOO in 1996, and was on a MUX in... 1997 I think?) "Back in the day" I didn't see players with authority to run plots. I'm not sure when that shift went down to make it somewhat prevalent, but it was during the time I was hiding out on a game that just. didn't. care. (read: Shangrila) from some of the more toxic members of the MUX community. (Mostly, that 'Spider' person mentioned earlier. Long story goes here; tl;dr: she hounds a lot of people right out of the hobby, sometimes for years, sometimes permanently.)
There are also usually limits to the kind of storylines players are permitted to run, vs. what storylines only staff can run. This usually has to do with very high-powered antagonists or metaplot (the larger actions at work in the world that are staff-directed, and proceed over a very long period of time).
A number of players never get involved in plots at all. They're more there for the 'improv' aspect of character immersion.
RPIs put a lot more responsibility on their staff to create content, including content that will immerse players when they're not expecting it.
It's an important distinction, but not a massive one.
There's more pressure to do it, perhaps -- but I think there are different ways to do it, which is partly what I was getting at. WoD is an interesting example in part because it has some actual social mechanics, despite being a game designed for more intrigue-based play rather than adventure-based play. The new(ish) conditions system allows for a lot with this. (I'm biting my tongue since I'm holding back on something spoiler-y on a project or I would go on at more length about some examples of this and how it can be a factor.)
The primary difference I see between the two processes on the creation front isn't the volume of content -- it's the type of content. I find I need to provide more content when it isn't coded than when it is, either to explain the rules for how a thing works, or provide enough options and story hooks to keep going.
(There's more I would add, but... lots of work today. )