Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

    
    5.  Remember that an increasingly large part of the net is connected  
    with relatively low bandwidth such as 57.6 kBps leased lines or even  
    14.4 kBps SLIP lines.

True. I'm one of those people. ALthough I find response is better through
"term" instead of SLIP.

    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.