Linked by Thom Holwerda on Sun 9th Jul 2017 23:16 UTC

Valve's Alden Kroll was at Indigo 2017 to talk about Steam and the changes they're working on. The talk covered the business side of Steam as well as some specific features available for game makers. The company wanted to meet developers face to face, answer questions, and hear feedback and suggestions as well.

The slides of the talk are available at the link (thanks to, and interestingly enough, the slides states Valve is working on a "overall UI refresh & update" of the Steam client - which I applaud greatly. I hope it's more than just a new skin, and that they are actively going to address the performance issues and UI complexity - preferably by making the clients on the various platforms (Windows, Linux, macOS) feel like proper, native applications.

In addition, one of the slides also shows that Steam is still growing, with 33 million daily users, 67 million monthly users, and 26 million new purchases since January 2016 (so 1.5 million per month). Those are healthy statistics.

Permalink for comment 646504
To read all comments associated with this story, please click here.
RE: Make it faster at startup
by ssokolow on Mon 10th Jul 2017 08:35 UTC in reply to "Make it faster at startup"
Member since:

Is there any situation where you'd have a use for a game launcher/organizer separate from the Steam client if all of the entries were auto-detected?

(Aside from "Here's the folder where I keep manually-downloaded games/ROMs which were installer-less Zip/RAR files.")

I ask because I'm working experimenting with with the feasibility of a Steam client-like tool with a "you choose your service-independence/convenience trade-off level" design and, the more use cases I can keep in mind, the better.

Here's the current state of the prototype GUI:

Everything you see was autodetected, because I'm still working to improve the accuracy and don't want to get lazy while dogfooding.

So far, my key goals are:

1. Very responsive, native GUI. (PyQt+rust-cpython now, fully Rust once QWidget bindings are more mature.)

2. Pluggable backends (eg. It will already query ScummVM and PlayOnLinux if found.)

3. High-quality heuristics for things which simply have no API to pull data from. (My filename_to_title test corpus has 841 file/folder names and, so far, I've got the accuracy up to 93% with most of the failings being bugs that I'm tracking down as I refactor.)

4. A GUI optimized for efficient keyboard operation.

For example:

- I've got the filter field forwarding various keys to the main widget for a more Launchy/Quicksilver-esque experience.

- Configurable search which defaults to shell wildcards and prefix searching with an implicit "at the beginning of words" requirement. (ie. "pir" will match "Pixel Piracy" but not "Spirits", and "pir* of" will match "Pirates of Pestulon" but not "of pirates")

- You choose whether typing in the search field clears any filters set using the category sidebar.

- I have plans to implement an even more Quicksilver/Launchy-esque mode of operation to be triggerable by a global hotkey.

5. The categories sidebar will support saved searches and allow tags to be grouped (represented via a tree widget), with intuitive AND/OR semantics for multi-select.

(Tags within a group OR together. Each group of ORed tags ANDs together... allowing stuff like "(Play_Status>In-Progress OR Play_Status>Endless) AND (Install_Status>Installed OR Install_Status>Downloaded)".)

Edited 2017-07-10 08:48 UTC

Reply Parent Score: 1