First section with player name setting and user preference access.
This Fsm deals with managing the user name. The user name is stored using the playerPrefs system, which allos saving and retrieving small data between sessions, so that next time you open the application, the name you entered last time is there. Referencing Data in the prefs requires a "key", for convenience and efficiency, a variable is there to define this key, so that all actions using the pref system do not need to worry about the key, the variable is called "PlayerName pref key"
RETRIEVING NAME FROM PREFS
When we START, we query the playerPrefs system for the user name. for the sake of clarity, I only check if the key exists, I could store it as well, the action allow for this, but I wanted to visually show both process clearly. So If the key exists, we retrieve it and store it in the "photon playername" state. If the key doesn't exists ( this means the first launch of this application), we create a random one in "create a random one" state and then store it the same way in the photon playerName.
EDITING NAME AND SAVE IT IN PREFS
Showing the name field gui to the player obeys to the same rules as for other menu items, we need to be connected to Photon before showing anything to the user. So we wait for PHOTON / STATE : CONNECTED and only when this built in event fires, we display the user name field in the gui. We know by then that the retrieval process has happened ( from the START event). the only thing we need to care here is when the user is editing his name.
The gui field declared in "main menu" state triggers a NAME EDITED event created for the occasion, when the name is edited, we transit to the "store in preferences" state, which effectivly write the new username in the prefs using the key we defined in "PlayerName pref key" variable. You can appreciate here the very convenient usage of the "PlayerName pref key" variable, we can access and work with the playerPrefs system in any State, and never worried about going through all the state potentially dealing with this key and rename it if we needed so. We have one central reference of this key, and everything will work ,even if you decide to rename that key to something else.
You'll note as well that the "store in photon playername" state has a duplicate. if you try to do this, you will firt get a warning, that two states can not share the same name: I simply add space to the name, so the warning goes away. duplicating states and processes is never a good thing, but sometimes, it's the most simply approach. If we wanted to avoid duplicating processes, we would need to implement more states to check if we should show or not the gui, which would complicate the Fsm a bit more and make it less readable. Making a second Fsm to deal with this, doesn't solve the duplication problem, it would make it even worse, because then you would need to store twice the pres key, and that would end up being less stable and prone to potential bugs in the long run. So yes, duplicates is to be avoided, but sometimes, it's way easier for granular features such as this one.
Photon Actions used:
- Photon Network Set Player Name Leave Room ( in both state "store in photon playerName")
