question

Planet 316 avatar image
Planet 316 asked

How to handle unique id creation?

I have seen some of the other post that mention you can't really lock data, but we currently need a way to create unique codes for users. I'll explain the feature here.

Original thought was to use Titledata or sharedgroup to store the starting unique ID and call the value and increment it with cloudscript. So, let's say the first unique id is A1Z1. When a user creates an account, this ID is assigned to them, then it needs to be incremented. So it might be A1Z2 after.

However, this doesn't seem safe as the new ID would have to be pulled, then updated, and sent back up. During that time, another user could pull the same ID.

It is an important feature that we be able to implement this ID system. We don't want to use playfab IDs (for this purpose) as these codes need to be shared between players.

I guess the main question is, is this even possible to do in playfab?

Thanks for any assistance provided.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

I'm not clear on the requirements. Why is sharing the PlayFab ID between players problematic? It's not a secret key or session ticket, so it provides no special access to the player account. The PlayFab ID would actually be the way I would implement what you're describing, as it is a guaranteed unique value. It is not sequential of course, but I'm not clear on whether that's a hard requirement for you, and if so, why. Can you give us more details on these requirements?

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Planet 316 avatar image
Planet 316 answered

The app that is being made is for children, so we need something simple that they can trade to add friends, but we can't let them create such things as usernames or display names to use, as this gets into COPPA laws.

PlayFab IDs are long and would be difficult to easily trade between each other when they want to add friends. Looking at current accounts on one of our other apps, the PlayFab ID is 16 chars long.

The basic idea is to implement a "buddy code" that they can easily trade with each other to become friends. 

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

Correct - the PlayFab ID is a 64 bit numeric, expressed as a hexadecimal, so it's usually 16 characters. Obviously, the main thing when creating a title that must be COPPA compliant is to have a conversation with your legal counsel, so that you're confident that your plan will be compliant.

Now, you are correct about writing data - a space which allows player updates is not going to be safe from overwrites (two players get the data at the same time, then issue writes - the second write is the one that "sticks"). While we will be providing a compare-and-swap operation in future, this still wouldn't be the right way to approach this feature, as we do not provide a single data space which can be used as both a read and write location by all users for an entire title. Data which can be read by all users, like Title Data, is sharded across many locations, so that all players can read it at the same time without issues. Data which can be written to by users, like User Data and Shared Group Data, is not sharded as that would cause potential synchronization issues, so it cannot be written to by all users - the physics of having a single store for the data precludes that.

Since you must expose the PlayFab ID to the code under the covers, and you're blocked from using email addresses or a permanent Username by COPPA rules, it sounds like you want to give players who have played together the opportunity to interact. If so, the simplest way to do this would be by storing in the local user's User Data (or a Shared Group Data dedicated to the one user) a generated "name" and the PlayFab ID of the user associated with it, whenever the player encounters someone they might want to connect to. You would then rotate through this list, expiring the oldest as you fill it up. Would that work for you?

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Planet 316 avatar image
Planet 316 answered

I'm not sure if that would work out. 

The idea of how we were wanting to implement this is during the account creation process we'll be able to retrieve an available "buddy code". So, as an example it might be A1A1 to start. This buddy code will be assigned to this account as a display name. The child will have access to this code to easily trade with local friends. Since display names need to be unique, we'll have to increment the code each time it is used. The code itself will be small, so they can easily trade it as we could have children of many age ranges using this app.

We have seen this system in another very popular children's game, so we are pretty certain it will be fine. However, we are seeking legal counsel on this app.

We do have a name generator to allow the kids to name their avatar, but it's limited to so many names and because it is a children's app, we would like to allow the kids to pick whatever name they'd like, thus we can't use the name generated here as a unique name, as we feel children will be sad if they get denied a name they want.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

Well, if what you want is a database that can transactionally support "handing out" IDs, you may want to use an external database which you access via Cloud Script http calls. However, I'd prefer to find something workable in the existing featureset. So let me ask this - since you're using a non-unique name as the player's visible username, why not use the Title Display Name for the generated name they can give to others, and generate it using several tables of words for each supported language? Xbox uses a similar generated name system - in this case, you'd pick a word each from tables A, B, and C, and try using it as the Title Display Name. If you store the tables in Title Data (or the Content service), you could then expand those lists if your user base expands beyond what you'd planned for. That way, it doesn't have to be a super-short code like A1A1, while it will still be easily remembered and reasonably unique at generation time (assuming you provide enough words - but again, you can always add more). You could even theme the words according to your game's overall theme.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Planet 316 avatar image
Planet 316 answered

We actually do have a name generator for the avatar that does what you describe, but we don't want to use that as these are kids of all ages so we want to be careful not to have to display "name already used" messages and have them not be able to have the name they want.

We do want to keep the codes short (probably not just 4 chars, but close) because we have no idea how easily these kids will be able to trade these codes in the future and it may even be that they are trading across states. We might be able to get away with a random generator for this code and if it finds a match just regenerate the code. We'll just need to consider the impact on account creation time if we go this route, though it probably would work fine depending on the length of the code we use.

An external database may be the better route depending on estimated growth of the app.

Though not exactly what we were looking for, this at least gives us options to consider. Thank you.

 

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

You're quite welcome, but it sounds like I may not have been clear on my suggestion:

I was recommending using the name generator as the code generator, so that instead of a 4 character code (which is very likely to have duplicate collisions as you scale up), you'd use the generated three (or four) part names. Words are generally easier to remember than a number/letter sequence, as well as being generally easier to tell people. This would also give you the ability to use a different set for different language settings, potentially. You'd then use user data to store the username the player selects, so that they can have a non-unique name that can be whatever they choose. Make sense?

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.