Summary

The problem of location synchronization involves three aspects: client, server, and other clients.

Game player feel is the most priority to meet the conditions, so the position of the client game player is a benchmark, but depends entirely on the game player client data is in danger of being cheated, so the server per second will be based on the general state of the projection of a game player client position.

The position that other clients see depends entirely on the state of the base client, and if there is a delay or pause, the state will be reset according to the latest status.

moving environment of gird

How do clients perceive each other's presence? The server map is divided into a grid of the same specifications, each client and NPC are assigned to different lattices. As shown in the following figure

3D or 2D games can be divided in this way, the difference is that the height of the 3D game will be much larger than the grid X or Y, so that the same XY area under the 3D game to have more space.

[attachment=34862:1.jpg]

Server synchronization grid data.

In the MMO game, players want to see all the players in the visible range, which requires other players to synchronize data over the network. Synchronous usually use 9 house grids determine what data need to be synchronized over the game player, and then their behavior to be synchronized to what game player.

The size of the server large grid to 3*3 lattice to the client than to show a larger range of principles. Larger than the client, is to reserve the time to load the resources.

As shown below, green represents the display area of the mobile client, when the character A is in grid 6, he could see the contents of the 9 lattices of 1,2,3,5,6,7,9,10,11, so when his state changes, you need to synchronize all the players in the 9 grids. also, when there is a change in the player or monster in the 9 grids, it also needs to be synchronized to the character A.

[attachment=34863:2.jpg]

When the character A moves to the grid where the character B is (7), Then he will no longer see the contents of the three 1,5,9 (players and NPC), at the same time, he will be able to see the contents of the map in the three 4,8,12. So in this process, the server to send a message, delete the role of the client where the 1,5,9 of the three A map of the contents of the grid, while the next message to add the contents of these three 4,8,12.

Player movement process

Player status refers to the current state of the player's operation as shown below, see the example program HelloWorldScene.cpp getstatus () function.

[attachment=34864:3.jpg]

Player state is divided into 8 directions, corresponding to the keyboard up, dawn, right, lefe. When you press the "up" button will trigger the state of the broadcast, the player's current location, state sent to the server, and through the server to all visible players broadcast. see HelloWorldScene.cpp onKeyPressed () function. The client coordinates the current player's coordinates x, y, and status (setstatus) to the server. The server handles this request via status.lua. Status.lua first get the length and width of the grid into g_x_len, g_y_len. calculate the current player client request. get the server to calculate the current position of the player to calculate the coordinates of the grid. and set the player's new status to path. the path is then put into the output buffer "script.out" and the "helpregist" script is used to calculate the grid and the grid that the player is going to enter. and call "client/clientregist", "client/clientunregist" script.

The server has two lists for each grid. "Client/clientregist" is the script executed by the server when the client enters the grid. first, the data in the "listclient" table is sent to the client, Here are all the client data stored in the grid. the player's data is then sent to other clients. the NPC data in the listnpc table is then sent to the client. then determine whether the input parameter r is 1 if it is 1 to record the current grid. "s.replyid" will format the content of "script.out" to XML and return it to the client.

The "parabuf" function in the client HelloWorldScene.cpp is used to handle all the returned data from the server. the "regist" command contains the NPC data within the visible range of the player. among them are the initial coordinates of NPC "P0" and the "P1" start time stamp "stamp". the client determines whether the current NPC exists and creates a, and according to the timestamp exists, if it does not exist as a "bomb" object.and according to the NPC coordinates and player coordinates to calculate the coordinates of the screen in the NPC, the NCP will be placed into the screen.

Sample program download

http://starrydb.com

Compiled client relies on cocos2dx, download address

http://www.cocos2d-x.org/download

For a real MMO experience you'd need a "fuzzy" method going as well, where the refresh rate of data from people farther away are lower.

For example if 100 people crowd into 1 cell, your client may only be capable of processing data for the nearest 10-15 in "real time", the rest may need to be updated with less priority.

Do all realtime MMO games need this kind of grid system? How do I know how many grids I need to have on the map? You have mentioned 9 house grids data to be synchronized during the update. But if the player is free to move around the screen at all times, unlike gameplay in diablo, but more like agar.io, all other player states on the camera will need to be synchronized.

Most MMOs will have some sort of area-of-interest management, but I've never used one that was grid-based. Any system for quickly finding out who is near enough to merit receiving updates will do. What's important is that you receive information about players before they appear on your screen.

For a real MMO experience you'd need a "fuzzy" method going as well, where the refresh rate of data from people farther away are lower.

For example if 100 people crowd into 1 cell, your client may only be capable of processing data for the nearest 10-15 in "real time", the rest may need to be updated with less priority.

MMO refers to Massive Multiplayer Online does not specifically refer to MMOFPS(Massive Multiplayer Online First Person Shooting Game )

Most MMOs will have some sort of area-of-interest management, but I've never used one that was grid-based. Any system for quickly finding out who is near enough to merit receiving updates will do. What's important is that you receive information about players before they appear on your screen.

Yes, because the player is moving the need to advance the perception of the object will enter the screen.

Do all realtime MMO games need this kind of grid system? How do I know how many grids I need to have on the map? You have mentioned 9 house grids data to be synchronized during the update. But if the player is free to move around the screen at all times, unlike gameplay in diablo, but more like agar.io, all other player states on the camera will need to be synchronized.

Yes, the grid is more mature in the mmo game technology, especially on large maps.but some small map scenes like diablo type, processing techniques will be simplified into a cell.

All MMOs do "interest management," but using a grid to do interest management isn't necessarily the best way.

For example, I've used octrees, and multi-resolution hash grids, to good effect (this was in early '00s)

If you have different objects that can be "seen" at different distances (a big dragon vs a small rabbit) then a single grid isn't the best option.

The operations that need to be fast are:

1. update information about a particular object that moves

2. query the interest management system for all objects that are of interest to a particular player

You do one of 1. per turn per mobile object, and one of 2. per network tick per player.

Also note that it's often important to use other characteristics than just plain distance for what is "important" to a particular player.

For example, any player that's part of the same group/team/squad is probably always interesting, and any object targeted by, or targeting, the player (or someone from their squad) is probably also more interesting than other objects.

And, no matter how you implement this technically, you have to decide how to handle the "most popular zone" problem.

There might be a small city square that works as an auction house or staging ground, and EVERYBODY might suddenly want to be there. Trying to show 1000 players to another 1000 players is an exercise in N-squared hurt.

Best is to design the game so that such "piles" don't occur for some reason. Second-best is to design the game so that it automatically shards (/instances/splits) one something gets too dense. Third best is to scale way back on the quality of updates you get about each other entity. However, most engines want to limit the total number of entities seen, because rendering too many entities, or simulating too may entities, is going to be really slow. Putting an upper cap on the number of entities you can see is often techincally expedient, but it leads to a pretty bad user experience.

(That's fourth-best: Limit the number of objects you can see to X, and only show the X closest objects, with some hysteresis to prevent churn for fidgeting/moving objects.)

All MMOs do "interest management," but using a grid to do interest management isn't necessarily the best way.

For example, I've used octrees, and multi-resolution hash grids, to good effect (this was in early '00s)

If you have different objects that can be "seen" at different distances (a big dragon vs a small rabbit) then a single grid isn't the best option.

The operations that need to be fast are:

1. update information about a particular object that moves

2. query the interest management system for all objects that are of interest to a particular player

You do one of 1. per turn per mobile object, and one of 2. per network tick per player.

Also note that it's often important to use other characteristics than just plain distance for what is "important" to a particular player.

For example, any player that's part of the same group/team/squad is probably always interesting, and any object targeted by, or targeting, the player (or someone from their squad) is probably also more interesting than other objects.

And, no matter how you implement this technically, you have to decide how to handle the "most popular zone" problem.

There might be a small city square that works as an auction house or staging ground, and EVERYBODY might suddenly want to be there. Trying to show 1000 players to another 1000 players is an exercise in N-squared hurt.

Best is to design the game so that such "piles" don't occur for some reason. Second-best is to design the game so that it automatically shards (/instances/splits) one something gets too dense. Third best is to scale way back on the quality of updates you get about each other entity. However, most engines want to limit the total number of entities seen, because rendering too many entities, or simulating too may entities, is going to be really slow. Putting an upper cap on the number of entities you can see is often techincally expedient, but it leads to a pretty bad user experience.

(That's fourth-best: Limit the number of objects you can see to X, and only show the X closest objects, with some hysteresis to prevent churn for fidgeting/moving objects.)