Posted on

The Steam Trade-off as a Linux User

With the excitement around Epic launching their own store and the advent of fresh competition for Valve’s Steam, here are some thoughts from a Linux gamer perspective.

First, what is the meaning of Steam or any storefront? They are a middleman, providing a marketplace for games to be bought and sold. But they are also a steward of that market, providing a common tissue for the delivery of the games, for the discussion and discovery, and all these other features. Some have more popular off-platform competitors. Others are too ingrained in the platform to be competed on without an alternative platform.

But one of the thing that Valve is doing with Steam, which it seems unlikely that Epic or any of the newcomers will do, is to spend resources in the interest of Linux-based gaming. They have supported Linux for several years now, including for their own games. They are doubling-down on this support with the SteamPlay/Proton integration that allows for Windows games to be run on Linux through an implementation of the Windows APIs.

Part of what you pay for when you pay the “Steam tax” (or the “Epic tax” or any other share of a sale that goes to an intermediary) is for the other activities a platform or marketplace delivers. Whether that’s Linux support or community forums or ARGs, the business decides what to deliver and thereby justify their fee.

The option of going to Epic’s store, or to other stores, is weaker for Linux due to lack of support. Steam deciding to make Proton such a first-class offering only makes that proposition weaker. For Linux gaming at the moment, Steam is the most attractive option, and there are no signs of that changing soon.

Steam currently supports gaming for Linux, but if they didn’t, Linux gamers would keep using WINE directly, as we did before 2013. As long as Valve is investing in Linux, though, their tax seems like a fair deal for Linux users, when the alternative is Epic’s lower tax but nothing for Linux.

Posted on

With WINE, Buying Unsupported (?) Games on Steam

Interesting news that Valve has developed and integrated a WINE fork called Proton into the Linux version of their game launcher. The consideration now becomes whether to buy games that work through this compatibility layer but don’t otherwise support Linux.

There are always a lot of people on forums that speak of dual-booting, and that class will mostly buy games regardless of Linux support. For them, lack of Linux support was never a deal breaker, even if they would have liked to have support. Game access comes first, and they’ll be happy to keep buying the games they want, playing them in a Linux environment when they can.

There are people that have used WINE or similar layers all along from Linux, and they would buy whatever games they liked that they could verify would work via the WINE database (plus natively supported games). For this group, access via Linux, by any means, comes first. But they’ll still happily keep doing their thing.

There are also plenty who will want first-class Linux support, and that group is harder to judge now. If a game’s support is via WINE/Proton, does that count as first class? Especially if they are willing to fix bugs that arise, either by contributing to Proton or by changing their own game. One issue there is that updating games for Windows to fix bugs for Linux seems weird. It’ll be up to Valve and developers to decide whether having a “Windows-WINE” flavored repository makes sense for developers that use that approach.

But I digress. Some of the purist camp will not want to play games via compatibility, but if the developers signal they support Linux through WINE/Proton, others will consider support support.

The main long-term benefit of adding a compatibility layer may actually be bigger than Linux gaming. Due to WINE’s potential for portability, there may be places that Windows games end up working in the distant future that nobody planned on.

I installed and tried the old Katamari Damacy clone, The Wonderful End of the World (Dejoban Games). It worked just fine. There were only one or two models without rendered textures (black instead), and only one occasion where mouse-capture was partially lost (alt-tabbing out and in fixed that).

When I get a chance, I’ll try some other games I haven’t played in the years since I left Windows. I suspect most of them will mostly work.

Whether I’ll buy games that work through “Steam Play,” I haven’t decided just yet. I’ll certainly consider it, though.

Posted on

Why Valve is Doing SteamOS

Lots of people question why Valve wants to make SteamOS, Steam Machines, Steam Link, Steam Controllers. But Valve has been pretty open about their reasons. They are in several businesses:

  1. Making games
  2. Making game engines
  3. Selling games

They probably make the most off the third, but they still do the first two. But the third is a driver of decisions for them. They surely ask, as any business, “how do we expand?” To sell more games requires more people buying games. And as the PC declines a bit, that means other platforms.

Mobile, although increasing in power and certainly ubiquitous, is not currently a prime target. The living room is. The living room is a proven gaming environment. The living room has the big screen and the comfy couch. It makes a lot of sense for a gaming company to want to be there.

This same logic is driving decisions about engine design, not just for Valve but across the industry. Making content easier to create means a larger market with more lottery tickets to win consumer dollars. It makes the platform broader and expands what gaming means. So does game streaming, which is becoming more popular.

Other businesses could learn a lot from Valve and the gaming industry in this regard. Building out transport and lowering the friction to relocate to new opportunities would do wonders for the economy. Valve is doing both of those, in their own way, in their own market, with SteamOS.

By making a living room PC platform, they’re bridging a divide between two long-isolated groups: console gamers and PC gamers. With SteamOS in the living room, people will actually be able to play against mouse-and-keyboard gamers (either with a Steam Controller or with a mouse and keyboard).

At the same time, the console makers are pushing their own initiatives to do the same. But at present it’s not clear if you will be able to buy a game for a console and play it on a PC. And even if you can, how widespread will that option be?

Valve has some challenges. They have to make sure the SteamOS platform has feature parity with consoles. That means video streaming and music. It means actively courting games to be on Linux and making sure drivers are up to the job. It even means working on better APIs like Vulkan to ensure a cleaner development-to-market process.

But they have advantages as well. The Steam Machine market is a market, not a single offering from one company. Consumers can decide when to upgrade, how much to spend, and so on. They’re delivering competition and choice to consumers and betting the consumers will make the right choices for them.

At the end of the day, Valve is working to expand their market. They are doing that to make more money, but they seem to be doing it in a way that is smart enough to mean more money for others too. And that’s what good capitalism should focus on.

Posted on

Thoughts About the Heavy (and Medic) in TF2

A lot of people think the Heavy Weapons Guy needs balancing in Team Fortress 2. Often seeming underpowered for gamers used to the pace of a Soldier or Demoman, the Heavy seems due for a buff (an increase in his abilities).

Meanwhile, the high-skill Heavy players present a huge challenge to that idea. They mow down whole teams, so the notion that a direct improvement of Heavy’s items can suffice misses the problem that Valve faces. If they direct-buff the Heavy, the skilled players will only become that much harder to beat.

Back before TF2’s Heavy update came out, Valve’s design problem was how to make Heavy less reliant on a Medic. The Heavy-Medic combination is very powerful, but lots of times there isn’t a Medic to help. So they added the Sandvich to compensate, and let the Heavy roam free of a Medic.

While that was itself a positive move, there was likely another side to that design problem: how to get more people playing Medic. Medic stands apart from the rest of the classes in being almost purely support. Medics do not get the same sense of achievement (that of actually getting frags). They can provide major help to a team, but without that reward of a kill it’s harder to quantify their ability.

If you play Soldier on a losing team, you can still see if you got a lot of kills and points. You made some difference. A Medic doesn’t have the same feedback, and being the one player that counts on others’ abilities makes Medic a niche class. Even using the Medic’s big ability of an Übercharge (making a teammate invulnerable for a period of time) still counts on them doing the killing.

A game like TF2 requires at least some damage-heavy classes. Too many Snipers or Spies sinks a team very quickly. There is something of a food pyramid to team construction. Roughly:

  1. Soldier, Demoman, Pyro
  2. Heavy, Engineer, Medic
  3. Scout, Sniper, Spy

It varies a bit by game mode, map, whether a team is attacking or defending, and a player’s skill in a class. But that’s the general shape of things. The first tier consists of classes that are good at dealing a lot of damage both offensively and defensively. The second group is area denial, slow pushes, support. The third is countering, distracting, and slowing the other team.

But skilled players can take their class of choice and push it up to the top tier, which is why Valve has to be careful about a buffed Heavy. If they found the right alternative (akin to Demoman’s shields), Heavy could straddle the line a bit more without making him too good for the skilled.

On the other hand, they could seek to tweak the Heavy to make him sit more securely in that second group. That would mean the players that can currently turn Heavy into an offensive powerhouse would find him in a more support-oriented role. It might not go over too well, but if that change involved new toys it might.

As for the Medic, it’s not clear what such an alternative would look like. Back in QuakeWorld Team Fortress the Medic could infect enemies. It’s not clear if that mechanic would do much or be something Valve is interested in reviving. Others have suggested making Medic a walking dispenser, but that would be overpowered unless the ammo dispensing capabilities were fairly limited. My guess is that a dispensing Medic is partly borne from the desire to see Medic have something more to do than just healing and Übercharging.

It’s also clear that the team pyramid is a good thing in itself. Small games need damage classes. Larger games need diversity of classes. I don’t think Valve will move away from that general landscape.

Posted on

Steam on Linux: Half-Life

It was the mid-to-late 1990s. Computers were becoming more popular, and computer games with them. In the early 1990s there was Myst. It was about the story, something like Zork but first-person. In 1996, there was Quake. It was about battling baddies, like its predecessors, Doom and Wolfenstein.

Around that time, Valve software must have licensed the new Quake Engine (the underlying software that created the Quake world on your computer). In 1998 they released Half-Life. It was in many ways a closer marriage of the first-person shooter with the story games and puzzle games that came before. Around a two-to-one ratio. Lots of action, but a bit more story than before. You had Non-Player Characters (NPCs), which are presences you don’t kill, either neutral or allied with you. You had movable boxes.

It’s a game that paved the way for a lot of the modern games.

Every discussion I saw prior to the announcement came to the conclusion that we probably wouldn’t see this happen. Most of those centered around Counter-Strike 1.6, which uses the same GoldSrc Engine as Half-Life. The feeling was that Valve would focus on their newest titles first, and worry about these oldest games later, if ever.

A few years back, Valve began opening up to the Apple Macintosh systems, and most of their new games made their way over. But never the old ones. With this release, those systems now have these oldest games too.

One wonders why. When the first news of Steam coming to Linux arrived, it was published that their title Left 4 Dead 2 was their vehicle of experimentation.

When the beta began, it was instead Team Fortress 2. That made enough sense, in that it’s free-to-play. It meant they didn’t have to give away a game that beta testers might have bought. It wouldn’t be costly to give the game to a few, in a small, closed beta. But when you open it up in the large, to a largely untested audience, it risks some loss.

Valve is very committed to the Linux platform, especially with the announcement of the forthcoming Steam boxes, basically set-top computers. They want to be as catalog-complete to help drive adoption. They also had the opportunity to hit two platforms at once, which wasn’t there when it was only Apple Macintosh.

Finally, with their flagship game sequels coming, they want to be able to have people play the original. There is a certain aspect to human psychology that values completeness. People want to have read every book, seen every episode. They want every achievement, to have left no stone unturned.

The question now is when we will see the rest of the Valve catalog for Linux. My guess is by summer. They probably don’t have as much work with the newer games which have all been ported to Apple Macintosh. There is some work, yes, but a lot of it will be simply replicating previous work. They are likely targeting those releases for the time when the Steam platform leaves beta.

Other tasks will take longer, including their plans to release their SDKs for Linux. That will mean porting work that hasn’t been done for the Apple Macintosh systems. These will be very welcome, as they will mean both new blood into the mod/mapping/development community and faster compilation of assets.