/site/docs/integration-patterns/ Recent content in Common Integration Patterns on Agones Hugo -- gohugo.io en Tue, 27 Jul 2021 00:00:00 +0000 /site/docs/integration-patterns/allocation-from-fleet/ Tue, 27 Jul 2021 00:00:00 +0000 /site/docs/integration-patterns/allocation-from-fleet/ Sample GameServerAllocation Since Agones will automatically add the label agones.dev/fleet to a GameServer of a given Fleet, we can use that label selector to target a specific Fleet by name. In this instance, we are targeting the Fleet xonotic. apiVersion: "allocation.agones.dev/v1" kind: GameServerAllocation spec: selectors: - matchLabels: agones.dev/fleet: xonotic Next Steps: Read the various specification references. Review the GameServer spec. Review the Fleet spec. Review the GameServerAllocation spec. Review the specifics of Health Checking. /site/docs/integration-patterns/matchmaker-registration/ Tue, 27 Jul 2021 00:00:00 +0000 /site/docs/integration-patterns/matchmaker-registration/ In this scenario, the GameServer process will need to self Allocate when informed by the matchmaker that players are being sent to them. Warning This does relinquish control over how GameServers are packed across the cluster to the external matchmaker. It is likely it will not do as good a job at packing and scaling as Agones. Next Steps: Read the various references, including the GameServer and Fleet reference materials. Review the specifics of Health Checking. /site/docs/integration-patterns/canary-testing/ Tue, 27 Jul 2021 23:49:14 +0000 /site/docs/integration-patterns/canary-testing/ To canary release/test a new Fleet, we can run a small, fixed size Fleet of the new version of our GameServer, while also running the current stable production version. Allocations can then prefer to come from the canary Fleet, but if all GameServers are already allocated from the canary Fleet, players will be allocated to the current stable Fleets. Over time, if the monitoring of those playing on the canary Fleet is working as expected, the size of the canary Fleet can be grown until you feel confident in its stability. /site/docs/integration-patterns/reusing-gameservers/ Wed, 01 Sep 2021 00:00:00 +0000 /site/docs/integration-patterns/reusing-gameservers/ Having a GameServer terminate after a single player session is better for packing and optimisation of infrastructure usage, as well as safety to ensure the process returns to an absolute zero state. However, depending on the GameServer startup time, or other factors there may be reasons you wish to reuse a GameServer for n number of sessions before finally shutting it down. The “magic trick” to this is knowing that the GameServer process can call SDK. /site/docs/integration-patterns/high-density-gameservers/ Tue, 31 Aug 2021 00:00:00 +0000 /site/docs/integration-patterns/high-density-gameservers/ Depending on the setup and resource requirements of your game server process, sometimes it can be a more economical use of resources to run multiple concurrent game sessions from within a single GameServer instance. The tradeoff here is that this requires more management on behalf of the integrated game server process and external systems, since it works around the common Kubernetes and/or Agones container lifecycle. Here are two different approaches to solving this problem with Agones: /site/docs/integration-patterns/player-capacity/ Tue, 31 Aug 2021 00:00:00 +0000 /site/docs/integration-patterns/player-capacity/ Using this approach, we are able to be able to make an Allocation request that is akin to: “Find me a GameServer that is already allocated, with room for n number of players, and if one is not available, allocate me a Ready GameServer”. Common applications of this type of allocation are Lobby servers where players await matchmaking, or a persistent world server where players connect and disconnect from a large map.