Introduction to game templates
You need to specify a game template when you launch a deployment with SpatialOS. A deployment could represent your whole game world, or could be one component of it (for example, one match or one arena). When you specify a game template, you get:
- cloud compute resources for your game servers (called “server-worker instances” in SpatialOS).
- egress bandwidth to send data to your players.
- the SpatialOS Runtime, which is unique to SpatialOS and the foundation of all games on the platform. It handles networking and area of interest management, orchestrates and load balances multiple game servers, and stores all of your live game data in memory.
- SpatialOS monitoring and debugging tooling: our metrics and logging services, and use of the Inspector.
Everyone who signs up for SpatialOS is automatically enrolled in the free tier. No commitment is required, and you do not need to enter any payment details. The free tier is ideal for starting development, prototyping a game, conducting technical evaluation, or just learning how to use SpatialOS.
It gives you:
- the ability to run one cloud deployment at any time, hosted in the EU or US, using any of the following game templates (see this table for details of what each template provides):
- free download and use of our GDKs and SDKs
- unlimited use of SpatialOS on your local machine
- free support via our forums (see Support)
You can access one of the available game templates by specifying it as your template name in your launch configuration file. While on the free tier you can’t use any of the larger templates, or run multiple deployments at the same time. If you would like to do either of these, you need to contact us so we can set you up on the paid tier.
You need to use the paid tier if:
- you want to use any game templates beyond those provided by the free tier, or
- you want to run more than one game instance (deployment) simultaneously.
We provide a range of templates which are ideal for getting started. As you progress through development and your game design becomes more static, we can provide custom templates that are a tighter fit to your requirements.
With our paid tier, all deployments automatically receive a 99.9% uptime guarantee as set out in this SLA.
To get set up with the paid tier you need to contact Improbable.
Running multiple deployments
Most live games are made up of multiple separate game instances that require multiple simultaneous deployments. An example of this is match-based games, where one game is made up of multiple similar matches (also called arenas, rooms, or sessions) running at the same time, with a small number of players in each match. For these types of games we would expect each match to be a separate deployment.
SpatialOS lets you have thousands of deployments running at the same time. Each deployment requires its own game template, and different deployments could each use different sized templates.
You only pay for what you use. Prices are shown on a “per hour” basis for simplicity, but you will be invoiced a prorated amount based on the duration you use the template for, to the nearest minute (rounded up). The duration is measured as the difference between when the deployment is created and when it is terminated. The minimum duration is 10 minutes, so if your deployment is live for less than 10 minutes, we calculate prices as if it ran for 10 minutes.
Game template sizes and prices
We provide a range of game templates. Each template comes with provisioned compute resources for hosting your server-worker instances, provisioned capacity for the SpatialOS Runtime, an allowance of egress bandwidth, and capped use of our monitoring and debugging tooling.
If you require a template with resources different to those below, please get in contact. We will discuss your requirements and could create you a custom template.
Currently we only offer public hosting on Google Cloud Platform. Prices differ by hosting region, but all prices are in USD. Prices are exclusive of local taxes and transaction charges, and are subject to change upon at least 30 days’ written notice being given to existing users.
|Game template name||Provisioned server-worker (game server) compute resources||Provisioned SpatialOS Runtime||Egress bandwidth||Monitoring and debugging||Price per template|
|Max op units per second for the whole deployment||Max op units per second per worker connection||Included GB per hour for the whole deployment*||Logs||Metrics||US hosting in USD per hour||EU hosting in USD per hour|
|w2_r0500_e5**||1 x (2vCPU, 7.5GB RAM, 40GB disk)||40k||5k||5||All templates include a capped usage of logs and metrics. See below for details.||0.54||0.55|
|w4_r0500_e5**||1 x (4vCPU, 15GB RAM, 40GB disk)||40k||5k||5||0.64||0.66|
|w2_r1000_e10**||1 x (2vCPU, 7.5GB RAM, 40GB disk)||75k||6k||10||0.97||0.99|
|w4_r1000_e10**||1 x (4vCPU, 15GB RAM, 40GB disk)||75k||6k||10||1.08||1.10|
|w8_r1000_e10||1 x (8vCPU, 30GB RAM, 40GB disk)||75k||6k||10||1.29||1.34|
|w4_r2000_e20||1 x (4vCPU, 15GB RAM, 40GB disk)||150k||7k||20||1.91||1.95|
|w8_r2000_e20||1 x (8vCPU, 30GB RAM, 40GB disk)||150k||7k||20||2.14||2.20|
|w16_r2000_e20||1 x (16vCPU, 60GB RAM, 40GB disk)||150k||7k||20||2.59||2.69|
*1GB is 2^30 bytes. Bandwidth usage in excess of the included bandwidth will be charged according to overage fees.
**You can use these templates in the free tier.
Understanding the table
Each game template comes with provisioned server capacity for hosting your server executables and the game servers (which we call server-worker instances) they create. Server-worker instances are often dedicated servers built using game engines, but can also be made from custom-built code written in C#, C, C++, or Java. Server-worker instances run in containers, in a similar way to other hosting services.
When you start a deployment these server resources are provisioned for you. They are only available to use for worker instances that are connected to this deployment - you can’t share them across multiple deployments. You should select a template that comes with resources that best suit your needs. It is up to you how many server-worker instances you run with these resources - there is no limit.
Currently we only offer public hosting on Google Cloud Platform. All of the servers we provision for you come with minimum CPU Platform of the type Intel Xeon Skylake. These have a base frequency of 2.0GHz, an all-core turbo frequency of 2.7GHz and a single-core max turbo frequency of 3.5GHz.
If you have resource requirements for your server-worker instances that differ from all of the publicly available templates, please get in touch.
The SpatialOS Runtime is unique to SpatialOS and is the foundation of all games on the platform. It handles networking and area of interest management, orchestrates and load balances multiple game servers, and stores all of your live game data in memory.
Each game template comes with a provisioned SpatialOS Runtime capacity. This is defined across two criteria relating to operations:
- operation units per second for the whole deployment
- operation units per second per connection
Operations are messages carrying information between worker instances and SpatialOS.
Provided your deployment is operating within both of these criteria for the majority of the time, the SpatialOS Runtime should be sufficient to support it, although this is not guaranteed (please see Known limitations below). If your deployment consistently uses more than the capacity levels indicated, we strongly recommend re-deploying with a larger template, or optimizing such that your usage is below the levels. This is because your deployment may not be stable, and even if it appears stable now, we cannot guarantee it will continue to be stable at these levels in the future. We are also not able to provide the SLA for any period in which you exceed the capacity levels for your template.
Every operation counts towards one or more operation units based on its payload size. The payload size is defined as the size of the serialized operation (post delta encoding); it may include some encoding overhead, but does not include transport-level headers.
Operations with payload sizes equal to or less than 40 bytes count as one operation unit. Operations with payload sizes of more than 40 bytes count as more than one operation unit, with every additional 40 bytes counting as one operation unit.
- 1 operation of 15 bytes counts as 1 operation unit
- 1 operation of 40 bytes counts as 1 operation unit
- 1 operation of 60 bytes counts as 1.5 operation units
- 1 operation of 80 bytes counts as 2 operation units
When we count your usage of operations, we only include operations that you have either direct or indirect control over; we don’t count the operations that you have no control over.
Operation units per second for the whole deployment
The total operation units per second across the whole deployment is the total amount of information SpatialOS is synchronizing at any given time across the whole of your deployment, and your choice of game template specifies an upper limit on how much your deployment can handle.
The amount you need depends on your game design and how you implement it, but in general, games with more players, more entities, higher density, or higher fidelity will all use more operations. See the pricing examples below for some reference points. In future we plan to provide more examples.
We provide a metrics dashboard where you can track your deployment’s use of operation units.
Operation units per second per worker connection
Your choice of game template also specifies the maximum number of operation units any one worker instance can handle (this could be a client-worker or a server-worker instance). You can think of this as the maximum “density” of your game, or, more specifically, the maximum density in any one local area of your game. This is independent of the total number of operations per second across the whole deployment, because games can be very large (requiring a large number of operations in total), but relatively sparse (requiring relatively few operation units per second per connection), and vice-versa.
Density depends on a number of factors. However, in the case of action games, the biggest driver is usually the number of players each other player can see. This is because each player needs to receive updates from each other player in their view (although this also depends on other configurations, such as your area of interest). Denser games require a higher number of operation units per connected worker instance.
The price of your game template includes an allowance of egress bandwidth for sending data to your players. Any data transferred from deployments to third-party applications or the internet contributes to this allowance.
The allowance is expressed in GB per hour, however it is prorated based on how long the deployment is running for.
Use of egress bandwidth above the capped amount is subject to ‘overage fees’ of $0.12 per GB.
Monitoring and debugging tooling
The price of your game template includes capped use of our logging and metrics services. We do not currently offer usage beyond this capped level, but if you have additional requirements, please let us know.
Each game template comes with a limit of 6000 user-generated worker log messages per minute. SpatialOS Runtime logs do not contribute to your usage limit. For more details, as well as information about the limits on retention and querying, see Logs.
The price of the template also includes all our aggregated metrics. For details about these, as well as information about the limits on retention and querying, see Metrics reference.
Other SpatialOS tools
As part of SpatialOS, we currently provide other ancillary services, such as the Inspector and the Launcher. We consider these separate services to the game templates, and therefore they are not included in the price. However, these services are currently free to use at Improbable’s discretion, subject to fair use limits. For more information, please contact us.
Before launching your game, you should always do extensive testing to ensure your game is stable. However, below is a current known limitation:
- We’ve tested the game templates based on typical game profiles. However, for deployments with a very high number of connections, the capacity of operations may be lower than that stated. As an example, the total operation unit capacity of the “w4_r1000_e10” template may fall below 75k per second once the number of connected worker instances exceeds ~250 connections.
Below are some pricing examples from our GDK for Unity Starter Project and from test games we have run. For each example we show the game templates they use. For the system test examples, we created simulation scenarios representative of the game specifications to determine the template requirements.
If you would like more help understanding which template would be right for your game, please get in touch.
|Game description||System tests: 100-player FPS||System tests: 200-player FPS||200-player GDK for Unity starter project|
|Game template required||w2_r0500_e5||w4_r1000_e10||w4_r1000_e10|
|Price per template per hour (US hosting)||$0.54||$1.08||$1.08|
|Equivalent to $ per player per hour||$0.005||$0.0054||$0.0054|
|Equivalent to $ per MAU (10 hrs per player per month)||$0.05||$0.05||$0.05|
|Players per match||100||200||200|
|World/map size||2.8km x 2.8km||4.2km x 4.2km||1.4km x 1.4km|
|Player view distance||Sniper rifles (approximately 300m)||Sniper rifles (approximately 300m)||Sniper rifles (approximately 300m)|
|Max player density||Some players can see 15 others||Some players can see 15 others||Some players can see 15 others|
|Avg. player density||Every player can see 3 others||Every player can see 3 others||Every player can see 3 others|
|Static game objects||2,000||4,000||0|