Member Discussions

If that's directed at me, you just lost $10. While I've tried out dozens of MUSHes (though not more than a couple in the last five years and then only for a few seconds), I don't really play them nor staff on them.

Me thinks he be one of them thar "arr pee aii" types.

Yep, MUSH aren't the only types of games that require applications to play. RPIs do as well and for the very reasons I mentioned.

I wish I'd saved samples of some of the character apps that were submitted to SoI back when I was on staff. Some were beyond horrible (and made all the worse because they were serious attempts at creating a character, not jokes...well, not intentional jokes). I can say without any reservation that I do not want to see a character named Darth Vader with the description of "You are very scared of him. He is evil-looking and has red eyes." in any RP game I play or staff. Good ol' Darth there isn't too far off (and in some regards even better considering I used proper spelling and punctuation) from some of the horrible character apps that I've seen.

Some people may not care what kind of a character they play. Some MUDs may not care what kind of a character is in their game. Conversely, some players and some MUDs do care. Play the kind of game that suits your taste, don't bitch about games that don't. It really is that simple.

I do think they need to stop bitching about games that don’t meet their taste though because if it doesn’t meet their taste, move the hell on.

The only one ****ing is you. Reread the thread. The OP simply said that if you have layers of bureaucracy, players would try to avoid it, and you went off on how he was immature and unintelligent. I responded it was silly to expect people to put work into a game before knowing anything about it, and you then flung a boatload of insults at me.

I think people who aren’t willing to spend time doing something because they don’t like waiting are impatient.

Look, dude. No one has any investment in your game. It's your job as an admin to advertise your game to attract new players. Not letting them in to find out anything about what you have to offer before they do a bunch of work is a pretty poor way to advertise. It's not a matter of impatience, it's a matter of not wanting to waste a bunch of time on some shoddy game.

I think I've made myself pretty clear. You either don't want to admit this, aren't capable of understanding it, or you're trolling. Frankly, I don't care which. If you're upset about not getting new players because everyone "****es about how your game doesn't meet their tastes", you can complain about it somewhere else.

Best of Luck,
-Jess

Mann_Jess wrote: None of which I'd be able to see if I can't get into the game. If you have things set up so that I can login, interact with the other players, and experience the game without first applying, then you don't have an application system. If you don't allow me into the game, then I can't try it out before filling out an application, which gives me no reason to do so.

Almost every single game I've tried that required application allowed guest accounts. I'd venture that's about a fifth of the games listed here.

> I don't think 'never' is the right word. None of 'us' will
> do it, but I imagine most MMORPGs of the future will have
> to adopt this practice in order to keep up with their vast
> playerbases.

The concept of "completely bug-free software" is a pipe dream. It's simply not going to happen when you're writing software of any real complexity.

> > until you realise that the vast majority of player content
> > sucks horribly, and that without some sort of administrative
> > content control, so will the mud.
>
> It depends...

No, really, it doesn't - not for any realistic situation. And that's what we're talking about here. I asked for one example of a thriving mud that has no staff, not some idealised theoretical game with the complexity of the real world.

Mr_Bane claimed that "There are enough examples out there that I really don't have to bother showing". Where are these examples?

> > If you have that access, then you're staff.
>
> If I buy hosting from bluehost to run my MUD, they have
> access to by binaries and code, but I wouldn't consider
> them staff.

Not them, you. You're paying for the hosting. You have access to the code and data files. Whether you choose to flex your virtual muscle or not, the fact remains that you do have that power. You're the owner - the staff - and the future of the mud rests in your hands.

The concept of "completely bug-free software" is a pipe dream.

Completely bug-free perhaps (though I'm not totally sure I agree with that either), but I don't think it's a stretch to imagine a game bug-free enough that it doesn't crash or have any other game-breaking effects.

Where are these examples?

You're getting me confused with him. I don't agree with his claim that any such MUD exists. I was just saying it's theoretically possible that one could, at some point. I think he was still wrong.

Not them, you. You're paying for the hosting. You have access to the code and data files. Whether you choose to flex your virtual muscle or not, the fact remains that you do have that power. You're the owner - the staff - and the future of the mud rests in your hands.

This is semantics. The situation I was describing initially involved a free host, but ultimately it's the same. If I don't have an admin account on the game, and don't ever touch the code in any way (intentionally, not out of laziness), then I wouldn't consider myself staff. My technical access to it doesn't make me staff if I don't use it... otherwise the host's janitor and some 1337 hax0r might also be, even if they never touch the sever ever.

But that doesn't really matter... I wasn't talking about the host anyway. I was talking about someone who had an admin account to the game, made changes, spoke for the future of the MUD, ran things, etc. It's possible to have a thriving game without such a presence.

Tyche: Almost every single game I've tried that required application allowed guest accounts.

The few I've seen didn't. Admittedly, at least one or two were dead, so I probably didn't hit the 'major' ones (if there are such things.) My point remains that you're still unable to experience the players and world before applying (unless you can do all that fully with a guest account). I am not against applications for new characters per se, but I am against applications at the door, which bar content from a player before they complete an essay for admittance. I'm also against the type of elitism that would claim anyone who didn't want to complete such an application was unintelligent.

Best of Luck,
-Jess

The only one ****ing is you. Reread the thread. The OP simply said that if you have layers of bureaucracy, players would try to avoid it, and you went off on how he was immature and unintelligent. I responded it was silly to expect people to put work into a game before knowing anything about it, and you then flung a boatload of insults at me.

He said that if you “layer a whole bunch of crap behind a buttload of bureaucracy”. What he defines as “crap” is subjective and what he finds to be “bureaucracy” is sometimes just as necessary to a game as anything else that he might not find objectionable. His title for the thread was not “Things I don’t like”, it was “3 Guidelines to Staffing”. That’s a very immature and ignorant position to assume that all games fit his type.

Likewise, your response about how you “don’t know anything about 99.9%” of the games out there also demonstrates immaturity and ignorance since there are very few games which do not provide any information about themselves, or the means to obtain it, meaning you can’t end up “put(ting) work into a game before knowing anything about it” unless it’s due to your own unwillingness or inability to read or ask questions be it on their website, forums, via email or even through word of mouth. If finding information about a game is work and you refuse to put any work into finding out information even via (gasp!) reading or checking out a website, you’ll find there is NO game you’ll end up playing because entering a telnet address is work too! Technically speaking, the application process often reveals a lot about a game and many games have help files within the application process (in addition to on websites). In other words, there are abundant ways to learn information about games with applications. Whether or not you choose to do so is your problem, not their's, so bitching about how you don’t like games with applications is just that, bitching.

No one has any investment in your game. It's your job as an admin to advertise your game to attract new players. Not letting them in to find out anything about what you have to offer before they do a bunch of work is a pretty poor way to advertise. It's not a matter of impatience, it's a matter of not wanting to waste a bunch of time on some shoddy game.

You keep going back to generalized claims which aren’t supported by facts. Many games do provide information about themselves so that you can learn about them. Sure, some don’t, but you didn’t argue against games that don’t, you argued against games with application processes.

Said you:

I'm a pretty patient/mature person, but I've never joined up with a game which required an application process. This isn't a reflection of my personality... it's just a reflection of the MUDding landscape.

You’ve “never joined up with a game which required an application process” and believe that it is a “reflection of the MUDding landscape. This demonstrates your ignorance because there plenty of application-requiring games with an abundance of information about themselves on their websites. Thus it is a reflection either of your personality, in the form of impatience to bother and look a little more deeply at or your general ignorance of “the MUDding landscape” before you comment.

I think I've made myself pretty clear.

You’ve made it clear that your knowledge of games requiring applications is severely lacking.

If you're upset about not getting new players because everyone "****es about how your game doesn't meet their tastes"….

Here we have another demonstration of your ignorance. I’m not saying anything about how many players play my game because it isn’t yet open nor will it be for some time. YOU are the one making assumptions about games and commenting on how you won’t play any game that doesn’t meet your tastes. Well, boo-hoo.

For the record, my game is a historical RPI set in 1860s London. The game will have an application system because we don’t want characters that don’t fit that setting showing up nor do we want cardboard-thin characters from players who demonstrate little or no interest in creating a fully-realized character that fits within the setting. We will have an abundance of information available on our website for players to read as well as links to even more information regarding the period and its various characteristics whether they’re social, political, economic, religious, etc.

We fully expect and realize that we will not appeal to everyone or even a significant portion of the RP community much less the MUDing community at large. That’s fine because we aren’t catering to everyone. We do however expect those players who are interested will invest the necessary time to ensure that their characters fit into the game world. To ensure they do, the application process is in place. We’re not the only game that’s done this. Off the top of my head I can easily name several games with application processes that do the same (Shadows of Isildur, Armageddon and Harshlands just to name three) and with a little research, I can name more.

The few I've seen didn't. Admittedly, at least one or two were dead, so I probably didn't hit the 'major' ones…

Then perhaps you need to consider that your limited pool of knowledge about application-requiring games is not an accurate reflection of all of them.

My point remains that you're still unable to experience the players and world before applying (unless you can do all that fully with a guest account). I am not against applications for new characters per se, but I am against applications at the door, which bar content from a player before they complete an essay for admittance.

Your point is based on, at best, exceptional cases of application-requiring games or comes from a perspective irrelevant to the types of games in question. You don’t need to know the players in many role-playing games. You interact with characters, not players. A vile character you can’t stand might be played by someone you’d be best friends with in real life. And most games do make information about their worlds available through a variety of means. No doubt there are a few out there that don’t but to judge all off “the few {you’ve) seen” is fault on your part, not that of all application-requiring games.

Examples of games without any information available don’t tend to want new players anyway. They’re probably run for their own personal group and no one else. I’ve encountered a couple like this though in each case they DID have information on their website regarding their game world though apparently that was for the benefit of their established players more than anyone else.

I'm also against the type of elitism that would claim anyone who didn't want to complete such an application was unintelligent.

If this is in reference to me, you’re again taking me out of context. I didn’t suggest “anyone who didn’t want to complete such an application was unintelligent” I said that the OP’s comment about “layer(ing) a whole bunch of crap behind a buttload of bureaucracy” isn’t necessarily accurate because his definition of “a buttload of bureaucracy” does not mean that it’s not important to the game even if he does not see it as such. If he or someone else can’t understand the reasons behind games requiring applications to play, run plots or anything else, that doesn’t mean they aren’t legitimate it only demonstrates a lack of maturity or intelligence of the person who believes that appeasing the lowest common denominator is a “guideline for staffing” and not a personal opinion.

> > The concept of "completely bug-free software" is a pipe
> > dream.
>
> Completely bug-free perhaps (though I'm not totally sure I
> agree with that either), but I don't think it's a stretch
> to imagine a game bug-free enough that it doesn't crash or
> have any other game-breaking effects.

The number of bugs can be reduced over time (although new changes will obviously introduce new bugs), but doing so requires staff. Furthermore, many bugs are only likely to show up through extensive play, which requires players and staff to coexist.

There are also other issues that cannot be dealt with in advance. What happens if the hardware fails and the mud needs to be moved to another machine? What happens if the data files become corrupted, and need to be manually fixed or restored from backups? What happens if the server updates its software, and the old code needs to be recompiled (possibly requiring additional changes)?

> > Not them, you. You're paying for the hosting. You have
> > access to the code and data files. Whether you choose to
> > flex your virtual muscle or not, the fact remains that
> > you do have that power. You're the owner - the staff -
> > and the future of the mud rests in your hands.
>
> This is semantics. The situation I was describing initially
> involved a free host, but ultimately it's the same. If I
> don't have an admin account on the game, and don't ever
> touch the code in any way (intentionally, not out of
> laziness), then I wouldn't consider myself staff.

But you still "own" the game. If it infringed a copyright, for example, someone has to held liable. Equally, if one of the mud's essential data files were corrupted by another application on the same machine, preventing the mud from running, then you could fix it. A normal player couldn't do that. Without you, the mud would die.

> But that doesn't really matter... I wasn't talking about
> the host anyway. I was talking about someone who had an
> admin account to the game, made changes, spoke for the
> future of the MUD, ran things, etc. It's possible to have
> a thriving game without such a presence.

You're splitting the staff activities into multiple roles, but they still are all staff roles:

In-game staff: Technically not necessary, although I've yet to see a successful text mud which didn't have active in-game staff (and personally I've noticed huge drops in playerbase whenever I've come back from vacation, or for other reasons have been unable to spend much time on my mud).

Development work: Technically not necessary, although once again my experience is that the playerbase tends to go up quite a lot when new features are introduced, and trickle away over periods of stagnation. I don't think I've ever seen a long-stagnant mud that had any players, to be honest.

Public face: Technically not necessary, although advertising and promotional events are yet another effective way of bringing in new players (and bringing back old ones).

Maintenance: This is the essential staff role. Without the other roles I find it extremely unlikely that your mud would "thrive", but it would at least survive, probably as just another empty mud floating among the many others out there. But without someone to maintain the mud, pay the hosting costs, and deal with any major problems, sooner or later it would die.

The number of bugs can be reduced over time (although new changes will obviously introduce new bugs), but doing so requires staff.

But we're talking about a game without new changes (code-wise), with a stable codebase from the onset. Whether the MUD was run with staff for a while until it was stable, or a stable codebase was developed elsewhere and adopted for this MUD is irrelevant; It is possible.

What happens if the hardware fails...

These are all things a host would handle, which I don't see as staff. Cronjobs can keep the MUD running, and most servers running important code don't just "get updated" with new software which cause things to break.

But you still "own" the game.

"Owning" and "Staffing" a game are two different concepts.

Maintenance: This is the essential staff role.

Again, I don't define a host who may run the server on which the game is located (without any other connection to the game whatsoever) to be staff. That a host is essential is no more pertinent than that the electrical company, janitorial staff, and local police force are necessary -- they are not staff of the game. But, suppose we do define staff in a way to include them, then yes, a staff is necessary. That's not my point, and it's not what the OP or me were talking about.

Best of Luck,
-Jess

If finding information about a game is work and you refuse to put any work into finding out information even via (gasp!) reading or checking out a website, you’ll find there is NO game you’ll end up playing because entering a telnet address is work too!

And yet I have played other games. Strange, isn't it? Perhaps this ridiculous dichotomy you've established isn't based at all on reality...

You've continually asserted that anyone unwilling to put effort into an application before playing a game is impatient, unintelligent, unqualified, and a slew of other condescending labels. This is arrogant and elitist, and entirely unprovoked given the ambiguous statement of the OP, and my remark of opinion about a specific environment.

You seem very invested in this for reasons I can't place. Whatever your goals, I have no interest in taking part, with someone so unable to remain civil in the tamest of discussions. Troll somewhere else.

Best of Luck,
-Jess

> > Which "most active RP MU* community" are you referring to?
>
> I'm guessing, just because chaosprime wrote 'MU*' and that Bane started this thread, he means WORA.

A winner is you!

And yes, I'm sure some numbnuts is going to chime in with traffic numbers supporting that PennMUSH Community is more active or something. To which I say, whatEVs.

> > The number of bugs can be reduced over time (although new
> > changes will obviously introduce new bugs), but doing so
> > requires staff.
>
> But we're talking about a game without new changes (code-wise),
> with a stable codebase from the onset.

It doesn't matter, there will still be bugs. There will always be bugs. Who is going to fix them?

> > What happens if the hardware fails...
>
> These are all things a host would handle, which I don't see
> as staff.

It's the hosts responsibility to repair and reboot the hardware, and to restore from backups if necessary. They may restart the mud as well, but they're certainly not going to reimburse players or manually repair corrupted files, nor are they going to modify and recompile the mud source code if changes are needed to restart on new hardware.

> Cronjobs can keep the MUD running, and most servers running
> important code don't just "get updated" with new software
> which cause things to break.

It's not that unusual to update servers, and updates can break things in subtle ways.

> > But you still "own" the game.
>
> "Owning" and "Staffing" a game are two different concepts.

The former is a subset of the latter. If you own the mud, then you have staff privilages and powers, regardless of whether or not you choose to use them.

> > Maintenance: This is the essential staff role.
>
> Again, I don't define a host who may run the server on
> which the game is located (without any other connection to
> the game whatsoever) to be staff.

I'm not talking about owner of the literal machine, I'm talking about the person responsible for setting up and maintaining the mud - the owner of the mud. They are indeed staff, regardless of how you wish to view them. There is simply no getting away from the fact that they control the fate and future of the mud.

mann_jess, even the latest incarnation of Circlemud has bugs, whether it be the last version 3.1 or its successor TBA.

But lets just say for arguments sake, there is such a thing as a bug free codebase. Now, you say, there wont be any bugs introduced because there wont be any new code, however, you also suggest player created content. This content will be the source of new bugs that could cause the mud to crash. You are assuming all players could add content that is bug-free.

Even experienced builders crash muds. Our build port crashes constantly.

sm007h: even the latest incarnation of Circlemud has bugs

It goes without saying that new code will sometimes result in bugs. I'm talking about a codebase which does not have feature enhancements. CircleMUD is also developed as a hobby... professional codebases can be pretty stable.

sm007h: you also suggest player created content. This content will be the source of new bugs

I'm not talking about giving players the ability to code. I'm talking about letting them work within the confines of the codebase to craft things and affect the world. i.e. construct a house, put wallpaper on the walls, raise and train a pet, plant trees / grow a forest, build cities, discover new areas, write, craft, etc.

KaVir: but they're certainly not going to reimburse players or manually repair corrupted files, nor are they going to modify and recompile the mud source code if changes are needed to restart on new hardware.

Most professional business don't change their server hardware for this reason... it's not a given that hardware will eventually change (at least, not for a long time). Any reasonable host would also restore backups in the case of hd failure... there's no need for him to restore individual files for the game, or reimburse anyone.

KaVir: It's not that unusual to update servers, and updates can break things in subtle ways.

It depends on the business, but whether or not it's typical is irrelevant, since we're talking about a possibility. It would be possible to set up such a game on a server which did not get updated with new software. (Lots of servers don't, ya know)

KaVir: The former is a subset of the latter. If you own the mud, then you have staff privilages and powers, regardless of whether or not you choose to use them.

Semantics. Owning a paintbrush doesn't make me a painter, and being the technical "owner" of a MUD doesn't make me staff. You may define it that way, but that's not what I'm talking about.

KaVir: There is simply no getting away from the fact that they control the fate and future of the mud.

So does any country with enough nukes to blow up the continent. One's ability to end the game doesn't make them staff, nor does one's access, as a hacker isn't staff, nor does one's necessity, as the power company isn't either. Staff are people who take part in the administration and direction of the game, and these are the people I am asserting are technically unnecessary for a sufficiently advanced MUD.

This is pertinent (to me) since I believe such a system would be both elegant and enjoyable, and I believe the future of large scale MMOs lies with similar environments, since the administration of a sufficiently large playerbase is simply impossible.

Best of Luck,
-Jess

> I believe the future of large scale MMOs lies with
> similar environments, since the administration of
> a sufficiently large playerbase is simply impossible.

Not to be too ridiculous with the analogies, but the administration of large playerbases is demonstrably not impossible. It's called "real life" ;D.

Didn't one of the big MOOs (LambdaMOO?) try out a player-run model at one point? OK, from Wikipedia:

While most MOOs are run by administrative fiat, in summer of 1993 LambdaMOO implemented a petition/ballot mechanism, allowing the community to propose and vote on new policies and other administrative actions. A petition may be created by anyone eligible to participate in politics (those who have maintained accounts at the MOO for at least 30 days), can be signed by other players, and may then be submitted for administrative 'vetting'. Once vetted, the petition has a limited time to collect enough signatures to become valid and be made into a ballot. Ballots are subsequently voted on; those with a 66% approval rating are passed and will be implemented. This system suffered quite a lot of evolution and eventually passed into a state where wizards took back the power they'd passed into the hands of the people, but still maintain the ballot system as a way for the community to express its opinions. Noted LambdaMOO political pundit, Jaybird, has successfully moved for the banishment of arbitration in addition to ending the ballot process. Most of his supporters are vocal but are outnumbered by the entrenched electronic hegemony.

Now with regard to applications -- there are mudders (perhaps a vocal minority) who maintain that requiring applications is a good reason to avoid a mud, as a good application in no way predicts the quality of a player, and in may in fact be a better predictor of a bad player.

Not to be too ridiculous with the analogies, but the administration of large playerbases is demonstrably not impossible. It's called "real life" ;D.

Actually, "real life" is my example. You best be backin off my examples, homes ;)

Without getting into religion here, "real life" is only demonstrably ruled by the laws of physics and government which is run by the people. There isn't, like, some superman guy flying around the world flaunting his banhammer and smiting all the villains who dare breaketh his commandments. It's just the people (players) who make the world (game) what it is. Such a system could exist in a MUD.

As for the implementation you quoted:

...allowing the community to propose and vote on new policies and other administrative actions

This is nearly the opposite of what I'm proposing. In this system, the players partake in creating more rules and administration. I'm suggesting an elimination of it altogether. Basic rules of the codebase, along with player-run organizations would control the game. With enough encouragement from the code for positive social behavior, I believe this would result in an enjoyable (and definitely playable) atmosphere.

Best of Luck,
-Jess

(Comment added by mann_jess on Tue Aug 25 22:08:13 2009)

To be clear, this is a continuation of the interesting discussion. I'm tagging it so people can sift through the silly me/KaVir he said/she said nonsense.

To be fair, I did start the application argument, but the thread has jumped a page in postings since yesterday when I last looked, and I'm too lazy to read all of this nonsense. So, assume that the application argument on my side is dropped.

> > sm007h: even the latest incarnation of Circlemud has bugs
>
> It goes without saying that new code will sometimes result
> in bugs. I'm talking about a codebase which does not have
> feature enhancements.

And as I already pointed out: It doesn't matter, there will still be bugs. There will always be bugs. Who is going to fix them?

> CircleMUD is also developed as a hobby... professional
> codebases can be pretty stable.

It doesn't matter, there will still be bugs.

> I'm not talking about giving players the ability to code.
> I'm talking about letting them work within the confines of
> the codebase to craft things and affect the world.

The more flexibility you offer the players, the more potential there is for exploitation and abuse. This is challenging enough to deal with when you've got staff plugging the holes - without them, you're going to end up with an unplayable mess.

> > but they're certainly not going to reimburse players or
> > manually repair corrupted files, nor are they going to
> > modify and recompile the mud source code if changes are
> > needed to restart on new hardware.
>
> Most professional business don't change their server
> hardware for this reason...

There isn't always a choice. That's why professional businesses have IT staff.

> it's not a given that hardware will eventually change (at
> least, not for a long time).

Nor is it a given that it won't. But if it does, and there's no staff, the mud is dead.

> Any reasonable host would also restore backups in the case
> of hd failure...

You'd think so. But don't count on it.

> there's no need for him to restore individual files for
> the game, or reimburse anyone.

Yes, there are situations when such actions might prove necessary. And once again, if there are no staff, the mud is dead.

> > It's not that unusual to update servers, and updates can
> > break things in subtle ways.
>
> It depends on the business, but whether or not it's typical
> is irrelevant, since we're talking about a possibility.

It depends on many factors, including luck. And if you run your mud without staff, that's exactly what you're basing the future of your game on - luck. A power cut, a lightning strike, a hardware fault...splat. Goodbye mud.

Your argument seems to be "You can run a mud without staff, as long as no problems arise that require staff to deal with". Well, great, that's fine for theoretical situations - but it's completely impractical for any real world application, because there will always be issues that require staff.

You might as well apply the same argument to the bug-free scenario; it's possible to run a really buggy mud without it ever crashing (as long as nobody ever expoits the bugs). But people will exploit the bugs, I hear someone say? Ah! But it's theoretically possible that they won't!

> Didn't one of the big MOOs (LambdaMOO?) try out a player-run
> model at one point?

A few have, but (1) they've all failed, and (2) they only gave the illusion of democracy (the admin could take back power whenever they wished - as they did in the example you gave).

> Now with regard to applications -- there are mudders (perhaps
> a vocal minority) who maintain that requiring applications is
> a good reason to avoid a mud, as a good application in no way
> predicts the quality of a player, and in may in fact be a
> better predictor of a bad player.

Some players feel that "feature X" is bad, and is a good reason to avoid muds that have it, while others feel that "feature X" is great, and avoid muds that don't have it. Replace "feature X" with the feature of your choice, including (but certainly not limited to) character applications.

With enough encouragement from the code for positive social behavior, I believe this would result in an enjoyable (and definitely playable) atmosphere.

Unfortunately, code alone cannot encourage positive social behavior because it cannot identify positive social behavior. The methods we have of identifying positive social behavior use human analysis feeding coded systems, and in the absence of administrators those systems cannot tell a user engaging in positive social behavior from a user who enjoys the benefit of a support bloc or a bunch of sock puppets.

And as I already pointed out: It doesn't matter, there will still be bugs.

We've already discussed this. Why do you keep bringing it up?

You are asserting that a game will always have bugs to be fixed. I don't necessarily agree, but it doesn't matter even if I do. A game can run with bugs as long as they aren't game-breaking, and a codebase without game-breaking bugs is absolutely possible. There are absolutely perfectly stable complex applications in the real world.

without them, you're going to end up with an unplayable mess.

I disagree. You are asserting that it's impossible to create a game which, without administrative supervision, wouldn't devolve into chaos. I don't know why you feel this way, but it's demonstrably wrong. There may not be games with no staff, but there are games with almost no administration which run just fine. Further guiding from the codebase could eliminate some of that administrative need as well.

> Most professional business don't change their server hardware for this reason...

There isn't always a choice. That's why professional businesses have IT staff.

This isn't a response...... There are legitimate businesses which do not change their server hardware. I've worked for some. It happens. You can't assert that the game is impossible because "when the hardware changes..." if it isn't necessary to change hardware.

> it's not a given that hardware will eventually change (at least, not for a long time).

Nor is it a given that it won't. But if it does, and there's no staff, the mud is dead.

Also not a response. Even if I grant you that the game would eventually end, that doesn't mean it can't run and flourish for a long time without a staff before a disaster. Furthermore, just because hardware changes doesn't mean the MUD dies... most hardware changes won't require code changes, and can be handled by the server host. And again (not sure how many times I've said this), I'm not defining staff as the server host... I'm defining them as those who administrate and guide the game... maintenance (even of the game binaries) doesn't come into play.

> Any reasonable host would also restore backups in the case of hd failure...

You'd think so. But don't count on it.

...then get a better host?

No game can survive with a terrible host who is negligent of his duties. That's not an argument in anyone's favor.

> there's no need for him to restore individual files for the game, or reimburse anyone.

Yes, there are situations when such actions might prove necessary.

Like what? Give me an example of a situation where restoring hd backups (and performing other general hosting duties) would not suffice to restore the game to a playable state.

Your argument seems to be "You can run a mud without staff, as long as no problems arise that require staff to deal with".

No, it's not. You're just defining staff differently than me and ignoring me anytime I clarify my definition. Administrative duties inside a MUD can possibly be avoided with a sufficiently advanced codebase, leading to no in-game staff. From the players perspective, this means no staff. No gods ruling over things. No rules to break or be punished for. No admins to whine or suck up to. No staff. This doesn't mean the game isn't reliant on someone along the line (obviously!!!) It just means the game would be run, guided, and affected solely by the players.

The important part of this (as I've eluded to again and again) is that the people the game would be reliant on (electrical company, host, building maintenance, etc) would not need to scale with the playerbase. More players != more work. Not only would the environment be pretty cool, but this sort of thing would be necessary for a sufficiently large playerbase.

Best of Luck,
-Jess

Unfortunately, code alone cannot encourage positive social behavior because it cannot identify positive social behavior.

You're excluding the influence of other players.

Remember, this system would be modeled after the real world. In the real world, positive social behavior is encouraged for a number of reasons:
1) It allows one to build friends and establish positive connections which are helpful
2) Negative behaviors are shunned
3) Some more negative behaviors are illegal, and other people (players) enforce rules against them by force
4) Positive behavior allows one to grow at a generally faster rate than negative behavior

Of course, some negative behaviors would develop. This is unavoidable (even with administration, mind you). I would contend that some negative behavior would be acceptable, and even create a diversity and realism which would ultimately be positive.

For example, the development of tyrannical governments would be bad in the short term, but players organizing themselves to overthrow such a government could be enjoyable.

The ultimate goal of such a codebase would not be to limit negative behaviors insomuch as to ensure freedom and limit oppressiveness. For example, player might be mugged, but it should always be within his ability to either protect himself, or to leave a particularly dangerous area. This is something we can enforce by code, simply by way of implementing benefits to group interaction, and not implementing ways of enslavement. By doing so, we've intrinsically created a system that encourages governments intent on protecting their citizens, and which disallows forced oppression which would prevent a citizen from choosing a better government (or none at all).

When positive governments develop, a law should develop which is most beneficial to the enjoyment of every player (because if it doesn't, players will naturally choose to form one which is).

Best of Luck,
-Jess

(Comment added by mann_jess on Tue Aug 25 22:09:05 2009)

To be clear, this is a continuation of the interesting discussion. I'm tagging it so people can sift through the silly me/KaVir he said/she said nonsense.

You're excluding the influence of other players.

I'm not excluding it so much as convinced that it can, and therefore will, be thoroughly subverted. Most readily, by the massive sock puppet farms that are, I'm afraid, not going to be identified and counteracted without staff.