Testing a Robust Netcode with Godot
The biggest challenge I faced in developing Little Brats! was the online multiplayer part: synchronizing computers with sometimes consequent latency while maintaining the “fast-paced action game” aspect was far from simple. I'll tell you all about it!
Lag compensation, prediction/reconciliation, etc.
I'm not going to do a detailed tutorial on these points, as there are tons of them already, but to give you an idea of the principle: when a client computer performs an action (in my case, for example, pressing the button to slap another kid), the server will receive this action, calculate what's going on, and send the result back to the client...
The problem is that even with a slight latency between the two computers, say 10ms, you end up with 20ms between pressing a button and receiving the result. It may not sound like much, but if you put a 20ms delay between each press of your keyboard keys and the execution of the resulting action, you're going to lose your mind in no time.
In principle, this is compensated for by several techniques: in my case, the client “validates” the action performed by default and applies it in its local scene. This is a prediction. When the server receives the action, it rewinds the game by the duration of the latency (so, for example, 10ms backwards), applies the action, and runs the game universe again for the equivalent of 10ms, all in the background, without this being visible on the server's game. Then it sends the final state to the client, which when it receives it will either validate its own state if its prediction was correct, or correct it if the server returned a different result (this is called “reconciliation”).
I'm not going to lie to you: it's very VERY complicated to implement all this reliably and “invisibly”. In other words, the people playing the game have to be as unaware of it as possible, and there has to be no camera “jumps”, inconsistencies, weird stuff... In practice, this will always happen a little, of course: if your client had calculated that you'd managed to hit a kid, but on the server that kid had already moved out of the way, well, you'll see your action “cancelled”, and the kid will finally go as if nothing had happened.
It was because of a delay on this network aspect that I was forced to postpone the release by 2 weeks, because my code was far too unstable, and in some cases the game was left broken or in strange, buggy states. Anyway.
The thorny question of testing
Obviously, the best way to test a multiplayer game is with several people. But in the meantime, when you're in the middle of development and incrementing little by little, it's still necessary to test “alone” behind your PC.
... continue reading