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.
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.
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.
It may not be official, but TypeScript support is pretty wonderful: https://breaka.club/blog/godots-most-powerful-scripting-lang... :)
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.
Interesting 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.
> 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.
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.
Thank you for selling your game DRM-free on Itch!
Out of curiosity, how optimistic/pessimistic are the drop rates the author picked?