[Agones Series – Part 5] Agones Summary and Outlook

By Qiuyang Liu (Liming)

The previous articles introduced the network, lifecycle, and elastic scaling features of Agones. This article introduces the additional features of Agones and summarizes the positioning and use of Agones. Finally, let's talk about the prospect of cloud-native games.

Other Features

Player Tracking: When introducing SDK, I mentioned the methods related to Player. The relevant fields of the player can be defined in the Spec of GameServer, such as initialCapacity. Set the initial capacity of gs to 10. As the game runs, the game server can realize the change of capacity through SDK.Alpha().SetPlayerCapacity(count) calls. As mentioned earlier, you can use SDK to call SDK.Alpha(). GetPlayerCount() to obtain the current number of players. The game can manage players by comparing the capacity with the current number. Agones only provides tracking functions and does not affect player connection behaviors.
Local Mode: In the development and testing scenario, you need to expose services through Agones GameServer. You can specify the IP of the agones.dev/dev-address development machine and use Static portPolicy to create a gs without creating a pod. Debug quickly.
Multi-Cluster Allocation: Agones provides a mechanism to set redirection rules for allocation requests to the correct cluster to allow allocation from multiple clusters. GameServerAllocationPolicy is a CRD defined by Agones for setting multi-cluster allocation rules. In addition to the cluster priority, it describes the connection information of the target cluster, including the game server namespace, the agones-allocator endpoint, and the client Kubernetes secrets name used to redirect allocation requests. Game servers will be allocated from the cluster with the least number of priority. If there is no game server priority available in the smallest cluster, they will be allocated from the second smallest number of the priority cluster. The probability of selecting the cluster relies on the weight when discussing clusters with the same priority.
Latency Testing: When deploying services globally, clients need to decide which clusters to connect to based on latency. Agones installs and exposes such a test service by default and supports both HTTP and UDP protocols.

Summary

First of all, we must see that Agones is a cloud-native load designed for a dedicated game server, which is suitable for MOBA/FPS/TCG and other game types that have competition concepts and need player matching. This type of game is characterized by a short lifecycle and a tendency to be stateless. It can be quickly built, and it can delete pods to maximize the use of resources. Therefore, the core of Agones aims to provide dynamic scaling capabilities. However, you also need OpenMatch to maximize the scalability of Agones.

OpenMatch is another Google open-source project. It provides a matching mechanism, so users can customize the matching method in this framework to achieve matching. From the implementation logic, this part of Agones is lightweight. The most important part lies in the matching capability provided by OpenMatch. OpenMatch is relatively cumbersome compared with Agones. Users need to carry out complicated work if they want to access it. Many companies provide SaaS services to simplify client access.

The best practice of Agones is to configure a FleetAutoscaler for each Fleet, define the buffer amount, and compress the latency of the start time of the game server to the user during the peak period. The allocator will find the gs service in a ready state, set it to allocated, and wait for the player to match and connect. The MatchMaker will do a series of matching work, find such allocated gs, let it establish a connection with the player, and wait until the match is over. When gs is destroyed or reused, the old pod (or new pod) enters the ready state again. Buffer defines the difference between allocated and ready. If there are many matching requirements, which means the number of allocated is not so large, the overall number of pods to be created will decrease, thus realizing the flexibility and improving the utilization rate of resources.

Outlook

Although Agones, as a cloud-native game load, simplifies the complexity of the game cloud migration and provides the ability to scale elastically, it still needs improvements:

It is not suitable for long-lifecycle game servers, such as PvE games with a big world. The status difference of each copy of this game is huge. The fleet that provides horizontal scaling is not suitable for managing this type of game.
It implements state awareness through SDK, which increases transformation costs and makes it more difficult for game developers to access.
Its network type is fixed, and the hostPort method cannot be applied to all scenarios. For example, some scenarios where IP ports are fixed cannot be satisfied.

The proportion of MMO/MMORPG games is huge in the gaming market. Such games migrating to cloud-native is a demand that should not be ignored. This type of game has heavy states and weak elasticity. Currently, O&M management in Kubernetes is complicated. The cloud-native transformation of this type of game is an issue the industry needs to pay attention to closely. What is the pain point of a cloud-native game? How should we deal with it?

Community

[Agones Series – Part 5] Agones Summary and Outlook

Other Features

Summary

Outlook

Read previous post:

Read next post:

Alibaba Cloud Native Community

You may also like

Comments

Alibaba Cloud Native Community

Related Products

ACK One

Cloud-Native Applications Management Solution

Gaming Solution

Container Service for Kubernetes