Some MMORPG designs can be summarized as needed

Unconsciously, it has been more than four years since the project was developed. I have gone through various stages of the project, reviewed the past, and summarized my experiences.

I. What are the most important principles of development?

There are many development principles, such as using less Goto, static variables, and combinations at design. however, the reality is complex, and there are always some situations that need to break through the principles. so what principles can be used consistently?

In my personal experience, kiss can basically meet the requirements in most cases. For example, when writing code, we will try to streamline variables and simplify the logic to implement functions. When a class continues to expand, the same function is extracted into a function.

We also use classes to implement relatively independent functions.

When designing an independent module interface, the interface should be simplified. at this stage, the unused parts are implemented internally. try not to expose it. when designing the system, try to analyze the existing functions. no unnecessary, large, and empty Scaling (reference standard: expansion is not used within one year after system design ). accurately predict the possible complexity of each function and isolate the complex functions.

2. How to design a Complex System

The process of designing a complex system is basically a process of gradually decomposing the problem into a relatively simple problem. Here we use developing a wow-like MMORPG as the proposition to describe the process.

First, we divide the game into clients/servers. First, we talk about servers.

If there is only one server process, both performance and stability are very problematic, we will gradually break it down based on the principle of functional independence/performance optimization.

1. First, break down the login function into a process.

2. Based on the independent features of the game map, the game server (players in the management map), the world server (global module chat team and Other gateways)

3. for cross-world applications, such as wow cross-server copies. you must add an intermediate layer between the logon server and the world server to manage the interaction between the world server. you can even remove the DB function of the logon server. makes the login server more specific.

4. as a major source of DB load for game servers, DB requests are divided into two types: one is the regular storage of player information such as blood volume and items. second, global information, such as the copy progress, must be saved immediately. for timed storage, if the time is too short, the DB will be overwhelmed. if the time is too long, it will cause a long time back to the file after the server exception. A separate DB server can be designed to cache dB requests. then, we can shorten the regular storage time of the game server as much as possible without affecting the DB load.

5. Wow has a large map and many NPCs. In this way, the AI module load is heavy for the game server. You can separate them to form an AI server to reduce the load on the game server.

6. finally, you can add a gateway server between the server and gamers if the broadcast pressure on the server is too high. if the pressure on the game server is too high, you can also separate the relatively independent modules to form a process like the AI server. for example, verify the validity of a player's position.

After the server is decomposed by process, the most complex functional breakdown of the game server is solved.

1. The game server is divided into two categories by module functions: global modules (for managing multiple players, such as unions/teams) and entity modules (attached to entities, such as items/skills)

2. initialize global module loading. in the traditional way, configure the Loading Function and module name in the configuration table, and return the public interface to achieve unified loading/initialization.

3. the entity module can also be processed by a global module. the difference is that each type of entity (player/PET/NPC) subsystem is different. In the configuration table, you can configure the name of the subsystem to be loaded for different entities. differentiate entities in the form of combinations.

The design of the server is similar. Let's talk about the client.

1. There are few clients that adopt multi-process design. The most important thing is the separation of logic and engine.

2. considering that most of the client logic is related to the UI, the UI logic generally does not affect the performance. you can use scripts to unify this part. the UI provides functional functions in scripts and C ++. this greatly improves the stability of the client.

3. The design of the logic module of the client is similar to that of the game server. The configuration table is used to drive loading and initialization of all modules.

Iii. Other important concepts

1. The module communication problems that need to be solved after the module division is completed. Generally, interface callback and delegation are used (similar to the boost: signal function)

2. carefully consider the server requirements. All logic is driven by a package and a timer. At the underlying layer, a single thread is used to accept these two processes. In this way, all logics do not need to consider multithreading-related things to make the server more stable.