Action card Game-system design-scene and UI system

People familiar with COCO2DX may know that the Ccscene class is provided inside the engine, which is a class of scene concepts, and COCOS2DX itself provides a way to switch scenes.

Ccscene T_scene;

Ccdirector::shareddirector ()->runwithscene (T_scene);

In fact, we have to do rather than how to change the engine. Instead, it is encapsulated outside the engine. Abstract out the various systems, and then through the various systems invoke the function of the engine, to achieve our needs.

Requirements: To achieve a scene, the scene is dynamic, floating on a variety of small islands, the scene of birds, water. It has a layer of GUI with buttons on it, such as backpacks, quests, etc.

Analysis:

"Scene Design Rules"

One is to cut a scene in the game, such as a A, a two scene switch, if a scene is currently displayed, the B scene's resources need to be removed from memory. If it is currently a B scene, the resources in a scene need to be removed from memory. In theory, the peak of memory can be changed in your most complex scenes. May be in the process of cutting the scene, need to do loading, time loss.

The other is a single scenario, and all we need to do is keep changing the UI.

Since we need to do battle scenes, we have taken the first cut of the scene in a way that plans 2 scenarios. One is the main scene, one is the battle scene, into the battle process need to do loading to load the battle resources. Then some of the resources at the home scene were cash to ensure a quick switch to the main scene after exiting the battle.

"UI Design Rules"

In the battle scene and in the main scene, our UI display is completely different. So we decided to go with the UI and the scene. Because there are two scenarios, you can manually write to the scene specified in the program to load the specified UI. If you design to a multi-scene mode, such as a 3D client game, the UI is actually irrelevant to the scene, unless you make a special request. In fact, in the end our UI modules and scene modules are also separate. It's just a matter of toggling the scene and hooking the specified UI to a layer on the scene. One of the more common operations in the game is that a UI pops up another UI, one UI switches to another UI, and one UI returns to the previous UI.

According to the usual rules, we will mainly set up three rules of the UI operation mode,

A call UI popup close rule (popup,popdown), which can be implemented in an interface to pop up any interface, and then after the popup, do not close the interface, such as after the battle victory, you must be certain to launch the current pop-up window. A bit like a modal dialog box in Windows programming.

One is called the UI entry Exit rule (entry,back), it is mainly used for interface switching, such as interface a-> interface b-> interface C layer, and then interface c-> Interface b-> interface a layer exit. Its internal implementation is a stack, LIFO, advanced and out.

A clear UI rule is to empty the stack and force it back to the main interface.

"Scene Hierarchy Division"

For a scene, we are currently divided into 4 levels according to demand, that is, Ccscene above the 4 Cclayer and set the ZOrder relationship, a call background layer, middle layer, UI layer, the front UI layer. Background layer is the basemap, such as blue sky and white clouds, the middle layer is floating island, UI layer is the UI to mount this above. The front UI layer is a layer where some special effects need to be covered in the battle UI during combat. Otherwise, throughout the framework, our UI will overwrite everything.

Action card Game-system design-scene and UI system