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

Re: client server part 1




Ok.  I can see the point about knowing that secret doors can not
exist if you are near the top or left of the map.  But this does not
give away secret door locations.

There is a big difference between knowing where a secret door is, and
knowing that there can not be a secret door.

 However, if this is a major concern, what could then be done is that
for each map in memory, a random offset is generated.  This way, the
player never knows for sure if he is at an top or left edge. (and
initially, this offset would be 0 to make debugging easier.)

Note, however, that many maps right now are not fully contained by
walls, and instead just have the blackness at the edge.  In these cases,
once the player finds this blackness on the left or top edge, he now
knows that some areas can not have secret doors.  This is perhaps a bug
in the map, but a lot of maps have this bug.  And magic mapping will
typically give some idea where doors can then be.

IMO, knowing where secret doors can not be is not a major gain.
Especially since the player may have direct access to many of the
maps, and could just load them up in the editor and see what is
where.

Client keeping data:
Sure - the client to do automapping or keep old data to let the
player zoom around in.  My impression on reading the previous message
was that the client would keep this data so that the server would
not need to resend.

The client can pretty much do whatever it wants with the map data
it receives.  If it wants to automap, or keep all of it, or change the
image for it, fine.  In fact, if 3D mode happens (which people seem
to want to do), the client could just have 1 type of wall and floor
look to start out with - it shouldn't give anything away (except not
looking as nice), and it would reduce the number of images that need
to get converted to 3D by a large number.


SHIFT_MAP:  One of the early messages I read suggested that relative
coordinates should be used because then not as much stuff needs to be
updated (each frame, what has changed relative to the square the player
is on gets sent.)  Thus, if you had something like (just using
generic codes, with the 123456 and ABC referances for the squares):

  123456
A fhhbgh
B gggpgg
C wwawta

And moved right, so it is now:
  123456
A hhbghh
B ggpggp
C wawtat

Then A1, A3, A4, A5, B3, B4, B6, C2, C3, C4, C5, C6 would then be
updated (only squares that changed their view.)

 What you are stating is different than the original idea I saw posted.

 I do think that absolute coordinates is more robust if you are going
over a nonreliable channel (which has been suggested for the future.)
With relative coordinates, missing one packet (the one that contains
the SHIFT_MAP) would mean that the entire map is suspect, and needs to
be retransmitted.  With absolute, a few squares don't get sent, and the
client may recognize this, and request those squares get resent.

 In any case, the first good reason to go to relative was because it
might save bandwidth (without the SHIFT_MAP operator.)  That is true
in some cases, false in others.  I think it still makes debugging a bit
harder.

Also, to reduce loss when changing between world maps, what could
pretty easily be done is add a field to the map structure which
contains an offset to use.  So if each of the world maps are 40x40,
then the map below the top left map would have an y offset of 40.  In
this way, the coordinates would changing maps would not change.

Output buffer:  It always needs to be large enough so that certain requests
or transmits do not overflow the buffer.  I beleive the default was 4K,
and I found that the data the the I_REQUEST protocols returned would
overflow this buffer.  So you need at least a large enough buffer so that
even trivial things don't overflow it (the I_REQUEST are optional
commands that can be issued.)

The biggest problem with a penalty for connection dropping is to make it so
players don't do intentionally, but at the same time, the player does not
get totally messed over for drops beyond his control (power goes out,
line gets cut, etc.)

Probably what will happen is there will be several categories, of
which one is chosen in the config.h file.  Some sites may want harsh
punishment, others not care that much.

 --Mark