Hacker News Reader

Comment by x0x0 | Hacker News Reader

Also, while it would obviously not catch every case, a warning that hey, this game won't work on your current system seems like a pretty low bar. The valve clients definitely can and I think do capture system hardware.

View on HN

The caveat is that it wouldn't be retroactive, at _best_ (to say nothing of how they'd need to quantify comparison between extremely different hardware types) - currently the hardware requirements are freetext fields with no constraints, which is how you get things like the requirements on [1].

[1] - http://store.steampowered.com/app/391570/

Steam could have some sort of automated benchmarking service - start with a server with a decent video card, and post the specs. Hire a gaming bot maker to make some kind of testing AI, and let it just play through games and automatically post the FPS statistics.

Or maybe someone could start an independent startup that provides this automated benchmarking service. I guess it's a legit excuse to learn how to write a gaming bot, as a weekend project.

Sure, but you'd still need volunteers to run (and not cheat) their benchmarking service on the long tail of far too many hardware variants for them to purchase and keep in a dark room somewhere, as well as some way for vendors to set the minimum requirements in a useful manner (e.g. ideally a one-dimensional scale per type of requirement), or it's not going to get used.

I think it's certainly doable to some approximation of correct, and that Valve is probably in the best position of all the game distributors to do it with their existing HW survey infrastructure (and quantities of app on their platform) giving them a large background in what they're looking to quantify, and for whom. I just wanted to observe that it's far from trivial, and would still involve some level of crowdsourcing data (or paying someone like PassMark to use their single numbers for performance of given pieces of hardware as a scale for vendors to map things against, though the different workload numbers show that making this comparison isn't simple...)

Steam had a benchmark in CS:Source and i'm disappointed they haven't added a more modern one. I know they track hardware data, but I like to do comparisons when I upgrade and using various other benchmarks and tracking/comparing results is hit or miss.

Openbenchmarking.org is not good enough?

They could either use a bit of their cash to pay a handful of contractors to hand tune up the requirements for their estimated 8k apps [1], or just do a two day best-effort programmatic match and issue an order to every seller to update the guess. It's very manageable for a business to do.

[1] https://www.reddit.com/r/Steam/comments/41rbhi/how_many_game...

Indeed: http://store.steampowered.com/hwsurvey/

PC game hardware requirements are fuzzy though. It wouldn't be impossible, but it isn't obvious how to do it either.

Well I think instruction set is a pretty easy bar to start with. Heck you could do it automatically. Is the executable compliant x86? is the User's machine x86? I could program a prototype for that in a few minutes if I had the info valve does already.

Stram games that you buy are not restricted to a single machine. I often buy games from a phone client and later (not) play them on one of my two PCs. Seeing any compatibility warnings when I buy would be quite weird.

Valve would obviously keep every hardware you've ever logged into the steam client on. So if you've played a steam game on the Sunahe account on a windows box, aha, Sunahe has windows! No warning.

But a red box for graphics intensive games that says "We've never seen you on a device that can play this" is, again, a low bar. Or a windows only game for an account that is mac only.

Not very useful. If you have at least once played on an old computer that you don't use anymore but which had windows installed this would break.

And before you say that steam could detect that i don't use that computer anymore, they would have to ask for confirmation and that would be unexpected and annoying in my opinion.

Generally the necessary UX would be too complex to be useful.

All that effort just to avoid something PC gamers did for a long time - check hardware requirements to see if it'll run on their device.

Steam already records the pcs you login from and even let you make them (steam guard)

The Google Play store already does this for Android phones. It remembers all the devices you have used, and warns you, but lets you purchase anyway if you really want to. It's a solved problem.

Yeah, I regularly buy games on my Mac and then install them on my Windows PC.

At the beginning Steam tried to be "smart" and made it really hard to buy a non-Mac game on a Mac which was extremely annoying.

Right, but is this a useful metric? I'm pretty sure 100% of Steam games are x86, and that users know that. Are there even any Mac PowerPC binaries on the store?

To be fair, the Steam Store in the client is just a browser loading a page from the Steam website. Could they put the system info in a cookie?

No, the client can push it to a valve hosted db.

So yes, there are corner cases. Eg if you've never installed the client this won't help with your first purchase. But so what?

> the Steam Store in the client is just a browser loading a page from the Steam website.

No one told them they had to architect it that way. It'd be a reasonable requirement to have the purchasing experience from within the desktop client be aware of what the computer running the client can actually support. If that means doing something a little bit smarter than a simple embedded browser, then so be it. The Google Play Store knows which apps are and aren't compatible with all of my devices, and I don't consider that to be an especially high bar (but rather, the minimum).

Would be trivial to pass the data as custom HTTP headers.

The client connects to the backend with a binary protocol that, among other things, gives it a token which it hands off to a web API that returns a valid cookie for the Steam store. They inject that cookie into the integrated browser instance.

That's the tech they already have on hand.

Reply on news.ycombinator.com