They allow you to fine-tune where you want your deployments to be located. They are a part of the policy itself, but by how they are constructed, we found that it would be easier to understand on their documentation page.
The policy data will not include the same structure depending on the policy's type. We will go through every type with examples.
This is the option we would prefer in our North American fleet.
We will add a slight constraint to our North American fleet to show you how you can tweak the filters to your taste. Let's say you don't want any of your games to be located in Miami because you find that it is too far from your typical players' location.
You will need to choose an available field from city, country, continent, administrative_division.
Next is the filter type. You can choose between:
- any - You want one or more of the values to match the potential locations.
- all - You want all the values to match the potential locations.
- not - You want all the values not to match the potential locations.
You can create pretty complex policies, but be aware that your filters might be technically correct but impossible to process. If you create an all filter with three different cities, it will simply not work since no location can physically be in those three cities.
You can get all the geographical information about the locations with the API.
The data for the policy is created in a small form with some predetermined values.
From the API, you must specify the type when updating the data field.
Tag type is less often useful for common use cases but can be very convenient if you need more technical filters like high clock CPU. The values will always be a key and a value separated with an equal sign.
You can get all the tags for each locations with the API. You will need to set the tags parameter to true.
Point type lets you give latitude and longitude coordinates. The fleet will create deployment at the closest location available from the point.