Re: A few thoughts on client/server in multi-player games

["Carl Edman" <>]

Philip Brown <> writes:
> >>>>[From Carl Edman]
>     1.  Do all possible processing on the client. ...
>     

>     2.  In an ideal world this would mean doing all LOS calculations
>     on the   client (as a matter of fact, that is what my last
>     prototype did). ...  So LOS has to be done on the server.
> 

> 

> But that directly contradicts the idea behind #1, which is to reduce
> load on the server.

Exactly.  That is why I listed them one after another -- to indicate  
that while in general as much processing as possible should be shifted  
to the client, both for performance reasons and to give more  
flexibility in client design, LOS is an exception.

> Let me remind you that currently line-of-sight processing is BUGGY
> as-is. it will require more processing than it now uses. kinda
> backwards to our goals.

I've found the current algorithm to work well in most circumstances so  
I don't see any pressing need to replace it with something more CPU  
intensive, but if you say it has to be done, I can dig out a couple of  
conversations I had a few years back on the net and in email about fast  
table-driven LOS algorithms needed for my project at the time.  I  
recall that it was fast enough to allow four or five players on one of  
the really slow machines of the day.  Considering that todays typical  
servers are on average about ten times faster, fourty or fifty players  
shouldn't be a problem with it.  And if that isn't enough, we can start  
to actually optimize the algorithm.

> It just means that people will ahve to define maps with challenges
> that don't require something as simple as not being able to see the
> entire map.
>
> After all, there ARE scrolls of magic mapping, are there not? It's
> still pretty silly to design a challenge that can be nullified by one
> single game item, let alone cheating.

Magic mapping is really pretty limited compared to downloading the  
entire map and having the client do the LOS calculations.  Magic maps  
give a rough idea of the shape of the dungeon and are today already  
blocked in all situations where they would be _really_ useful.   
Downloading the map to the client and trusting the honesty of its  
programmer tells the player the exact location and idenity of every  
single treasure and (by inference) the location of every single hidden  
door.  Furthermore it also requires constantly updating the location of  
every moving monster in the entire map.  


In that regard doing LOS on the server is actually a positive virtue  
for us with the low speed links as it saves us a lot of traffic both  
whenever we enter a map and when any monster we can't see moves.  That  
is positively a win for players who travel, only moving a couple of  
squares in every map before entering the next one.  In the maps which  
players spend a lot of time totally exploring them, server-side LOS may  
break even in total bandwidth consumed.  However the data will not all  
be transferred at once when entering the map (which leads to  
player-noticeable delays).  Instead it trickles in all the time while  
playing at a relatively low rate.  That is a far preferable situation.

In any case, I still think regardless of the above server-side LOS is  
essential to prevent cheating.  If you don't, Greshams Law applies:   
Dishonest clients drive out honest clients.  In effect, you'll have  
eliminated LOS from crossfire.  Now whether that is either a) a good  
idea anyway or b) worth doing for the possible simplification of  
client/server is debatable.  But if we decide to do that, please let's  
do so explicitly.  It will save us a lot of hard programming and angry  
accusations later.

>     The server should always refer to pictures and sounds by   name
>     (or possibly persistent unique integers).  For example, it might 

>     send the command 'disp 15 -34 vampire' to tell the client that
>     the   player sees a vampire a coordinate (15,-34).....
> 

> Again, that goes against the previously brought up issue. using ascii
> is too verbose for the 14.4kbps SLIP model. Only viable method is
> constant predefined integer indexes.  Direct, binary, 16-bit integer,
> I might add.
>
> FOr byteorder, you just have to specify for your client at compile
> time. It will then have to switch byte-order if needed.  This is
> trivial integer math that takes comparatively zero time.

I've written and posted a long article dealing with these issues in  
detail, though you may not have had a chance to read it before  
responding to this article.  If you do read it and still disagree,  
please let me know.

	Carl Edman