In the previous article, we saw the storage of core card data in hearth stone. Today we continue to explore Cards & skills.
Through previous analysis, the main classes involved several classes of cards and Skills: entity, actor, card, and spell, which are very confusing, especially the first two. Here we will explain the basic positioning of these classes in a slightly arbitrary way:
- Entity is mainly used for network data synchronization;
- Actor is mainly used to control rendering objects on the client, and is mounted as a component on the resource object;
- Spell is the script for skill prefab mounting;
- Card is a script mounted to the card Prefab. It is in a central position during runtime and handles the contact between the first three users.
Entity
- Entity is created through network data, mainly the Message Network. packetid. power_history. For details, see the gamestate. createnewentities () function. Because entity is not a monobehavior derived class, it is new and then added to gamestate for Management (gamestate. addentity (), the entity data sent from the network is mainly tags (each tag is a name-> Value Pair), and then calls entity. initentity ();
Actor
- Actor is also a resource that is loaded through assetloader. loadactor;
- Corresponds to assetfamily. actor;
- The corresponding resource package is "actor ?. Unity3d ", the package is gameobject;
- The actor loading entry is in: card. determineactorthentransitiontozone ()
Spell
- The spell loading entry is in entity. processcarddefassetrequest ()
Card
- Entity. initcard () is called in initentity. It only creates an empty gameobject and adds the card with addcomponent.
- The real card prefab is loaded in entity. loadcard (). This function is called in gamestate. onshowentity () when processing powertask;
- The specific loading operation is carried out through defloader. loadcarddef (), and it calls assetloader. loadcardprefab () internally to load resources;
The creation of entity in card and skill loading processes and card and spell loading are all triggered by network messages. The whole process is complicated, mainly because there are many asynchronous callbacks, it is difficult to use text descriptions. See:
Architectural Design appreciation of hearth stone (6): runtime organization of card and skill data
