[Adonthell-devel] Ideas from yesterday's meeting

[Alexandre Courbot]

Hi, we had a nice and interesting meeting yesterday.

I've thought on how we could implement our network layer, especially
from the map engine side, as it's the part that concerns me the most for
now. I'll expose the basic ideas here for improvments. Also, I'll launch
again the discussion about the saving scheme.

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. What's more
interesting is how to keep the server and the clients in sync. This will
bring security issues we discussed yesterday.

The goal is to minimize at maximum network usage. Let's concentrate on
the map itself, and on characters movments. The server has a copy of the
map it could send to the clients when they connect (after all, a map is
a very small piece of data - the Redwyne Inn map is less than 3Kb). All
the graphical medias are handled on client side. The server would then
send all the positions of all characters on the map, so the client have
exactly the same representation than the server. Actually, you could
even use the same map class on client and server sides, provided it has
the ability to send/get it's state through a socket.

After that, the client just sends the player's controls to the server,
which performs the actual game loop. The client could also make the
player move to avoid the lag effect, but the server will send it it's
own coordinates and it will have to take them as the final word anyway.
>From this point, the server listens to all the clients, performs the
game loop, and sends only the changed datas on all clients so they can
keep their copy of the map up to date.

There are some advantages and disadvantages with this approach:
Pros:
-The server only needs to send exactly the same datas to ALL the
clients.
-The game state is always stable, as the clients know as much as the
server.
-The client can safely and easily perform some movment anticipation in
case of lag.

Cons:
-The clients know as much as the server. That way, anyone can quickly
hack a client to know what's happening at the other end of a map, which
you normally can't see.
-Some probably useless datas are sent. However, the amount of datas is
still quite low.

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.

Quite a hot topic, let's open the discussion! Lakin, you're particularly
welcome to give advices here, as you have some experience with network
issues. For me (and most of us I think) it's the first real deal with
network programming.

You have noticed that in this scheme the map object sends it's state
through a send() method and receive it with a receive() method. This is
quite similar to the current state saving method which uses save() and
load() methods. Actually, I can't find an example where these methods
aren't similar, which makes me think that they could be merged, excepted
that when you save a game the data is written to a file, and when you
send a state it is send through a socket. For 0.3 we had save() and
load() functions (to save a complete character, gfx included) and
save_state() and load_state() functions to only get the state. Here,
only the state saving/loading methods are needed, as graphics are only
handled by the client.

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 :)

In this case, how is it better that the current state saving/loading we
do? I even fear it would be more confusing. Not all objects should be
saveable, and would I need to save an object, what's clearer than
myobject->save()? Note that I'm not opposed to a new saving strategy,
but I don't get the advantages of changing it for now.

I'll now perform some tests with the latest SWIG to see how much it
likes namespaces and templates - expect another mail about code
organisation in the evening!

Comments, ideas - make Savannah servers explode! ;)

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.

See ya all!
Alex.

-- 
http://www.gnurou.org

pgpcqs6C2dbdn.pgp
Description: PGP signature