Steamworks’ Announced Changes for 2019

Steam: Steamworks Development: 14 January 2019: “2018 Year in Review” announced some expected changes in 2019, including:

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.

7 March, 2015

Source 2 and Valve’s History of Ports

Over a decade ago, Source, the successor to Valve’s original engine (GoldSrc) debuted with titles like Half-Life 2 and Counter-Strike: Source. Now that Valve has officially announced Source 2, it looks like it will see the light of day this year.

What will that mean for their existing catalog of games?

If we look back to the release of Source, they drew some lines for porting. They ported the original Half-Life, mostly as an example of portability between the engines. It was a loyal port, without taking advantage of anything new to the Source engine.

They did a less direct port of Counter-Strike. Counter-Strike: Source was a mild evolution from the original mod-turned-product version of Counter-Strike. They also ported Day of Defeat as Day of Defeat: Source. Although I never played the original Day of Defeat, my impression is this was another mild evolution.

They did not port Team Fortress Classic. They did not port Ricochet, either. They waited to make Team Fortress 2, which was a reimagining.

What has changed since the Source release is mainly the addition of economies to games. Team Fortress 2, Counter-Strike: Global Offensive, and Dota 2 all have economies.

Economies create a fresh challenge for porting of games. Previously, a port was a way to revitalize an aging game, to improve on its graphical quality, and so on. But with players having a set of game items, how do you move them to a new version without either entrenching game-wealth by porting their items (thus alienating new players), angering players that have game-wealth (by not letting them carry items over), and make adjustments to gameplay (by eliminating or modifying old items to fit the new game)?

Not all those challenges apply equally to each of the games. In CS:GO, for example, the items are skins only. They do not have gameplay implications in the same way that TF2 items have.

Other challenges exist because of the economies that exist. If the new game is more popular (as is expected), the old version’s items suddenly become less valuable. This means that players will seek to cash out rapidly, which crashes the old economy further, while the scramble for the new items creates a bubble in the new game.

How to handle the economy problem for new versions of existing games seems very difficult. But the incentive to create new versions of games for new engines is likely too great to continue to adding content to existing games while also creating new titles in those traditions.

I suspect the solution will be some mix. Players can carry some value from their existing items, but not the whole value. That may be done through crafting or similar mechanisms. It will likely involve PRNGs (Pseudo-Random Number Generators) so that some level of risk is involved.

But Valve is very creative, so time will tell what solutions they find and how they are received.

15 March, 2014

Improved Discovery of Functions via Socialization

You have probably seen a comment on a website do something like:

Hello, world!
I am a block quote.

One common, simple styling of blockquotes is to throw a left border on them, maybe some indent, and call it a day. Even some rich-text-esque e-mail programs do that for quoting in replies.

Now you may have seen a comment on a website do something like:

| Hey, answer my question: what?

The answer is mu.

That use of the vertical bar (|; a.k.a. pipe; see Wikipedia: Vertical bar) is an example of cargo culting. People reading comments see the left-bordered replies and say, “okay, good, a distinctive way to quote exists,” but they fail to guess that the quote character is > (a.k.a. greater-than).

Still, if you see users cargo culting something, it tells you a couple of things:

They think the behavior they’re trying to mimic is valuable for some reason.
It isn’t easy enough for them to discover how to do it.

I nearly wrote “the right way” for [2] there, but if it were the right way, then it would be discoverable.

There are options:

Adopt the cargo-cult attempt as the new way (or an alternative way).
Implement a rich editor (e.g., with a shiny “quote” button).
Make it easier to “view-source” of existing comments so users can see the secret sauce.

Something like [3] is the way to go in this instance. Let people learn from each other without explicitly needing to ask, “how?” If a user sees another with a fancy comment, they might dig into the source (when available) to see how it works.

This is the way we traditionally learn: observation. That’s how we learned to speak, and to a lesser extent how we learned to write and read.

In general, if you see mistakes being made with a piece of software that’s an opportunity for improved design. One source of inspiration should be video games. If you watch the commentaries from Valve Software’s games, they have a common pattern for learning game mechanics.

Show the user the mechanic in action.
Let them try it in a simple example.
Trap them until they show they’ve got it down pat.

The games Portal and Portal 2 are chock-full of this pattern. You start out not even holding the portal gun, only learning you can move through portals. Then you only control one portal. Finally you learn to control both.

In more advanced puzzles you learn about conserving momentum to fling yourself, or in the second game how to paint with and make use of the gels.

Only after you have completed what amounts to a whole set of portal classes do you get to the part of the games where you are apparently fighting to win, but the whole experience (classes and all) are kept enjoyable.

We don’t currently approach general software in that manner. The first time you fire up Firefox, you aren’t presented with a puzzle of how to open a webpage, for example.

But maybe you should be.

4 August, 2012

Attack of the Undead Penguins

Steam coming to Linux, you say?

People following the Valve/Steam/Linux news already know that the awesome hackers at Valve have Left 4 Dead 2 running on Ubuntu like a champ. They know that Valve has been doing some work toward a so-called three meter display (ie, for television display), and have probably speculated that they are at least considering building a console.

This is a post about what I’m looking forward to seeing out of Valve on Linux.

Playing Games

Foremost, I’m looking to playing games without even the minor inconveniences of WINE. Often there are tweaks, there’s turning off features, or some minor thorn of just about every game I’ve played on WINE. WINE is awesome, and it’s made some money for game companies, as there are games I bought because I knew that I could play them.

But it’s not perfect, and for people that eschew yak shaving to play a game, the set of titles they might purchase and play drops (I’m not thinking about side projects like PlayOnLinux, as I’ve not tried them).

For a lot of games, if they make it to Linux, that means getting full eye candy. Full features.

Building Games

Secondly, I’m hopeful that the game creation tools will be coming to Linux. Some of these kind-of-sort-of run under WINE, but my experience with these hasn’t been nearly as good as with games. Even if the current generation tools don’t make it, maybe the next generation will.

The lower the barrier to entry for creating game content, the more that will be created, and the better games we will see. That’s true of technology in general.

I’ve made a few maps years ago under Windows, but the few times I tried to build maps under WINE it was much clunkier and fraught with peril. I’m very hopeful that in another decade or so it will be commonplace for gamers to be mappers and modelers, even if their extent of mapping and modeling is just to customize existing maps and models.

Building Bridges

But, like others, my biggest hope is that this work will result in greater support from the four corners of the earth for Open Source and Linux. That it will widen the market for gaming, while making governments and businesses evaluate Linux as a greater possibility for their employees.

Just like Android has pushed a device with Linux to far more hands than ever before, a Valve console could do it again. But so can Steam for Linux. There’s plenty of people that keep a second computer or dual booting just for games. There also a general perception that Windows is the king because of gaming. Linux getting more gaming means that even Apple may end up supporting iTunes for Linux one day.

A side bet is, assuming the success of Steam for Linux, could that competition bring Microsoft back from the brink? For years Microsoft has had the capacity to push the computing world far beyond its current state. But it’s had no reason. That’s harmed its server market, which hasn’t been very competitive.

Conclusion

In any case, as a long-term fan of Valve’s games, I look forward to playing Half-Life 3 on Linux (just like I played Half-Life 2 here), and with any luck the Black Mesa modification can be playable on Linux too.

4 June, 2011

Discoverability in Software

Discoverability

One of the big challenges in writing usable software is making all of the features and options apparent to the user, particularly to the novice.

Menus do a good job, by being visible and readable (including by accessibility tools). But keyboard shortcuts that are not menuized have poor discoverability, as do some mouse actions (gestures, uncommon or inconsistent button behavior).

For example, you’ve probably repeatedly clicked on a text field in software before and noticed portions of the entered content are selected. It’s not obvious what happens if you aren’t paying close attention.

The general behavior here is that a single click moves the cursor while a double click will select some portion of the entered text. The double click rules are basically:

Select the word the cursor is over (if it is a word).
Otherwise, select the surrounding word(s) (if over a space).

But there’s also the triple click here. Triple clicking will select the entire paragraph.

How would you determine these behaviors, other than having been told or experimented? Unlike a checkbox, which has some kind of indication that clicking it does something like erase or add a check to it, text gives no such indication.

There are regular threads across the internet where people discover that shift and middle click both have myriad uses in Firefox. Having an about: URL that gave the full list might be useful, but even that wouldn’t be too discoverable. And the sidekick of discoverability is remindability. If the user reads a long list once, they won’t necessarily remember for the next time they could use that action.

Certain UNIX text editors have extensive tutorials to help people learn their commands and behavior. And the evidence is compelling that once you learn them it makes you more productive. But, learning them is still a fairly big hurdle, even with tutorials. This is purely a discovery issue.

One of the best possible solutions I can imagine would be to create video games with the UI for these applications. If you had to kill space aliens (no offense to any space aliens reading this) while playing a game version of vi, you would learn the commands much faster. Same goes for killing zombie tabs and zombie bookmarks in Firefox.