1
\$\begingroup\$

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)

Improve this question
\$\endgroup\$
4
  • \$\begingroup\$ I might be missing something but.... What's the benefit of sending movement data to the server much more frequently than it can process it? Presumably other clients would only see updates once per tick anyway? Don't you want to batch those packets up as a summary per server tick? \$\endgroup\$
    – Basic
    Jan 24, 2022 at 14:59
  • \$\begingroup\$ Yes, this might be another flaw with the approach, @Basic. I just set up that arbitrary tick because as I was reading I noticed that server update rates were much slower than clients' to save up resources. Should I process packets instantly and match the server update rate to client send rate? Also, sorry, what do you mean by "batch those packets up as a summary"? \$\endgroup\$
    – Mdr
    Jan 24, 2022 at 16:25
  • \$\begingroup\$ Re: "batching up"... If (over the course of one tick) my packets contain: Forward .1, Forward .15, Forward .2, you could just send a single Forward .1,.15,.2 packet (or even a Forward .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\$
    – Basic
    Jan 24, 2022 at 19:34
  • \$\begingroup\$ Pardon me, but even if I match the server update rate by calling a "SendToServer" function at 100ms intervals on client side (that will send all accumulated packets from player inputs), the problem will still exist right? The player input itself is taken at 60 Hz and the position calculated by Godot (client-prediction) will differ because of the different tick-rates. Your suggestion makes sense, I'm just a bit confused if it would fix the main issue I was having. For movement, I'm sending a short variable for command ID, 2 double variables for input vectors and I'd add a long var for tick no. \$\endgroup\$
    – Mdr
    Jan 24, 2022 at 20:53

1 Answer 1

Reset to default
0
\$\begingroup\$

If your client input is being sent to a queuing system, which will then be processed by the server at a certain tick rate, you don't need to worry about the variation in the information processing between the client and the server.

It's the same on the server even if different information (physics vs input) is processed at different tick rates because queued information will be unsynchronized when the tick happens.

Let me know if that makes sense or if you meant something else.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .