I had already shown in the Tutorial to the World-Server-Login that one can query the so-called packet round trip time (RTT) with an active ENet connection over get_statistic(ENetPacketPeer.PEER_ROUND_TRIP_TIME). At that time I had received values in the range of 17ms and had wondered, but then left it at the following explanation attempt:
One should not be surprised about the relatively high values ~15-20ms for the RTT in local tests. This may sound high at first, since the connection is local, but you have to consider that the RTT not only includes the way there and back, which is omitted locally, but also the processing time on the server.
My comment at that time is not wrong, but kept very vague. This was because at the time I couldn’t quite figure out why the processing time was so high, after all there was no interaction at all on the world server at that stage of the project. I filed this information away for now, thinking I might figure it out when I get a chance. A few weeks later, while researching the replication interval from the MultiplayerSynchronizer, I came across the following description:
Time interval between synchronizations. When set to
0.0(the default), synchronizations happen every network process frame.
And I was wondering what exactly this “network process frame” is. Since I couldn’t find anything else about it in the documentation, I asked in the networking channel of the Godot Contributors Chat and got an answer from fales a little later:
process frame is the func _process(delta), so it’s the engine FPS.
That’s when it clicked for me 💡. All incoming network messages are fetched from the network buffer once per frame and then processed. By default I work with a refresh rate of 60Hz, because my graphics card consumes less than 10W in idle. As a result, the server also runs at about 60 FPS. Thus, it processes the network messages 60 times per second, which results in a processing time of 1s ÷ 60 ≈ 0.017s ≙ 17ms and thus corresponds exactly to the determined RTT.
So I finally had my explanation for these “high” latencies, although no network was involved at all. This knowledge will certainly be very helpful in the future. But if you plan to pass this information on to the players, you should let them know that this is the RTT and not just the “ping”. This correlation can also help us with development, because we can specifically simulate different latencies and try out how our games “feel” with which latency. Until now, I thought that this could only be achieved with the help of proxies.
You can set the max FPS via the property application/run/max_fps. So you can set it either in the code or in the project settings (Application -> Run -> Max FPS). When going through the project settings, don’t forget to enable the “Advanced settings”.
And finally a short video how the example project “feels” at 6 server FPS, i.e. with an RTT of 160:
Of course, it’s stuttering, after all we have to keep in mind that we haven’t dealt with client-side prediction yet. But if you pay close attention, you can see that a simple version of it is already integrated. Especially if you compare the movement of the character with the projectiles, which don’t have any client-side prediction yet. The projectiles should serve as a small teaser for a next tutorial 😉.