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

This article introduces how to implement MMO-level scenario services only based on the request response pattern. The content is very detailed. Interested friends can refer to it and hope it will be helpful to you.

In essence, if you just want to send a series of messages to the client, the req/resp request response pattern is no different from the pub/sub publish and subscribe model. You can think of req/resp as an one-time subscription to only one (or limited) message; if you need to maintain the push of such messages, you need the client to initiate a subscription again after receiving the message.

Like the timer timer system, the ability to subscribe to a timer that is triggered periodically is not necessary. If you need a timer that triggers every minute, you can initiate the next scheduled task request immediately after triggering a scheduled operation. It is functionally equivalent.

The potential real-time impact is that if it is stipulated that the next request is not allowed until a response message is received, then the delay pushed to the client after an event may increase by up to twice as much. That is, if you have just responded to a message, a new event occurs at this time; the client needs to make a new request after receiving the previous event, and then you can send the later event through the response packet of the new request.

The method to reduce this real-time impact is also very simple, and the protocol allows you to initiate a request again before receiving a response after the client initiates the request. The number of concurrent requests corresponding to similar messages should be determined according to the real-time requirements of such messages. It doesn't make much sense to infinitely increase the amount of concurrency allowed. After all, physical delays cannot be completely eliminated.

From the client point of view, in a game like MMO, the client is just a presentation device, which constantly receives changes in the state of the game world sent by the server and makes performance. The client mainly distributes the business logic by the response package, and uses the request response mode to match the previous request packet according to the session number in the response package (usually the type of the package is in the request package, not in the response package data), and combine the two (request / response) to call the message distribution function.

Since the effect is the same, the request response pattern has greater data redundancy (some seemingly meaningless request packets, in which you may only need to subscribe once), what are the benefits of the request response pattern?

It can naturally solve the problem of overload. If the server pushes data without considering the bandwidth / hardware processing capacity of the client, the client may not be able to process it in time, and the bandwidth of both sides is wasted needlessly. In the request / response mode, if I haven't finished dealing with it, I won't ask for more, which naturally avoids the question.

For the server, sending a message selectively is either an O (N2) operation: you need to traverse each user and compare other users to determine whether the other person cares about the message; or, it will increase the complexity of the data structure by an order of magnitude: you need to classify and index objects to improve the efficiency of retrieval. If you put the right to choose the message I care about on the client, then the time complexity is only O (n). Clients always know more about their own situation. I am iphone6s, so I can care about the changes of 50 people around me; if you use red rice from two years ago and block everyone around me, the server will not send me the event that the person next to me danced.

Message priority is easier to handle. I am fighting, those on the world chat channel to tear the news to me later, do not delay my opponent is rubbing the fireball, which I am more concerned about.

Whether it is the client or the server, as long as you think clearly, the business logic can be written more clearly. What to do, let's talk about it.

In MMO's scenario service, what should I do if only the request response mode is used?

First of all, the players in the scene, NPC and so on are abstracted into the same object. At the same time, put the scene on the appropriate size grid (for example, a grid of 100 meters in side length, depending on the player's field of view you allow), and treat each grid as an object.

Each object has one (or more) event queues.

For lattice objects, the event records only other objects coming to the grid, and an object leaving the grid.

The player object's event queue records what actions the object has done, what damage it has received, what buf has been added or decreased, and so on.

Your scenario should work in a heartbeat cycle (usually no more than 10Hz), that is, on the game server, all object changes are discrete.

All attacks, movements, and skills are placed in the event queue of the object in the form of an event, plus a timestamp.

There are only two query protocols on the client:

Query the current state of an object and the timestamp of the latest event of the object.

Query an object for a list of all events that occur later, starting with a timestamp.

If the client does not already know an object, it initiates query 1; if it already knows the object, it initiates query 2. Or initiate query 1 as needed (for example, once queried, but don't care for a long time)

Limit the number of times the query can be raised again before the query is not answered.

This always keeps you abreast of the latest state of an object.

When a player enters the scene, what he has to do:

Query the entry point.

According to the coordinates of the entry point, the query is initiated by the grid where the query is located and the surrounding grid.

According to the query of the perimeter grid, we know the objects that exist around us. Then make further queries on these objects respectively. As a MMO, there may be a large number of objects, and it is usually enough to filter some of them.

Once the object of interest is far away, it is no longer monitored; this does not depend on the state change of the lattice object. Therefore, the status feedback of the grid only needs to have a new object, and there is no need to have a message that the object leaves. Monitoring an object means that after each query response, the next query is brought up again. Some objects, such as themselves, need to be more responsive. Multiple query requests should be made to the server at the same time, so that once the server determines that you have been attacked or changed by some event, there is always a response session available to send response packets. By the same token, if you are fighting a person / NPC, then the opponent is also the focus. While people around you run around and make a move, maybe you don't care so much. This can be controlled by the client over which to keep tracking and which to ignore for the time being.

Finally, focus on yourself (the object in the scene). In this way, if someone attacks you, you will know that the incident happened. After the attack, you can also pay attention to the person who hit you immediately (if you haven't paid attention before).

The optimizations that can be done and are easy to do are:

Event merge. When a user requests all events after a timestamp, some events can be merged, such as multiple movements can be merged into one; an object in and out of the grid can be merged and only respond to new events.

Response package cache. There is some overhead in serializing the event list into network packets. Some information is sure to be asked by a lot of players. You can serialize the data only once, cache the data, and respond directly to multiple people when they request it, eliminating the process of serializing the information repeatedly.

Multi-query merge. When querying multiple cells, they can be merged in the same request, so that the movement messages of objects between adjacent cells may be merged.

From the protocol layer, it is allowed to make query requests for many objects at once, and their query session must be continuous, so it is not necessary to encode them one by one, but only need to give an interval; at the same time, it does not hinder individual responses. In the above query convention, if there is no event in the object event list after the timestamp is found, the server will not respond.

For example, if you come to a no man's land and do a query on your location, there are no other objects except yourself; if you query again, the result will not change, so the server will suspend your request until a new object appears nearby.

Since requests and responses correspond one to one, you don't have to worry about too much unnecessary traffic than simple data push (subscription mode).

This is the end of the scenario service on how to implement the MMO level based on the request response pattern. I hope the above content can be helpful and learn more. If you think the article is good, you can share it for more people to see.

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.