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-based game 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
- the ability to run one simulated player deployment (in addition to a game deployment) using the simulated player feature available with our GDKs for Unreal and Unity
- 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.
The paid tier covers use of the SpatialOS Platform beyond the free tier. You need to use the paid tier if you want to do any of the following:
- use any game templates beyond those provided by the free tier
- run more than one game instance (deployment) simultaneously
- run more than one simulated player deployment
Pricing applies when you are testing or launching your game in the cloud.
With our paid tier, all game 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.
What we charge for
Currently, we only charge for the use of the following:
- Hosting of cloud-based game instances (game deployments)
- Hosting of simulated players (simulated player deployments)
All other tools and features available through the SpatialOS Platform are free to use at Improbable’s discretion, subject to fair use limits associated with each template.
See below for more information on what is included in:
Your game deployment
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.
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 a custom template for you.
Currently, we only offer public hosting on Google Cloud Platform. Prices differ by hosting region, but all prices are in USD. General hosting for free-tier users is currently located in clusters based in the EU and US; if you require a deployment in other regions, please contact us. 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_r0100_e1**||1 x (2vCPU, 7.5GB RAM, 40GB disk)||8k||1k||1||All templates include a capped usage of logs and metrics. See below for details.||0.26||0.27|
|w2_r0500_e5**||1 x (2vCPU, 7.5GB RAM, 40GB disk)||40k||5k||5||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|
|w48_r2000_e20||3 x (16vCPU, 60GB RAM, 40GB disk)||150k||7k||20||4.38||4.67|
*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 drivers are usually the number of players each other player can see and the average rate at which the updates for players or NPCs are sent. 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.
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|
Simulated player deployments
If you’re using the GDK for Unreal or Unity, we provide the ability to scale-test your game. A simulated player is a game client that is controlled by simulated player logic as opposed to real player input. Read more about simulated players in the GDK documentation for Unreal and Unity.
With the free tier, you can run one simulated player deployment alongside your game deployment. With the paid tier, pricing for simulated player deployments is comparable to pricing for game deployments.
A simulated player deployment has a template that defines the cloud resources required to run the simulated players (the template has been configured for this purpose). When running a simulated player deployment with the GDKs for Unreal and Unity, the GDKs handle the launching and configuration settings for you.
Prices are calculated in the same way as for game deployments (see Calculating prices for more details). Prices are exclusive of local taxes and transaction charges, and are subject to change upon at least 30 days’ written notice to existing users.
Currently we have one simulated player deployment template which the GDKs for Unreal and Unity use automatically:
|Simulated player template name||Provisioned compute resources for simulated players||Price per template|
|US hosting in USD per hour||EU hosting in USD per hour|
|sim_players||2 x (8vCPU, 30GB RAM, 40GB disk)||1.01||1.11|
The following tools are not included in the price of game templates, but are currently free to use (on the paid tier as well as the free tier) at Improbable’s discretion, subject to fair use limits:
For more information, please contact us.