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

[J C Lawrence]

On 21 May 2003 11:09:05 -0400 
Edward Glowacki <glowack2 at msu.edu> wrote:

> I don't buy this argument.  UDP is an unreliable protocol, so you're
> never *guaranteed* that what you send will be received, or in what
> order.  Something like "lite fuse, drop bomb, move east" might end up
> as "move east, like fuse, (drop bomb command lost in transit)".  Boom.
> By the time you make sure commands arrive, and do so in order, you've
> re-implemented TCP and destroyed your simplicity.  

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.

> 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).

> ... and (as you mentioned) it does make it a lot easier for people
> with firewalls to use TCP.

Actually the problem isn't with firewalls per se, its with NAT devices.
Specifically the problem is with establishing a connection between two
devices, both of which are behind NAT devices.  TCP vs UDP doesn't
really change or affect this problem at all.  The problem is that NAT
devices establish the port pair relationships by noticing packets
*outbound* through the device, and if both sides are behind NAT, both
sides can't create outbound connections...

> In order for this to work, an "action" will need to be some sort of
> function, which brings up the question of how to associate functions
> with game objects.  Back to object-oriented...

Poking about the various Tiny-* derived server models (I'd start with
COOLMUD as previously stated) is probably a good idea.  Minimally have a
look at one of the Tiny-* clan, MOO, and Cold.


> 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

> If you're looking for a large audience of content creators, then
> you'll want to build the content creation interface with as much
> polish as your game interface.  For any interface, make sure you
> understand the goals your users are trying to reach and try to make
> the interface streamline the path to get there.  The KISS philosophy
> you've been describing for the rest of your game should work
> especially well here.

Its also worth looking at those systems which have fostered the most
user content creation.  Tiny-* clan servers with MOO being the most
notable, LP, and in the commercial world things like AlphaWorld and
SecondLife (which later seems more interesting than There).

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

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