Description of the MMO component in the Tornado game engine

For a long time I was looking for an open and free MMO engine on the Internet. Either it was outright nonsense, or a paid project. In general, these engines among companies doing MMO RPGs are full, but each company writes its own engine. There is no single standard. I had to write it myself - and I did it. I thought over the library interface for a long time. Then he also brought it to life for a long time. Then he added security (AES and RSA based on OpenSSL, the "Man-in-the-middle" problem was fixed). The engine turned out to be cross-platform (working with the network thanks to boost). Packets can be exchanged using both TCP and UDP.

As a result, according to my calculations, the server can hold up to a million clients (it all depends on the hardware, the more the better). This is possible thanks to the cluster organization of the server.

So, for the client side, the Client interface is presented. Using it, you can log in and then exchange data with the server.

Things are more complicated with the server. It consists of three layers. The first layer is Slave. It is with him that the client works after authorization. The second layer is Master. Client authorization passes through it. When the client logs in, the IP master is used. Next, the wizard directs to connect the client to the least loaded in the Slave cluster. The wizard is the head of the cluster and usually a number of slaves are associated with it. Using the wizard, you can combine clients into groups (for example, to conduct a battle in one room, so that physically it was one computer). Then the master redistributes the clients so that they have a network connection with one Slave. A transfer of clients occurs (re-switching).

If the number of clusters is more than one and you need to exchange data between them, then SuperServer (third layer) is used. A superserver binds clusters into agglomeration. The super server owns information about all agglomeration clients and controls the authorization process (for example, the prohibition on authorization on two clusters using the same client authorization data).

Features of the implementation.
It is based on the idea of ​​scripting. There is a script (pure logic) and a script context.
A script is a sequence of actions (sending packets and a response to receiving) that are performed on a context.

A session (network connection) is associated with a set of contexts, each of which is designed for its own scenario (for example, data exchange and authorization).
But when one of them is being worked out, the rest should be blocked. That is, work on a session is always carried out according to only one scenario.

For example, the Wizard has many sessions with subordinate Slaves. For each session, fulfills its own scenario.

They simply palm off the package to the script and it searches for the context that is associated with it (either by ID_Session or by the key that is transmitted inside the package).
Next, some of their actions are performed according to the script.


Engine source code:
Video demo:

Also popular now: