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

[Andrew Sayers]

Here are some more random thoughts about the game that have occurred to
me over the day.

*** YOG:

Does the YOG server just do game advertising/creation?  In other words,
does the server just need to give clients a list of sessions that are
waiting for people, and set up the port for NAT?

*** Registering:

Stephane, you mentioned something about not requiring the same version
of the game - in other words, allowing people with 0.8.16 to play
alongside players with 0.8.17.  This strikes me as quite useful, as new
versions of the game don't come out simultaneously on different
platforms, etc.  As a modification to my proposal from last night, how
about we register new handlers like this:

// original version
const oldHandlerID myHandlerID = registerOrder(myOldFunction, "myFunc0");
// new version
const newHandlerID myHandlerID = registorOrder(myFunction, "myFunc1");

Then later:

const bool myClass::orderSomethingToHappen()
{
        if (newHandlerID)
        {
                // Send new-style message
                return true;
        }
        else if (oldHandlerID
        {
                // send old-style message
                return true;
        }
        else return false;
}

It wouldn't be that hard to negotiate a common set of orders on a
per-game basis this way.  It would also remove the absolute requirement
for commands to be registered in the same order each time.

*** Latency:

The basic problem with network games is that data takes time to get from
place to place.  Please tell me if I'm wrong, but my understanding is
that Glob2 gets around this by setting orders to be executed a certain
number of ticks after the order is sent.  This number is negotiated
somehow based on the latency of the network, and if a player still
hasn't received his orders after that amount of time, the game pauses
and the "waiting for player" message comes up.

*** Communicating over the network:

I've not looked into how it works at the minute, but some ideas for
lower levels of the protocol stack, based on the ideas I posted last
night:

When a tick is finished, the string associated with the current
orderStream is sent to the next level down the stack for transmission,
and a blank string takes its place.

Sending an orderString is quite complex, because UDP doesn't guarantee
that packets will always arrive (in fact, it's quite common for them not
to).  A way around this is:

* Alice sends the orderString to Bob.  The orderString might not arrive.
* If Bob receives the orderString, he sends an acknowledgement to Alice.
  The acknowledgement might not arrive.
* Until Alice receives an acknowledgement from Bob, she keeps resending
  the orderString.

The problem with this is that when Alice re-sends the orderString, she
will need to send the orderString for the next tick too.  I think the
solution will be to send and acknowledge messages with several
orderStreams in them, but I've not yet thought through the complexities
involved in games with three or more players sending three or more
orderStreams at a time.

*** Saved game format:

The reason I've had to rewrite the map format is more to do with the
underlying changes in the map code, than problems with the format.  So
long as we stick to using the new iostream system from now on, we
shouldn't have any trouble with the underlying format.

        - Andrew