[Erlang 0020] online game line-to-line

In the past year, we can see a major change: the online game line separation has gradually changed from standard to optional, and more games are starting to be offline. Why did we need line separation? Why is there no line? What are the technical challenges? Is it just a technical problem?

Glossary

Different technologies implement different concepts of "One Line". We use Erlang implementation. Here, a line corresponds to a VM of Erlang.

Why do we need to split the line?

You can answer this question through comparison: all players are on the same line, and the same number of players are allocated on multiple lines. If all players (assuming 1000 players) first, the number of players in the same scenario will be relatively high in one line, especially in some hot game regions such as copy entry, Master center, portal, etc. Of course, the number of players on the same screen will also be high; the broadcast pressure corresponding to related scenarios on the server side and the computing pressure of business logic are concentrated on the same line. After the split, players are diverted, and the number of people in the same scenario and on the same screen is reduced. On the one hand, the computing pressure on a single line on the server is reduced, on the other hand, the number of clients on the same screen also dropped;

The division of lines actually reduces the pressure on both the server and client. In particular, the number of simultaneous screens of Flash clients has been limited for a long time. In most games, the number of simultaneous screens is more than 100, but not more than 200; this is actually a short board in the barrel theory. Even if the server side can be disconnected, the client side cannot support such a high screen. (Of course, this problem has already been broken through)

To sum up, why do we share the computing pressure and limit the number of people on the same screen?

 

Influence of cabling on Design

Line breaking is actually a solution that breaks through technical bottlenecks to support more players. Once the line is split, it will naturally lead to problems of "line changing" and "cross-line, that is, the player shows switching from one line to another. players that are not in the same line belong to "cross Line". What should they do if the player is on the first line and the player is on the second line? Team up? What about chatting? What about fighting? Even if we ignore the interaction factor and only look at one player, which line should this player choose to launch? Can a player change a line in a combat, transaction, or hanging state? What should I do if I go offline and go online in these statuses?

Essentially, linefeed is actually a process in which player data is migrated from an Erlang node to another Erlang node. There is a process of destruction and reconstruction, while the cross-linefeed is the data of two players in different Erlang nodes.

Some solutions come from planning. Some game states are mutually exclusive, such as cross-line transactions and line-changing in practice; on the other hand, we must fully consider the following points during design:

What should I do if the player is not on the same line? Can gamers change the line currently? What should I do if the player switches to the current status? What should I do after gamers go offline? What should I do if my service is global ?......

In terms of technical implementation, Erlang has inherent advantages in Load Balancing by starting multiple nodes, designing a gateway node, and performing horizontal scaling.

 

Line-breaking

It can be found that the design of the split line requires that multiple lines be taken into account when a function is completed, which will increase the complexity of the problem; I don't know how many games that adopt the line separation strategy once fell behind because of the line separation, So we almost killed the game's economic system due to a bug in the line separation; things probably went through:

A colleague from operations around on a certain Sunday told me that there were player gold coins in the game abnormal.

Go to the company seal at around, analyze the log, and find that the source of the gold coins should be player transactions, eliminating the possibility of server attacks

All transaction protocols are blocked around and server updates are suspended.

Another problem may occur at around 1: update again.

2. Capture abnormal player data from the player logstore for analysis and find that the player's gold coins multiply by 2, 4, 8, 16, 32, 64. That is to say, the gold coins are "copied", but how can the players achieve this? Are you trading with yourself? Although the analysis code lacks this protection, the SQL used for transactions also ensures that it does not get any benefits.

~ At, I tried to simulate transactions under various circumstances in a local testing environment. Answer: The game had a wire division selection bug, which allowed the player to log on to two lines at the same time, players use two accounts to repeatedly log in and change the line, and then make a transaction to copy the gold coins through the transaction;

Install patches at about to update the first version.

Client patches are also distributed around.

The next day, the operations submitted the relevant account repair rules. The premise of a game's recharge is that the economic system in the game is stable. Once something like gold coins is stolen, the economic system is disrupted, the game server will die;

 

Why is it out of line?

First, there are various line-Breaking restrictions. For example, cross-line transactions are not allowed. This increases the player's operation steps and requires the player to change the line first. In addition, the line-breaking distribution also disperses the pressure and popularity, it seems that the game is not busy;

Secondly, the optimization solution has been available for the flash screen problem. You can see that the number of simultaneous screen users exceeds the limit of 100, when a Region gathers many people, it is not rendered in full, but one by one. There are also some client-side optimization strategies, the combination of these solutions results in more people on the same screen;

 

How to implement it?

Some are implemented by splitting the function modules of the game, such as placing scenario operations on separate Erlang nodes, and splitting functions into multiple nodes to share the pressure; once the pressure goes up, you can increase the corresponding function nodes to relieve the pressure. In fact, it is a different way to share the pressure, which is transparent to the client and players.

It is more difficult to split the game from offline to offline. All the logic is completed in one node before, and it is difficult to split the game according to the function. This will be disruptive. Consult Li Tao. His advice is to open only one line, enable SMP, and support a single line of 2000 ~ 3000 people should be fine.

Erlang smp vm is a little slower than ordinary Erlang Vm, but it can take full advantage of multi-core advantages:

Starting from OTP r12b, if the OS reports that there are more than one CPU (or core) VM SMP version, it will be automatically started, the same number of schedulers are started based on the number of CPUs or cores.

The Erlang VM without SMP support has only one scheduler running in the main processing thread. The scheduler extracts executable Erlang processes and IO tasks from the Run-queue, and does not need to lock any data because only one thread accesses them. The Erlang Vm with SMP support can have one or more schedulers, each running in one thread. The scheduler extracts executable Erlang processes and IO tasks from the same public running queue. All the shared data structures in the smp vm are protected by locks, and the running queue is such a Data Structure protected by locks.

See here for details: http://shiningray.cn/some-facts-about-erlang-and-smp.html

In practice, we still adopt a compromise plan. As long as the player does not exceed the threshold value on an online line, only this line is enabled, and the client does not have the line selection function, if the threshold value is exceeded, a new line is enabled and the client is notified to display the line selection function;

 

Is it just a technical problem?

From offline to offline, it is not just a technical issue. Planning also needs to make adjustments. For example, in some areas in the game that are easy to accumulate players, we need to distribute the pressure, such as adding portals and modifying the NPC position; there are also some numerical restrictions that need to be re-considered. For example, a maximum of 30 players are allowed to participate in an activity division mode. If this mode is not online, you have to change the limit. Otherwise, most players cannot participate in this activity.

What if the maximum number of online users in a single server exceeds 3000? First, there are very few cases where the gaming platform can be pushed online. Second, if this value is exceeded, new servers are generally enabled, that is, operating means rather than non-technical means to solve this problem.

 

What is the next stop from dividing lines to dividing lines? A world?

What is the next battle for developers?

 

Updated on 2012-09-06

Strong ☆2002 22:38:52
There is a problem: Can I solve all the logic in an Erlang node without having to consider the current situation of service import and export volume and the server activation mode of one machine and multiple servers, is it not a technical solution, but a new server?
Now, I have encountered this problem when designing a new project architecture.
Chenglitao 22:40:12
Well, it's all out of line. The peak value is solved by High-configuration machines.
Do not consider any distributed architecture. The code is simple, easy to maintain, and modular.
Strong ☆2002 22:42:08
In addition, I think it's no longer a problem for the role client and the same screen.
Chenglitao 22:42:25
Well, yes, it's not a problem now.
Strong ☆2002 22:42:56
OK