Network game server architecture

Online Games generally adopt a C/S structure. The client is responsible for drawing real-time images of the game world, while the server is responsible for responding to connection requests from all clients and game logic processing, and control the rendering of all clients. The client interacts with the server through network packets to complete each step of the game logic.

The gateway server is mainly responsible for isolating Client Communication from the game server.

The gateway server is only responsible for parsing data packets, encryption and decryption, timeout processing, and filtering error packets. The client only needs to establish a connection with the gateway server to enter the game without directly connecting to the game server.

Gateway servers include logingate and gamegate ).

 

1. logingate is mainly responsible for maintaining network connections and communications between the client and loginserver during player logon.

The communication data between the loginserver and the client is encrypted and verified.

2. loginserver verifies the validity of the player account and generates a logon credential sessionkey.

3. gamegate is mainly responsible for network connection and communication between the client and the gameserver, and simple analysis of client requests and sending data.

4. gameserver is mainly responsible for game logic processing, including combat systems, task systems, role systems, and map systems.

5. dbserver is mainly responsible for game data caching, including gamer game attribute data to reduce database pressure.

6. mserver is responsible for data forwarding and broadcasting between multiple gameservers in a group of servers.

7. MySQL is responsible for persistent data storage.

Server Event System

What is an event system?

The event system is a core component of the entire webgame system. It controls the game process and enables the game to execute expired commands in a timely manner.

An event refers to an activity instruction of a player in a game. It can be divided into instantaneous activity and non-instantaneous activity.

Instantaneous activities, as the name implies, are activities that can be completed immediately when the player sends instructions.

The player buys a bottle of potion from the NPC. After the player sends this instruction, the player's money decreases and the potion increases by 1 bottle, which is completed instantly after the player sends the instruction.

A non-instantaneous activity is executed after the player sends a certain instruction for a period of time.

For example, in an RPG Game, a gamer clicks a monster on the map to launch an attack. This attack process is a non-instantaneous process. It has a combat process, which consumes a certain amount of time.

In webgame, many operations of players can be considered as the combination of Instantaneous Events and non-instantaneous events.

For example, in a strategy game, when a building is upgraded, the instantaneous event is the reduction of Village Resources, the non-instantaneous event is the building construction, and the non-instantaneous event is the building level rising.

For example, in the military war in the strategy game, the instantaneous event is the decrease of soldiers in the current village, and the non-instantaneous event is the decrease of soldiers moving to the village where attacks are needed. As a result, the two villages started to fight.

Comparison between database storage and memory storage:

The number and type of event queues in the game are large. Various event queues.

In the SLG game:

1. City pool construction.

2. Inter-city war.

3. Create troops in the city.

4. Research Technology.

In RPG games:

1. fight monsters or PK.

2. Continuous attack and suspension.

3. Train and hook up.

4. skill cultivation.

The advantage of Message Queue storage in Linux is that it reduces the pressure on the PHP process to query the database. The disadvantage is that the server is down and the message event queue stored in the memory will be lost, the loss of the RPG monster event queue has little impact, but the current monster is invalid. However, the loss of other types of event queues may have a huge impact, as well as the efficiency of querying expired events.

 

A client player initiates a combat event command. The server PHP receives the event and verifies the combat validity. Then, it stores the event (related computing data) in the Linux message queue, PHP combat processes listen to Linux message queues.

If a combat event is found in the message queue:

1. php operations.

2. After the computation is completed, the PHP computation process writes the computation result to the memory table of the player combat result dB for storage, and pushes the war report to the client for playing with IM. (Note: Is the combat result stored in dB or in Linux message queue or memcache memory ?)

3. the PHP combat completion process listens to the gamer combat result table in the database. When the combat end time is reached, the data is deleted,

And handle combat rewards.

4. To prevent gamers from repeatedly initiating combat events, you can use the player ID on the server to verify whether a combat queue is in progress. (Note: Do I need to verify the server combat status? How? Query and Retrieval ?)

In summary, there are more than two server-side combat-related processes. php listens to combat events and calculates processes, and PHP listens to combat-end processes. PHP's combat computing process can be extended to the combat computing distributed server.

For any project, a good database design is extremely important, and it is even more important for webgame. A good database design is equivalent to a good skeleton and context. When your skeleton is set up and the context is straightened out, the game function code will be very smooth.

How can we design a webgame database?

Make the following preparations before design:

1. The game business logic should be quite clear.

2. Communicate with game planners to fully understand the functional needs of the game.

3. Report and adjust the game logic to the planners in a timely manner when any conflict arises.

4. The game functions are divided by module first, and then refined to the structure of each table.

5. The complex features of the game logic require repeated scrutiny.

Note the following when designing a database:

1. Table names and field names are normalized, and tables with similar logic are put together by game function modules. 2. Reasonably differentiate game configuration data tables from player data tables. 3. The game configuration data table and the game player data table are separated on the table name, or sub-databases. 4. Reasonably weigh the logical relationship, excellent performance, easy to understand, and easy to expand the table structure. 5. The length of the table field type is set appropriately. If you can use int, do not use varchar. If you can use mediumint, do not use Int. 6. reasonably use the vertical and cross-cutting of database tables to reduce the table pressure. 7. reasonably plan the table structure. Common fields and frequently used fields should be avoided in the design. 8. Be sure to use the InnoDB Transaction table, where transaction-related data is everywhere in the game data table. 9. Reasonably store data in JSON format. 10. data redundancy and performance trade-offs are issues, such as user nicknames and occupation fields. 11. design the table index fields and make good use of the combined indexes. 12. Make good use of the database memory table with appropriate functions. 13. You must use count (*) to verify whether data exists through SQL (*). 14. When a master-slave database is used in the game, there will be data latency issues, not real-time enough. 15. reasonably plan and split the database.

Network game server architecture (switch)