Server Framework Review

"C + + End Tour"

The first touch of the game project, MMORPG, although the MMORPG has a pretty high technical threshold, but that will be mostly in writing logic, rarely deep in the bottom, so the harvest is limited.

Win platform, the overall view is divided into three layers: HomeServer, Gameserver, four DB process (Accountdb, Chardb, Logdb, mailDB). HomeServer is responsible for the login queue, the same control, platform interaction, etc. gameserver is the main game, inside except database, network IO ... Game logic is related to the use of single-threaded architecture, a unified service loop framework, a variety of functions are registered into the service by the main loop initiated, such as: AI, Buff, mobile, player data Write library ...

Online players are placed in the memory pool, because of single-threaded sake, so strong interaction support is very high (do not consider concurrency consistency, RPC call, RPC delay ...) ）。 The legendary way of fighting can also cope with dense calculations.

Unfortunately, the overall realization of not much, in-depth study of only three parts: AI, network module, activity design.

Our AI is a recursive call system based on virtual functions (the parser pattern in essence), with the specified toggle rule when initialized. In a nutshell, it is divided into three tiers:

1) Do: Perform basic actions, such as walking, attacking, sleeping

2) Base: Do simple packaging of do layer, add conditional judgment, control, such as random walk, around a point, follow

3) Logic: Combine any AI (logic can also be combined with each other), with switching logic

The difference between the peers for the tree:

1) logical judgment and behavior are written together.

2) The Behavior tree extracts common nodes, which are easy to organize logic, such as

A) Selector Node

b) Sequence Node

c) Parallel Node

Interacting with external systems:

• Behavior Tree
• Get a global variable/dic, write condition detect
• Add the corresponding condition node, check it yourself when update
• Project AI
• Tell AI toggle behavior directly via event type (OnEvent)
• Ai only cares about its regular processes, such as patrolling, attacking, following ...
• The logic of the special conditions, all to the outside event processing ... I think this decoupling is pretty good.
• The place where the incident happened, equivalent to the decision
• The decision-making in the behavior tree is the whole tree structure, the behavior is encapsulated in the behavior node, or a small tree
• The condition node of the behavioral tree has to be pulled into external data.

　　

This AI system, comparing behaviac behavior tree, magnitude is very light, the core code does not exceed 300 lines, easy to control the details, and the implementation of most of the game AI is not a problem.

Network module, Windows is IOCP, this can be opened in a detailed description of the post, can dig a lot of things.

Activity design, the work of a great God, with C + + to do the communication kernel, data storage, the specific logic of all the Lua script, extensibility is very high, and easy to use. An example of deep impression:

The client needs the data is very messy, difficult to unify the format, the great God in the script layer made a set of instruction system, the SVR side only need to tune the same interface to issue instructions, like "command#param1#param2#param3 ...", in the client script, just register the same name function, That can be called automatically. Send display information conveniently very.

AI and IOCP have collated refactoring over, source address:

Https://github.com/3workman/InterpretAI

Https://github.com/3workman/IOCP

"Lua Hand Tour"

The architecture of this project is more fashionable, Logic, Gateway, Battle, Cross, SDK, Center, DB, world ... It's complete.

multithreaded architecture, C + + kernel, lua write logic, where logic, Battle, Gateway, DB can be horizontally extended. Cross is responsible for communication between the backend modules, such as battle and logic (each battle, logic completes initialization, goes to cross registration).

First, the advantages:

1) The use of convenient, packaged RPC communication, do not have to register the message, and the use of buffer parameters, the code in the definition of the message structure is saved;

2) from the service process design is very good, distinguish between the init, Onready, sequence and other different interface call stage, convenient data layout, hot update;

3) with the help of Lua's powerful mettable, we can eliminate all database operations in the business layer, all the bottom control, player data automatic synchronization client;

4) Support logical transactional, server-side bulk operations, direct interface, as long as a failure, the entire MSG call automatically fallback ... A ratio of cool, do not have to make a lump of judgment beforehand;

The disadvantages are also obvious:

1) The bottom has a large number of data copy, performance is not high, as a hand tour server, seemingly only support 5k online

2) does not support strong interaction, with Erlang, go comes with a light-weight thread different, here is the system-level thread, the data between players to modify the lock, and can not guarantee the consistency of data in the time series, such as B first changed a data, C again to visit, it is likely to get the old data or C ... The volume player's data interaction, even needs the developer to anticipate the race state, and then avoids with the corresponding skill;

3) The server is originally used for page tours, is designed to: a server process can run multiple services of data, so a thread may be running a few of the data, and a service data will be divided into multiple threads. This feature allows you to write code with extra attention, such as a, B two players if assigned to different threads, then they are not visible to each other, using the wrong API has been returned to empty, such as activity data, demand uniform, you can not casually disorderly release;

4) There are too many data types for static lifetimes: Player data, Player temp data, sharedata, player shared data, LUA file data, global _g data ... To understand the purpose of their existence, the application of the scene ~ ~ can be a kung fu

Even so, but this architecture I think is very good, especially design ideas, a few advantages brought about the gospel, writing code high Explosion, development efficiency, a skilled can deal with all SVR side tasks.

"Go Hand Tour"

Recently contacted, go is a very useful language, although not the same as Erlang, but the general game is absolutely enough. and write code readability is high (also have bad, not artifice play, hard code of writing a lot more), static language save a lot of dynamic language debug time.

Back to the architecture, this project uses a multi-process architecture: ACCOUNTSVR, Battlesvr, Chatsvr, Crosssvr, Gamesvr, Logsvr, MongoDB.

The primary logical Server GAMESVR uses the HTTP short connection (above two is used long connection, battle the battle server uses the UDP), BATTLESVR, CHATSVR uses the TCP long connection to interact with the client.

Each module is a separate process, the architecture is very clear, functional cohesion, and some of each module provides a taste of the service, can continue to extend, still in the study.

This is compared to the previous server, the biggest advantage is simple, clear, learning to grasp the cost is very low, and enough ... Well, this is also the design philosophy of Go (*^__^*)

Server Framework Review