Re: client server part 1

[Tero Kivinen <>]

Mark Wedel writes:
>  I don't see how relative vs. absolute coordinates make secret
> doors any more or less visible.

   0  1  2  3  4  ...
  +--+--+--+--+--+
0 |WW|WW|WW|WW|WW|
  +--+--+--+--+--+
1 |WW|  |  |  |WW|
  +--+--+--+--+--+
2 |WW|  |pp|  |WW|
  +--+--+--+--+--+
3 |WW|  |  |  |WW|
  +--+--+--+--+--+
4 |WW|WW|WW|WW|WW|
  +--+--+--+--+--+
.
.
.

'WW' = wall, '  ' = floor, 'pp' = player

Player can obviously see that the north and west walls cannot have
false walls leading to another parts of the map. Similarly if the
smallist x or y cordinate seen by the client is about 30 player can
assume there must be something he/she haven't found. This is not
possible if using relative coordinates.

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

The world map is one map, even if it is split to separate small maps
for technical reasons there is no reason it should be taken as separate
maps when shown to client.

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

The one thing I always liked in doom and other new pc-dungeon games is
the automapper, and I think such thing should be possible in
crossfire too. At least it should be made possible. 

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

No, the server don't know if the client is storing map information, it
will send the information about map as usual, and the client will show
them in color showing they are actual data. All stored information
could be show as grayscale ghost images so the player can see the
overall structure of the map, not the current status. So if player
cannot see the earthwall it is shown in the state that he last saw it
(but in grayscale, so the player can see it's not active data only
memories) and when it comes visible to player the server sends the
information about the object and client redraws it in color in its
current state. Or the client can generate small map in the side
showing what the character remembers from the earlier visits in the
place (like magic mapping or the small map in xpilot).

[Note all this above is only examples, client can use other methods to
show stored information, and the first clients probably don't even
think implementing this].

Because there is no way client can save this information to the server
so if player wants it stay to next session he/she saves information
locally.

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

If the player have been in the room already, he/she probably remembers
there is earthwall somewhere, so this only helps, so you don't have to
draw your own maps of things, because the computer does it for you. 

> 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?

Its all up to the client. Server don't know if the client is storing
information and it don't assume that client have stored any
information, so client can throw away stuff as it likes. 

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

This is what I assumed to be used, so the map is shifted just like in
the absolute coordinates, but we don't give player the information
about real coordinates. 

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

True, but because player can still give commands, he/she can run away
(although he/she cannot see where he is running) as soon as he/she
sees those 5 real dragons and 5 chinese dragons... I think it is still
better to reset the state skip some updates than slow down other
players or close the connection.

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

Perhaps it could be adjusted by protocol, so players who are playing
over slow link could lower it so they will skip updates more often but
then they will loose only few updates.

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

If the buffer is 1MB then the dragons have already killed the player
30 seconds before player even can see he/she is taking some real
damage. There is no way he/she can run away then (if he/she starts
running away when he/she sees the effect there still exists lots of
updates in the buffer probably killing hime before he/she can even
move a inch). 

For slow links its much better to use as small buffer as possible and
if it fills up skip some updates and send the most resent information
to the player than tell the player what happened 10 seconds ago. 

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

Arrest that character and put it to prison and require some other
character to pay ransom to free the character. Perhaps the character
should be left to the place where he/she ware when the connection
closed for 10 seconds before guard comes and arrests character. This
way if the player press ^C on purpose before dying he/she probably
will still be dead before the 10 seconds are over. I think this
penalty time will come almost automatically if the connection breaks
down because it usually takes some time to notice that connection is
broken and the world still keeps going.

Perhaps there should be some safeguard so if several player drop
simultaneouslu then the penalties/ransom is much lower or even
removed. 
-- 
              	     Work : +358-0-451 4032
Magnus Enckellin kuja 9 K 19, 02610, Espoo   Home : +358-0-502 1573