-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Using the Steam Runtime through SteamCMD? #638
Comments
scout
There are two main ways to do this. The first is a 1:1 equivalent of how the Steam client will normally run your game client, using the scout libraries as an overlay over whatever random host OS you or your dedicated server operators happen to be using. Download
The second is a "pure" and pedantically correct scout runtime (Ubuntu-12.04-based) container environment. To get this, fetch the OCI (Docker/Podman) image described in https://gitlab.steamos.cloud/steamrt/scout/platform, and (ask your dedicated server operators to) run your game inside that. A variation of the first way would be to fetch a container image for either Debian (e.g. |
sniper
For this, the easiest way will be to use the OCI (Docker/Podman) image described in https://gitlab.steamos.cloud/steamrt/sniper/platform. It is also possible to download and use SteamLinuxRuntime_sniper without using Steam, but SLR brings you a significant amount of complexity that is really only there to handle graphics drivers, which should be irrelevant for a dedicated server, and complexity means bugs - so I would recommend avoiding that, and using Docker or Podman instead. |
To the best of my knowledge, yes that's still the case. If there was a "self-service" mechanism to do this, it would be part of Valve's partner web interface, the same place you set other metadata for your game. |
I should mention that this option is only going to work if your game has been compiled in an equally "pure" build environment for scout: either the SDK Docker/Podman/Toolbx image described in https://gitlab.steamos.cloud/steamrt/scout/sdk (recommended since 2022), or an equivalent If you're compiling your game in a newer environment than scout (perhaps Debian 10 or Ubuntu 16.04 or similar) then it is already a matter of luck that it's working on end-user systems, and it certainly won't run successfully in the Platform container from https://gitlab.steamos.cloud/steamrt/scout/platform, so you will need to go one of the other routes. In the long term, you are correct to think that the way to get a newer build and runtime environment for new or actively-maintained Steam games will be to build and run them in sniper, the same way that Valve are now handling Counter-Strike 2 and Dota 2. For games that are already active/released, the way to do this is to transition a non-default beta branch first, (ask Valve to) swap that branch over to sniper, get that working to your satisfaction, and then (coordinate with Valve again to) reapply the configuration change in your default branch. I'm hoping that configuring the runtime to be used for your game can become a self-service thing that doesn't require Valve's help, but that isn't something that I have control over. Out of interest, which game is this? (But if you would prefer not to say in public while discussing its technical details, then I understand!) |
The game is Pirates, Vikings, and Knights II. We are using a Scout container and I do use docker/podman. I want to move to a newer runtime primarily to make developing on Linux easier. Unfortunately the GLIBC version of Scout is so old that using something like VSCode's devcontainer tools isn't really possible. Many years ago, I did try to do a build based on a newer Ubuntu image, but some server owner running CentOS with an ancient GLIBC version could no longer run it. This was before Soldier existed I believe. So, that's why now I'm really interested in what a better option is for our dedicated servers to run them in the runtime. I don't want to break anything for server owners. Based on everything you've said, it may be easiest for us to continue using Scout for now. I'm sure I could somehow modify our dedicated server's launch script to handle what the setup.sh and run.sh do. Technically I guess we could use Soldier, but the docs say you can't have a game on Steam using Soldier, and thus it sounds like Valve doesn't support that. I guess I'll just have to think some more about it. Thanks for all the information though. |
Technically soldier (Steam Runtime 2) is exactly "the same shape" as sniper (Steam Runtime 3), just older - it's based on Debian 10 rather than sniper's Debian 11. The reason why Valve is not supporting soldier as an independent target for native Linux games is to limit the number of actively used runtimes. Each container runtime that a user installs will cost around 700M, which is perhaps no big deal on a modern desktop/laptop or the current-generation Steam Deck with 512G+ storage, but adds up quickly if your gaming platform is an old desktop/laptop or the smallest model of the first-generation Steam Deck, which only had 64G eMMC. There wouldn't be much point in targeting soldier anyway: changing from scout to either soldier or sniper would take about the same amount of work, and if you're going to make that investment, you might as well get the benefit of libraries that are 2 years newer.
That's good, you're building your game in a supportable way. (Not all developers of native Linux games on Steam do, unfortunately! Thanks for being one of the supportable ones.)
Yes. For the Our exit strategy from this is to use the new container runtimes like sniper (which use namespaces/containers to be able to rely on a newer glibc without imposing new minimum requirements), and recommend those as the way of the future. But that needs a metadata transition, and I don't think you can do that in a self-service way just yet.
Yes, unfortunately this is expected. If you built in a newer environment (whether that means soldier, sniper or Ubuntu) and then ran in Steam's traditional In the medium to long term, the way to get out of this trap is to build and run your game in a sniper container, the same as games like Counter-Strike 2:
|
Is https://steamcommunity.com/app/17570/discussions/0/1698300679775227577/ your official guide for running PVK2 dedicated servers? I think it might be useful to have a template for a "how to run a dedicated server" guide for scout games, and the same for sniper games. PVK2 is free, so it seems like that could be a good game to use as an example. |
So, we have a dedicated server appid for a Source based game. Usually when people setup servers, they're installing the dedicated server through SteamCMD.
At the moment, we build with the Scout container and just kinda hope that the server runs even though when installing with SteamCMD, there is no Steam Runtime for it to run in. (A dependency on curl also makes this tremendously more painful)
I want to know if there's a proper solution to this. At the moment, we just kind of ship some of Scout's binaries (like for curl) and append their location to the LD_LIBRARY_PATH.
I would like to upgrade to the Sniper runtime at some point which is why this is important. We would need to somehow be able to run the dedicated server in the Sniper runtime. The last time I tried to build with a newer runtime, we had complaints from server owners because of the newer GLIBC. So, I would really like to be able to properly run this in the runtime.
Any information is greatly appreciated.
(As a side note, if we do upgrade to Sniper, the docs say to contact Valve as there is no method to set the Sniper runtime as the default for the game. Is this still the case?)
The text was updated successfully, but these errors were encountered: