Hi there, I have a use case for creating a more private/closed online game, where registering an account requires something like a separate password (not the user's password) or a referral code or something.
Are there other ways to add users besides the RegisterPlayfabUser client API call? I'd essentially like to disable it and then use this hypothetical alternative method to gate user account creation.
Thanks!
Well first, if this is a Steam title, there's already an existing query for app ownership. If that's what you need, please open a ticket with us using the option on this page.
Otherwise, player accounts can be created by any of our authentication mechanisms, but you will need to provide the client with some means of creating an account. It's after the account has been created that you would then be able to apply some form of restriction on the player by setting a statistic or granting an inventory item that it must have in order to play.
You could do this a few ways, but if you want this to be unique per player (as opposed to a shared secret code hidden in Title Internal Data that a client would send up, in order to have a statistic set), I would recommend using coupon codes. You would distribute these to players, and they would use them to get the item from your catalog that the player must have. You could then check the player inventory in Cloud Script at key points in the player experience in order to gate the data the client needs in order to continue the gameplay experience.
If you choose to go that route, please note that the Game Manager code generator is meant to be used only for a small number of codes. If you need a lot of codes, please open a ticket with us.
We have discussed a code system where you would give generated codes to players, and those codes would be required in order to create an account. But to be honest, this is low on our priority list as we've had very few requests for this (and we tend to prioritize based upon overall impact - helping the most titles).
Thanks, Brendan. This would be a standalone PC application, and the current plan is to use email addresses / usernames for account registration, rather than integrating with Steam or other services. That might change down the road.
I like the idea of restricting after the initial registration happens. We could essentially let anyone create an account, but default them to a segment that doesn't give them access to anything, then use coupon codes to move them into a segment that does allow them to get into the game itself.
One clarifying question on the code generator limits: is it a small number of codes at any given time or a small number of codes in total? One idea we're floating is to allow players to request a coupon code for this purpose, then distribute that code to a friend outside of the game. Codes would probably be generated one at a time, and we'd keep some sort of code threshold/limit in PlayerData so that they can only refer a handful of friends per month or something similar.
Would coupon codes still work in this scenario without needing to open a ticket? And are there any other "gotchas" to think about with that approach?
Any of those would work (statistic, user data, segment, inventory item), since you'll just be checking them in Cloud Script, and returning something the client needs in order to continue play.
The reason I was suggesting using an inventory item via a coupon code is because it sounds like you want to have a different code per person (so that a global code isn't just shared in forums to the world).
A title can have as many codes as it needs - we're not really limited there. I'm just saying that the Game Manager hook to the code generator is not designed to support requests for tons of codes. If you need more than the drop-down provides in that interface, please open a ticket. We will make a coupon code generator available in the Admin API in a future release, but there isn't one there right now, so while you could use the Game Manager to generate a few at a time, it would be a very manual process.
2 People are following this question.
