Epic Games CEO Tim Sweeney has reopened one of PC gaming’s most durable arguments: whether Steam’s scale and developer services have helped build the modern PC market or made it harder for competing storefronts and ecosystems to thrive.
In a social-media exchange that began with criticism of Valve’s 30% revenue share, Sweeney argued that Valve has constrained gaming by placing developers’ PC releases inside what he called Steamworks’ “social walled garden.” His specific complaint was about communication between players: he said players could not talk to one another across iOS, Android, Xbox, PlayStation, Switch, other PC stores, and Steam.
That claim received an important correction in a community note. Steamworks documentation indicates that Steam Datagram Relay, or SDR, can be used on platforms outside Steam when a game also launches on Steam. The distinction matters because a complaint about a platform’s commercial leverage is not automatically the same thing as proof that its underlying networking tools cannot operate across platforms.
The argument does not settle the wider question of Steam’s position in PC gaming. It does, however, make the details of the technology—and the precise meaning of “cross-platform”—essential.
What is Steamworks?
Steamworks is Valve’s set of services and tools for game developers. In the current dispute, the focus is on its social and online components rather than a single store-page feature. Multiplayer games need practical systems for players to find each other, connect reliably and communicate. Developers can choose how to build and run those systems, and platform-provided services can reduce the amount of infrastructure a studio needs to operate independently.
That convenience can also create dependency. If a game’s matchmaking, friends functions, multiplayer connection path, achievements or other services are closely tied to one platform’s ecosystem, moving players between stores—or supporting them consistently across devices—may become more complicated. That is the concern behind the “walled garden” framing.
But “can be complicated” and “cannot be done” are very different propositions. The correction attached to Sweeney’s post centers on SDR, which Valve describes as a virtual private gaming network. The cited documentation says the relay system can be used on other platforms provided that the game releases on Steam. In other words, the available evidence challenges the suggestion that Steam’s relay technology inherently bars cross-platform use.
Why Steam Datagram Relay is central to this exchange
Multiplayer networking is often invisible when it works. Players see a lobby, invite a friend, join a match and expect the game to cope. Behind that ordinary sequence, the game must establish connections, account for varying home-network conditions and protect the experience from disruption where possible.
A relay network routes game traffic through intermediary servers rather than requiring every player to establish a direct connection to every other player. Valve’s terminology for SDR emphasizes the private-network role of that system. In practical terms, a relay service can be one building block a developer uses to connect players and manage the less glamorous technical work behind online play.
The key point in this controversy is not that SDR answers every question about multiplayer. It does not tell us, on its own, how a specific game implements voice chat, identity, friend lists, account linking, matchmaking rules or platform permissions. Nor does the confirmation of external-platform support prove that every Steamworks component behaves identically on every device.
It does mean that the broad claim that players cannot communicate across the named platforms because of Steamworks needs qualification. A developer with a Steam launch can use SDR outside Steam, based on the documentation highlighted in the community note. That is a materially different picture from an entirely sealed system.
Interoperability is more than one technical switch
Cross-platform play is frequently treated as a single yes-or-no feature. In reality, it is a bundle of separate decisions. Can players find friends using different accounts? Can they party together? Can they join the same matches? Can they communicate? Do progression and purchases move with them? Are the rules, moderation tools and parental settings compatible?
Those questions can produce different answers within the same game. A title might support shared matchmaking but keep account inventories separated. It might allow a PC player and console player into the same match while presenting different social menus. It might use a platform network for one function and a separate service for another.
That complexity is why arguments about platform lock-in should identify the layer being criticized. A storefront, a relay network, an account system and a social graph are related, but they are not interchangeable. The evidence here directly addresses the networking portion of Sweeney’s assertion. It does not independently resolve every debate around Steam’s broader influence, developer terms or social-platform design.
For players, the practical issue is simpler: whether the people they want to play with can join them without needless friction. For developers, the question is whether useful tools remain flexible enough to support their intended audience across PC stores and devices. Those goals can overlap, but they do not erase the commercial incentives of the companies providing the services.
The 30% argument returns
The latest exchange was prompted by Kiaran Ritchie, a former principal animation programmer at Epic Games, criticizing Valve’s 30% share of gross revenue. Ritchie characterized that share as a drain on the industry and argued that building a Steam alternative would be straightforward with enough modern development help, while Steam’s remaining value lay in its network.
The “30%” figure is doing a lot of rhetorical work in debates like this. A revenue share is the portion of a sale retained by a platform rather than paid to the developer or publisher. Critics see a high share as a tax on creative work and a barrier to better prices, investment or competition. Defenders may point to the platform services, audience reach and operational infrastructure included around the transaction.
The supplied information does not establish how those trade-offs apply to every developer, nor does it offer a side-by-side financial comparison between competing stores. What it clearly shows is that the dispute is not limited to a technical protocol. It is also about who owns the customer relationship, who supplies the network layer, and what a developer gives up or gains by joining a large PC ecosystem.
Ritchie’s suggestion that a rival can be built quickly also deserves careful parsing. A basic software client and a mature game platform are not necessarily the same undertaking. His own point—that the network is Steam’s lasting value—implicitly recognizes that player communities and connections are significant assets. The difficult part of competing with an established platform can be less about making a launcher open and more about persuading players and developers to use it together.
Steam’s role in the PC ecosystem complicates the claim
Sweeney’s criticism arrives against a backdrop in which Valve has been a major force in PC gaming’s move toward digital distribution. The company’s recent hardware and software efforts have also been associated with Linux gaming, including Steam Deck, Steam Machine and Proton.
Proton is significant in this context because it is tied to running PC games in a Linux-oriented environment. The supplied background describes Steam Deck and Steam Machine as leading efforts for gaming on Linux through Proton. That makes a sweeping statement that Valve has simply “held gaming back” difficult to evaluate without acknowledging areas where Valve’s work has expanded options for players and developers.
That is not a rebuttal to every concern about Steam’s market influence. A company can help create useful technology and still be criticized for the power it gains from its market position. Nor does the success of a handheld PC or Linux compatibility initiative automatically answer questions about store competition. The point is that the record presented here is mixed enough that a totalizing verdict loses precision.
The same applies to Steamworks. A suite of developer tools can lower barriers in one situation while making a studio’s ties to a particular ecosystem more consequential in another. The proper question is not whether a platform is wholly open or wholly closed, but where developers retain choices, what requirements attach to those choices and whether players are left divided by store or device.
Epic’s criticism comes amid its own AI-focused push
The exchange follows Epic’s recent claim that it had used “vibe coding” to make the Epic Games Launcher faster, as part of what it called a major turn toward maximum AI acceleration. “Vibe coding” is a loose term generally used for directing software creation through high-level prompts and iteration, rather than manually writing every part of a program in the traditional way.
That claim has its own competitive subtext: Steam had released a faster update the previous day. More broadly, it places the Steam argument alongside an industry-wide rush to frame AI tools as a route to faster development and better software experiences. Broader PC-platform changes—from AI messaging to hardware positioning—remain active elsewhere, as seen in recent discussion of AI and ray-traced gaming on desktop hardware.
For this particular dispute, though, the strongest takeaway is narrowly technical. Steam Datagram Relay’s documented availability on non-Steam platforms, for games that ship on Steam, undercuts the categorical version of Sweeney’s cross-platform communication claim. It does not make concerns about platform concentration disappear. It does require those concerns to be argued with more specificity.
Steam’s scale, Valve’s revenue share, Epic’s challenge to that position and the appeal of cross-platform communities will keep the fight alive. But the terminology matters. “Walled garden” is a powerful description of restricted choice; it should not substitute for identifying which systems are restricted, which are portable, and what developers must do to use them.
