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

[Mark Wedel <>]

 I don't think all images and sounds should be referred to by name
when the client is actually playing.

 Doing some handshaking at startup to agree on integer values for each
image/sound to use when the game is running seems like a very reasonable
and fast way to do it.  Whether these integers are passed as binary
values (probably 2 bytes), or ascci characters (probably 4 characters, but
could be 5 some day) might be less relevant.

 I personally don't see the need of the client to be extremly efficient
in how it sends to the server as really important.  I doubt the client
will be sending a lot of data.  However, how the server sends to the
client is much more important.  But it also depends on what information
the client knows.

 For example, if the client knows about the entire map, either all that
stuff needs to be stored on the client end (which would be really
unsecure, and not especially feasible for those sites that add new
archetypes and maps), or that information needs to be sent down the
wire.  Depending on many factors, sending an entire map with various
object information may not be any better than sending small pieces as
required.

 I've actually run some crossfire (albeit single player) with profiling
information, and the big cpu hog is the process_events function
(I have since split the player portions away from it, but haven't played
enough to see how that changes things).  That function consumes about
half of the total cpu time of crossfire.

 Beyond that, there is no single function in crossfire that consumes
 a lot of cpu time.  get_ob_diff actually consumes a fair amount
(about 25% of what process events does).  get_variable and draw_color_pix
both consume about the same amount, which is about 1/12'th of what
process_events does.

 Actually, here is a portion of the information:

granularity: each sample hit covers 2 byte(s) for 0.00% of 662.78 seconds

   %  cumulative    self              self    total
 time   seconds   seconds    calls  ms/call  ms/call name
 38.9     257.66   257.66    10671    24.15    31.31  _process_events [3]
 11.3     332.36    74.70    38211     1.95     2.23  _get_ob_diff [10]
 10.0     398.96    66.60                            mcount (841)
  3.1     419.61    20.65   184745     0.11     0.18  _get_variable [18]
  2.9     438.75    19.14    10738     1.78     1.78  _draw_color_pix [21]
  2.3     453.90    15.15   305860     0.05     0.05  _update_position [24]
  1.6     464.32    10.42     3975     2.62     2.92  _expand_sight [28]
  1.5     474.31     9.99    21841     0.46     0.46  _write [31]
  1.4     483.37     9.06   326905     0.03     0.03  _memccpy [34]
  1.3     492.29     8.92    33467     0.27     0.27  _read [35]
  1.2     500.33     8.04                            _ParsePixels [36]
  1.2     508.33     8.00    29376     0.27     0.27  _select [37]
  1.1     515.72     7.39   184745     0.04     0.31  _set_variable [15]
  1.1     522.82     7.10   193145     0.04     0.04  _hashstr [40]
  1.0     529.42     6.60   288059     0.02     0.05  _fgets [26]


 Not all that many of these functions will ever be in the client.
draw_color_pix definately will be.  But beyond that, it is hard to say.

 As such, I am not sure how much difference it will make for the client
to be doing a lot of work, especially if it is not really secure to do
so, or makes things more complicated.

 These values will vary from system to system.  The general usage of
how much each function uses is pretty consitent run to run on my system.

 Having multiple players may shift it some, but if they are on different
maps, probably not that much (as there will just be more objects).

 --Mark