When game hosts join in multiplay, the position of their playable game characters must be shown to each other. For this, the position of game characters must be synchronized.

When a host sends a message to another host in internet, latency occurs due to the time it takes to transmit the message. Because of this latency and the limit of network traffic, there is also a limit in the rapidity and number of sending the position information of game character. A method that can synchronize the position of characters is Dead Reckoning.

When sending information of each game characters under control of users to other hosts in a casual online game that only a small number of gamers enjoying the game in one game world, the entire users can form a P2P group and communicate with each other. Please refer to Gameplay synchronization for small number of hosts for more details.

However, such P2P method increases significant amount of network traffic if it has used in a game with a massive number of users playing together in one game world. Thus the range of synchronization has to be limited to game characters only in the sight of each user. Please refer to Gameplay synchronization in MMO for more details.

You can also look up sample programs from 3. Character synchronization in 3D world .

Gameplay synchronization for small number of hosts

In typical casual games, normally a relatively small number of game clients (less than 15) play the game together. At the case like this, each client can Multicast their character information via P2p without causing too much trouble in network traffic.

Here are the procedures.

• User entering the game world: Adds the user as a member of P2P group in server. (Refer to Proud.CNetServer.CreateP2PGroup or Gameplay synchronization for small number of hosts)

• User exiting the game world: You can delete the user leaving P2P group by calling for Proud.CNetServer.LeaveP2PGroup or leave the user being automatically removed from P2P group when the user disconnects from server (refer to Proud.INetServerEvent.OnClientLeave).

• Synchronizing character position: Each user sends information related to their character to P2P group by RMI. (Refer to 11. Usage of Remote Method Invocation) The method to synchronize the position of characters is guided in Dead Reckoning.

Gameplay synchronization in MMO

In a massively multiplayer online game or MMO, normally a massive number of game clients play their game in a single game world. In a game like this, sending character information to every client via P2P excessively increases the amount of network traffic and most of all, it doesn't have to be transmitted to every client in the first place since client doesn't have to see characters of other clients out of sight.

Therefore, it is much efficient to send character information to only clients within your sight in the gameplay. In the screenshot below, client B sends the status of character under control to server. Then server shows the position of character only to the ones within the sight. At this case, it is client A and C. And client D doesn't receive the information since he is out of sight range. By doing this, you can save the amount of network traffic against client D. This process is called area filtering.

Visible area filtering can be summarized as followed.

• Sends your character information from client to server.

• Server stores the status of each character and sends the information only to the clients who can only see your character.

Above is a traditional way of visible area filtering which uses server. The disadvantage of using this method is that server must Multicast for every client thus it most likely causes overload. But ProudNet can enhance the performance with its high performance P2P grouping and communication technology. Together it is called Hybrid Phase Networking Method (Registered patent No. 10-0812019). And this method can only be used in a project using ProudNet.

To briefly explain Hybrid Phase Networking, it is a method that doesn't Multicast through server but directly transmits data to other clients via P2P as limiting the range of Multicast to visible area.

Synchronization method applied from ProudNet and Hybrid Phase Networking is as followed. To help your understanding better, we will explain it along with source location in 3. Character synchronization in 3D world .

• Server must have a space to save character's information of each client. (Refer to CRemoteHero, server source of 3. Character synchronization in 3D world )

• Client must have its own character (Refer to CLocalHero, server source of (3. Character synchronization in 3D world ) and other clients' synchronized characters (Refer to CLocalHero, server source of 3. Character synchronization in 3D world ). And server must have Proud.HostID variable that ties all ‘clients who can see the character' as P2P group for each character. (Refer to CRemoteHero.m_viewersGroupID, server source of 3. Character synchronization in 3D world )

• Client sends its character's position to server in a timed manger. And server saves it. (Refer to CLocalHero::FrameMove, client source of 3. Character synchronization in 3D world )

• Server timely checks whether or not the character under control of client is within the visible area. (Refer to CRemoteClient::FrameMove, server source of 3. Character synchronization in 3D world ) When server confirms in or out of character from visible area, it sends RMI containing message of apprearance or disappearance of character to its associated client and adds or removes the client to or from the group of ‘clients who can see the character'.

• If the character is indeed within visible area from the client then it sends appearance RMI (Refer to RemoteHero_Appear RMI of synch_world_sample의 RemoteHero_Appear RMI) and adds the client to the group of ‘clients who can see the character'. (Refer to CRemoteClient::FrameMove, server source of Character synchronization in 3D world).

• If the character is out of visible area from the client then it sends disappearance RMI (Refer to RemoteHero_Disappear RMI of 3. Character synchronization in 3D world ) and removes the client from the group of ‘clients who can see the character' (Refer to CRemoteClient::FrameMove, server source of 3. Character synchronization in 3D world )

• When a client enters the game world for the first time, client must obtain P2P group ID of ‘clients who can see the character'. (Refer to NotifyLocalHeroViewersGroupID RMI of 3. Character synchronization in 3D world ) Based on this value, client timely sends its character's position to P2P. Dead Reckoning will come handy to handle this. (Refer to CClient::P2P_LocalHero_Move, client source of 3. Character synchronization in 3D world )

• If the character of client appears in the game world then its condition is same as ‘character is within the visible area of client.' (Refer to CSynchWorldServerDlg::RequestLocalHeroSpawn, server source of 3. Character synchronization in 3D world ) On the contrary, when the client leaves the game world then it would be considered as ‘character is out of the visible area of client'. (Refer to CSynchWorldServerDlg::OnClientLeave , server source of 3. Character synchronization in 3D world )

When using Hybrid Phase Networking, there could be excessive amount of transmission from one client to another. In order to prevent this, please refer to 11. Traffic auto-control function (Throttling) or 6.9 Performance difference between Direct P2P and relay communication.