[MUD-Dev] Thoughts on a simplified multiplayer game.

[Edward Glowacki]

J C Lawrence wrote:

> While this is the common wisdom, its wearing thin.  There are
> several useful levels above UDP's lack of guarantees, before
> reaching full TCP behaviour which are useful.  For example a layer
> atop UDP which guarantees order of delivery while not guaranteeing
> delivery can be useful for delta/mark based update messages.
 
> Have a look at ENet.

But in a MUD scenario, with each packet as a command (per the
original post), you need guaranteed delivery as well.  You can't
exactly have your "quaff healing potion" commands falling off the
face of the earth...  I'll cede the point that there may be other
options between UDP and TCP that might be viable for this particular
application, but hold onto my suggestion of TCP for simplicity
(i.e. it's ubiquitous, and doesn't require additional libraries to
be installed or distributed with the client), since the original
poster was big on simplicity.

>> It doesn't really cost anything to hold on to some TCP
>> connections on the server side...

> It does when you are dealing with large numbers of connections (I
> start thinking hard as soon as I got into or past 1,000), and
> while the curve is not exponential, its certainly not flat.  For a
> reasonable (slightly dated) discussion see Dan Kegel's C10K page
> as well as the archives of this list (there' been a good bit of
> discussion of the area here).
 
So I guess it ultimately depends on how many simultaneous clients
he's planning on having, and how soon he wants to move out of the
"simple" phase into the "somewhat more complex" phase.  I can see
your point though.

>> One of the great features of a text MUD is its text interface,
>> i.e. the keyboard, which can be very efficient.  When you start
>> switching to the mouse, you lose efficiency
>> (keyboard-to-mouse-and-back is an expensive operation
>> time-wise...).

> There's some common wisdom here regarding keyboard speed versus
> mouse which is simply false in lab tests.  Read up on Tog:
 
>   http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
 
I hadn't read that particular bit by Tog, but I have read some of
his other stuff.

I wasn't trying to argue that the mouse was inefficient, just that
depending on what you're doing, the keyboard *can* be extremely
efficient, and that switching between keyboard and mouse *will*
cause some delay.  Whether or not that delay is required is another
story that depends on how well the whole user interface is designed.

In a traditional MUD, where commands are all done by keyboard and
the display is entirely serial, there really isn't much to do for
the interface design: organize and format the text for basic
readability and setup the commands to reduce the number of
keystrokes.  So MUD interface efficiency is a fairly known quantity
(excepting GUI mud clients, ala zMUD, etc.).  Once you start making
the jump from text to graphical, the issue gets a lot more difficult
and complicated very quickly.  GUI design is *hard* to do *well*.  I
would rate most software GUI's out there to be mediocre at best, and
even most commercial products don't get it quite right.

Somewhere in there I think I lost track of what I was arguing
about... =P Maybe it had something to do with being a text mud vs a
graphical mud, doing one right vs. doing both poorly, and to be
careful with how you ride the line down the middle...

-ED




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