> Regarding network communication: I'm not familiar with the way glob2 > handles that now. That said, I'd generally suggest communicating state > changes for the whole game between clients, maybe managed by a > dedicated server. ZeroMQ [1] combined with Google Protocol Buffers > [2], for example, has proven well for handling the communication for > this kind of task.
glob2 uses deterministic behavior that is expected to be simulated on all clients identically, reducing the amount of network traffic to the human actions. This approach certainly has its academic value but turned out to be fatal as it bound the game speed to the slowest client's speed and caused big syncing trouble when one client had connection issues. Also by its nature all clients had to know all game state and only because people plaid fair, the fog of war was not lifted above the enemy base, so yeah, consider the current network design as obsolete. The only part that might not be obsolete is that games have to run off the meta/handshake server once the game starts, meaning that one of the clients should take the role of the server to be scalable. Alternatively servers should be dedicated machines like it is common in FPS servers, but the meta server should be able to handle many such servers dynamically.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ glob2-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/glob2-devel
