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

[Andrew Sayers]

On Tue, Oct 25, 2005 at 10:18:15AM +0200, Stephane Magnenat wrote:
> Hi,
> 
> I don't see the reason of setting latency manually, as the game should choose 
> the best one according to actual network conditions. The fact that latency is 
> choosen manually in StarCraft is a drawback, not a feature.

Are you referring here to length of a tick, or to the number of ticks
that messages need to be post-dated by?  In my opinion, even without
considering network issues, the optimal length of a tick is really a
matter of personal taste - I might want the game to run quite slowly so
that I can take my time observing what all my globs are doing, while you
might prefer the game to run very fast to keep your attention.

I would certainly agree that the amount of time messages need to be
post-dated should be set automatically, but if you and I play a game over a
very latent connection, it's a matter of personal choice whether we find
it less annoying to have the game run at a snail's pace, or for our
globs to keep walking into traps because we can't order them away
quickly enough.

> Now on your proposal: if I understand correctly, it is for a client/server 
> model where clients do indeed recompute all the world (and thus game is still 
> synchronized) but where orders go through a central point, which should not 
> be behind firewall/NAT ?

Sorry, I should have been more explicit about this.  The grandparent to
this post was intended to describe a way of setting post-dates that
could apply equally to a client/server or peer-to-peer model.  However,
a client/server model where orders were sent to a server with no
specific time to be executed by, the model I described would be
redundant.

Personally, I still believe that the synchronised peer-to-peer model is
the best solution for most of Glob2's problems, but I recognise that I
might not be right - for example, the idea of hosting AIs on single
peers strikes me as a hybrid solution that is better than either
extreme.

Although it's useful for me to write my thoughts down while I'm thinking
about them - because I'll have forgotten them by the time we make a
decision - my intention wasn't to try and shut down the very useful
peer vs. client debate.

Actually, I will make one last point about this model before I forget -
although the system I described only involved two parties (which are all
that would ever apply in a client/server system), I think it could be
easily extended to apply to many peers, by taking the longest of all
calculated post-dates.

        - Andrew