Architectural Design appreciation of hearth stone (3): A Preliminary Study on gameplay

After the analysis in the previous two articles, we are no stranger to the hearth stone code. Next I will try to analyze its game logic code.
Welcome to reprint, please indicate the author [Yan Liang @ Game Development] and the original address: http://blog.csdn.net/neil3d/article/details/39453291

After the previous analysis, we have found two key classes, gameplay and gamestate (of course, spell and spellcontroller, which I am most interested in, will be analyzed later ).

First, let's take a look at the awake method of the gameplay class. The main work it does is:

1. Call "gamestate. initialize ()" to create a new gamestate instance;
2. Register the creategame event: Respond in gameplay. oncreategame (), mainly
   • Initialize the card back; (the card back IDs of local players and remote players are read through the player class );
   • Start a coroutine: notifyplayersofboardload. The main task is
     • Wait until the boardstandardgame object is loaded;
     • Call onboardloaded () of all players. The main task is to initialize the management logic related to the mana crystal;
3. Use assetloader to load attackspellcontroller, secretspellcontroller, and turnstartmanager;
   These classes seem to be important and will certainly be used in subsequent analysis of game logic.

Next, let's take a look at the gameplay. Start () method. It registers some network messages that you care about and then calls

1. Network. startcountdown () -- sends the network message "beginplaying ";
2. Network. getgamestate () -- send the network message "getgamestate ";

Let's take a look at gameplay. Update (), which seems to be normal only by calling gamestate. Update (). OK. The above are the three automatically called functions inherited from monobehavior. There is no clue about the game logic.
Further analysis, the biggest difficulty encountered is that many operations should be completed through network interaction, such as [admit defeat] operations, which are analyzed from gamemenu. concedebuttonpressed () is always called to connectapi. concede () sends a Giveup message to the server, but cannot determine what the server returns.

Next, let's analyze the transfer of the game round first, or let's take a look at the relevant class diagram:
The end of the round is triggered by the player clicking the end trun operation on the right. The corresponding code is: inputmanager. doendturnbutton (), the logic of this function is somewhat confusing. Currently, we can only guess the following:

• First, determine whether the optionspacket of the gamestate can be accessed and whether the endturnbutton can be operated;
• Then, gamestate. getresponsemode () is used in two cases:
  • Gamestate. responsemode. Option -- the preliminary assumption is that the operation is normal in the game round:
    Retrieve all networks from the gamestate. options, traverse, and find "optiontype. end_turn "or optiontype. and then call gamestate. setselectedoption (I); gamestate. sendoption ();
    
  • Gamestate. responsemode. Choice -- initially guessed that the operation of the initial hand card was selected at the beginning of the game round;
    

It is difficult to guess the behavior of the server. You can only wait until the client behavior analysis is complete. The server-side response is roughly like this, and the start of gameplay contains the following sentence:

network.RegisterNetHandler(Network.PacketID.ALL_OPTIONS, new Network.NetHandler(this.OnAllOptions));

Imagine that the client uses gameplay. onalloptions () processes all player operations received by the network layer. the data retrieved by getoptions () is sent to gamestate. onalloptions () to process, the latter will trigger the event gamestate. fireoptionsreceivedevent (). Through the corresponding gamestate. registeroptionsreceivedlistener () member function, we can analyze which objects will respond to this event. Find endturnbutton. onoptionsreceived ().
The analysis at this stage is becoming more and more difficult. This analysis is a small achievement, but the entire round flow process is not clear yet. Summary:

• Player operations are handled in inputmanager. Key member functions include donetworkresponse () and doendturnbutton ();
• Player operations and network-sent operations are stored in gamestate. m_options;
• Another entity class system also needs further analysis.

Architectural Design appreciation of hearth stone (3): A Preliminary Study on gameplay