Testing a Robust Netcode with Godot
studios.ptilouk.net
studios.ptilouk.net
I'm using ENet for my RTS project and found that Steam's networking code offers many of the same features offered by ENet (including the reliable, in-order delivery of packets, which is invaluable for an RTS Game). I was able to abstract things out so that my game uses ENet on LAN games and Steam networking for online games, and the rest of the game code is none the wiser.
While I think gdscript is largely a mistake and I look forward to feature parity in the C# interface, I'm still very excited to see all the projects coming out of Godot developers today.
Initially the move to godot was because I wanted sovereignty over the future of my projects.
But Godot is genuinely a delight to work in. If you're not making AAA games in a massive enterprise, Godot is the right blend of tools provided and getting out of the way.
The core of Godot's netcode is way too minimal. It gives you a way to synchronize state and make RPC. That's it.
As the author mentions adding in the higher level functionality like prediction, rollback, etc is extremely complicated so it's nice that netfox takes care of a lot of that complexity.
Maybe I’m missing something, but wouldn’t you either want the input to drop or the rewind to not happen at some point? If my network is extremely laggy when I’m playing a multiplayer game I would expect that my attempt to hit an opponent wouldn’t still succeed 1+ seconds later when they have already moved and are no longer in a position to be hit.
It should be:
1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)
2. On correction, client is rubber banded into the correct positions to match server state; rollback/replayed with correction if the game is deterministic
3. Server-authoritative; if it never reaches the server, the input never existed.
You're also fundamentally misunderstanding the design.
> 1. Client input is either dropped or the input is applied but in an unexpected position (because when the user input occurred the client visible state was wrong)
The system is built around rewarding the player for making good inputs and tracking the state in which they made those inputs. It's not as far as "all perspectives are valid" but it's close.
- Player A moves in to make a hit. The character starts the hit react.
- <lag>
- Player B see's the telegraph and makes a valid block.
- <lag>
- Player A receives the rollback and the character moves into the block animation instead of the hit react. Ideally this is unnoticeable.
Player A fires at B at time 0
Player B moves at time 0, causing A to miss
Due to lag, player A receives B movement at time 3
So player A fired at a still target, and hit. Player B moved, and dodged. Rollback would apply to player A.
Does the hit register or no?
If player A receives the rollback, and now witnesses B dodge, but the hit registers anyways, then I don’t see how there can be a server validity check — from the perspective of the server, the state of the game in which A landed the hit never existed
My understanding of AAA fps games is they show the hit animation as a prediction, but it’s still up to the server whether the hit registers. Eg, if I lag in overwatch and everyone stands still, nothing I shoot lands (except by accident). When my inputs finally reach the server, reconciled and replayed on my machine, it turns out I was shooting at a wall.
> If player A receives the rollback, and now witnesses B dodge
Why would they witness the dodge? They would likely see the VFX of the hit and then the target move slightly faster than they should for a frame.
> from the perspective of the server, the state of the game in which A landed the hit never existed
You can validate that player positions and visibility raycasts and such that you're verifying plausibility. You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened." The point is to make a fun game so its fine to reward the player.
> You say "the state never happened on the server" but what does that even mean? You're not replicating look rotation with enough fidelity to know that and its not the job of the server to simulate "what actually happened."
The video in that post is what I was essentially talking about; the server tracks player A's attack-input, and player B's movements, and ignores the fact that the two don't at all line up. The final reconciliation of the event sequence is nonsensical -- player A is hitting player B in a manner which simply should not work. The violation of game rules / simulation state is occurring, it's just being accepted and ignored (and I don't know what, if any, verification the server is doing here, since actually doing the hit-registration check would reject this).
This is upsetting to me, but so be it.