Re: Networking (was Re: [glob2-devel] Glob2 salvage proposal)

[Andrew Sayers]

On Tue, Oct 25, 2005 at 12:18:05AM +0200, Martin Voelkle wrote:
>    On 10/24/05, Andrew Sayers <address@hidden> wrote:
> 
> On Mon, Oct 24, 2005 at 09:35:50PM +0200, Martin Voelkle wrote:

> That's true - although a client with no state information would have
> to get updates about every movement of every glob, which would take
> significantly more memory, and be significantly more susceptible to
> network instability.
> 
> It would take way less memory than the pathfinding stuff (gradients,

Sorry, that was a typo on my behalf - I meant bandwidth, not memory.
You're right that it would take much less memory and somewhat more
bandwidth.

> etc.). Network latency would be much better with this design, and
> that's the problem with the complexity of having every player running
> the game: synchronization of orders needs high latency. And that is
> incredibly more susceptible to network instability: dropped packets
> lead to multiplying the latency you have with optimal conditions.

I don't expect the client/server model to significantly affect latency
actually.  Orders still need to be sent from client to server in the
thin client model, so there still needs to be a delay to cover that
latency, and the server still needs to send update information out to
clients, so the probability of packets getting lost and re-sent is still
proportional to the number of players (albeit now only in one
direction).  Since each player has to receive orders and execute a tick
before it can send orders back to a server, you're just as likely to
wait for a player with a client/server model as peer-to-peer.

> The only loss with the server design would be the higher network
> bandwidth, which is every day less of an issue. Additionally, we could
> use very simple bandwidth adaptation techniques, like only sending
> information about the displayed portion of the map which would only
> impact the update of the display when scrolling. And glob's movements
> are very lightweight: they only change when the glob is on a new cell,
> which occurs every 20 ticks (I'm not sure about this number).
> Ressources growth information is also very slim.

The number of ticks between actions varies, but 20 is a decent average.
You make a good point about bandwidth adaptation - actually, you could
just send one message when a glob starts performing an action and assume
it continues until a message is sent to change the action.

I don't think sending information about the displayed portion of the map
would work, but only sending information about what's inside active
vision is certainly possible.  At the start of the game, this would be a
huge saving, but towards the end it's less impressive.

Actually, there is some flexibility around the poles of client/server
and peer-to-peer models.  For example, even in a peer-to-peer system, it
would be better if each AI chose one peer to run that AI and send orders
out to the others.  Although this would increase bandwidth a bit, it
means that AIs can use non-portable programming techniques - which is
very important if we ever want to make them scriptable.  In general, we
can make a decision for each part of the game as to whether it's best
synchronised across peers or run on one with orders being sent to
others.

        - Andrew