Is node.js suitable for game background development？

How are web servers and game servers connected?

1. There are many kinds of games. Let's take a look at mmorpgs first.

No RPG server is too simple to handle multi-person interactions, hundreds of people in the same scenario, and each client needs to receive information from everyone else.

Second, the user's operations are very frequent, and the average server tends to have long connections. Moreover, these links are frequently interactive, and there is no obvious persistent partitioning strategy, so the horizontal scaling of the server is limited, and the same scenario can only be run on one physical machine.

Third, the end game is usually afraid to put the logic operation on the client, the user minutes for you to crack out, change the gold, brush two pieces of equipment is common. So this map server has to verify the operation of all the players in the map, and calculate a series of business logic such as monster AI, drop rate and so on.

We can see that the traditional game server is significantly different from the web server, with unique business requirements such as long connection, multi-broadcast, complex business logic, and limited partitioning strategy.

2. Let's take a look at the benefits of concurrency to the game server.

For the server, if the task spends most of its time on I \o, the concurrency mechanism can prevent the entire map service from being blocked by I \o access. When a task is blocked, allocate free computing resources to other tasks. In this case, concurrency is good for server performance and response time.

For programmers, a separate logical flow means that you can do your job in a reliable, simple, loosely coupled context.

Because the OS handler logic had to be switched back and forth into the kernel, some people felt this was too slow, so they made some threads in the user space and controlled multiple logic flows within the process. Because of the limitations of language description, it is too much trouble to write and use such things on C/C++. This produces the coroutine grammar sugar in Erlang, go, lua.

Node. js essentially controls multiple logical flows by itself, but this logical flow is distributed based on the I \o state and priority. In the actual implementation, it tries to use non-blocking asynchronous I \o, when a single task calls I \o, I stop it, wait for the signal of I \o to complete, I restart it.

Note that every time I run a task, I don't actively switch to another stream until it completes or an I/o call occurs. So if there is too much computation involved in this task, then the entire map process will be blocked here.

And because node.js is asynchronous, you need to keep writing callbacks to listen for the completion of I \o. The flow of logic for a single task is broken many times. When a task becomes quite complex, there is something called a callbak hell, which can be very difficult to debug and develop.

3. For the above reasons, I do not recommend using node.js in non-prototype MMORPG server development.

The recent rise of mobile game servers is a good fit for node.js because mobile game is limited to network problems , the server can only do critical data validation, and there is no way to deal with very many people interacting with each other. The server side is as simple as a web server, the business logic is simple, the data is processed, and then persisted.