I'm designing a simple MMO game server with the help of ENet (reliable UDP library) and the Godot engine for client-side. I've read tons of articles, guides, stack exchanges questions regarding movement prediction. Here is what I have so far:
- A network thread that sends/receives packets from a ConcurrentQueue, so that no blocking is necessary.
- A game thread that will periodically check if there are any new packets in the queue (every 15ms) and a game loop that runs each 100ms.
My issue is the following: how can I get inputs from packets sent by the client (input data is sent 60 times per second to server) and correctly simulate them on the server? Since the server game loop runs on 10 ticks per second, my "delta" will be different than the ones used by godot, right?
Is this approach (sending inputs instead of position data/velocity data) feasible with different tick rates? Right now I'm sending Godot inputs every 16.6ms, reading batched packets every 15ms and updating physics every 100ms.
Edit: I think a possible solution would be to send the game frame number along with the move input, but wouldn't that be unnecessary data? (at 60 inputs per second, I would need 4 bytes to make sure it wont overflow)
Forward .1
,Forward .15
,Forward .2
, you could just send a singleForward .1,.15,.2
packet (or even aForward .45
summary packet). The server only cares about what happened from the last tick to this one. You're sending n updates in that period and asking the server to accumulate/aggregate them. You could do that on the client. Really though, I'd need to know much more about the data you're sending and why to be able to identify ways to reduce it down. \$\endgroup\$