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).
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.
matthewkayin|8 months ago
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.
sosodev|8 months ago
ghushn3|8 months ago
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.
ehnto|8 months ago
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.
jedimastert|8 months ago
Benjamin_Dobell|8 months ago
unknown|8 months ago
[deleted]
sosodev|8 months ago
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.
fedorareis|8 months ago
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.
jayd16|8 months ago
righthand|8 months ago
remram|8 months ago
bee_rider|8 months ago