<div dir="ltr"><div>Our game is a 10 player Lords Management Game. I use ENET for the network layer and so far has been working very well.</div><div><br></div><div>The basic design is as follows:</div><div><br></div><div>- all 10 clients and server rely on the simulation being determinilistic. only user input commands are sent, not state. RTS heritage. The exception would be clients rejoining the game)</div><div><br></div><div>- while the game is running there are 2 channels.</div><div>channel 0: ENET_PACKET_FLAG_RELIABLE</div><div>channel 1: ENET_PACKET_FLAG_UNSEQUENCED | ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT</div><div><br></div><div>channel 0 is for all user input commands sent by the client to the server. (ex. move hero to this position). </div><div>channel 1 is for 2 types of packets</div><div><span class="" style="white-space:pre">        </span>server -> client : UPDATE : what tick the server is at, and what commands were executed up to that tick</div><div><span class="" style="white-space:pre"> </span>client -> server : UPDATE_ACK : ack the server tick</div><div><span class="" style="white-space:pre">     </span></div><div>so the server is always moving forward and executing ticks, and sending to clients all the information needed to get to its current state. as clients ack the server packets, the server can safely forget about commands that it knows all clients have received.</div><div><br></div><div>based on this design every client gets its own custom update packet. they will all have a different set of commands determined by the last tick the client has acked. this means that until a client has acked, the server will keep sending old commands over and over again.</div><div><br></div><div>there is a threshold for if clients get too far behind the server stop sending so many updates until it gets an ack again (500 ms)</div><div><br></div><div>the server sends all clients update packets every 50 ms.</div><div>client sends update acks immediately on receiving an update (50 ms).</div><div><br></div><div>Server Average Outgoing Data Sent is 6000 bytes/sec. So about 600 bytes/sec per client.</div><div>Server Average Incoming Data Received 900 bytes/sec. So about 90 bytes/sec per client.</div><div><br></div><div>some other minor details:</div><div><br></div><div>- the network layer is done in a seperate thread from the main thread. The thread is basically</div><div>for all queued packets : enet_peer_send()</div><div>enet_host_service(host, 0, 0);</div><div>ENetEvent event;</div><div>while(enet_host_check_events(host, &event) > 0) {}</div><div><br></div><div>- the packets have custom compression based on domain knowledge (ex. if enum only send the # of bits required to handle all enum values). container maximum sizes, etc.</div><div><br></div><div>our game seems to run quite well given the various pings we have to deal with but we definitely have reports of lag and I have experienced spikes of packets being lost and received in huge chunks myself.</div><div><br></div><div>my question is there anything in this design / implementation that looks bad and that you would recommend changing?</div><div><br></div><div><br></div><div>Jamie Seward</div><div>Lead Programmer</div><div>Ironclad Games</div><div><br></div></div>