Inscription:
It has been a while since I started learning the server, and the progress is still quite slow without anyone pointing out. Because the reference is a mature framework, I was physically and mentally exhausted by some interlocking things during the learning process. For example, you need to use the corresponding protocol when sending and receiving data, so you make up for the use of Protobuf halfway, and then you need to send and access data when linking, so you make up for the use of the database mongodb in the middle, and then you have to insert the learning of the corresponding things halfway. So I have been studying for almost a month, and I understand a little bit. The following is a summary of the recent learning progress.
About progress
So I learned from scratch, and started with the client from logging in. Then take the address of the server from the database and return it to the client for display. Well, that's it.
About the server
The function is to interact with the client data. In fact, I just wanted to do a simple Scoket test at the beginning. Later, I found that the role played by the server is different according to the degree of interaction. The one I have come into contact with now is that the server acts as a data storage role, and only records important information to record player information and game progress. The other is that the server participates in all calculations and game logic, and the client is only used as a display page. In this case, the client is really a jigsaw puzzle.
The more troublesome thing is to understand the design of the server framework. Just like the client, when you get started, you only consider writing out the functions. Later, you start to consider expanding reuse and systematizing components. So for a mature framework, it is necessary to understand why it is designed that way.
For details, you can refer to some documents about server architecture, which I have only encountered.
What is more troublesome is why the server still has to distinguish what login server, what game server, what db server, GM server, etc. are messy, which makes my single-line learning process even worse, because when I test sending information to the login server, the login server sends information to the game server or other locations, so I have to jump between different modules.
Until now the concept is still a bit vague.
answer reference
Then I found an explanation that I think is more in line with my speculation. The following is just for reference:
because now almost all mobile games are separated by operators (channels) and developers (CP).
Under the concept of channels, it is easy to understand why login and game server should be separated. Because in the era of mobile games, all online games need to access the channel login function, so the work of accessing channels should be included in the development plan at the early stage of game development.
The servers that are actually responsible for saving game data and executing server-side logic for games that are generally operated are deployed and maintained by the developer, while the servers responsible for logging in are deployed and maintained by the channel. Since channels often have many ready-made users and various convenient and fast login methods (such as WeChat’s automatic login), these login methods are often very different from platform to platform, and the competition among channels is also very fierce. Therefore, most channels provide ready-made login modules (SDK) and unified interfaces for developers to access.
However, it should be pointed out that the "login" here should be a simple "authentication" module such as a simple user name password, visitor account, etc. In fact, developers will also have separate login function modules in their own game servers.
The advantages of separating the game login logic into a service are as follows:
1: The only login entry. If the game is not operated by itself, it needs to be on other platforms. Each platform can only have one login server, but the game logic server will increase as the number of players increases.
2: Easy to expand: the game may operate on multiple platforms together, and different platforms may handle login differently. If you separate the login part separately, you only need to modify the code of the login service, and then publish it. The other parts of the server do not need to be modified.
3: Flexible deployment: When the number of players in the game is small, the login server and logic symbol can be deployed on a physical server. When the number of players increases and the pressure on the server increases, the login server can be deployed separately to a more powerful physical server.
4: Reduce coupling: After the login server and the logic server are independent, the login server will not affect the players who are playing the game. If a logical server is down, it will not affect the login.
Subsequent progress
This is a simple concept of the server structure. In the future, we will try to use a simple framework to test and build a fully functional server.
If it works well, a conceptual architecture diagram will be added.
that's all.