Pomelo Game Server Is Scalable

Pomela is fast, scalable, distributed game server framework for node.js. It is open sourced and can be downloaded from github. Pomelo is a game server framework that can be used for building mobile, web and social games. Online multiplayer games need this framework.

This is not a framework for Single player games. It is also for realtime application server framework so you can develop web application like chat holding millions of users online.

Pomelo is not a single project. It includes many other projects like client for C/cocos2d-x, iOS/android, web/javascript, unity3d, some tools like admin console and command line and many more libraries and plugins for example AI, Schedule, path-finding, AOI etc all made on the basis of this framework.

You can see all these projects in https://github.com/NetEase/pomelo

There are also many success cases for online games and real-time applications like Combat Strategy Games, Mobile Chat application using voice and text.

Why Game Server Is Not Scalable As Web Server ?

Reason 1: Long connection

Game server needs long connections because it has to respond to players in a very short time within 100 ms. Another is the need for bi-directional message flow. We not only need to make a request to the server but also need to push message back to the client. This problem is very easy to solve with the help of node.js which is perfect for holding long connections and building real-time and network-intensive applications. In other cases, if you are using Socket.io, it can hold 25,000 connections in 1 process. Mqtt (machine-to-machine (M2M)/“Internet of Things” connectivity protocol) can hold upto 120,000 connections in 1 process.

Reason 2: Stateful

The second problem is difficult to solve. Web applications are stateless which depends on random partitions and a request can be routed to any server. But game is designed in a different way. Game is partitioned by area which means most of the player interaction happens in one map or area which can be controlled by one process. Because of this partitioned strategy, we have a problem of stateful. The request come from client must to routed to fixed server, not to random server.

This problem cannot be solved in technical level. It depends on game design. The game should be designed in such a way that no area is too much crowed and the game elements should be distributed in a balanced way so that a process can hold many online players to interact. In too much crowded area, a process cannot hold many players.

Reason 3: Broadcast

When a player fight or do something in a game area, all the players need to see that player. For this, a message should be broadcast to all the players in that area. If there is one player, then number of messages broadcast is 2 i.e. message in and message out. If there are 2 players in the area, 4 messages should be sent to notify all the players. If there are about 4 players, 16 messages need to pass over network to notify all players. This means the relation between players and messages is exponential.

10 players needs 100 messages
100 players need 10000 messages
1000 players need 1000000 messages

A million messages cannot be handled by any process. How to support 1000 players online at a time ?

The first strategy is AOI (Area of Interested) which is an algorithm that broadcast messages to those players who see the main player and don’t need to send anything to other players. This saves a lot of network activities.

Second strategy is split process and separate load. If we have all the logic in one process say game logic and broadcast logic, all this eat CPU and server goes down. So the process is split into two logic broadcast and game logic that are controlled by Frontend (connector) and Backend(area) respectively. This is additional benefits because frontend part is stateless and backend logic is stateful so that it can handle many processes without any problem.

Third strategy is pushScheduler which is more like real-time application i.e. we can send message directly or using buffer to send part of it and flush it every 50ms.

Reason 4: Tick (game loop)

The game loop is present in both client side and server side. So suppose we have tick on every 100ms and we have to update many thing on each tick. For example if player is dead, it need to be removed from the area and make disappear. If the game loop is 100ms then all the update process should take far less milliseconds or maximum of 40ms. So how to solve this.

The entity number should be limited.
Pay attention to update algorithm: AI. AI should not take much time.
Garbage collection or full GC and memory must be limited by dividing process.
Its distributed architecture makes pomelo scale better than other real-time web frameworks. It is robust game server that is built taking into consideration all the above optimizations. So it is much more scalable than other game frameworks.