Ignore the play time if a game is running in the background

[Smig]

I don't know how feasible this is but Steam should count the play time only when the game is actually being played. I imagine one could check if the game is the active window in the OS, or maybe stop counting playtime if the OS is reporting idle inputs for longer than X minutes regardless of the window.

The reason why I'm suggesting this is because my pc is always on, and often I just alt-tab out of games instead of quitting when I leave, so games stay running consecutively for several days (usually in some menu) even if I only play 2-3 hours a day, and not all days at that. The result is that there are games in my library that have a ridiculous amount of playtime (in the thousands of hours) because of this issue.

I suspect this happens to many people. This makes that information less useful to me, and it also makes it less useful to other people if they're judging a review by their play time.

[XBL Laberbacke]

Not happening. People would find ways to abuse this and refund games they played a lot.


I take it you don't have to pay for electricity yourself?

[Smig]

Originally posted by XBL Laberbacke:

Not happening. People would find ways to abuse this and refund games they played a lot.


I take it you don't have to pay for electricity yourself?

I do, but I have other reasons to keep it on. And maybe I don't value my money as much as I should. Anyway, there could be two distinct measures then, a run time and a play time. The run time metric would be used for refunds, since that's harder to abuse, and the play time would be displayed everywhere else, like reviews and in your profile.

[SpunkyJones]

I run my pc 24/7, but I shut down my games when done. If the app is running, its running, there's no getting around that.

[Satoru]

Originally posted by Smig:

I do, but I have other reasons to keep it on. And maybe I don't value my money as much as I should. Anyway, there could be two distinct measures then, a run time and a play time. The run time metric would be used for refunds, since that's harder to abuse, and the play time would be displayed everywhere else, like reviews and in your profile.

Runtime is playtime

There is no distinction

Quit your games or come up with better 'reasons'

[Smig]

No, run time means whatever Valve wants it to mean, and play time means whatever Valve wants it to mean. Come up with better 'objections'.

[Start_Running]

Originally posted by Smig:

No, run time means whatever Valve wants it to mean, and play time means whatever Valve wants it to mean. Come up with better 'objections'.

There are many games that actively run in the background. FOr many that's actually how they are meant to be played. Tower defense as a genre pretty much assumes you'll be in another window.

So yeah. Just because it's in the background does not mean it isn't active. IT's still using cpu cycles, it's still occupying memory. ergo, it is running, and therefor it will be counted as run time.

[Smig]

Originally posted by Start_Running:

Originally posted by Smig:

No, run time means whatever Valve wants it to mean, and play time means whatever Valve wants it to mean. Come up with better 'objections'.

There are many games that actively run in the background. FOr many that's actually how they are meant to be played. Tower defense as a genre pretty much assumes you'll be in another window.

So yeah. Just because it's in the background does not mean it isn't active. IT's still using cpu cycles, it's still occupying memory. ergo, it is running, and therefor it will be counted as run time.

That's news to me. I guess I'm just not into those games.

I get your point though, this change wouldn't make sense to all games then.

[ KARR™]

Originally posted by Start_Running:

There are many games that actively run in the background. FOr many that's actually how they are meant to be played. Tower defense as a genre pretty much assumes you'll be in another window.

.....what???

[Start_Running]

ANy game that has a mechanic wherein you wiull spend your time waiting for something within the game, is problematic. This includes, Turn-Based, games, Autoplayers, MMOs, Survavl games, and many others, even RTS games.

[Satoru]

Originally posted by Smig:

No, run time means whatever Valve wants it to mean,

Yes and runtime is playtime

External executables have ZERO visiblity into what a game is doign other than "Its running". It has no idea you are 'not playing' or 'in the main menu'. There is no Win32 API that is magically called IsTheGameInAMenu

Steam detects a game is running. That's all it can see. That's all it can EVER see.

and play time means whatever Valve wants it to mean. Come up with better 'objections'.

If you don't understand how things actually work then dont tell Steam to do something that is functionally impossible.

[Smig]

No, it doesn't. Valve decides what means what, and Valve may access information about the active window or the input idle time to make those kinds of determinations -- though for Steam to attach an overlay with the features it has, and to even manage a Steam Controller, I suspect they can do much more than what I can imagine. Either way, all of that is completely irrelevant.

If you don't understand how things actually work then dont tell Steam to do something that is functionally impossible.

You couldn't be more wrong. It's not the job of the user to decide whether something is technically feasible or not. I'm not the Valve software engineer here. Even technically knowledgeable users, if they want to be helpful, should only communicate needs, not the actual technical means by which those needs should be satisfied -- which is a common problem in developing custom software, btw. That is the developer's job, which know better than us both combined how exactly may that need be satisfied.

[Start_Running]

Originally posted by Smig:

No, it doesn't. Valve decides what means what, and Valve may access information about the active window or the input idle time to make those kinds of determinations -- though for Steam to attach an overlay with the features it has, and to even manage a Steam Controller, I suspect they can do much more than what I can imagine. Either way, all of that is completely irrelevant.

None of that would really work. There is no difference between fore ground and background . The only thing you can determine is 'focus and as I pointed out of focus doesn't mean doing nothing. You AV program is out of focus 95% of the time but it still uses a lot of cpu and memory. As for idle, again... again, how much input do you do when you're atching a cutscene, or in a stealth game where you're waiting for a guard to patrol by. And there's not much that Valve can do to see what is actually going on.

You couldn't be more wrong. It's not the job of the user to decide whether something is technically feasible or not.

But taking the time to understand what is or is not is beneficial to the user. Just like it's not your job to calculate sale's tax, being able to and doing so however is very beneficial to you.

I'm not the Valve software engineer here. Even technically knowledgeable users, if they want to be helpful, should only communicate needs, not the actual technical means by which those needs should be satisfied -- which is a common problem in developing custom software, btw.

The communication of suggested methodology can give greater insight into the problem or perceived problem.

That is the developer's job, which know better than us both combined how exactly may that need be satisfied.

Devolopers, being other humans never look down on someone who makes an effort to make their job easier. It's a janitor's job to pick up litter and mop the floors, but that doesn't mean they don't appreciate you picking up the candy-wrapper that missed the bin.

[Smig]

None of that would really work. There is no difference between fore ground and background . The only thing you can determine is 'focus and as I pointed out of focus doesn't mean doing nothing. You AV program is out of focus 95% of the time but it still uses a lot of cpu and memory. As for idle, again... again, how much input do you do when you're atching a cutscene, or in a stealth game where you're waiting for a guard to patrol by. And there's not much that Valve can do to see what is actually going on.

I already conceded that due to the nature of some games, the very concept of determinig what playing even means would be problematic. I came to realize that this is the real problem with this idea and that I defined playing a game in a narrower sense due to my own narrower experience playing games.

If we define it more narrowly though, then it's very likely that Steam has all the tools it needs to make a much more accurate estimate of play time. Even if you're watching a cutscene for 2 minutes, those 2 minutes that are absent from the play time would be negligible in hours of gameplay, though you're assuming a very unsophisticated and rough system. You could have it only stop counting if idle for 15 minutes, for instance, and you could further improve it in a number of ways. I believe this would result in a more accurate estimate of playing time in most cases.

But taking the time to understand what is or is not is beneficial to the user. Just like it's not your job to calculate sale's tax, being able to and doing so however is very beneficial to you.

That is questionable as I argued, but also irrelevant since the user can't be expected to do that for the sake of giving feedback. Remember that whether a user should give feedback despite lacking knowledge of the technical side of things was the point I took umbrage with, and then I went further than that argued that it was actually helpful not to focus on the technical details in this context.

The communication of suggested methodology can give greater insight into the problem or perceived problem.

Devolopers, being other humans never look down on someone who makes an effort to make their job easier. It's a janitor's job to pick up litter and mop the floors, but that doesn't mean they don't appreciate you picking up the candy-wrapper that missed the bin.

I don't think I ever looked down at anyone by doing that. Not here and definitely not in my personal and professional life. Whether that helpful attitude is really helping is another matter altogether. This is getting into a long tangent but it is my opinion that, on average, it doesn't, and it actually creates a needless overhead to the process that, in some extreme cases, may warrant being discouraged. It is my experience that things run more smoothly when the communication is centered on the user's needs. But I would absolutely never "look down" on someone for doing that. In fact I did exactly what I'm recommending not doing here by briefly speculating on potential technical implementations of this idea, so I may as well look down on myself.

The janitor analogy doesn't really work, though, since Valve's role in this interaction isn't equivalent to the role of the janitor's interaction with you, in your example, and his job is far too simple in comparison (sorry janitors!). In that case you're not giving feedback to the janitor, you're just doing his job for him, and that task is so empty of any technical requirements that it can't really disrupt the janitor's job. Now if we were to slightly increase complexity by, say, add different bins for different things, and you decided take upon yourself to put candy-wrappers on the wrong bins, even if well intentioned, may be quite unhelpful. Though again, I'm not doing Valve's job so these things aren't analogous to begin with. I'm merely communicating a user experience problem that I have.

[76561198407601200]

Op, don't leave the game running if you aren't playing. It's about as simple as it can get. Speaking of ignoring things, you should not ignore the search feature, this has been brought up and shot down quite a bit.

[print(name)]

Just quit the game?