MOO-cows Mailing List Archive
I've seen this subject or varients of it come up relatively often, most
recently as the message that started the `long live pavel' thread.
There are at least four fairly significant problems with writing
character mode applications in the server:
The LambdaMOO server originally handled only line-oriented input. The
network buffering and I/O builtin functions are all designed with this
in mind. Interactive character oriented applications typically
involve considerably more network traffic than line oriented ones.
Making your MOO's interface character oriented rather than line
oriented at the server therefore puts a bigger load on your MOO and
slows things down. Finally, latency over a typical WAN is not what
you want for response time in interactive applications.
The scheduler was presumably written with the existing command model
in mind. Each command invokes one or more tasks which then run to
completion. The more tasks, seconds, and ticks a task queue uses, the lower
the overall priority that task queue has. This means your character
application gets slower and slower over time, since it has to be
doing all of its own I/O since it can't afford to have its lines
broken up or wait around for the user to hit enter.
There is plenty of infrastructure for writing line oriented
applications in the MOO and none for writing character mode apps.
Finally, a lot of work was done to make the /etc/termcap system and
related cruft so users of UNIX programs that expect to talk to a
terminal work. You would have to duplicate a large portion of this code, and face the additionally possibility that your user is not even using a character mode client. Otherwise you face this situation:
^134^124^1425[124ms4[13[34Welcome to cursesMOO
(lots more VT100 spam)
>connect Ken foobar
Login: connect Ken foobar
>connect Ken foobar
Password: connect Ken foobar
*** Disconnected ***
For these reasons, it is impractical to write character mode
applications to be served by a typical MOO server. If you do this,
you will take a significant speed and response time hit.
A far better solution is to write or use an existing MOO-specific or
general purpose MUD client and customize it for your application.
There are plenty of clients including several that support local verb
and description editing.
There are lots of clients, including some for Macs and Windows
machines and some that use vt100 interfaces (for curses fans), listed
in the current rec.games.mud FAQ part 2
(http://www.math.okstate/~jds/mudfaq-p2.html). Making a client do all
the work it can is a good thing because it distributes the load and
enables better and more responsive interfaces.
Ken Fox, firstname.lastname@example.org CCS, Northeastern University, Boston, MA
Subject Index |