Map Design of coco2d-x Based on The View

View-Based Map Design
DionysosLai 2014-06-14
The third person is the game, where players are in control of the entire game from the perspective of God. Therefore, in game design, we need to place the game's main character in the center of the screen or in most areas of the screen, such as some games such as super Mary and tianyao, when you are careful, the player will find that the main character is in the same position or within a certain range. When the main character moves, the background will not move, but when the entire range is exceeded, then the background will be moved. All these designs are basically the Map Design Based on The View. The typical example is angry birds. Note that the main character of the game here is the released bird.
For the design of such a map, first understand the concept of the view. The view, that is, to set the range in which the main character can be moved under normal circumstances. If the range is exceeded, the map will also be moved. If this is not the case, for example, the map has already been moved to the edge of the screen. This is because when the role exceeds the corner of the view, the map cannot move with the role, and the black edge cannot be seen. For the view, as shown in:
Figure 1
The black area is in the black range. However, there is a problem with the design of the viewport, that is, when the role enters the Four Corner areas for some reason (maybe only God knows this reason, then the role moves, but the map does not move (for example, from A to B), and the actual situation is that the map also needs to move. One of the solutions to this problem is to determine whether the map is at the edge of the screen, or do some processing. The second solution is to reset the concept of the view.
The design of the second method is as follows:

Figure 2
This design can avoid the above problems, but there is a problem that if C moves toward the arrow, it will not cross the view, and the map will not move. To solve this problem, add a rule that if the role is out of sight and does not move in the direction of the view, then the map will also follow the role.
OK. At this point, the map design based on the view is basically like this.
The following is the problem, that is, the overall design.
In the game, the protagonist often has to deal with some collisions, so it is recommended that the protagonist be placed on the same layer of the map. Because of this design, the location of the saved role remains unchanged. When the map is moved, the role must move in the opposite direction.
The following are some key points of the design.
Design 1 Map and role movement design:
In the final analysis, there are three ways to move:
1. Move the role and the screen together;
2. The role moves and the screen does not move;
3. The roles and maps are not moved. For example, if a role encounters an obstacle, it must be stopped.
The Code is as follows:
Enum // movement status {MAP_E_MOVE_ALL, /// <map and role move MAP_E_MOVE_ROLE, /// <role move MAP_E_MOVE_STOP, // <map and role cannot move };

Design 2 how to set and change the mobile status:
Check three situations from time to time: 1. Whether the role is in the eye; 2. Whether the role is out of the eye, but whether it is moving towards the eye; 3. Whether the role has encountered obstacles.
The Code is as follows:
Do {// first, pre-determine whether the main character will be out of sight and if (isRoleInView (ccp (0, 0) {m_iMoveState = MAP_E_MOVE_ALL; /// <move the map with the main character} else {// you can determine if you want to move the trend of the visible view if (roleToView (pointBy )) {m_iMoveState = role; // <main character movement} else {m_iMoveState = MAP_E_MOVE_ALL; // <map moves with the main character} if (isCollision (ccpMult (pointBy, 2.f ))) {m_iMoveState = MAP_E_MOVE_STOP ;}} while (0 );

Design 3 map Adjustment
Based on the moving status, the map needs to be moved every moment. You need to record the moving size of each frame, determine whether the frame has exceeded the screen, and adjust the position based on the four directions of the top, bottom, and bottom.
          
Design 4 how to move
We do not recommend that you use the moveBy function provided by the engine. This is because we need to check the function at any time. Therefore, we need to record the position where we want to move. Based on the role position (I believe that on the tablet, the position the player clicks is the position where the role is expected to arrive), we need to calculate the relative vector. Then, each frame needs to move the distance to the unit vector of the relative vector.
The Code is as follows:
Float m_fMoveDistance; /// <record the distance from each movement to cocos2d: CCPoint m_moveVector; /// <moving vector float m_fMoveSpeed; // <moving speed

Design 5 Map Display Design Problems
The screen size is so large that a map has a screen size, and a screen can only display up to four maps. Therefore, we can temporarily remove maps not on the screen, this greatly improves the game efficiency. --- In the Demo, we designed a map of 100*100 to run smoothly. Similarly
The same map can use CCSpriteBatchNode.
The Code is as follows: in the void setMapVisible (void); Function
In fact, this method can also be used for items that are not displayed in the map. Currently, this optimization is not available in the Code and will be added later.
    
Okay, basically the problem is solved. To download the source code, log on to my GitHup Website: https://github.com/dionysoslai/maplayer. You are welcome to download it.
 
For the current design, it has been tested by the game "Super excavator" and there is no problem. However, there is a design bug that cannot be avoided at all, that is, in the case:

A moves toward the discovery of arrows. If A is more inclined to the right of the screen, it feels bad to move.