[MUD-Dev] Games vs. simulations

[Caliban Tiresias Darklock]

Dmitri Zagidulin wrote:
> 
> Not to spark a holy war, but can anyone explain to a newcomer why non-room
> systems (read some kind of coordinate systems) are a bad idea?
> They seem like a good holy grail to me...

Personally, I feel that the room-based system has very few real
problems. For interior areas, rooms are a natural division, and only
really cause problems when people use odd features of the room system to
do weird things. For example, in most MUDs you can have a room which is
of very large size -- but in which everyone can hear everyone else. This
would be like going to a party and hearing every conversation with
crystal clarity. That just plain doesn't happen. Coordinate systems,
however, allow the room to have actual SIZE, so while you may know that
someone halfway across the room is talking, you can't hear them
clearly... and someone on the other end of the great hall can't be heard
at all. 

This is normally solved by having a great hall or the like consist of
three rooms, each of which can "hear" the adjacent rooms. MUSHes often
have "mutter code", which can be used to partially obscure conversation
too far distant to be clearly heard. Unfortunately, these sorts of
features are voluntary, and few users/builders really make use of them.
The open building environment lends itself far too well to abuses, but
there again you have a large benefit: when anyone can build, you get a
lot of amateur builders who create pretty neat stuff. This, in turn,
inspires your staff builders and also allows you to target talented
individuals for addition to the staff. In the open building environment
of a MUSH, you will often find areas which are built by committee: three
or four players will get together, with one of them creating the
fundamental structure of the building while another constructs the
descriptions and a third adds the complexities of MUSHcode to achieve
the desired in-game results. This sort of collaboration is rather
difficult in a MUD environment.

I've always thought a MUD should run on three ports, for that reason.
One port should be for players; one for staff, who are invisible to the
normal players and have access to added commands and functionality; and
one for builders, who are much like staff but have a different set of
commands. All of them work on the same database, in real time, but staff
and builder ports have the added security layer of a "commit" command --
which makes their changes visible and accessible to the playerbase at
large. Most importantly, the "player" command set remains accessible at
all times, so areas and code can be effectively tested, but no login
over the player port can access the staff or builder commands --
addressing both the concerns over players "hacking" staff commands, and
staff "cheating" with them while playing the game.

> If so, do you think it's really possible to do expansive terrain (lakes,
> fields, wilderness in general, seas, planets) using the myopic room-based
> system?

Not really. Expansive terrain -- which comprises a lot of the "action"
areas of a traditional MUD, of course -- doesn't lend itself well to
rooms. Dungeons and castles, however, do. It would be interesting to see
a hybrid system, in which rooms were imposed over coordinate systems --
basically making slight modifications to the normal coordinate setup.

I think MUD developers face a threefold challenge when designing such a
system. On the one hand, it must be efficient to handle vast numbers of
players; on the other, it must be easy to build in so the builders can
effectively create interesting areas. And over top of it all, it must be
easy to *use*, so the players don't become frustrated or bored. Not an
easy proposition.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev