Re: [Adonthell-devel] map structure

[Kai Sterker]

More design ideas for the lowlevel map stuff.

I have little ideas for the mapobject cache yet. Obviously it would need
to store both objects with and without gfx. As one inherits the other,
this shouldn't be a problem. More of a problem is whether it should only
be a mapobject cache, or a generic cache useable for all sorts of
things. Although I guess it could be implemented for mapobjects first,
and generalized if needed later on. Anyway, I don't want to deal with
that now.

My main thoughts have centered around the map representation in memory
and on disk. Here's my idea of the file format:

version number:
not much to add here

width and height:
the maximum extension of the map in x and y direction. That does not
necessarily mean that the map consists of x*y areas. There may be less.
However, the index for the areas will contain x*y entries.

area index:
a two-dimensional array, specifying the position of each area in the
file (and on the map). index[x1][y1] returns the file position of the
area located at (x1, xy). If no area exists at a certain location, 0 is
returned. That means, no 'empty' areas are saved in the file.

areas:
after the index, the individual areas follow. For the beginning, they'd
be stored without compression. Later on, the individual areas could be
compressed.

One file per map, as Alex suggested.


This file format, and the architecture I suggested earlier are crying
for division of the actual map and area index. A map can have multiple
instances (one per mapview), with different areas in view, while the
index for all those instances would be the same.

So we had at least the following:

        +---------------+            +--------------+
        |  map_manager  |------------|   map_index  |      Server
        +---------------+            +--------------+
                |                      |
                |     +----------------+                          
                |     |  
        +---------------+            +--------------+
        |      map      |------------|   map_view   |      Client
        +---------------+            +--------------+

A map_index is created whenever a certain map is loaded for the first
time. The map_manager keeps a list of maps in memory. On creation, the
map_index reads the index of the mapfile and stores it for later use. It
could even keep the actual file opened for faster access, although that
would limit the number of maps we can have open simultanous. (255 file
descriptors). OTOH, that shouldn't be an actual limitation ;).

The map_manager is a static class. It would offer load and unload
functions for maps. If the map is already loaded. a pointer to the
according map_index object is returned, otherwise a new map_index is
created. Whenever a map is no longer needed, it should call the
map_managers unload function. If no map references a map_index any more,
it can be freed. 

The map class is the representation of the map in memory, composed of 9
areas, as explained earlier. It is rendered by the mapview. Whenever the
player nears the borders of the map, appropriate methods of the
map_index have to be called to retrieve the areas in that direction.
That means, actual map file access is encapsulated in the map_index
class. No other of the classes involved needs to concern itself with it.
                

I'm not 100% sure about the data each of the classes needs for it's
task. That'll come when I actually go about coding the stuff. But the
overall design should be sound. What do you think? Any improvements or
problems?


Oh, and regarding a possible Client/Server implementation. Both manager
and index could be located on the server, while map and view definately
have to be on client side. Of course in that case there had to be an
additional communication layer in between, but the principle would
remain the same.

Kai