adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] map structure


From: Kai Sterker
Subject: Re: [Adonthell-devel] map structure
Date: Wed, 17 Jul 2002 22:22:07 +0200

On Wed, 17 Jul 2002 19:22:14 +0200 Alexandre Courbot wrote:

> 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! ;)

As long as you've got it working before the meeting ... :P
 

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

Don't confuse 'area' and 'map'. The map areas are all the small squares
('areas') the map is composed of. So the map would indeed be saved in a
single file.


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

No, that wouldn't work. As the map is no longer completely in memory,
only a few areas, how could two mapviews share the same instance? That
would mean they have to show roughly the same part of the map. But the
map could be huge. Each mapview needs it's own instance of the map.

You could say, the map class holds a part of the actual map, and the
mapview renders an even smaller part of the map class data. And as the
player moves along, the map class will dynamically load the area around
the player (or mapview). That's why each mapview would need it's own map
class instance.


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

Well, right. The server might need a map as well. 

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]