Testing a Robust Netcode with Godot
studios.ptilouk.net
Testing a Robust Netcode with Godot
1–10 of 22 posts
Re: Testing a Robust Netcode with Godot
#2Interesting article. I'm surprised the author didn't mention https://github.com/foxssake/netfox
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.
Re: Testing a Robust Netcode with Godot
#3I 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.
Re: Testing a Robust Netcode with Godot
#4I 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…
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.
Re: Testing a Robust Netcode with Godot
#5Thank you for selling your game DRM-free on Itch!
Re: Testing a Robust Netcode with Godot
#6Out of curiosity, how optimistic/pessimistic are the drop rates the author picked?
Re: Testing a Robust Netcode with Godot
#7Godot 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.
Re: Testing a Robust Netcode with Godot
#8Godot 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.
Godot seems to be doing to the game industry what Blender has been doing to the 3D animation industry, I'm very hopeful for it as well.
Re: Testing a Robust Netcode with Godot
#9> 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.
Re: Testing a Robust Netcode with Godot
#10> 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…
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).