Addon Extension Wrapper for linux and MacOS

0 favourites
  • 12 posts
From the Asset Store
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
  • Ashley I implemented: construct.net/en/make-games/addons/1124/steamworks-plus-webview2

    I'm thinking about adding some more features, but I wanted to check in with the roadmap for the wrappers for linux and macos. I'm wondering if the C3 Steamworks Webview2 addon will add support for the linux and macos wrappers and the possibility of making steamworks-plus also support them or whether there is a different approach.

  • As of today's r412 there is support for wrapper extensions with the Linux export option, which the official Steamworks (formerly "for WebView2", but dropped that part of the name now) add-on plugin uses for Linux/Steam Deck support. The code on GitHub for both the wrapper extension sample addon and Steamworks now include the source code changes and build instructions for Linux (a pretty straightforward minimal CMake setup).

    We're aiming to get wrapper extension support for macOS in the next release cycle, so at least a couple of months away for that, but then the Steamworks plugin should work on all of Windows, macOS and Linux. After that we'll be looking at the feasibility of dropping support for NW.js entirely, but we'll be asking for community feedback on that at the time, and I suspect we will be supporting NW.js for quite a while longer to ensure nobody with important projects gets left unsupported.

  • That's great that there is now Linux support for Steamworks (and thanks for sharing the development of the addon in github, so I can use it as a model.)

    I do wonder if I should continue with my Steamworks Plus addon. I see that you added DLC support, which overlaps with some the DLC support in Steamworks Plus. While they should not interfere with each other, I do think with our limited time - I don't want us to duplicate work.

    What is your suggestion here, do you expect to continue adding more features and I can just deprecate Steamworks Plus (and move on to other work, fine by me) or is there another way where we won't be doing overlapping work. I know you want to keep 3rd party devs away from the Steamworks repo, but I am wondering if that is another alternate, where there would not be overlapping work.

  • I'm happy to keep small and simple APIs in the official Steamworks plugin - or even accept pull requests for them if they are limited in scope. The contributing guidelines are mainly about our reluctance to merge large, complex changes, as it's likely we end up obliged to maintain those changes indefinitely. I don't currently plan to implement the more complex APIs like UGC, networking/matchmaking, or the full remote storage APIs (I think auto-cloud should be fine for most games anyway). So if you have small simple changes, you can propose those to be merged in to the main plugin, but for the larger and more complex stuff, a companion plugin is a better option.

  • Thanks, good feedback. I know where to focus.

    What environment do you usually test regarding Linux CEF and wrapper extension and testing?

    I tried out wsl2 on Windows 11 (I installed Linux Steam from steampowered.com). I got Steam running and signed in, exported the Steam test app with the latest addon, downloaded zip to wsl2 unzipped on wsl2 (ubuntu 24), and ran the test from the command line (and from Steam using add game). The C3 app loads and runs fine (correct display), but Steam is marked as unavailable.

    I followed these directions: construct.net/en/tutorials/exporting-linux-steam-deck-3155

    However, it looks like the wrapper extension is not loaded. I connected via remote debugging, but the JS side does not have it on its list. I can launch other Linux Steam Games.

    I also see steamworks-x64.ext.so and libsteam_api.so in the x64 dir w/ the app.

    I also tried on Ubuntu 22 and got the same result (on a Parallels VM in MaCOS)

    I know you at least have it working on Steam Deck, but that's a more complex platform to debug new work. Do you have a recommendation for another environment or something I might have missed?

  • I set up dual boot to Ubuntu 22 LTS. WSL is good for command-line stuff but its support for GUI apps is clunky and a bit weird - I don't think it's worth using. A VM should probably work as well, but I just boot in to a real system to remove any complications from VMs (particularly around GPU drivers, which seem to not always work so well in a VM, and Linux has enough trouble with GPU drivers as it is).

    I'd note the OS version you build on has significant compatibility implications: due to the way glibc seems to work on Linux, it requires the glibc version of the system you build on - so in short it won't run on any older OSs than the one you build on. This seems to be a particularly horrible aspect of Linux development: use too old a system and all the compilers are out-of-date and you might not be able to build anything at all, but if you choose too new a system it won't support some older OSs still in use. You can work around this with various options for virtualization, building your own toolchains, or integrating runtime environments (Steam has one) - I researched those and they all look like a total nightmare. So I just use Ubuntu 22 LTS and build on that and it seems good enough and the right balance between old and new.

    Also you have to install Steam directly from steampowered.com (I noted this in the Steamworks documentation). Ubuntu's app store has Steam, but if you install it from there, integration doesn't work. I haven't looked in to this too much but I'd guess that Ubuntu's app store uses some kind of emulation to install the Windows version of Steam and be able to run Windows games, whereas the official version is a genuine Linux version; as Construct's Linux export is a genuine Linux export, I guess it can't talk to a Windows emulated version. Just a theory though. To help debug it you can run the exported Linux app from a terminal and you should see some messages logged to the terminal about whether the Steamworks plugin was able to initialize. If it doesn't load it at all, probably something else is wrong, like the .so was built incorrectly (e.g. perhaps built on a system using newer glibc or something like that).

    Fortunately it looks like Valve have done a good job of making the Steam Deck easier to work with - obviously you can't do things like install the wrong Steam, its glibc is pretty up-to-date so that doesn't cause a problem, and generally if it runs on Ubuntu it just works on the Steam Deck too. I don't think I had to actually change anything at all specifically for the Steam Deck.

    For IDEs, I just use VS Code - I'm already familiar with it, and if you install the C++ and CMake extensions you can build, run and debug in VS Code, and it's good enough. Of course you can use different tools, build setups or whatever, but in my limited experience you quickly end up going down a rabbit hole doing things like spending hours configuring a build system to build a custom tool to build something else, and I'd rather do something straightforward so I can actually get real work done.

    In short I learned a lot about Linux development, and it's overall a huge pain, and no surprise lots of people don't bother (sorry Linux fans - at least sort out the glibc situation and the whole thing will be a lot better). However I focused on getting as simple and straightforward a setup as possible, and that makes it tolerable. Perhaps I should write this up in a blog or something.

  • Thanks for the reply.

    I think I have met the requirements, but I will recheck.

    My first experiment on actually running a c3 app in Linux was:

    - Only using the Steamworks addon that you created for Linux. So the .so is from your build (in 22 LTS) (I have not added my linux addon extension yet)

    - Ubuntu 24 (wsl), I have GUI working ok; I had to uninstall some PKG to make the windows open quickly.

    - I downloaded and installed the .deb from steampowered (which required more pkgs to be installed to run)

    - I got the results of the extension library not being listed in JS

    - I then tried the same on my ubuntu 22 LTS VM install and same result.

    I will try using Steam Deck next, using partner.steamgames.com/doc/steamdeck/loadgames, which looks like a 'fun' process. Steam can be so convoluted.

    In general, I feel like I must be missing a step or something, but will keep at it.

  • Did you try running from the terminal to see if any errors were logged there?

  • Yes, I did, didn't see anything too interesting. I will try a dual boot setup.

    I did download it to a steam deck and as expected, that worked, so that's good.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I got it working in wsl.

    I had to revert wsl to Ubuntu 22 LTS, and then the Scrirra C3 Steamworks plugin worked.

    I then compiled my Steamworks Plus extension on Ubuntu 22 (instead of 24), which also worked on wsl Ubuntu 22 (I imagine it will work on Steamdeck).

    As you mentioned about Linux, it seems like a backward and forward compatibility issue. What a mess.

    I've seen comments about compiling differently, statically linking libs, etc.

    Thanks for the model on how to do the linux port, very helpful for Steamworks Plus on linux.

  • One other item I had to update while testing on another system:

    patchelf --set-rpath '$ORIGIN' Steam_plus_x64.ext.so
    

    I don't know if you also had to do this, or there is a parameter I am missing in linking to handle this.

    This change made it possible to search locally for other needed *.so files (such as libsteam...), instead of hardcoded paths.

  • Updated Steamworks Plus for Linux CEF export (Ubuntu 22 tested.)

    construct.net/en/make-games/addons/1124/steamworks-plus

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)