fix: changes required for apple silicon / macos

[jolexxa]

This was based on chandlerpl's fork with additional fixes by @TheDevRatt.

[TheDevRatt]

Dropping a comment here to note that these fixes helped the issue of Steamworks.Net not functioning on Apple Silicon based Mac's.

The bulk of the code is based on Chandlerpl's fork as Jolexxa mentioned with a minor error being resolved within the BuildTargets file to ensure that the DLL's were assembled correctly without any errors when building.

Furthermore, I validated the functioning of these changes within the Mono Version of Godot 4.4 and was successfully able to connect my Windows Desktop to my M3 Macbook air without any issues on a sample scene utilizing a rudimentary lobby system.

Some further notes:

• The addition of net8.0 within the <TargetFramework> tag may be able to be removed together entirely, its likely just an artifact of when I was building based on the net version I had installed on my system. I'll perform some further tests tomorrow and write a new comment (and some screenshots) of everything I have set up.

[rlabrecque]

Awesome!

Instant merge if you confirm the TargetFramework piece could be removed; I do think that might be an important change in a separate PR

Should be noted this is only for the "Standalone" non-Unity builds

[TheDevRatt]

Okay! So confirmed that the inclusion of the TargetFramework piece was just an artifact of chandlerpl's fork I have since removed it and everything still functions as expected. Regardless, allow me to demonstrate the initial problem and proof of functionality after a brief run through of my set-up before outlining what was failing.

In the above image, I have created a rudimentary scene with a simple button and two labels to demonstrate a connection to a steam lobby utilizing the AppId of a game I currently have in development. SteamManager.cs is a "Global" file within the scope of the project and the .csproj file is set up to move the appropriate dll's to the root of the game folder upon compilation (a quirk of the Godot game engine I believe, it requires the dll to be in root rather than finding it within the addons folder).

Note for any readers out there: (SpaceWar unfortunately does NOT work on any Apple Silicon based Macs due to it being a 32-bit game. It requires bootcamp or a pc to use even for development purposes, so this is really the big caveat for all standalone users attempting to utilize Steamworks.Net.)

Digression aside, before even attempting to build the game for any format of testing, the Godot game engine fails in loading the required .dll's that permit the usage of Steamworks.Net within the scope of the project. Any attempt to compile or utilize the Steamworks API fails unceremoniously and the indie dev is left helplessly distraught at the loss of their perfect image of a brand new fps shooter or something. (I swear that Fortnite clone would have been amazing).

Cue the basis of Chandlerpl's <Platforms> and <ToBuilt> addition for arm64. although I had also noticed there was also the inclusion of teeniest tiniest minutest issue in the BuildTargets file that wasn't creating a file path appropriately, fixing this and removing the error that had resulted during the build process, that was my addition to this great endeavor to getting everything working on Arm Mac's.

Lo' and behold, upon rebuilding Steamworks.Net with these additions and overwriting the dll's that were already present within your latest release using the newly built files, this glorious scene is presented to us. Me and my alt account (insert no friends joke here) seamlessly connected inside of a steam lobby with a few chat messages being sent to one another to boot!

Pardon the censoring of the User Steam Id's, don't know if they're necessarily important but figured I would just to be safe.

[jolexxa]

@TheDevRatt thank you for the write-up!

@rlabrecque not super related, but I noticed there weren't any GitHub action workflows — can I ask how you're triggering releases and what the process is? We're potentially interested in helping make an automated release workflow that will also publish to nuget.

[rlabrecque]

I ended up cleaning this up locally just to squash the TargetFramework in the initial commit; but this is in!

Edit: Sorry this looks red; was hoping if the PR # was in the commit message it would auto close this as merged :(

[rlabrecque]

As for the release process; it's horrible and gross, primarily because it requires running the python generator then compiling the "Standalone" dlls; then we run the TestGenerator, compile the TestGenerators, run them and diff the output, then compile both StandaloneTest and StandaloneGameServerTest. Finally we copy all this into Steamworks.NET-AssetStore to make the old .unitypackage; then we build the zip for github.

Nuget is it's own thing from this point.

I think we could probably nuke the unitypackage now which is the only reason I never bothered with any CI on this project because it required Unity installed with an active license. I wonder if it's even still supported on unity 6+.

A general question I have for ya'll is what's with the uptick in usage of Steamworks.NET especially outside of Unity in the last ~6 months? A year ago I basically assumed usage was downhill as Unity went downhill.

[jolexxa]

@rlabrecque Thank you!! Glad it's in. And yeah, that's quite the janky release process. Sounds like a lot of history there...

I'm not sure I can pinpoint why Steamworks.NET popularity is improving, but I can give you a little background on what we're up to.

For the last few years, I've been organizing Chickensoft, an open source ecosystem / community for Godot + C# devs. Even well before some of Unity's recent reverse publicity stunts, I had begun advocating for mid-size indies to adopt Godot & C# once I realized how good of a combination it was (e.g., here, here, and here if you are interested). I've also been releasing opinionated tooling built around Godot in C#, too.

@TheDevRatt joined up with us recently and is building out a happy path around Steamworks integration and dogfooding it in the game demo that we maintain. We have identified Steamworks.NET as currently being the best choice for integrating Steam with Godot + C# games and will endorse it as such once we have proven out a happy path. We based our decision on the following:

• Facepunch.Steamworks did not seem particularly well supported.
• GodotSteam is incredible, but GDExtension support and C# integration in Godot is not there yet. It's terrific for folks using GDScript, though.
• Steamworks.NET was already very close to being a perfect solution (I'd gotten it working a while back in the Godot 3 era on macOS, Windows, and Linux, but Godot 4 moved away from mono to .NET and it was no longer working on mac — hence all this).

Anyways, I would expect Steamworks.NET adoption to continue growing — we're big fans!

[khyperia]

Hmm. I don't have access to an arm mac right now to test, but the fact that Steamworks.NET.Standard.csproj had this line added:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'OSX-Linux|x64'">

seems a little suspicious. That exact condition is repeated just above the added lines. Shouldn't it be:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'OSX-Linux|arm64'">

(Apologies if this is a completely wrong/irrelevant comment!)

[TheDevRatt]

Thank you @rlabrecque and @jolexxa for your help in getting this off the floor and merged in! Pretty confident that Jolexxa hit the nail on the head with regards to the uptick in Steamworks.NET usage. This is by far the most complete and functional implementation out there for C# at the minute, so likely a lot of Unity Refugee's that have moved to Godot still utilizing and exploring the tools they are most familiar with.

@khyperia - You're absolutely correct! I can't believe I didn't notice that at all. I had been so confused as to why there were still minor build errors when compiling the dll's and that would definitely be the cause. If @rlabrecque could change the repeated condition to arm64, everything should build nicely, (despite the fact that the dll's still worked just fine for MacOS regardless, for some reason).

Thanks again everyone, I'm sure a lot of people are going to be very grateful for this fix.