Re: [Adonthell-devel] More v0.4 design issues

[Kai Sterker]

On 08 Dec 2001 13:11:11 +0100 Alexandre Courbot wrote

> What if you enter a dungeon which would be an entire map? I think we
> should also allow exceptions for cases like this one.

Hm, yeah. True.

 
>> Such a regular structure should be quite easy to handle. Especially it
>> should be entirely transparent to the player and map maker. Both would see
>> one large, continuous overworld. The map editor / map engine would do all
>> the actual work in the background. 
> 
> Hehe. More pain for me ;)
> 
>> At one point in time, a client had to have 9 such map parts in memory.
>> The one in the center where the player sits on, and the 8 surrounding
>> tiles. When the player leaves the center and walks a certain way into an
>> adjacent tile, we could load the 3 new tiles that lie in that direction in
>> the background and unload the 3 opposite tiles, so that the player would
>> be on the center tile again. The renderer had to handle a situation
>> where either 2 or 4 different maps would be visible at the same time.
> 
> Wow - you mean you load 3 tiles each time the player makes a step?

No, 'course not :). I used tile to refer to such a map-part of, say 64x64
individual tiles. That means you had an area of 192x192 tiles in memory.
First the player would be in the middle sector (64,64)-(128,128). As he
nears the border (e.g. x < 32) we'd load 3 new areas (-64,0)-(-1,63),
(-64,64)-(-1,127), ... :

      -64      0     64     128    192
        
    0   +--  --+------+------+- - - +
        |      |      |      |             One square 
               |      |      |      |  <-  represents an
        |      |      |      |             entire map
   64   +--  --+------+------+- - - +
        |      |      |      |      
          (*)  |  P   |      |      |
        |      |      |      |      
  128   +--  --+------+------+- - - +
        |      |      |      |      
               |      |      |      |
        |      |      |      |      
  192   +--  --+------+------+- - - +
            ^                   ^
            |                   |
          Load               Unload

 It

> imagine that you have to find these tiles in the file,
> check whether there are gfxs to be loaded for these, and perform some
> huge memory operations to place them on the map. I fear it'll be
> unplayable that way. 

Remember that one of those squares would be a complete map. So you load a
complete map file and transfer it from the server to the client, where you
load all new graphics on the map. (Which makes it important that as many
graphics as possible are already in the cache.)

I agree that this is a lot of work, and cannot be done smooth during one
game cycle or two. However, it needs not happen in one cycle. As you see,
when the player (P) reaches (32,y), it will take a while until he'll reach the
border of the area in memory. 

First we'd load the map marked with (*). I guess we have a couple of seconds
to do so, even if the player walks straight into that direction. Then,
depending whether the player is more north or more south we'd load the
remaining two maps in a certain order. Loading could be done in a different
thread, or distributed over many game cycles otherwise. (For example by
loading only a limited number of graphic objects per cycle). 

And with the multiple channels, the actual map data from the server can
also be transferred over several cycles. 

And as the mapobjects used come first in the map, we can already start
loading them before the whole map has been submitted.

Of course this requires more work, but I think it is possible, and the
gameplay would be nicer on a continuous world. Also such a dynamic loading
wouldn't be perfect. You'd possibly load maps that are not needed,
but as it doesn't interrupt the game, that should be okay. Maybe the
hardware requirements for such a system would be a little higher as well:
if normal gameplay already eats up 100% CPU, the background loading won't
go unnoticed. But you cannot make it right for everyone.

 
> Moreover, think that the next mapengine will be much
> more complicated than the current one (several walkable layers, and so
> on...), and such real-time loading will be extremly hard to do.

Again :). That shouldn't be a problem as we'd load entire maps. Some extra
work had to be put into the areas where the maps connect, that's right.
But if we keep that in mind right from the start, we can design the map
format to make this as easy as possible.


Kai