<div dir="ltr"><div><div>I don't see anything too obviously wrong with this. You might get about a teency bit more mileage out of using plain old unreliable packets instead of unsequenced since their bookkeeping is a bit more lightweight, but theoretically they should perform about the same.<br><br></div>I've implemented a similar networking scheme to this before and had no real problems with its performance.<br><br></div>As always, be careful that you are calling enet_host_service often enough. If you are only doing it every 50ms, that may not be often enough. That doesn't mean you have to have your update logic running more frequently, just that you have to service the host more frequently than that to give it opportunities to do its thing. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 4:44 PM, Jamie Seward <span dir="ltr"><<a href="mailto:jamie.d.seward@gmail.com" target="_blank">jamie.d.seward@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 style="white-space:pre-wrap">      </span>server -> client : UPDATE : what tick the server is at, and what commands were executed up to that tick</div><div><span style="white-space:pre-wrap">       </span>client -> server : UPDATE_ACK : ack the server tick</div><div><span style="white-space:pre-wrap">   </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><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Jamie Seward</div><div>Lead Programmer</div><div>Ironclad Games</div><div><br></div></font></span></div>
<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br></div>