Multi Platform

Queues can also allocate to multiple platforms by referencing a 'multi' platform definition. This can be used to achieve failover (i.e. if one platform is out of resources, try the next one), or to achieve client-latency based matchmaking.

Failover example

In this example, the matchmaker will first attempt to allocate servers in the first-listed platform (primary), followed by the second-listed (secondary).

{
  "id": "myproject.failover",
  "name": "projects/myproject/platforms/failover",
  "title": "Failover platform",
  "multi": {
    "platforms": [
      {
        "active": true,
        "platform": {
          "name": "projects/myproject/platforms/primary"
        }
      },
      {
        "active": true,
        "platform": {
          "name": "projects/myproject/platforms/secondary"
        }
      }
    ]
  }
}

Location-based example

This should be used in conjunction with client latency-based matchmaking to efficiently match players to servers located nearer to them. For example, if you have already defined three platforms in London, New York and Mumbai, you can combine them into a single 'multi' platform that is capable of routing players depending on their client latency measurements:

{
  "id": "myproject.location-aware",
  "name": "projects/myproject/platforms/location-aware",
  "title": "Location-aware platform",
  "multi": {
    "platforms": [
      {
        "active": true,
        "labels": {
          "location": "london"
        },
        "platform": {
          "name": "projects/myproject/platforms/london"
        }
      },
      {
        "active": true,
        "labels": {
          "location": "newyork"
        },
        "platform": {
          "name": "projects/myproject/platforms/newyork"
        }
      },
      {
        "active": true,
        "labels": {
          "location": "sydney"
        },
        "platform": {
          "name": "projects/myproject/platforms/sydney"
        }
      }
    ]
  }
}

note

The labels field for each platform specifies a location key that must exactly match the value reported in the clientLatency field of the QueueJoinRequest.