[ENet-discuss] general questions about ENET usage and implementation in an RTS/MOBA

[Lee Salzman]

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.

I've implemented a similar networking scheme to this before and had no real
problems with its performance.

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.

On Tue, Jun 9, 2015 at 4:44 PM, Jamie Seward <jamie.d.seward at gmail.com>
wrote:

> Our game is a 10 player Lords Management Game. I use ENET for the network
> layer and so far has been working very well.
>
> The basic design is as follows:
>
> - 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)
>
> - while the game is running there are 2 channels.
> channel 0: ENET_PACKET_FLAG_RELIABLE
> channel 1: ENET_PACKET_FLAG_UNSEQUENCED |
> ENET_PACKET_FLAG_UNRELIABLE_FRAGMENT
>
> channel 0 is for all user input commands sent by the client to the server.
> (ex. move hero to this position).
> channel 1 is for 2 types of packets
> server -> client : UPDATE : what tick the server is at, and what commands
> were executed up to that tick
> client -> server : UPDATE_ACK : ack the server tick
> 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.
>
> 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.
>
> 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)
>
> the server sends all clients update packets every 50 ms.
> client sends update acks immediately on receiving an update (50 ms).
>
> Server Average Outgoing Data Sent is 6000 bytes/sec. So about 600
> bytes/sec per client.
> Server Average Incoming Data Received 900 bytes/sec. So about 90 bytes/sec
> per client.
>
> some other minor details:
>
> - the network layer is done in a seperate thread from the main thread. The
> thread is basically
> for all queued packets : enet_peer_send()
> enet_host_service(host, 0, 0);
> ENetEvent event;
> while(enet_host_check_events(host, &event) > 0) {}
>
> - 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.
>
> 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.
>
> my question is there anything in this design / implementation that looks
> bad and that you would recommend changing?
>
>
> Jamie Seward
> Lead Programmer
> Ironclad Games
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20150609/5c294169/attachment.html>