> For the complete documentation index, see [llms.txt](https://docs.proudnet.com/proudnet.eng/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.proudnet.com/proudnet.eng/proudnet-note/notes/character_sync.md).

# 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**](/proudnet.eng/proudnet-note/dictionary.md#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**](/proudnet.eng/proudnet-note/dictionary.md#undefined-1) 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. <mark style="color:orange;">CreateP2PGroup</mark> or <mark style="color:orange;">JoinP2PGroup</mark><br>
> * **Leaving the game world**: \
>   Call <mark style="color:orange;">LeaveP2PGroup</mark> to remove outgoing users from the P2P group, or let <mark style="color:orange;">Proud.INetServerEvent.OnClientLeave</mark> automatically remove them from the P2P group when they disconnect from the server.<br>
> * **Synchronizing each user's location**: \
>   Each user sends their character's information as an RMI to the P2P group above.

<table data-full-width="false"><thead><tr><th width="193">C++ 11 function</th><th width="366">C# function</th><th>Description</th></tr></thead><tbody><tr><td>Proud.CNetServer.CreateP2PGroup</td><td>Nettention.Proud.NetServer.CreateP2PGroup</td><td>Create a P2P group.</td></tr><tr><td>Proud.CNetServer.JoinP2PGroup</td><td>Nettention.Proud.NetServer.JoinP2PGroup</td><td>Add a peer to an already existing P2P group.</td></tr><tr><td>Proud.CNetServer.LeaveP2PGroup</td><td>Nettention.Proud.NetServer.LeaveP2PGroup</td><td>Kick a member out of a P2P group.</td></tr><tr><td>Proud.CNetServer.OnClientLeave</td><td>Nettention.Proud.NetServer.ClientLeaveHandler</td><td>This event occurs when the client closes the connection.</td></tr></tbody></table>

## 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 <mark style="color:orange;">visible region filtering</mark>.

<figure><img src="/files/EX1vLVqVgwauVKbbYWk4" alt=""><figcaption><p>Visible region filtering in large-scale warfare games (via server)</p></figcaption></figure>

The summary of <mark style="color:orange;">visible region filtering</mark> 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 <mark style="color:orange;">visible region filtering</mark> 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 <mark style="color:orange;">mixed-phase networking technique</mark> <mark style="color:orange;">(Registered patent no. 10-0812019)</mark>.

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.

<figure><img src="/files/0cPq7nQjfaHj4OEUJDEs" alt=""><figcaption><p>Visible region filtering in large-scale warfare games (mixed-phase networking approach)</p></figcaption></figure>

## 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.<br>
> 2. Clients have their own characters and synchronized characters from other clients, and the server has a <mark style="color:orange;">Proud.HostID</mark> variable for each character that groups <mark style="color:orange;">clients who can see the character</mark> into P2P groups.<br>
> 3. The client sends its character's location to the server at regular intervals, and the server receives and stores it.<br>
> 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 <mark style="color:orange;">clients that can see the character</mark>.<br>
> 5. When the character is confirmed to have entered the client's visible area, an appearance RMI is sent to that client and the <mark style="color:orange;">character is added to the clients that can see it</mark>.<br>
> 6. When it is confirmed that the character leaves the client's visible area, a destruction RMI is sent to the client and the <mark style="color:orange;">character is removed from the clients that can see it</mark>.<br>
> 7. 클When a client first enters the game world, they must obtain a P2P group ID that points to <mark style="color:orange;">clients who can see their character's character</mark>.\
>    Based on this value, the client needs a [**dead reckoning**](/proudnet.eng/proudnet-note/dictionary.md#dead-reckoning) technique to transmit its character's location to the P2P at regular intervals.<br>
> 8. When a client's own character appears in the game world, it is equivalent to the <mark style="color:orange;">character entering the client's field of view</mark>.\
>    By contrast, when a client's own character is removed from the game world, this is equivalent to the <mark style="color:orange;">character leaving the client's field of view</mark>.

{% hint style="info" %}
In a mixed-phase networking scheme, too many transmissions can be generated by too many clients.

To prevent this, please refer to [**Throttling**](/proudnet.eng/proudnet/using_pn/communication-messages.md#throttling) and [**P2P communication**](/proudnet.eng/proudnet/using_pn/p2p.md).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.proudnet.com/proudnet.eng/proudnet-note/notes/character_sync.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.