I have a question that is more architecture/logistics-oriented than coding-oriented in terms of player management.
BACKGROUND:
I have a game which can be played as a single user or in a head-to-head competition. The single player version is free with ads. To play head-to-head users must purchase a paid version of the app.
High scores and gameplay features are handled by my own backend server.
QUESTION(S):
When a new user first downloads the free app, the app generates a unique key for this user/installation. The user can then play as many times as they like, trying to beat their own personal best score. For every game they finish, the app sends the unique ID, the new score, and various game stats to the server where they are recorded.
If the solo user wishes to see their standings on the leaderboards for that day, they need to create an account, either via a standard email registration or using Facebook. If the user wishes to play head-to-head against another user and has purchased the paid version of the app, they must also register using one of the aforementioned methods.
Once a registration is created (or a Facebook User ID is obtained), the app communicates back to the server, tying the newly created account with all previous games sent with the original unique ID. We then have the newly registered users tied together with all of their historical gameplay information.
So my questions:
- is this an acceptable (or standard) way to accomplish a registration while keeping the info gathered before the user registered?
- I figure that if the user has played (or will play) on more than one device, no problem. Once they login to their existing account on the second (or third, etc.) device I’ll just associate that new unique ID with their other unique ID(s) and combine their history. Is there any drawback to this?
- Can you foresee problems arising with this that I am perhaps not yet realizing?
- Is there a better way? Or something I am not thinking of?
Thanks in advance for any feedback/insight!