Tag: steam

Steam Library Update—A refresh of the Steam client akin to the refresh of the Steam Chat that occurred in 2018.

New Events System—A way for games (and groups?) to announce non-release events to their followers.

Steam Chat for Mobile—Apparently a separate app that includes the upgrades to Steam Chat on the client.

Steam Trust—A provider-side reputation system that helps games moderate their players better.

Valve-time being a thing, we’ll see if these rollout this year (there were others, but these were the ones that interested me).

Library update

The Library refresh has been pending for several years and is long-expected and desired (though undoubtedly subject to backlash by a vocal minority). Games have changed a lot over the years, but the Steam Library view has stayed the same, so it will be interesting to see what this ends up looking like. It will also be interesting to see if there’s any visual-crossover between the refresh of the Library and Big Picture Mode.

At least some of the facilities mentioned in my recent post about instrumenting games for streaming could be useful for a future version of the Steam Library. For example, logging capabilities in games could easily populate the game-view in the library with details from your last game session.

Events system update

The events system is primarily an opportunity to let developers remind players about their game over time, in ways they largely already do on Twitter, but where many players may not see them. It’s not clear if the event system will apply to groups as well. Groups have been able to announce events for awhile, but if they’re granted the same abilities under the new system, it could be a shot in the arm for social-on-Steam, particularly when many gamers are far more reliant on Discord.

A full-featured event system could even let non-group events happen in the vein of “bowling night” among friends. If a group of friends likes to play together at a set time every week, Steam could enable that without them needing to create a full-on group. If game makers wanted to encourage that among players, they could also be empowered to do so.

Steam chat for mobile

The advent of a separate app for chat seems unwise (the language in the announcement is: “We’re going to ship a new Steam Chat mobile app…”). Hopefully they mean that they’ll ship a new version of the Steam app that includes chat upgrades. If not, oy. There’s a new contender to replace the old law that all applications expand to encompass e-mail: all providers expand to release a mobile chat application.

Steam Trust as a service

And Steam Trust will be welcome to the extent it helps reduce griefing and cheating in multiplayer games.

The Steam Client Beta for Linux added a force-Proton option on 17 January 2019, which is great news and shows that Valve is hitting the ground running this year. The option allows Linux gamers to choose to run the Windows version even when a Linux version exists, which may help in some circumstances:

Bad ports—Not all Linux ports of games are up to snuff.

Upstream bugs—Whether in the game’s engine or a video driver, sometimes bugs in other places break the native version, but not the Proton version.

Missing features—Some ports are great, but for whatever reason miss a feature or two. Being able to use the native version for just those cases is a great option to have.

There are arguments about whether Proton diminishes the desire of developers to write Linux-native games or to invest in ports to Linux, but Valve’s strategy is two-fold:

Get people playing on Linux, especially those who already love Linux but feel bound to Windows for a few games.

Invest in Vulkan and other technologies that lower the cost of writing cross-platform games.

The latter is especially important, as games that aren’t written for Windows-specific APIs are much easier to port to Linux. It’s a longer-term strategy, but it should pay off both in better game performance generally and in portability.

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.

Valve’s Steam service is set to roll out an escrow on non-two-factor-authorized trades. They are calling this a “Trade Hold.”

Alice wants Bob’s hat and Bob wants Alice’s key. They agree to trade.

Alice has Steam Guard Mobile Authenticator (SGMA), Bob does not. After the trade, they wait three days to get their items.

At this point, it’s unknown whether Alice could know at the point of trade whether she was risking the trade hold. It seems likely she will, and thus she could avoid it.

Problems with the system include:

People without Android or iOS devices being unable to use SGMA.

Automated trades via bots being unable to deal with escrow without major changes.

People feeling that, generally, they are being disadvantaged due to a minority of users who fall for scams or install malware.

Valve has a scam/malware problem masquerading as a customer service problem. They have looked at improving customer service, but correctly realize that will not really solve the problem. They do need better customer service, but they also need to do more to address the problem of fraudulent trading. The escrow is supposed to be a pressure valve, to relieve some stress by limiting the damage that fraud traders can mete out.

Education of users is important, but simultaneously unrealistic short of Valve creating a trading simulator game that people want to play and it teaching them the hard-learned lessons of what to avoid. Users that would be helped by education either already educate themselves or will be a minority. Forcing education (e.g., through testing prior to granting trade privileges) would deter users from trading altogether.

Previously, Valve has used e-mail confirmations. This failed for hijacked accounts, because the users would simply have their e-mail accounts compromised in the hijacking. SGMA differs in that the likelihood of also compromising a mobile device is much lower.

If machine learning is mature enough, Valve may be able to leverage it to identify fraudulent trading patterns in a bulk of cases, in a manner similar to the credit card industry. It isn’t clear if it is up to this task, nor is it clear how easily Valve could implement such a filter. It seems reasonable to expect that will be a large part of their eventual strategy in fraud prevention.

What does not seem likely is Valve Customer Service becoming a peudo-law-enforcement agency. Investigating claims of fraud and trying to uncover the realities of events after the fact is just not in the cards for a video game services company. They will undoubtedly continue to seek to prevent the fraud.

It seems reasonable to say nobody wants to wait three days for a trade to go through, including Valve who will have to keep track of the trades. But Valve also does not want to have the volume of scammed items and problems sustain their current rates or grow. So they have to keep trying stuff, even if the community feels burdened.

Some minority of users may circumvent the protections of SGMA via emulators and desktop applications implementing the HMAC technology that SGMA uses. It’s a risk, and there doesn’t seem to be a easy way to avoid it, but that user count will likely stay small, sustaining the general integrity of SGMA/trade holds.

So I’d written a piece that painted the paid mod controversy as a new alternate-reality game by Valve. But since the whole thing is on hiatus, I guess it won’t work.

What can be said, instead?

I think Valve is right about the inevitability of paid mods and having a more fluid system for moving works online from free to paid. They just didn’t have a very successful rollout. Part of that was the 75% rake between Valve (30%) and Bethesda (45%), leaving the mod maker with the smallest share (25%). Sure, the money spends for a mod maker that would otherwise get none, but it rubs the buyer the wrong way.

There’s a lesson in that. If other semi-predatory industries like the music industry had a more prominent display of how little the artists get out of your $15 album purchase, it could shake things up a lot. And that goes for other industries like farming, clothing manufacturing, and so on. If people know that workers are getting screwed, they’ll at least make a stink. If they can just ignore it, because it’s not in their face, they’ll tend to ignore it.

There were issues with misappropriation of others’ mods. Valve will have a hard time working out a perfect model for derivatives and dependencies on the legal side of the issue. But they can at least push for better technological integration of mod dependencies in games.

And Valve is right to glimpse a future where games themselves might be seen as a greater-than-the-sum-of-their-parts assemblage of mods. Something like a patchwork quilt that you play on a computer. That future will come to pass in time. It won’t be exclusive, other non-mod-based games will exist. But it will live alongside those games, both feeding off them and feeding into them.

In the meantime, it appears that the factions I’d described in the hypothetical ARG seem to be here to stay. We will probably see mods that will license themselves only for use with free mods, for example. While others will say they’re happy to be used by paid mods.

But paid mods do give modders an incentive to work and a mechanism to buy work from others to make their own mods better. If you’re doing free mods exclusively, you might want to get some better textures or models, but have to take what’s free. If you sell the mod, however, you can afford to hire professionals to augment your abilities (e.g., if you’re writing code, you can pay other professionals can do the art) make that mod a bit better for customers.

The other thing this whole incident reminds us of is that we will undoubtedly see other monetizations come forward. You might earn gametime or rewards in future games by helping new players out (as a guide would through a dangerous environment in the real world), for example. Or you might earn real money for doing so, as some already do by streaming their gameplay.

The nature of gaming is so digital that it provides a key ground to try things that might not fly in other industries, and although Valve didn’t get it right the first time, I hope they keep working on it.

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.