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

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 Valvetime.net), 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.

Thread beginning with comment 646504
To view parent comment, click here.
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"
ssokolow
Member since:
2010-01-21

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:

https://imgur.com/2yQMBZI

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

RE[2]: Make it faster at startup
by leech on Mon 10th Jul 2017 18:16 in reply to "RE: Make it faster at startup"
leech Member since:
2006-01-10

Gnome-Games-App does this already, as far as being a separate game launcher.

https://wiki.gnome.org/Apps/Games

Reply Parent Score: 2

ssokolow Member since:
2010-01-21

I'm aware of Gnome-Games-App. While we overlap, we have different goals.

Their goal is to take the best aspects of various existing launchers and emulator frontends and put them all in one place.

My project's goal is to push the envelope and build a launcher as a side-effect of the "If you want it to be good, dogfood it" effect.

It makes more sense if you see my project as two projects that I'm still working to peel apart:

1. A backend that, unlike Gnome-Games-App, can reliably auto-generate launcher entries when given a path like /mnt/buffalo_ext/games and told "get going".

2. A frontend which serves as both a test bed and something I can use in day-to-day life instead of Gnome-Games-App because I'm not a fan of GNOME 3's UX.

While I do want to have frontend features they lack, I also hope to eventually export a C API from the backend and let Gnome-Games-App use it too. (Or, even better, an API based on their efforts to improve the interop story between Rust and GObject Introspection.)

TL:DR; Their project is a proven-style frontend that's growing backends. My project is an experimental backend that's growing a frontend. Also, their frontend doesn't fit my tastes.

Edited 2017-07-10 18:58 UTC

Reply Parent Score: 2