The versioning problem is more difficult than you think: because all games are
in sync, the problem is not only to send compatibles orders, but to ensure
that the execution of orders is the same everywhere, i.e. to have the same
engine. This is why glob2 has several version numbers: one for engine, one
for savegames, and one for releases. This is also why we can't use float, not
because we can't serlialiize them (indeed we can), but because floating
computation results differs on different computers (this is not fantasy, we
had float and we got game desynchronization because of this, so we had to use
int only).
Whenever you decide to use floats, you'd better have a real good excuse, because most of the time, there isn't.
Your understanding of the interface between the network and the rest of the
game is correct. The latency also works as you have described. But the
problem is more complex that you have described. Your example was a two
player game. But with a four player game, for instance, any player can
receive or not any packet, including the ones that ask for resend or the ones
that tell that other players are waiting for resend, etc... This is the
reason why the network is so complex. When you add YOG into this scheme, for
the initial connection, that becomes a mess. Nuage rewrote the network
several times until it finally works most of the times. So my feeling is that
this model is just too complex to manage each case in a proper way.
About having multiple orders in a packet, please note that actually glob2 put
two orders in a single UDP packet, and thus every order is transmitted twice.
This assures that if a single packet is lost, the network system can recover
without any resend.
You should take into account your new design: orders don't need to be multicasted anymore.
State information from server to client can use UDP, since there is no
problem if packets get lost: the display can be temporarily
inconsistent and updated with the next state transfert.
For these two reasons, I think UDP can be used for client/server
interaction. Because reliable messages are unicasted and the server can
confirm their receival with state information corresponding the order.
For example, the client sends an order and the server answers with an
ACK and by telling him to display the building in construction. With
stamps (UID), the client can resend orders and if the ACK had been
lost, the server will resend it without executing the order twice.
About your idea of directly serializing orders instead of creating objects,
I'm not convinced: the overhead of containing data in a struct and only
serializing when required is low and it is easier to debug an Order struct
than a bunch of bytes. Of course, we should modify the actual Orders to use
your new streams. Furthermore, we could also remove the switch statement that
chooses which order to create in favour of a registry of Order constructors,
adressed by the order ID, which would just be constants.
A registry is a great thig, but IDs can be generated by the server, so they won't be hand coded.
To resume, the two big problems of the actual network model are:
- initialization when behind NAT and with lost packets.
- management of lost packets with several players.
Problems (theoretically) solved.
Thanks, have a nice evening,