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

[Kai Sterker]

On 02 Dec 2001 18:29:59 +0100 Alexandre Courbot wrote
> Hi, we had a nice and interesting meeting yesterday.

For those who couldn't be there, the log is on the ftp as usual.
 

> The main problem with this scheme is cheating, which is quite easy. One
> improvment would be that the server only sends the datas the client is
> authorized to see. This complicates things a bit, as the datas would
> then be different for all clients, and some changes might not be taken
> into account by the client. Say I'm on the left of the map, and on the
> right a door opens. I'm not allowed to see that so the server doesn't
> send me this information. But when I arrive at the door's place, it is
> opened since a long time, and the server has no reasonnable way to know
> that this door is still closed for me. The same problem would apply to
> characters, if one character stays without moving and I approach him, it
> shall not appear on the client as the server only sends update
> information when the character's state change and my client focuses on
> him. 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.
> Moreover, the map renderer cannot work with such parts of map.

Hm, that is a problem. 

What if we limit the things a client does know to submaps? A submap is a
rather small area (a room, or a limited outdoor area). Here cheating isn't
really a problem, as you wouldn't gain much.

So on submap change, the server would once submit the complete submap data
(which isn't much either) and afterwards only the updates, as you
suggested above. Then there wouldn't be problems with a door opening on
the other side of the submap, etc.

OT: remember to discuss having multiple maps (and seamless connections
between them one day).

 
> Which makes me think about the other way to save objects we discussed
> yesterday. If I understood correctly you'd have a generic saving object,
> but:
> -you have to specify manually what to save for each object,
> -you have to write your loading function anyway.
> 
> Am I right? Sorry if I don't get it right, please quickly explain me the
> details then :)

Didn't my mail this morning come through? 


As to your question:
 
> In this case, how is it better that the current state saving/loading we
> do? 

You'd still do myobject->save() :). However, that does not write anything
to disk yet. So what you reach is a seperation of normal program code and
disk access code. As I said yesterday, good programs have three distinct
vertical layers:

    GUI
    -------
    Program
    -------
    Disk/DB

As we want to achieve a clean design with v0.4, I think it's simply not
feasible to have program logic and disk access stuff in the same class.

However, concerning your idea of merging the send/save stuff. That looks
like a pretty good idea, and I can see no reason why it shouldn't work
with a different saving/loading scheme too.


Kai