Architectural Design appreciation of hearth stone (2): Scene Management

In the previous article, we analyzed that scenemgr handled the loading of scene. Today, we mainly analyzed which scene exists in the Firestone game and what they are responsible, and its internal logic and UI processing method.

Before the official start, I will perform some additional analysis on the scene switchover mentioned previously. In the previous article, we saw that scenemgr called "application. loadleveladditiveasync (this. scenename);". Isn't there more and more things in the memory? Let's take a closer look at the scenemgr: switchmode () function, which is a coroutine and mainly performs the following operations:

1. Call the scene: preunload () function of the current scene;
   Send a firescenepreunloadevent event;
   Wait until the unload process is completed (by detecting the loadingscreen stage );
2. Call scene: Unload () function;
   Send a firescenepreunloadevent event;
   Call the member function postunloadcleanup (), which calls two key functions:
   • The first is the member function: destroyallobjectsonmodeswitch (), which finds all gameobject (object. findobjectsoftype (typeof (gameobject), and then filter (through the shoulddestroyonmodeswitch function), in addition to some global objects (mainly scenemgr, pegui, box, defloader ), all are deleted (by calling object. destroyimmediate ()).
   • Then the following code is called: resources. unloadunusedassets ();
3. Then, call the previously mentioned member function loadmodefrommodeswitch () and perform the loadleveladditiveasync () operation;

To sum up, the scene switching of hearth stone mainly involves two steps: 1. Delete all non-Global Objects, unload unreferenced assets, and 2. Load new scene. (I think of another alternative solution: to create a completely empty scene and call loadlevel to load it, all objects without "dontdestroyonload" will be deleted .)
In addition to the login mentioned above, we can see that scene has many derived classes. For details, see:

This is the relationship between these classes and the game content I have guessed. I did not carefully analyze them, but some of them may be wrong:

Next we will select a simple scene to analyze its internal operation mechanism. Let's take a look at adventurescene. There are many classes related to adventure. We only make a rough analysis and only involve the following classes and interfaces:

First, I guess that after clicking the "solo Adventure" button in the middle of the hub screen, I loaded a scene related to the adventure mode through the loadscene process we analyzed above. There is a gameobject bound with the script "adventurescene". We can see that the adventurescene: awake () method mainly registers callback for many events. We can see that there is an "adventruesubscenes" enumeration, which basically corresponds to the button in:

public enum AdventureSubScenes{    Chooser,    Practice,    MissionDeckPicker,    NormalHeroic,    ClassChallenge}

Next, "adventuresubscene" is used to process the logic corresponding to the sub-scenario.

We can see the class "adventurechoosertray:

• I guess this class is used to deal with the UI interaction operations on the above game screen;
• This class creates the buttons related to the content modes of the previous adventure games by calling the "createadventurechooserbutton ()" method during awake;
• These buttons are bound to the Event Callback: adventurechoosertray. buttonmodeselected (). When these buttons are clicked, they are called mainly:
  • Adventureconfig: setselectedadventuremode (). This function triggers the event after modifying internal data: fireselectedmodechangeevent ()
    
  • Adventurechoosertray responds to this event through onselectedmodechange (), which means some processing to be done after you click the buttons above: including updating the screen on the left and setting the choose button status;
    Playmakerfsm is called, mainly to send the event "burst" to it. Here, we can confirm that hearth stone uses the playermaker plug-in.
  • Adventurescene also corresponds to this event through onselectedmodechanged;
    
• It also contains a member variable "playbutton m_choosebutton" and adds eventlistener to it to call the changesubscene () method. This corresponds to the actual operation of the game: select the mode above, and click the "choose" button below to proceed to the next step.
• Adventurechoosertray: changesubscene () uses coroutine to call adventureconfig: changesubscenetoselectedadventure (), and then calls adventureconfig: changesubscene (). It mainly triggers two events:
  
  • Firesubscenechangeevent: adventurescene responds to it through the onsubscenechange () function. It mainly calls adventurescene: loadsubscene () and internally calls assetloader. loaduiscreen ();
  • Fireadventuremodechangeevent: adventurescene responds to it through onadventuremodechanged.
    

Through the above analysis, we have roughly understood the operation implementation logic in the above game. This analysis is a warm-up. The next analysis focuses on two aspects:

• The organization of game logic, especially the data and logical organization of skills, may need to be tried several times and approached slowly;
• Game asset resource management and loading mechanism;

OK. Today's analysis is here. You are welcome to make a picture. Future Analysis is coming soon!

Architectural Design appreciation of hearth stone (2): Scene Management