Valve's documentation highlights the different ways standalone games run on Steam Frame

With the upcoming new Steam Frame hardware from Valve, they want to get as many games as possible running - and there's multiple ways for developers to do it.

This documentation actually went up last month, but it's a good reminder of all the work that goes on behind the scenes with Valve's hardware to make the experience as smooth as possible for both players and game developers. With the Steam Frame, Valve are clearly suggesting that developers stick to one version of their game - which currently for a lot of VR titles means just optimizing the Windows version.

Taken from the Steamworks page:

We think customers are better off if a developer can focus on the one best version of their game, rather than making and maintaining many separate builds-- especially if one build ends up as a second-class experience missing some testing or updates. We've spent a lot of effort making it as easy as possible to run that best version on Steam Frame. For most developers that probably means running Windows x86 via Proton and FEX.

For VR developers that have already spent the effort to make a mobile optimized version of their game for other hardware (typically Android Arm64), we think it makes sense to run that version on Steam Frame.

Steam Frame natively runs a Snapdragon 8 Gen 3 (Arm64) chip on SteamOS (Linux Arch-based) and includes a range of compatibility layers for other Operating Systems and architectures.

Windows via Proton

Windows games can be run via Proton. Proton is a compatibility layer that allows Windows games to run on Linux by using a modified version of Wine and a collection of high-performance graphics API implementations such as dxvk which translates DirectX to Vulkan (Steam Frame's native graphics API).

Android via Lepton

Android games can be run via Lepton. Lepton is a compatibility layer that allows Android games to run on Linux. It is implemented as a container to minimize overhead.

x86 via FEX

x86 (32-bit and 64-bit) via FEX. FEX translates x86 compiled games to Arm64 instructions, but forwards API calls to native host system libraries like OpenGL or Vulkan to reduce emulation overhead, and leverages code caching to minimize in-game stuttering as much as possible.

All makes sense to me. If you already have an existing version of your game that runs elsewhere, just ensuring it works well in one of their compatibility layers would save developers a lot of time. Valve are being smart with this, after years of building up the likes of Proton and directly funding FEX to get as many games running on SteamOS Linux as possible. We've come a very long way since the original Steam Machine failure with its lack of games.

Valve's little note about other builds often being a "second-class experience" also split a few old wounds. Remembering some of the earlier days of Linux gaming where we had a bunch of ports that were repeatedly missing features (like cross-platform multiplayer, or patches being weeks and even months later - or not getting them at all).

As long as the price is right, I think the Steam Frame really will shift the industry due to how accessible and open it will be. Something I touched on in another recent article.