Re: client server part 1

[Mark Wedel <>]

 I don't see how relative vs. absolute coordinates make secret
doors any more or less visible.

 Sending data of when the player changes a map can give clues
that they otherwise would not have.  Like the
world maps, for example.  all the world_?? maps should be
considered just one very large map., and the player should not know when he went
off the edge of one
and onto another.

Also, for the client to buffer any data is inherently dangerous.  This
certainly gives the player clues, or makes things much more difficult
on both ends.

Example:  Take an earthwall.  When the player leaves a map, it is at
full strength, and they player should have no idea that there is
an earthwall there.  Now suppose something else damages.  Either you
now need to re-send only the earthwall images when the player
re-enters (also checking to what strength they are at compared to when
the player left), or initiallize, you need to send the client the fact
that the earthwall is not something that should be saved.

In either case, in many cases, the client could display something to
the player that that in fact is not a normal wall (may not know it is
an earthwall, but certainly knows it is not somethign normal.)

Also, saving map data makes things more difficult for the client.
What happens if the player leaves the starting city, never to
return to that city for 8 hours of his playing?  Do you start adding
timeouts and stuff for the map portions that the client saves?

With the above reasons, I don't see a lot of reason why map data
should be saved on the client ends when the player changes a map.

Relative Vs absolute coordinates:
Thinking this ove some more, I am not sure how much a gain relative
coordinates over absolute is.

Where you gain in relative is when the map is mostly unchanged. But here
is a basic example:

Start in the starting city, on the road just below the mage shop.  Now
move to the right.

 In this situation, there is some blacked out rows.  But when you do
that move, a lot of data changes.  The side wall (to the left) is
now 2 over instead of 1.  All the shops above are now in a new
place, and even the building below the player are now changed.
About the only thing unchanged is the 2 roads and the small houses.
As a rough count, on the map that is visible, 20+ spaces now have
changed faces for that move.  And of course, some of the spaces have
several images that would need to be sent if the player is using
XPM mode.

Now take absolute coordinate.  Only the row that appears need to
be sent (9 spaces).  Worst case for normal movement would be 21
spaces (when moving diagonal.)  When changing map, however, the entire
map would need to be resent.

However, even with relative coordinates, many map changes would still
require the entire map to be resent (enter the gatehouse from the
city or outside.)  The example given where relative is a major gain
over absolute is the world_?? maps.  But maps where the two meet
seamlessly like this are very rare.

I suppose if you add something like SHIFT_MAP for relative, the old
data could be preserved, but in this case, you still need to send
the new squares that appear.

So I am not quite as sure if relative vs. absolute coordinates is
quite as much as a gain (or any gain) compared to relative.

Sending the entire map each time is not an option - at least not if
you want to be able to play on low bandwidth connections with
decent graphics (XPM with several images per square.)

Server output buffer:  IF we assume that our goal is to allow
people to play over low speed links (say 28.8 modems, which is about 3K/sec),
then if the 32K buffer fills up, that means that the player lost about
10 seconds of play time (sure, some of that space might be filled up
by REQUESTS or whatever, but that is a lot.)

And if it is a situation where there are several area of effect
spells going off, the player might very well be dead.

32K was actually a number that I chose arbitrary.  I believe this
buffer can be set to any size (but the man page on the command that
does it says that the OS may impose some maximum limit.)

It is much easier programming to give a big buffer - big enough that
if it overflows, the connection is deamed to slow.

However, one thing that does need to be decided is what to do to the player
when the connection is lost (not necessary by buffer overflow - perhaps
the player just hit ^C on his client.)  Do you kill the player (pretty
harsh), or save the player where he is (which could have advantages - if
you know you are going to die soon by some monster, kill the client,
server saves character, and you come back later with reinforcements.)

The decision on this can also help influence what to do on buffer 
overflows.  If the player just gets saved, dropping the connection
when the buffer overflows may not be too bad - player can come back
in 10 minutes when there is less congestion or whatever reason caused
the connection to fill up, and resume where he left off.  However,
if the player is killed, then you probably do want to try and keep
teh connection no matter what.

--Mark