This does raise an issue that's being discussed in the Linux game dev world: Will Steam's In-home Streaming finally remove any motivation to develop native games for Linux? If you can develop for Windows, with its vastly larger userbase, why spend money porting to Linux at all? Especially now that a nix user can be told: "Just stream it from a Windows box"?

It's an interesting question. And a very real concern since the economics favors not porting. Many nix users who are diehard game fans already (of necessity) keep some flavor of Windows in house purely for gaming purposes. They either have a separate game box, run Windows in a VM, use a copy of CodeWeaver's CrossOver, or can dual boot into it. So the serious (i.e. buying) gaming crowd is already there.

Yep...very interesting question.

-40hz (February 05, 2014, 07:56 AM)

The people who are capable of streaming aren't the target market for porting games to Linux.  If someone has a Windows box to stream off, chances are they'd be willing to use that box for the game anyway.

Porting games to Linux has two major targets:  People who have no Windows machines (Or none that are gaming capable), and the potential market of the SteamOS boxes.  This second one is a huge market by it's very nature [Simplifying PC gaming to a level that Console owners are used to].  The people who buy a SteamOS box are doing so because the Can't/Won't/Don't want to set up a gaming PC.  This means they don't have a machine to stream off, and will be stuck with games that have been ported to Linux.

I think that's part of OAuth or OpenID.

-Deozaan (January 06, 2014, 07:24 PM)

You can do it with both.  OAuth would be much more useful for a non-browser app.

However, my solution would be this:

• Each device/profile gets a GUID on first run.
• Player is prompted to link profile to an email address.
• If they do, send a confirmation email, and add the GUID to a database: [Email address]<[GUIDs]
• Merge data from local profile to email address

The profile ID is a unique identifier. This essentially means you don't need a password, because having the device is enough proof.
Linking to an email address should be optional. Only required if a user wishes to merge to GUIDs into a single profile.
Other than a once off association (Which is optional), the user doesn't need to see the login process again.

-kamahl (January 06, 2014, 07:41 PM)

This sounds very much like it could accomplish what I want to do. However, I see two potential problems with it:

1. I'd really prefer not to have any personal information about the players. This includes email addresses. Though I suppose I could store a seeded hash of the email address and compare it, and if it matches then merge accounts or whatever.
2. I hear stories about people changing some of their hardware (often their GPU) and it invalides their DRM-enabled program (usually a game) because they suddenly have a new GUID or something similar. Though I suppose I don't need to access the GUID every time the game runs. Just the first time to link to their online account and then I can simply store a reference to their account number or whatever and not rely on the GUID.

Are these problems anything I should even be concerned about? If so, do my own suggested solutions seem like they would reliably circumvent the problems? Are there other problems with my ideas that I should be aware of?

-Deozaan (January 06, 2014, 10:08 PM)

I would recommend creating the GUID once, and then storing it, rather than trying to link it to hardware identifiers.
That way, as long as the user doesn't blow away the config files your UID won't change.

The reason I suggested email addresses is that they are something that would be personal enough that people can't impersonate you.  
There would be nothing more irritating than if someone were to get their PC associated with my account, and sell all my items/get me banned from chat/other such effects.
A salted/hashed email is fine.  Just as long as there is a way for the user to be sure nobody else can associate to their account without their knowing.

EDIT: If someone were to clone said config files, and impersonate your GUID, that would still be an issue.  But such things can only really happen with physical access - And when that's true, it's generally easy enough bypass further restrictions anyway.

Updated to 1.0, and added support for Notification Priority.

Note that for the moment, the app API Key I'm using has a limit of 7,500 calls per month.  They say they're willing to bump that for Open Source projects, and have done so for the OSX Growl one.  But for the moment, I've got a limit.

I'm a huge fan of Growl for Windows (and have included support for it on a few of my own apps).   :Thmbsup:

-skwire (December 31, 2013, 12:16 AM)

As am/have I. 

And while existing solution did work for me, I disliked having two notification apps on my phone, one for Growl, one for IFFT. So this happened.  On new years eve; when I realized "Oh hey! I haven't done anything for NANY yet".