Re: [Adonthell-devel] Ideas from yesterday's meeting

[Lakin Wecker]

> The basic idea, separating graphics from game data, is quite easy to get
> - actually you just need to define classes without any gfx management,
> and the client (renderer) would have another class that would be
> dedicated the them. There's no problem with that. 

I'm interested in knowing how you store the graphics for Entities in the game.

>What's more
> interesting is how to keep the server and the clients in sync. This will
> bring security issues we discussed yesterday.

I'm going to give my general impressions of how the client->server should act.

The server maitains the game world as a whole, which includes avatar 
positions, state of a door(open/closed/jammedshut/broken/etc.), and 
everything else.  The client maintains it's local game_state which is in 
effect a copy of the servers's game_world.   
Which means that if someone opens a door on one side of the world, when you 
get there it should still be open, unless of course someone has closed it.

As actions happen, the server evaluates those actions, decides on their 
outcome, and then notifies all clients within a reasonable region what 
happened.   So when someone moves, all clients in the surrounding area who 
can "see" this character get updates.    If someone is standing still, and 
you come upon this person you will get an update because each time you move 
in a particular direction you get an update of the "new" things you see.  
So when you come upon a person standing around you will get an update.
You're client stores this information and assumes the person is still there 
until he gets different information.  If you leave that area and the person 
moves, when you come back it's the clients job to notice that there was no 
update telling you that person is there, In other words,  you're client can 
assume all it wants about what is offscreen but until the server tells it 
what is there, the client can't be sure.
(I hope I'm not being to confusing here, and if a greater explanation is 
needed let me know)


>A workaround would be that the server sends all the data for the
> client's current region, but that's too much to send every time.

How is this any more than sending ALL the map and it's info?
Think of the small submap that the client knows about as it's _entire_ map. 

> Moreover, the map renderer cannot work with such parts of map.

Why not?  it should.  At least if you plan on networking it should.  If you 
have a local game and the renderer can read the entire map file, then sure, 
it's feasible that the game can look at the entire map, but as soon as you 
get into having multiple human players in the same world, based on the server 
client model, you need to have a client able to work with smaller map files. 


> Offtopic: Would you mind if I GPG sign all my mails like this one? Not
> that it is absolutely necessary, but that's a good habit to take. But if
> you or your mail client don't like it, just tell me and I'll avoid
> signing when posting to the mailing lists.

I have no problem with it.

Lakin