<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Common Integration Patterns on Agones</title>
    <link>/site/docs/integration-patterns/</link>
    <description>Recent content in Common Integration Patterns on Agones</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Tue, 27 Jul 2021 00:00:00 +0000</lastBuildDate><atom:link href="/site/docs/integration-patterns/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Matchmaker requests a GameServer from a Fleet</title>
      <link>/site/docs/integration-patterns/allocation-from-fleet/</link>
      <pubDate>Tue, 27 Jul 2021 00:00:00 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/allocation-from-fleet/</guid>
      <description>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: &amp;#34;allocation.agones.dev/v1&amp;#34; 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.</description>
    </item>
    
    <item>
      <title>Matchmaker requires game server process registration</title>
      <link>/site/docs/integration-patterns/matchmaker-registration/</link>
      <pubDate>Tue, 27 Jul 2021 00:00:00 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/matchmaker-registration/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>Canary Testing a new Fleet</title>
      <link>/site/docs/integration-patterns/canary-testing/</link>
      <pubDate>Tue, 27 Jul 2021 23:49:14 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/canary-testing/</guid>
      <description>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.</description>
    </item>
    
    <item>
      <title>Reusing Allocated GameServers for more than one game session</title>
      <link>/site/docs/integration-patterns/reusing-gameservers/</link>
      <pubDate>Wed, 01 Sep 2021 00:00:00 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/reusing-gameservers/</guid>
      <description>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 &amp;ldquo;magic trick&amp;rdquo; to this is knowing that the GameServer process can call SDK.</description>
    </item>
    
    <item>
      <title>High Density GameServers</title>
      <link>/site/docs/integration-patterns/high-density-gameservers/</link>
      <pubDate>Tue, 31 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/high-density-gameservers/</guid>
      <description>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.
Utilising the new allocation gameServerState filter as well as the existing ability to edit the GameServer labels at both allocation time, and from within the game server process, via the SDK, means Agones is able to atomically remove a GameServer from the list of potentially allocatable GameServers at allocation time, and then return it back into the pool of allocatable GameServers if and when the game server process deems that is has room to host another game session.</description>
    </item>
    
    <item>
      <title>Allocating based on GameServer Player Capacity</title>
      <link>/site/docs/integration-patterns/player-capacity/</link>
      <pubDate>Tue, 31 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>/site/docs/integration-patterns/player-capacity/</guid>
      <description>Counters and Lists will eventually replace the Beta functionality of Player Tracking, which will subsequently be removed from Agones.
If you are currently using this Beta feature, we would love for you to test (and ideally migrate to!) this new functionality to Counters and Lists to ensure it meet all your needs.
This document will be updated to utilise Counters and Lists in the near future.
Warning The Player Tracking and Allocation Player Filter features are currently Alpha, not enabled by default, and may change in the future.</description>
    </item>
    
  </channel>
</rss>
