I will give an outline by comparing between P2P and C/S networking in real-time multi-play in mobile games.

 

If we go to the conclusions first, they are as in the following.

 

•  If you play a game in the Wifi environment, you do P2P communication directly in a high probability.
•  P2P is effective for games with sensitive latency such as FPS, racing genre, etc.
•  P2P is tend to be vulnerable to hacking. C/S can be vulnerable to hacking depending on how you use it.
•  In general, P2P shows better latency (response speed) than C/S

 

I will tell you in more details.

 

 

What is C/S and P2P networking?

When you do C/S networking or client-server networking in a multi-player game, messages from the client, such as movements of a player character or commands entered by a player, are transmitted to the server and the server sends them to other clients.

 

When you do P2P networking or peer-to-peer networking, a client directly sends messages to other clients.

 

 

• It does direct P2P communication in a high probability when you play a game in Wifi environment

 

When you play a game, the success rate of hole-punching is very low if two devices are all celluar network, i.e., 3G or LTE. In other words, it is processed as relay

But if either one of both are Wifi, the hole-punching success rate becomes high.

 

In real-time multi-play games, data communication charge occurs. From the perspective of users, this is always on their mind.

In China, where communication charge is expensive, people go to places with free Wifi to check push alarms from messenger apps when they receive them.

Therefore, users tend to prefer Wifi, instead of 3G or LTE.

 

 

• P2P is efficient for latency-sensitive games

When the quality of a mobile network (3G/LTE) not good, there is no difference between the latency of P2P and C/S.

However, if the quality of a mobile network (3G/LTE) is good, the difference between P2P and C/S becomes remarkable.

 

In a mobile network (3G/LTE) with a good quality, you can see the processing delay of

2ms in case of P2P and,

about 12ms in C/S

(you may see some difference depending on the environment.)

 

Perhaps people who mainly play FPS games can totally agree that the difference of 10ms of latency can mean so much

 

 

•  P2P is vulnerable to hacking. C/S may be vulnerable to hacking depending on how you use it.

In the case of a multi-play on-line games in the C/S method, the method to synchronize multi-play is categorized into major ways.

–  Method  1: A “command” is sent from the client (Player 1 -> Player 1 Input(Scene Update))

–  Method 2:  A client sends only “calculated player movement information”

Method 1 is more resistant to client hacking compared to method 1.

The reason is that the movement calculation is of player characters is also processed in the server.

However, processing all scene updates in the server takes a considerable load in the server performance.

 

There is even a bigger problem; that is, there are more severe break-ups and lags occurring during game play than method 2.

 

<Lags seen in a game using method 1 https://www.youtube.com/watch?v=83i8Yzkkzvg>

 

In method 1, the client does the movement calculation on player characters compared to method 2. Therefore, compared to method 1, it is vulnerable to hacking. P2P is also vulnerable to hacking but method 1 is vulnerable to hacking as much as P2P. The best you can do is to inspect whether the calculation of the client is a result of hacking.

The advantage of method is more pleasant multi-play because it is less sensitive to latency.

 

Mobile games use wireless networks (WIFI/3G/LTE).

The problem is that the latency of wireless network is bigger compared to wired networks.

Even if the quality of a wireless network is satisfactory, sporadic big latencies cannot be avoided.

In method 2, even if there are sporadic big latencies, you cannot feel anything unusual during game play.

However, in method 1, stuttering occurs during game play whenever a big latency occurs. This is when your screen freezes for a short moment.

 

For such problems, in most of mobile games, you are forced to use method 2 when you do client-server networking.

 

In mobile P2P networking, processing the movements of a player is the responsibility of the client. Therefore it has to be vulnerable to hacking.

But even if you make it to a client-server networking, as long as you select method 2, it becomes vulnerable to P2P networking similar to P2P networking. If you want to solve the problem, you need to use method 1, but it is not preferred since it reduces the quality of any game.

 

 

•  In general, P2P has better latency (response time) than C/S

Mainly, there are two ways to apply P2P networking in multi-play

• Super peer method: one of the clients takes responsibility for scene updates of all players. Commonly, this is referred as the listen server method.
• Replicated peer method: each client takes responsibility for scene updates of each player. This is not the listen server method.

 

The super peer method originated from package games and is used in some on-line games. It is sometimes used when there is much calculation of scene updates for a server to handle or a reason that makes it difficult to develop with the replicated server method.

 

Unless unavoidable, you have to avoid the super peer method.

In the case of the super peer method, there is the problem that when the player designated as the super peer breaks away during game play, the game stops for all the other players playing together, and if the processing performance of the super peer is bad, all the other players are affected negatively.

 

Therefore, in many on-line games, P2P networking is used in the replicated peer method.

In the replicated peer method, the location information of each player is directly transmitted to other clients.

Therefore, the player can experience faster response speed compared to playing in the C/S method.

Even if you are forced to relay because you cannot do P2P hole-punching and this slows down the play, you can confirm the same latency with the games that communicate in the C/S method.

 

In other words, the P2P method offers faster response speed than the C/S method and even in the worst case, the response speed becomes as same as the C/S method.

 

 

Many uses of the P2P networking

P2P networking is utilized for not only multi-plays with even faster response speed, but also utilized for the following uses.

 

• When there is too much traffic generated among clients (e.g. voice, video communication, etc.)
• When there has to be too much calculation to be done for a server to handle (e.g. game physical engine calculation, etc.)

 

For more details, you can refer to The chapter on P2P communication in the help menu in ProudNet (Korean).

Ok, someone asked questions regarding to server side game play programming on Reddit.

https://www.reddit.com/r/gamedev/comments/4kjoac/question_about_mmo_servers_and_enemies/

• Best way to handle enemies on server?
• Transferring map data between client and server?

Fortunately, I have worked a lot about these issues so I can explain where we should start and finish doing them.

Best way to handle enemies on server?

13 years ago when I was developing an MMO tank battle game ‘Blitz 1941’, I was afraid of taking a lot of CPU time at server for calculating flying projectiles which curves then collide to terrain or combination of cubical objects. At that time, I developed it like this.

1. Each client simulates a projectile then sends the movement message to server.
2. The server receives it, stores the projectile data to itself, then multicast the movement message to nearby players.

It worked fine, but the development was not so easy and it was prone to be exploited as the gameplay was decided by clients.

So I added another feature:

1. All clients simulate the projectile then send the movement message to server.
2. The server picks up the most accurate

This worked fine too, but I thought it might cause needless overhead on server.

Years after when I was working for another game developing project, I checked how much time is consumed while a network message is sent to be received.

Finally, in my opinion, I would suggest you to HANDLE ENEMIES ON SERVER ANYWAY.

The reason is simple: Handling the network messages is also heavy.

Yes, we also use I/O Completion Port or epoll for massive multiplayer and fast running game server. We make it very quickly with many optimizations. But, we cannot optimize the OS kernel. Of course, there is a way of optimizing them too, but it is out of the topic here. If you want to check them out, look for articles about user level network stack development.

In short, it takes thousands or tens of thousands of CPU clock cycles for sending or receiving a network message inside OS kernel. During that time, you can sufficiently calculate one or many enemy objects at server.

It is just simple. Import enemy handling code to your server and run it. Then multicast the movement message or action message to nearby clients. 10~20 per second is enough, depending on what game you develop. Of course, your game server should load map data on server, too. In Blitz 1941, my game server loaded map data including Line of Sight data map, navigation path map, etc. Just simple do as the clients do, except multimedia data such as texture, sound, animation, skeleton and mesh.

Please note that doing so much work such as mesh collision check is costly at server. The server does not do rendering for each scene, but it must handle thousands of scenes in it. Most of the time is done on CPU. For collision detection and reaction, use sphere or cylinder if you can.

Transferring map data between client and server?

Unless you are developing Minecraft thing, you might need to transfer map data. It is easy to develop and saves your server management cost if you just copy the map data to the client folder and the server folder.

What if the map is updated? Just simple. Upload the patch and let the clients download them, and copy the map to your servers and just reload them. Some bloating people say to upload them to SQL database, but remember to keep in mind KISS: keep it simple, stupid.

When developing game, you might need “Synchronizing time between two devices”.

Let’s check this out.
Synchronizing time between two devices is generally the way of using round trip latency (RTT).

Suppose that there are two devices; device A and B
* A->B: Send system time of A.[1]

* B->A: Send [1] as it is.
On A, you can get RTT by subtracting time of [1] from system time of A.

Now, try:

* A->B: Send RTT[2] and present time of A[3].

To get present time of A out of B, calculate:

* Present time of A = [3] + [2]/2
NTP works similary.

But the nature of computer network means that RTT is not accurate when measured for once.
RTT is bit different from time to time. In case of wireless network, gap between measurments can be way bigger.
So, averaging measurments for several times will be much accurate.
In addition, ProudNet(proudnet.com) provides variety of fuctions for time synchronizing .

* CNetClient.GetIndirectServerTimeMs

* CNetClient.GetP2PServerTimeMs

* CNetClient.GetServerTimeMs

ProudNet provides function to get not only RTT of server but also between other clients connected to P2P,

using CNetClient, GetLastPing of CNetServer and GetRecentPing function.

The news about ProudNet is release in Gamasutra.com!

You can check the article if you click the button below.

Go to the article

We had an interview with Gamebusiness.jp which is the online media for Japanese game developers.

Go to the article

Nettention attended GDC 2016 in San Francisco.

View article (Korean)

G-Star 2014, one of the biggest game exhibitions was held in Busan BEXCO from 2014.11.20 to 2014.11.23.

Nettention participated in this exhibition to introduce ProudNet which is a game server & network engine.

A lot of visitors came and visit us to get to know more about ProudNet.

 

 

 

 

 

Nettention CEO gave lectures on the subject of distributed game server.

A lot of game developers took the lecture and they were very satisfied with his lecture.

 

 

 

Nettention has a joint seminar with UNITY on the 25th of September in Kangnam area.

Nettention provides ProudNet (Game Server Network Engine) which is the best-known engine in Korea and UNITY provide UNITY (Client Engine) which is also the best-known engine in Korea.

Mr. Hyunjik Bae (Nettention CEO) made a speech about various considerations for smartphone online games and UNITY 5.0 new functions were introduced by UNITY CTO.

Mr. Hyungjin Yoon who are using UNITY and ProudNet introduced strengths of UNITY and ProudNet.