1. Thinking about game business development

In game development, it is necessary to understand the upper-level business logic in order to further understand the underlying code of the engine. Developers who are good at game business logic also have a very unique understanding of engine logic. Here’s a quick rundown of what I know about the game business. The game business logic is divided into a client part and a server part. The client-side logic is mainly responsible for the performance of the game and is used to make the game look good. Server part of the logic is the soul of the whole game, most of the game’s logic, numerical calculation occurs in the server part (here to state synchronization for example, not considering frame synchronization online games).

Client development and server development require two very different development approaches, and both require a so-called “framework.” So the question is, what is a framework?

The so-called development framework, with my shallow understanding, I think more can be compared to the motherboard of the desktop. A good motherboard, can plug in more memory, better graphics card, more core CPU. A poor motherboard can’t support many powerful components. And the game framework is the same, a good framework, can have more scalability, can be on more functions. On the other hand, a weak framework will often break down on the first new feature, and then the project will almost collapse as the coupling gets stronger. Because there is often little room to expand.

However, a good framework is not the silver bullet of software engineering. A good framework will greatly slow down the aging process of a project, but it will not prevent it from dying. When the project is large to a certain extent, simple investment in human and material reconstruction often can not solve the problem. A successful project only grows into a leviathan monster. This part of the content can refer to the software engineering management philosophy in the soft work bible “Legend of man and Moon”, and will not be repeated here.

1.1 Client

As the core development of the game’s presentation, the client is the key to the overall look of the game. Client-side logic determines a number of key aspects of the game, including gameplay mechanics, presentation, and graphics quality. This part of development is what most people think of as “developing a game.” A game client often has more to think about, so here’s what I think you need to think about to build a game based on a basic engine:

Game resources are loaded. How to load resources in the game, such as models, tiles, etc. Material system for game objects. Material format in the game, shader writing, how the render pipeline is rendered, etc. Script framework. The framework for writing in-game logic, what the mechanics are. Model animation system. Model animation state machine, action switch, two-dimensional mixed tree, IK animation, etc. Skill effects system. The character’s skill release, determination, special effects, etc. AI state machine, behavior tree. The AI design of the character, based on the pathfinding algorithm. Physical collision detection. Real-time physical representation based on rigid body collision. UI manager. UI part of the logic, a variety of callback functions, a variety of module design. Input module. Detects hardware input and associates with it. Game timer. In-game timer. Network module. Parses server messages and sends messages to the server. There are also some common frameworks:

The GameObject Component framework. Based on the dependencies between game objects and components, the framework constructs the entire game in the form of a full combination of players. ECS framework. The Entity Component System is an update to the GameObject Component framework. It makes full use of the spatial local properties of computers.

1.2 Server

Server-side development is the soul of the whole game development, and the whole gameplay mechanic is determined by this part. At the same time, the development of the server side is different from the client side. Client development is about linear thinking, which is how to get better and cooler results with less resources on the current machine. And the server side needs to think about all the time, to do a new function, is for thousands of machines to run, this needs to consider more and more performance issues. So here are the basics of what I understand to be a server:

The Socket. Proficiency with transport layer apis. Synchronization mode. Such as the realization of state synchronization, frame synchronization and so on. The RPC protocol. How to design an elegant RPC protocol is the key to server logic. Message mechanism. Message-based information transmission. The timer. Used to calculate the time record in the game server. Math library. Often the game logic for security, are placed on the server. Protocol design. TCP/UDP/KCP. Of course, there are many deeper topics: load balancing, floating point numbers for frame synchronization, random numbers, etc. I won’t repeat it here. Mastering the above is enough to write a basic game server.

2. Design ideas for a basic game server

Here’s the basic idea I used to build a state synchronization server from zero. The overall game server framework can be divided into three parts:

Base Socket layer. This part is composed of the Socket API hierarchy. Basically nothing to say. Message receiving and sending layer. The current layer is used to handle client logic linking to the server. The Socket API edited by layer 1 is integrated to provide encapsulated data receiving and sending interfaces for layer 3. Manage the unique client ID, Socket list in the current game. Server core logic layer. All server logic is written at this layer. In my opinion, a basic game server should be designed as follows:

Functional decoupling.

Data decoupling.

Therefore, for the layer 2 client list, the client socket can be encapsulated into different types of entities, and each entity has different functions (function decoupling). At the same time, the data access by different clients through the Entity is independent of each other (data decoupling). Take the state synchronization server I designed based on building a room to start the game:

Linked entities. When the client connects to the server, it becomes a linking entity. Linked entities have limited functionality, only login registration. Login entity. After login, increase the selection, mall, enter the room interface and other functions. The login and registration functions are unavailable. Room entity. After entering the room interface, it can add functions such as room opening, room entering, preparation and game entering. Loss of layer 2 functionality. Game entities. After entering the game, add game logic functions (such as put skills, attack, walk, etc.), exit the game function, etc. Loss of other functions. As we can see, entities at different levels have completely different functions. In other words, at different stages of the client, its open function is also different. This greatly avoids functional coupling. We can maintain a dictionary to quickly find out which layer of entity the current client is on. At the same time, the intra-entity logical invocation uses RPC protocol to quickly invoke the corresponding method.

Of course, in addition to the functional decoupling of the game entities, the entire server is maintained as a room manager. There are many rooms under the room manager. Each room can be called by the entity created. At the same time, a room corresponds to a unique world. Using the multi-process method can make multiple rooms run at the same time without pressure. The specific structure is as follows:

class RoomManager
{
public:
vector<Room> roomList;
};

class Room
{
public:
World world;
};


Copy the code

In each room, a list of current in-game clients is maintained to quickly synchronize in-game messages. The World design in the room is closer to the idea of the client. A good analogy is to recreate the entire logical world within the server. By designing the in-game AI, terrain (A** algorithm), and so on, you can finish writing the world inside the server.

In short, game development is about the client side and the server side working together. Taking state synchronization as an example, when the server is running, it only needs to send the state attributes of the client and the state attributes of other players in the current game to the client, and then the client performs corresponding performance according to these attributes, so that the multiplayer synchronization game can be perfectly carried out.

The above server idea can be said to be a toy level, but more to illustrate the design idea. The hole in the server is very deep and will be filled in later when there is a chance. In my opinion, as an engineer, the most important thing is not what language, what framework, skilled use of XXX; The most important is the ability to solve problems. Hope the above ideas to share can help some of the pit game development students. Let me encourage you.