[MUD-Dev] Re: WIRED: Kilers have more fun

Caliban Tiresias Darklock caliban at darklock.com
Tue Jul 21 21:16:48 CEST 1998


On 07:18 PM 7/21/98 -0500, I personally witnessed Dr. Cat jumping up to say:
>
>Movies started out by putting stage plays on in front of a movie camera 
>and recording them.  TV started out by taking popular radio shows, and 
>pointing TV cameras at the people so you could see them.  But eventually 
>people figured out what the new medium itself was, what its strength 
>were, what would "play well" there.

Something that wasn't really touched on here is that MUDs not only attempt
to reproduce RL (which is a relatively modern concept, the majority of MUD
developers in the early days knowing full well that to do so was patently
impossible using their technology), but even more often they attempt to
reproduce other games. The initial crop of MUDs was almost entirely
composed of people who wanted to play D&D online. Currently, we have *how*
many THOUSAND MUDs which are running some sort of World of Darkness setting? 

I think it's rather interesting that the MUD genre is sort of an imitation
of an imitation, with its own specific strengths and weaknesses (compare
Dikus, where the staff primarily build areas and write code, to modern WoD
games... where the staff primarily arbitrate disputes between characters
and/or players). The Doc's point, of course, was that online games have
their own strengths and weaknesses, and that we should look at what and
where those strengths and weaknesses are. There seems to be a lot of
discussion on this list of how to *overcome* the difficulties of the genre,
but little to no discussion of how to make it possible for the players and
staff to ignore these difficulties entirely. 
Something I've said on several occasions which seems to fit here is if you
try to make your game look and feel and act just like real life, you teach
the players to *expect* that. Eventually, they hit a minor problem in the
code, and they crucify you for it -- instead of being impressed at the
power of what you've done, they're annoyed that your creation isn't
perfect. This makes you feel unappreciated, and teaches them to expect
incredible and almost-impossible things from you on a regular basis. This
doesn't help anyone. I have a personal belief about how this can be
rectified, but it sounds really cheesy and rude. 

Basically, I think a game should be overly simplified, and that when you
first put it up it should have BIG problems. Then you teach your players to
expect a carefully balanced half-finished construction that falls apart if
you breathe hard on it, and when you brace and support it a little better
(say, by fixing the 'random socket disconnection' bug) they'll appreciate
that. When the system is running smoothly and the code is relatively
bug-free, those who complain about system X not working right will be
immediately beaten into submission by the older players who remember when
you had to enter all of your commands in Sanskrit (using a three-letter
keyboard) and manually code your intended actions (in APL... backwards). 

I know, it sounds manipulative and unethical, but I really do think it's a
workable social solution. Look at all the people who are still playing
Dikus. Complain about any part of the server, and they jump all over you.
"You ingrate! How dare you! Don't you remember when this whole MUD only had
one exit, and the only way to move was to wait until the exit got to the
room you were in and just hope it went someplace you wanted to go?! Why,
when *I* was your age, I walked FIVE MILES to get to an internet terminal
just so I could log onto this game, and there was only ONE command, and it
was 'quit'!"


Of course, if anyone quotes me on it to any of my players, I'll deny
saying it until they bring me a copy of the e-mail, at which point I'll
pretend to remember it and say it was just a joke. And who knows? Maybe it
is. ;)

But let me get to the point here. The thing computers do best, in my
opinion, is numbers, text output, and repetitive activity. They're not
generally too good at real-time AI, but turn-based AI works pretty damn
well. (Compare the computer opponents in Quake to the computer opponents in
a chess program.) What I'm looking at is going back to the same concepts
and ideas that we were using ten years ago, and just using more of them.
I've been thinking about faking real time activity by counting commands;
for example, if there are thirty players online, the AI kicks in and makes
a move every thirty commands. As the game progresses, the AI will keep pace
with the players, although the more active players will still be ahead and
the less active players will still be behind. I'm anticipating having a
text-based command interface which in turn is optionally operated from a
graphic terminal program that lets the user use menus and buttons to go
about his business; the graphic terminal would send text commands, so users
who didn't like the graphic program could log on through flat telnet or use
TF or whatever. I'm thinking about having some sort of in-game 'punishment'
for killing players, but nothing the average player wouldn't be able to
overcome on occasion (as opposed to being able to race around and kill
everyone else with impunity). 

An awful lot of people are building graphic MUDs, but an awful lot of folks
still play text, and it doesn't seem like that many of them are *playing*
the graphical MUDs. Most people I know who play graphical MUDs do so on
rare occasions, not as a constant thing. Most people I know who play the
text MUDs (including myself) do so for WAY too many hours out of the day,
every day. So I tend to be of the opinion that my system should be text
based, since people playing for an hour here and an hour there is all well
and good... but I'd really like people to be addicted as hell and playing
all day every day. :)







More information about the mud-dev-archive mailing list