Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how the Web workflow is". In the daily operation, I believe many people have doubts about the Web workflow. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how the Web workflow is". Next, please follow the editor to study!

Perhaps the biggest difference between Web and online games is data synchronization.

The Web workflow (excluding page games here) has a lot of changes, but it is generally divided into roughly three steps.

1. Enter the URL in the browser, and the browser requests the server to load the data through the HTTP protocol. After receiving the HTTP request, the server loads the corresponding data from the database (possibly some data such as HTML,JS for browser rendering) and returns it to the client. This step is called query.

two。 After receiving the data returned by the server, the browser renders the data and presents it to the user. This step I call rendering.

3. After seeing the content rendered by the browser, the user performs different actions as needed to cause the browser to send some data to the server for processing, a step I call commit.

In addition to looping between these three steps, one important feature of most Web logic is that there is very little real-time interaction. For example, if you change your name in a forum, you need to refresh it manually to see it. Of course, there are things that can be displayed, but there are very few features that are treated (and usually through Hang HTTP requests), which is not considered here for the time being.

Therefore, most of the market researches on the high scalability of Web are done around the database. So HTTP's data synchronization really has nothing to study, his model has almost reduced the data synchronization to a minimum. Only user actions will load data, which is such an economical way of data synchronization.

The online game itself is a strong interactive mode, player A has done an operation, and all other players who should be able to see player A must be able to see what player A has done (just in theory, maybe because others can't see it. This situation is not discussed here).

In this way, the amount of data synchronization will be very large, and this amount of data will increase with the number of players online at the same time.

So people study a variety of algorithms to reduce the amount of data synchronization, such as AOI, frame synchronization and so on.

Here I privately divide the game into two modes: open room and big map.

In the game of opening room mode, there are generally not too many people in the same room. So the easiest thing to do is to synchronize the location and status directly.

When everyone moves, the client broadcasts the coordinates to all the players in the room at a fixed time (such as 10ms), and then the customer makes interpolation compensation according to the new coordinates. This is also known as the shadow following algorithm, that is, the actual performance of the client always lags behind the real location of the client.

If the client puts a skill, the effect of that skill is broadcast to all players in the room.

But there is a problem here. If this is a delay skill, for example, it takes effect in a few seconds, then the server needs to broadcast once when it receives the release skill, and again when the skill actually takes effect. If it is a buff that takes effect every few seconds, it will be more troublesome. Every time the buff takes effect, the message will be broadcast. The amount of data will far exceed the player's operation frequency.

Even if most of the data is caused by state synchronization, then I let the client calculate all the states on its own, which is the essence of frame synchronization. The client has all the operation logic of the whole game, and the whole game process is artificially divided into logical frames. Each logical frame player reports his own operation, and the server broadcasts in the room. The client receives the operation to restore various states for itself. If there are N people in the room, each person will only operate M times, and the amount of data synchronization will only be M messages, which is much lower than the previous data volume of state synchronization. This is especially good news for mobile phones whose traffic is not rich.

How to ensure that all client logic and performance are consistent, in addition to doing a correct logical frame operation to restore, it is also important to restore random logic (there are often various probability judgments in combat). This can be guaranteed by pseudorandom sequences.

Let's take a look at the big map mode (the big map mode here means that all players are on the same map and do not switch scenes during combat).

In large map mode, all players move on one map, so the number of players is not the same as the data in the room (although it is possible to block the map in order to increase the number of people online at the same time, but that is also much larger than the number of people in the room).

This means that it is unrealistic to broadcast data (operational data or state data) to all players on the map. So you have to use the AOI algorithm to select the players who need to receive the data. The data is then multicasting to the selected players.

When using the AOI algorithm, generally speaking, the order of magnitude of the number of people is about the same as the number of people who need to be synchronized in the room mode above.

Then, after using AOI, we can also use frame synchronization algorithm to optimize state synchronization.

The answer is obviously no, as mentioned above, all combat systems generally have probabilities, and there must be and can only be a pseudo-random sequence on a large map (because the horizons between players are staggered). This means that it is impossible for all clients to know in advance where the pseudorandom sequence is going (each battle will make the pseudorandom sequence a step forward, if you want all clients to know the progress of the current pseudorandom sequence in real time, it is obviously not realistic that the current random number must be broadcast to all players on the map during each battle).

From the above analysis, we can draw a conclusion that the only factor restricting the use of frame synchronization algorithm in large map mode is the inability to recover random logic. So if there are no random factors in our game map (whether it is possible or not), can we use a variation of the frame synchronization algorithm on the basis of AOI?

Let's analyze several scenarios to see if it is feasible, and it is important to emphasize that we assume that the entire communication is transmitted by TCP, while TCP is FIFO, and the server is in single-threaded mode.

1. Player B first saw player A, then player A was beaten out with 5 drops of blood, and finally player A had 75 drops of blood.

Player B first sees player An in the field of vision, and then synchronizes to player A with a health of 80.

Then B received the operation that player A was hit (this operation fixed injury 5 drops of blood), player B subtracted 80 from 5 to get player An and 75 drops of blood. Obviously, this is correct.

Although it may be difficult to control things like buf with time, I think there should be no problem logically after reasonable design.

two。 Player B also confiscated the sight of player A, and then player A was knocked out with 5 drops of blood.

After receiving the operation message that player A was hit, player B found that the data of player A had not been loaded in his field of vision (note that the data was loaded from the server, not that the client had not finished loading data such as the model), so the message was discarded.

After that, player B receives the data requested from the server, and A's blood volume is 75. Obviously, there's nothing wrong with that.

Therefore, in the absence of pseudorandom, the theory of frame synchronization algorithm can be used to further optimize state synchronization.

Coincidentally, in our recently developed game, the performance on the big map really does not require pseudorandom sequences.

At this point, the study of "what is the workflow of Web" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.