GameNetworkingSockets VS henet

Steam does have a NAT traversal/punchthrough service too. It's apparently usable without Steam according to their README on https://github.com/ValveSoftware/GameNetworkingSockets but honestly the only easy to use implementation I know is in Facepunch.Steamworks which requires a SteamID to initialize

Halo was mostly all about single player and early multiplayer/local multiplayer but their online netcode has sucked since Blood Gulch. Lots of games do networking horribly, I have been in gamedev making networking and I hate most of what people do. The ones that have a clean natting, based on enet style reliable UDP channels, RakNet style punch are better (RakNet was good until Facebook bought it). It has come a long way but also fallen back. Valve source netcode (on github) is probably the best and you can check it out here. They started with the best in Quake networking, then to Source.

There are some general APIs that are tied to Steam, like some networking stuff (even then there's an open source library), but the devs are not required to use any of those. If the devs chose to develop exclusively for steam and use their libraries, then that's their own decision.

Keep in mind that if you do go the GodotSteam route, there's GameNetworkingSockets from valve that doesn't have the requirement of needing Steam that you can use for releasing on other platforms. It has the same interface as the Steamworks SDK without requiring the Steamworks SDK.

Their UDP-but-connection-based game networking protocol can be used completely separetely from Steam (it also supports encryption). I think that does not include their relay networking solution, but still.. maybe it's helpful. They also have a TCP-like interface to make it easy to plug into an existing solution.

You can also use the non-Steam parts of that library in any game in case you don't just release on Steam (have a look at https://github.com/ValveSoftware/GameNetworkingSockets )

If you want to go the route of using a raw protocol and packing your messages yourself, I suggest to at least have a look at Valve's GameNetworkingSockets either for inspiration of what you might need or even to just use the library: https://github.com/ValveSoftware/GameNetworkingSockets

There is early NAT piercing support in Valve's GameNetworkingSockets. Check out:

You can also try Valve's GameNetworkingSockets with a serialization of your choice.

Halo was mostly all about single player and early multiplayer/local multiplayer but their online netcode has sucked since Blood Gulch. Lots of games do networking horribly, I have been in gamedev making networking and I hate most of what people do. The ones that have a clean natting, based on enet style reliable UDP channels, RakNet style punch are better (RakNet was good until Facebook bought it). It has come a long way but also fallen back. Valve source netcode (on github) is probably the best and you can check it out here. They started with the best in Quake networking, then to Source.

Enet already talked about in the thread

Probably not. It says Enet runs over UDP, which Web Browsers / WebAssembly / Emscripten don't provide. Web browsers / Emscripten provide TCP only (source). That, and Enet probably calls standard UNIX / Winsock functions, which Emscripten doesn't have. ENet would have to specifically support Emscripten as a target platform.

Are you familiar with enet ? It's a popular C library which implements optional reliability on top of UDP.

The other that is the base of most networking libs today is enet, one of the cleanest C networking libraries you will ever find. The RUDP and channels in it were very nice.

Inconsistencies can be prevented by ensuring the server handles all operations and does so in a given order, then transmits the results to clients. I wrote a little about this for my game Avoyd a long while ago. Clients (including a client running the server) send an edit request via reliable ordered UDP (e.g. using Enet, Raknet, Steam Networking etc.) and the server places these in a single queue then performs the edits and sends the results back also using reliable ordered UDP.

I find this interesting. Vibe.d is async, but written in a sync fashion (in essence, the async is hidden in the i/o subsystem). For my class with grade-school students, I used enet (http://enet.bespin.org/) with a wrapper I wrote to automatically serialize messages.

A popular simple low level open source reliable UDP library is ENet.

-Improve the status of the Online Mode: This mode built with eNet, currently allows to create multiplayer races, but while it works acceptably well in a LAN, over the internet is unplayable presenting a huge lag, among other problems.