Synchronizing Character Position

All game hosts in multiplayer need to see the same position of all characters in the game, which requires character position synchronization.

In general, the internet introduces latency, the time it takes to send a message from one host to another. Due to latency and communication volume limitations, there is a limit to how often and quickly a character's position can be sent, which is why dead reckoning is the primary method for synchronizing the position of a moving character.

For casual games with a small number of users playing in a single game world, you can group all the users in the game world into a single P2P group for P2P communication between them when sending information about the characters they control to different hosts.

However, if you have a large number of users playing in your game world, communicating everyone's information to each user in the above manner will increase the amount of communication exponentially. Therefore, instead of using the above method, you should limit the sync range to only the characters that are in each user's line of sight.

Synchronizing gameplay between a few hosts

In many casual games, a small number of game clients (usually 15 or fewer) play together in a single game world. In these cases, clients can P2P multicast their character information to each other and still enjoy a smooth game without causing too much traffic.

Summary of key steps

  • Entering the game world: The server joins the user to the P2P group. CreateP2PGroup or JoinP2PGroup

  • Leaving the game world: Call LeaveP2PGroup to remove outgoing users from the P2P group, or let Proud.INetServerEvent.OnClientLeave automatically remove them from the P2P group when they disconnect from the server.

  • Synchronizing each user's location: Each user sends their character's information as an RMI to the P2P group above.

C++ 11 functionC# functionDescription

Proud.CNetServer.CreateP2PGroup

Nettention.Proud.NetServer.CreateP2PGroup

Create a P2P group.

Proud.CNetServer.JoinP2PGroup

Nettention.Proud.NetServer.JoinP2PGroup

Add a peer to an already existing P2P group.

Proud.CNetServer.LeaveP2PGroup

Nettention.Proud.NetServer.LeaveP2PGroup

Kick a member out of a P2P group.

Proud.CNetServer.OnClientLeave

Nettention.Proud.NetServer.ClientLeaveHandler

This event occurs when the client closes the connection.

Synchronizing gameplay across multiple hosts

In a massively multiplayer online game, or MMO, many game clients play together in a single game world (for example, one large region).

In this environment, sending each character's information to all other clients in P2P causes the problem of exponential communication. As a result, in large-scale games, it is recommended to send the character's location to clients, but only to clients who have the character in their view.

In the diagram below, client B, who is controlling the character, sends the server the character's status (location, etc.). The server then sends the character's location, but only to clients A and C who have the soldier in their line of sight. Client D does not have the soldier in its line of sight, so it does not send the character's location, saving communication.

This is referred to as visible region filtering.

The summary of visible region filtering is as follows.

  • Sends the state of its own character from the client to the server.

  • It receives each character's state from the server, holds it, and selects other clients who can see that character and sends character information only to them.

The above visible region filtering is the traditional way of communicating through the server, which has the disadvantage of overloading the server as it is responsible for all multicasts.

ProudNet solves this problem through a very fast and high-performance P2P grouping and P2P communication technology, which is called mixed-phase networking technique (Registered patent no. 10-0812019).

This technique is a way to send your character's location directly to other clients P2P without multicasting it through a server, while limiting the multicast range to the visible area, and is only licensed for use by projects using ProudNet.

Synchronization methods with ProudNet and mixed-phase networking

  1. On the server, you must leave space to store the location of the character controlled by each client.

  2. Clients have their own characters and synchronized characters from other clients, and the server has a Proud.HostID variable for each character that groups clients who can see the character into P2P groups.

  3. The client sends its character's location to the server at regular intervals, and the server receives and stores it.

  4. The server checks at regular intervals to see if a character controlled by a client is in the line of sight of another client. Whenever a character enters or leaves the viewable area, the server must send RMI messages to the appropriate clients about the character's presence or absence, and add or remove them from the list of clients that can see the character.

  5. When the character is confirmed to have entered the client's visible area, an appearance RMI is sent to that client and the character is added to the clients that can see it.

  6. When it is confirmed that the character leaves the client's visible area, a destruction RMI is sent to the client and the character is removed from the clients that can see it.

  7. 클When a client first enters the game world, they must obtain a P2P group ID that points to clients who can see their character's character. Based on this value, the client needs a dead reckoning technique to transmit its character's location to the P2P at regular intervals.

  8. When a client's own character appears in the game world, it is equivalent to the character entering the client's field of view. By contrast, when a client's own character is removed from the game world, this is equivalent to the character leaving the client's field of view.

In a mixed-phase networking scheme, too many transmissions can be generated by too many clients.

To prevent this, please refer to Throttling and P2P communication.

Last updated