GameNetworkingSockets VS Introducing .NET Multi-platform App UI (MAUI)

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.

I am migrating XF app into MAUI and writing a simple Navigation framework because Prism doesn't work well and I didn't use anything advanced anyway. So, I am surfing the code of MAUI to intercept all the back buttons, etc. I haven't found a single mention of apis related to predictive back "RegisterOnBackInvokedCallback", "OnBackInvokedDispatcher", "OnBackPressedDispatcher", "AddCallback", "android:enableOnBackInvokedCallback" Also I don't see any issue on github that would say "Support Android Predictive back". Only one kinda related https://github.com/dotnet/maui/issues/8680

Below issue is still reproducing in Maui .net7.0 version also. #10163

Maui is Open Source, MIT License

https://github.com/dotnet/maui

.NET is Open Source

https://dotnet.microsoft.com/en-us/platform/open-source

I do share your skepticism of Microsoft, but it looks like the economics and cash flow dynamics have changed drastically after the advent of the cloud.

Microsoft is more focused on getting developers onto its ecosystem and help them with open source projects with the hope that they will use its Azure cloud services and bring in the money.

My skepticism is a bit relaxed now and I have no qualms using .NET.

I hope I am not wrong.

It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work.

Avalonia[0] and MAUI[1] have known working templates with it, but YMMV.

[0] https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ / honorable mention https://github.com/VincentH-Net/CSharpForMarkup

[1] https://github.com/dotnet/maui (try out with just true in csproj - it is known to work e.g. on iOS)

While this is the quite endorsed by the community: https://github.com/dotnet/maui/discussions/339

I think the fundamental issue is that desktop Linux is way too fragmented. Not only just GTK2/3 and Qt but you have GNOME, KDE, XFCE, Cinnamon and then you have X11, Xorg, Wayland...

To be honest, all those craps are why desktop Linux never took off. I'm very safe to say MAUI for Linux will eventually renders components off its own using framebuffer and hardware acceleration APIs such as OpenGL or Vulkan just because of the market fragmentations...

If desktop Linux truly wants to get the attention, it will need to unify. Fixing dependency hell using Flatpak is the right direction.

There is an existing old fork of MAUI for Linux that uses GTK: https://github.com/jsuarezruiz/maui-linux

First I came across this Github issue: https://github.com/dotnet/maui/issues/9687 - According to this issue, this is a known bug for MAUI iOS, but it works OK for MAUI Android. As I said, I target Android only and I have the exact same issue. It's apparantly fixed with some of the latest versions for MAUI but the problem still occurs to me even with MAUI version:

I saw this and tried to imitate (ofc my lack of experience wouldn't allow me to do it in the exact way). Already found some documentation that allowed to understand better. Thanks for the insigh.

I implemented the Auth controller following this sample code from Microsoft.