MMO Multiplayer Real-time synchronization problem

In the 2.5D MMO game, characters are rendered in 3D, 2D maps are displayed by 2D, so there are three coordinate systems on the client side:

a) 3D coordinate system: all roles and light effects that require 3D rendering are positioned in the coordinate system.

b) 2D coordinate system: used to locate and draw fixed 2D map elements, such as turf, road, etc.

c) grid coordinate system in 3D coordinates: used to achieve mask, auto pathfinding and some coordinate configuration (such as NPC and Monster initial position). Using grid coordinates, one is to facilitate the calculation of mask and automatic pathfinding (classic A * pathfinding), the second is to make it easier to find the exact location of coordinates.

The size of the lattice used for the end trip is generally (64, 32), the accuracy of the hand tour is lower, can be used (100, 50), that is, the 3D coordinate system with a length of 100 width is 50 of the rectangle, which is a coordinate in the grid coordinate system. The example diagram is as follows:

2. Server Synchronization Large lattice: 9 Palace lattice

In MMO games, players can see the behavior of all the characters on the map, which requires the synchronization of other players ' movements over the network data. Synchronization generally uses 9 Gongge to determine which player's data to synchronize, and then to synchronize their behavior to which players.

The size of the server large lattice, to 3*3 the grid is always more than the client display range is a little more principle. A bit larger than the client, in order to reserve the time for the resource to load.

As shown, green indicates the display area of the cell phone client, and when role A is in grid 6, he can see the contents of the 9 lattice of the 1,2,3,5,6,7,9,10,11, so when his state changes, it needs to be synchronized to all the players in these 9 squares; When the status of the player or monster in these 9 squares changes, it needs to be synchronized to character a.

When role a moves to the grid (7) where character B is located, he will no longer see the contents of the three squares of the 1,5,9 (players and monsters), and he will see the map contents of the three squares of 4,8,12. So in this process, the server to be issued a message, remove the client in the role A is located in the 1,5,9 of the three lattice map content, and issued a message added 4,8,12 these three lattice map content (type one).

Recommended large lattice specific size, according to the client Iphone4s 960*640 resolution to make, take the screen length and width of 1/2 large, can be set as 640*360.

3. Mobile Synchronization of roles

The synchronization of the characters on the map can be divided into the synchronization of the displacement and the behavior (such as the skill of putting). This paper mainly discusses the synchronous mode of displacement.

The purpose of the displacement synchronization is to send a change of location to the server, which is then forwarded by the server to the other players around it by 9 Gongge.

Some end-trips are synchronized with the basic unit of the client grid, and when the player moves from one grid to another, a message is sent to the server. The disadvantage of this approach is that:

One, the synchronization delay. When the player moves from one grid to another, the message is sent to the server, the server is forwarded to the other client, and the other client's player location is always postponed.

Second, when the network is unstable, it is easy to see other players are not the average speed of movement, such as the player position is not moving, and then suddenly moved to the next lattice.

The way we do this is the change in the state of synchronization, and then the client will trigger the server to judge the big lattice leap:

d) when the player clicks somewhere on the map, or changes the direction of the joystick, the player's running state changes, that is, moving to a point of coordinates. When the state changes, the client immediately sends a message to the server and the server forwards it. This way, if the delay of the network is ignored, the role is almost at the same time moving on all clients.

If there are no other changes during the move, only one message is synchronized during the entire move. The problem here is that the server needs to know when the role crosses the server's sync big grid, and the server needs to do the second section (type one) when the character crosses the large grid.

e) How to determine the role of the mobile process across the synchronization of large lattice, some games using the server to determine the way, that is, according to the character's movement speed and direction, calculate the time span, and then use a timer to trigger. At the same time, if the server is going to take the role's current position, it needs to be calculated using the motion formula. This scheme is relatively accurate, but more complex, the server also needs to set a timer for each mobile role, the performance of the server has a impact.

We use the way that the client determines the role of each move a small distance, and then send a message to notify the server, the server does not forward the message, but only to determine whether to cross the large lattice, while recording the coordinates, as the current position of the role. This small distance can take 100 or so, the greater the value, the less the message is sent, but the server synchronization large lattice leap judgment and the role of the current position is less accurate.

Because it is the running state of the direct synchronization, the coordinate unit that the client sends to the server is the unit in the 3D coordinate system, not the coordinate unit of the 3D coordinate system grid. This is more accurate, a little distance of the movement, can be accurately synchronized.

f) one of the problems with synchronous motion is that if the player is operating very frequently, such as when he is dying to flee, the crazy location map, when the movement state changes very quickly, if each state changes are synchronized to the server, plus broadcast, the message volume is very large.

So you need to set a state synchronization of the shortest time, when the motion state changes quickly, the state changes the message cached in the client, while adding a timer tracking. When there is a new state change message coming out, replace it and update the timer at the same time. When there is no change in the state of the message comes out, the timer will be triggered by the time, the cached state changes the message, to the server.

In this way, the message cache plus the processing of the timer, both to achieve the running state synchronization of the shortest time limit, but also ensure that the last effective running state will be a little bit later sent to the server.

4. Synchronization of Monsters

The synchronization of monsters in the traditional end of the tour, is completely triggered by the server's monster AI system, the client just purely accept the server issued by the Monster State data. For mobile games, because the mobile phone is difficult to appear like a PC plug-in, so the monster AI can be considered on the client trigger, while reducing the state synchronization of monsters. Detailed description is as follows:

A) random movement of monsters is not synchronized

On the map, monsters will have a fixed position. When monsters are not in combat, they walk around in this fixed position and move randomly. This random movement is controlled by each client itself, so that the mobs are randomly moved without the need for a message broadcast to synchronize.

Because the client controls the random movement of monsters, there will be a different problem in the client, the monster location. But because the mobs have a small range of random movements, the problem is not obvious and is acceptable on the phone. The role of playing strange, is a fan of the damage range, so even if the monster coordinates in different clients a little inconsistent, the effect is also acceptable to play the blame.

b) Behavior synchronization of Monsters

When a character attacks a passive monster, or enters the field of view of an active monster, the monster's AI is locked by the client on which the character is located, and the monster enters the attacking state. The judgment of the attack is handled entirely by the client that locks the monster AI, and the client sends the behavior of the monster to the server, which is broadcast by the server to the other players around it.

The monster's AI locks up, using preemption, that is, who first sends the message to the server to request the monster's AI lock, who gains control of the monster until the monster dies or is out of combat.

Monsters can attack each time, the client sends a message to the server. In doing so, the message is still a bit more, especially when a group of strange characters around the attack, the message broadcast is a bit more. Therefore, the concept of the state can be expanded upward, only the monster in the attack which player, but not to synchronize each attack, and then by each client according to the attack speed fixed by the mob to each performance. Such a strange to attack a player, there will be only one message broadcast.

c) AI of elite and boss monsters

Elite and Boss monsters because of the number of small, and more important, so the client can not apply for AI control, but the server based on a strategy to control. The strategy used can take into account the damage value of the role, the defensive value, the distance between the character and the boss, and according to these factors, the server calculates the object that the boss is currently most suitable for attacking (such as the least-valued player, the most vulnerable mage, etc.), and then sends AI control to that client. The client controls the attack behavior while simultaneously synchronizing the server to other players via the message.

Summary: The choice of the monster synchronization method is to minimize the broadcast of the message, while allowing the game to be within an acceptable range. This processing of the monster AI, in fact, eliminates the game server's monster AI module (end-trip is generally dedicated to a process or another physical server for the calculation of monster AI), thus simplifying the development of MMO games, while ensuring a better gaming experience.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

MMO Multiplayer Real-time synchronization problem