I noticed you have your game on Steam. Did you end up using any of the Steam networking features via Steam SDK and Godot Steamworks?
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.
The Steam networking sockets do offer the same functionality as ENet. Is it possible to use the Steam Datagram Relay without the steam networking sockets? I would assume so. Not sure I see the benefit of supporting both.
Godot has been really killing it lately, I'm so bullish on their future.
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.
I have tried Unreal, Unity and Godot. Released a commercial game in Unity, and now use godot.
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.
> I use the reliable mode for sending client inputs to the server: the server needs to be able to recalculate the state of the game reliably, and it's not acceptable for some client inputs to get “lost”. This may cause a bit of latency, and a bit more work for the server, which will have to “rewind” the game a bit further if an input arrives very late, but that's the price to pay for a stable game.
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.
Conceptually you didn't hit after they moved. You hit at the right moment in your timeframe. That is sent to the server 1 second later and you were rewarded for the hit from 1 second ago because it calculates the results based on when you made the input, not when it was received. This can even change the result of an encounter (ie rollback).
While I get what you are saying, it seems weird from the standpoint of the other player since they have been out of the engagement area for 1+ seconds. It still seems to me that you would want some sort of cap on the rollback period.
You can think its weird but it turns out to feel the best. After some maximum threshold of lag you'd just have to kick the player. That that threshold is varies with game mechanics.
It is weird, and if I’m reading this right a single player with a poor connection will trigger repeated rollbacks for everyone. It also seems to be client-authoritative? Which is just 100% illegal if you’re at all concerned about cheating. All the problems of peer-to-peer in a client/server package?
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.
Client side hit detection (with server side validity confirmation) is the standard for competitive games these days. It just feels the best.
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.
Cheating is handled by console DRM and root kits. Similar for Overwatch, similar for Valorant. Such is the state of the art.
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.
The current trend is to count the hit. Its very frustrating for the shooter to make a valid hit under the crosshair and miss. Whereas the player that moved has no real obvious way to tell exactly where the player aimed. If this was a defensive move like a shield, then its up to the game mechanics to decide that sort of thing.
> 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).
I would love to read more specifics about the Godot implementation. Godot has its own concept of time, pausing, and updates, and its own physics engine. So rewinding the game and running the simulation again seems a little tricky.
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.