Prologue
Updated to support Modules. The 'v2' sample file has been updated to support Modules, as 'Classic' mode has been removed. SDK has also been updated to v1.84.
Introduction
This second part adds PlayFab registration, email and username login, and account persistence to the template introduced in Part 1.
Registration
Deciding on a login mechanism wasn't quite as simple as you might think. The PlayFab tutorial itself starts with the CustomID example, but there's no way for the user to upgrade that to another mechanism, so I went with email, only to find out that there is no way to upgrade that either. Digging in further, it's clear that the best login mechanism is username, or PlayFab login. With a PlayFab login, you can add other mechanisms on top, and maintain the master account underneath. So I do recommend that you at least offer username accounts, and whether or not you include email is up to you, but that does offer the ability for the user to deal with lost password issues.
Something to note is, once a user has an account with your studio, that account can be used for all of your registered games - they don't have to register per game, just per studio. Another 'complication' is that the Leaderboard defaults to the PlayFabID, not any of the login accounts, but they do also support a DisplayName. For the sake of simplicity, my example sets the DisplayName to be the UserName. You can alter this if it makes sense, but having a total of four input fields (username, password, email, and displayname), seemed like overkill for a tutorial.
Register
After GUI setup, we check if we have a PlayFabID first, and either keep going with the cached values, or check if we have localstorage.
Since we have neither, we end up in On localstorage missing, and just finish up our GUI placement.
Since we have no accounts yet, enter in a UserName, Email address and Password. Press Register.
We call RegisterUserWithPlayFab(), WAIT, and then check for an error. We either display the error, or just report that registration worked.
Login
With the account data filled in, press Login-Email. After grabbing the input and trimming it to get rid of junk, we call LoginWithEmailPlayFab(), WAIT, and check for any error.
If there isn't an error, then this time we cache our data in another Dictionary and store it with LocalStorage so that when the user runs the game a second time, we can pull the data back in and avoid the login step - we can login automatically.
The same pattern is followed for Login-UserName, just with the appropriate function call, and dictionary data. There is also a subsequent CustomID section, but we covered that in Part 1, and frankly, you'll never use it again anyway.
Note: I am not encrypting the password in this example. If you choose to cache the password, you should do so in a safe manner.
When the localstorage is done, On item set is called, and we call ProcessLogin().
Now that we are logged in we can start making calls to the API to get further user details. ProcessLogin() deals with some house keeping (changing our login panel to a 'welcome' panel), and then calls GetUserDataFromPlayFab() to get the DictionaryData JSON string back, which we then load back into the dictionary, so we can display our custom user data, in this case, the number of monsters that were killed last time, and the score from last time.
Finally we call DisplayLeaderboard() which calls GetLeaderboardFromPlayFab() to get the current leaderboard, and we populate a list of objects to display the results.
Conclusion
That's it in a nutshell. The rest of the code deals with running a second time and finding the account details in localstorage. LoginByParameters() is called to make the appropriate login call based on the last data, and everything else follows from there.
If I decide to do a Part 3, it will explain some of the details of the ePlayFab event sheet which provides Function proxies to the actual PlayFab.js JavaScript code, but that's already beyond the intermediate level that Parts 1&2 are labeled as, and is unnecessary to actually use the C3 function interface that I've presented. Unless you needed more API calls, there's no need to actually look at that level of detail.
Having said that, the same pattern is pretty much followed at both levels. ePlayFab is mostly one to one calls to PlayFab.js using the 'await' keyword, to make the calls asynchronous. PlayFab.js is also just a design pattern for calling the PlayFabAPI, converting it from callbacks to an asynchronous mechanism, caching data for later retrieval.