[CF-Devel] 25 by 25 instead of 11 by 11 map

[Mark Wedel]

On Thu, 24 May 2001, Peter Mardahl wrote:

>
     
     
     >
     
      Hello,
     
     >
     
     
     >
     
        Yes, this is interesting in general.  It's nice to have someone
     
     >
     
      hacking on things independently.
     
     >
     
     
     >
     
        We did a poll recently, and it seems people would indeed like
     
     >
     
      a larger display...
     
     >
     
     
     >
     
        We thought it'd be easier to do it this way though:
     
     >
     
      increase the viewable size to "NxN", but have the server only
     
     >
     
      keep "up to date" 11x11.  The client would be responsible for
     
     >
     
      remembering and mapping outside that 11x11, and would add
     
     >
     
      grayness to things it didn't have current data on, a "fog of war"
     
     >
     
      type of effect.
     
     
 This gets pretty tricky to do properly.  Things like teleporters taht just
move you a few spaces will make such a system unusable.  I'd have to
double check, but I don't think it is easy to know when the player has
moved a space - there is the scrollmap protocol commands, but I don't
think they are used in all cases (ie, if player gets pushed, is on top of
a gate that moves them, or is on a player mover, I'm not sure if those
cases use that).

 In either case, I was thinking of optimizing that for bandwidth - compare
the price of doing a scroll and update vs just sending a new frame.  If
in combat, probably cheaper to skip the scroll as the monsters and spells
will make most of the old frame useless anyways.


>
     
        That would give more viewable area without increasing the
     
     >
     
      bandwidth overhead at all, and has the further advantage of
     
     >
     
      being mostly backward compatible, and would require very little
     
     >
     
      change to the server.
     
     
 As said in another message, ideally, the client can negotiate on size
of map it gets sent.  There should also be some other optimizations it
can negotiate, like how many objects to send per space (on low bandwdith,
you maybe only want the top one)


>
     
        Also, it would allow the client to do 30x30 (or NxN) if he had
     
     >
     
      screen space for it.
     
     
 That is true. Of course, even if the server sends say a 25x25 map, there is
still nothing preventing the client from trying to cache more than that.

 One of the worries I have about client caching is if it becomes a
'advertised feature', new players will try it out and pretty quickly complain
that the stored data is completely bogus.


>
     
     
     >
     
        Would you be interested in doing that?  It's significantly more
     
     >
     
      coding than you have already done, but it has its advantages.
     
     
 As said above, doing one does not preclude the other.  But obviously,
if the server supports a 25x25 viewable map, the need for caching is much
less.

>
     
     
     >
     
        If not, then we may simply (after some democratic process)
     
     >
     
      adopt your patches regardless.
     
     
 I'm going to take a look at the code regardless.  As said, ideally
this will become a config issue, so server admins and players can do what
they want.  If a server admin wants a 'classic map size', then they just
set those defines to 11x11.

 Bandwidth is increasing at a fairly rapid rate.  While support low
bandwidth/cpu things is still desirable, I don't think we should be
limited by that.

 But at the same time, I think 25x25 is probably on the large size - bandwidth
needed for updates would be roughly proportional to the amount of data - 25x25
is 625 spaces, 11x11 is 121, so you talking roughly 5 times the bandwidth to
send that larger map (this ignoring the fact the additional overhead for a new
map update command, since the current one only supports 15x15 max map sizes).
And in terms of resolution, you are talking 800x800.  If your running the
server on the local machine/ subnet, the bandwidth may not be an issue.

 The problem of course is that the bandwidth needs become much higher
when in combat, which is more important to get quick updates.  Some form
of dynamic updating may then be desired - ie, if in heavy combat, maybe
only a 9x9 map gets sent just so the player can see what is immediately
around them (and presents danger), while when strolling accross the
countryside, you get the 25x25 map.  And in the case, caching of the
older data certainly becomes much more desirable - still nice to know
that the red dragon may still be up the corrider in the way of your
exit path.