Re: [Adonthell-devel] map structure

[Alexandre Courbot]

Okay, I've finally put the hands out of my Zaurus and can reply! But
since I'm looking at porting Exult and Adonthell to it, I'm sure you'll
forgive me Kai! ;)

> More design ideas for the lowlevel map stuff.
[....]
> 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.

In this case, what does the map area entries contain, if the maps are
stored into individual files? Actually I had suggested to store them all
into the same file. It would avoid having too much file descriptors
opened at the same time, without causing problems as the file is
indexed. It would even prevent other problems like an area file missing
- too much files might get messy. And I can't think of any drawback in
our case.

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

Actually, as for 0.3 (and for 0.4 in my mind) all the mapviews work on a
unique map instance. Of course, if you are talking about one instance
per *client*, then we agree!

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

Yep. Looks much like the theme_manager, which has proven to be
efficient.

> Because of all that, I think it is enough if the client has it's
> representation of the map (for rendering), while the server needs
> none. Only the index to hand out map chunks as the clients request
> them.

Mmm no I don't think so. If every client runs its own instance of each
character, and one is cheating, the games states wouldn't be the same.
If the cheater kills another player by cheating, the victim would die
unexpectingly. We could compare with the state of the other player to
prevent this, but then he could modify his client to always reply "no,
I'm not dead". I guess everything regarding game actions must be
centralized on the server, the clients being only input/output devices.

My proposals aren't very different from what you said anyway. I guess
that for the basics we are ok.

Alex.
-- 
http://www.gnurou.org