After reading the news a few days ago, two grand prizes of Unity awards were awarded to blizzard's Firestone legend. This is really a great promotion for unity-you see, blizzard started to use unity. As we all know, most of the Games released by unity do not confuse and encrypt the Assembly. Therefore, as a beginner of Firestone and unity, you naturally cannot miss this opportunity. Let's take a good look at blizzard's code.
The legend of hearth stone game is rich and colorful, so I spent some time analyzing its assembly, recording some design ideas, and analyzing them with everyone. All experts are welcome to make bricks. You are welcome to repost the bricks. Please indicate the source: yanliang @ game development, http://blog.csdn.net/neil3d/article/details/39426329.
The main purpose of this analysis is:
- Let's see how hearth stone organizes game logic to support complex skill logic and performance;
- Let's see how Firestone uses unity and what is worth learning in its structural design and skills;
- Learn English from Blizzard programmers.
Next we will officially start. I used to analyze the game startup process first. This involves the management and initialization of basic game data, various Manager-level classes, and mutual reference relationships.
First, let's take a look at some of the classes related to the game startup process. below is their class diagram:
Next, we will analyze the game Startup operation process.
- The applicationmgr object should be bound to a scenario object, which should be loaded at game startup;
- Applicationmgr: awake () is automatically called by the Unity engine;
- Call applicationmgr: Initialize (). In this function, the following member functions are called for initialization in sequence:
- Initializemode (): sets the mode to applicationmode. Public;
- Initializeunity (): Some attributes of unityengine. application are set;
- Initializegame (): It seems that the core content is here. initialize network, gamemgr, and so on;
- Initializewindowtitle ();
- Initializeoptionvalues ();
Game startup should be more than that. Because we rely solely on the dynamic analysis of the Assembly, we cannot know its Scenario Editing, object script binding, or tracking and debugging, so we can only rely on speculation. In addition, some events are triggered by network messages, which makes static analysis difficult. OK. Let's continue. I noticed that class login is derived from scene. I have checked that there are still many derived classes in scene. I guess each derived class serves as a script for specific scene logic processing. Login should be activated and run in 0th scenarios. Let's take a look at login: Start (), which is automatically called by monobehavior. He mainly does the following:
- Registered resource Version Detection and network message callback related to login;
- The scenemgr scenario is loaded;
- Call the member function: autologin (); this function calls network. autologin ();
- Find the user name from the configuration file, and then call connectapi. autologin () -- it is strange that this function simply returns false without actual operations.
Let's take a look at login: Update (), which is also a script function automatically called. Here it detects the status of login and calls the member function loginok (), which mainly calls assetsversioncheckcompleted (). This function has a rich set of content:
- Notify other modules that they have successfully logged on, including baseui, inactiveplayerkicker, healthygamingmgr, and gamemgr;
- Call initialize functions of some modules, including defloader, collectionmanager, adventureprogressmgr, tournament, and storemanager;
We have seen that login is derived from scene and there is also a scenemgr class. We can conclude that the game is divided into several scene based on different logic. Next we will explore the scene switching process. Or start with login.
The following process is completed in the login class. The process described below is the call of the login member function:
- First, I found the login: onnetcachereadystep2 () function, which should be the network message callback function at a specific step in the login process;
- It will call the coroutine function waitforachievestheninit (), which detects whether to play the video and then calls reconnectorchangemode ();
- This function is used to reconnect. Generally, changmode () is called ();
- Changmode () processes the startup logic related to the new tutorial. Generally, changemode_hub () is called ();
- This part seems to have called a special skill effect. After the special effect is played, the callback function is called: onstartuphubspellfinished ();
- This function calls showunackedrewardsandquests ();
- Handleunackedrewardsandcompletedquests (), OH ~,This should be the interface that shows the current task and unreceived rewards when the game is started.;
- It calls shownextunackedrewardorcompletedquest ();
- Showwelcomequests () is called ();
- When the displayed task is 0, the following statement is called:Scenemgr. Get (). setnextmode (scenemgr. mode. hub), which is a key step;
Next we will jump to the scenemgr class and continue to explore the implementation of the scene switching process. The following are the member functions of scenemgr:
- The setnextmode () function mainly sets the member variable "m_nextmode" to a specified value;
- Next, let's take a look at Update (). This function mainly checks whether mode needs to be switched and then calls:
- Switchmode (): This is a coroutine, which calls loadmodefrommodeswitch (). Its core is to call loadmode ();
- Directly call loadmode ()
- Loadmode () function, mainly based on the current mode, call loadscene ();
- The loadscene () function is called mainly:Application. loadleveladditiveasync (this. scenename );
- This completes the scenario switching.
OK. Through the above analysis, we have a general understanding of the game startup process as follows:
- Verify the account;
- After the account is verified, unreceived rewards and tasks are displayed;
- Switch to the scenemgr. mode. Hub mode, that is, the corresponding scene is loaded.
The Analysis of game startup has come to an end. The next article will analyze the scene organization of hearth stone.
Architectural Design appreciation of hearth stone (1): Game Startup Process
