Hi Andrew, YOG does indeed do game advertising/creation, NAT setuping and also manages chat rooms (but we can delegate this to IRC).
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). 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. 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. 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. Bye the way, we should do a developer FAQ out of those emails.. any new of icclus ? If they don't answer in some days, we'll go for Kyle's proposal (thanks Kyle :-)). Thanks, have a nice evening, Steph _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
