Improbable Icon


Quick idea of the cost for an indie developper



Hello !

I’ve been searching but I can’t seem to find info about prices, so I’m posting here in the hope that someone could give me an idea about how much it costs.

I’m not expecting an accurate or reliable number, but just an approximate idea in order to let me know whether this is even an option for me or not at all. I read that the pricing will be based on the used resources (cpu/memory/network), but there isn’t any figure. Is it like 0.01$ per player per hour ? 0.1$ ? $1 ? I have really no idea.

I’m an lonely indie developer who never made a game before so my budget is close to zero, but I could maybe spend a bit of money if it is worth it.



Hi @StarCore, sorry for taking so long to get you an answer. We just published a pricing explainer that should clarify how our pricing model works. If you’re getting serious with your game then definitely use the contact us link at the bottom of that page to get more details. We’re also going to try to put together some more specifics (like numbers) for some examples in the near future.


Agree with @StarCore, I have this same question and it’s hard to get an idea of the cost per user.
The pricing explainer does not help much because it actually does not mention any price in dollars.
In a typical game what would be the cost ? What is the order of magnitude?
Quoting @StarCore: “Is it like 0.01$ per player per hour ? 0.1$ ? $1 ? I have really no idea.”


Hi @joaquin.keller,

Unfortunately, as the bottom of the page says, the actual price depends on a number of factors specific to your game. This makes it difficult to have a one size fits all public price number. If you have more details about the game you are building, we can put you in touch with the right people to discuss pricing specifics with.


Just want to add to this - since spatial’s value comes from the tech, not the raw data processing, maybe you folks should think about revenue share model + minimum costs for traffic? As a dev, I don’t use SpatialOS for its wonderfully cheap data transfer costs… I use it because it saves me a crap ton of dev time. If you base your business model on data usage, it doesn’t make any sense - why am I paying for the least important part of the engine?

I really think cutting down on the direct traffic costs and focusing on capturing value from successful games created on your platform is a much cleaner way to go.


Hi @Swizzlewizzle,

Thank you for sharing your thoughts. The pricing approach you mention is one of the options we considered when designing our pricing.

There were two main reasons we decided against a revenue share approach. Firstly, we didn’t believe it was fair on our customers to demand a fixed share of their revenue, regardless of the profile of their game. We recognise that different customers will want to make very different games with SpatialOS, and we wanted to design pricing in a way that charged them fairly based on the extent to which they use the platform.

The pricing model we’ve chosen scales the price of games with use of SpatialOS (e.g. games with more concurrent players, more scale, more complexity, will pay more). We believe this is fairer to users because it gives them the ability to make these design trade-offs, and to scale their costs as their player base grows.

Secondly, and connectedly, we believe users should reap the benefits of their games’ financial success. The usage based pricing model we have chosen means that we will charge the same for two games that use the platform identically. That gives developers the freedom to decide how to monetise their games, and to receive the greatest benefit from a successful model.

We have not yet publicly released our price levels, but as you suggest our current plan is to minimize costs for ‘Bandwidth to Players’. This is because we agree with your observation that this component of pricing is not the most valuable part of the platform.

I hope that helps you understand some of the rationale behind our pricing.

Kind regards,


You make fair points Jack.


@JackC - have had some time to think about it, and just wanted to follow on a bit with additional feedback.

Coming into Spatial, it seems like a large part of the platform’s attractiveness is to handle much of the nitty-gritty problems of scaling and MMO networking. Of course, many of the same problems an MMO faces also extends to running highly complex ongoing simulations.

On the pricing side though, focusing only on charging based on raw usage means then that two major scenarios would likely play out:

  1. A large developer capable of highly optimizing their game/simulation pushes down their usage costs and pays only a very small portion of the revenue they are making to Spatial.

  2. A small indie company uses Spatial to handle the networking/scaling side of their game/sim. Indie company spends most of their time putting the actual gameplay/content/etc… together, with optimization perhaps leaving a lot to be desired. They end up paying a much larger percentage of their revenue/profits to Spatial to continue running the system.

From Spatial’s perspective, I see both of these cases as being bad for you. In case 1, you are only able to capture a very small % of the success enabled by your cutting edge technology.

In case 2, you get a comparatively large % of a smaller pie, from a customer who is already running at the edge (as is the case with most indies/small companies I hope we can agree?) in terms of keeping the lights on and growing. It seems to me that companies like this would not become long-term customers of Spatial if they feel Spatial is “too expensive” (when perhaps it’s just an optimization problem…).

I’ve had some first-hand feedback from a number of devs on the SpatialOS discord where there have been concerns where people are worried about the prices not being transparent, and that prices could easily get too high.

This makes a lot of sense considering if a project decides to base their core tech around SpatialOS, and then start getting into problems down the road with pricing… what do they do? They have already sunk (likely a lot) of development time into creating things using the SpatialOS platform. Consider the case that they end up paying much higher prices to Spatial then they were expecting… do they simply take the loss, cut the project and change their tech? Do they need to engage in negotiation games with Spatial’s sales team? Either outcome sounds like really bad news.

I just cannot agree that CPU / Bandwidth / Storage / “Worker #” pricing makes sense for any dev studio serious about using SpatialOS.

One final note… I have considerations from both sides of the fence, since there are potential opportunities on my side to either use SpatialOS on an enterprise level, or just as a prototyping/do-it-on-my-off-time thing.


Hey Swizz - super interesting points!
I’ll make sure J follows up when he can - I just thought I’d chip in from an engineer’s point of view.

Pretty soon - we’ll be able to show you the OPS used for a deployment. The major benefit of this as an indie (and also, depending on a few things - a AAA ) developer is that using SpatialOS you’ll be able to quickly ascertain two really important pieces of information:
a) is the game fun when ‘n’ people actually play it ( where n== your game design)
b) is it cost effective

Now, the initial prototype will almost certainly not be as optimised as possible - but my experience so far works out roughly as below:

  1. feature is built and gets tweaked to the point where it is fun with a group
  2. initial graphs are looked at, and a first pass optimisation is made (basically - don’t do anything really stupid )
  3. post the first set of optimisation, reassess the cost effectiveness making assumptions about how far it could possibly go.
  4. if necessary, apply a second round of deeper optimisation (don’t do stupid things, and do a few smart things) to get the feature to the point where it is ‘geenlit’ from an experience + cost perspective.

I don’t doubt that bigger budget games have more time spent on optimisation (although, normally it boils down to eeking every millisecond of CPU on the client) but in terms of OPS and bandwidth used my bet is that indie developers will be able to go toe-to-toe with cost effective implementations right from the very get-go.

It’s not about how many resources you have to throw at a project - it’s about the design of each system taking advantage of the programmer’s knowledge of how each feature impacts cost. On a smaller team - that knowledge will disseminate out pretty quickly :wink:


Thanks for the reply callumb.

I see where you are coming from… makes sense.

It still seems strange to me that the platform is mainly focused on raw resource usage as the barometer for fees and payments. I mean… we use SpatialOS because of the tech, again, not because of how efficiently it can do processing/data storage/etc… I mean to say, if the cpu/etc… costs are charged near “at cost” and then most of the revenue to Spatial comes through the creation of a successful game/venture, then it seems to me that creators could have more freedom to focus on what their game needs to be fun, instead of what drives the most revenue based on the amount of resources used.

IE. Something like hearthstone probably has overhead/resource usage 100x or more lower than something like Star Citizen… and yet the revenue made may likely be very comparable.

I just worry that if the entire pricing model is based off of resource usage, wouldn’t it push more devs to move towards “simpler” games that avoid “cool but costly” stuff like persistent items on the ground? I mean, if you charge a premium on all the resources used, then it just tilts the balance even further towards “ok guys, that feature with the x and y is really cool but it takes too many resources, which spatial is charging us a premium for, so let’s drop it and do something less cool and simpler”.



This is all great discussion. The pricing explainer tells us nothing without some context. I feel like spatialOS desperately needs broken down example pricing for a simple project. Obviously the example estimate will miss the mark for a majority of developers BUT it gives us a vague idea what we’re looking at.

Amazon gamelift provides a wild ballpark cost estimate for data usage/transfer using a simple example game.
I realize gamelift is a product that is solving a different problem than SpatialOS and that the nature of spatial lends itself to wildly variable data rates dependant on amount of time players remain within eachothers’ interaction spheres(to name a single thing)… But giving us SOMETHING to chew on would be killer.

SpatialOS has the potential to revolutionize the indie scene and I’d hate to see this tech passed up because developers don’t want to risk creating something on technology with a mystery pricetag.


Hi @Swizzlewizzle, Hi @Gypaetus ,

Thanks again for taking the time to share your thoughts.

Firstly, I understand that you would like to see us add price points and a pricing example to our existing pricing page. This is definitely something we are working towards, and you should expect to see these added within the next 2-3 months as we finalise our numbers. Also, as @callumb indicates, we aren’t currently able to show you the Ops usage of your deployments.

As I mentioned previously, the pricing approach you are proposing is something we have considered; I agree that it has benefits for some users compared with a purely usage based approach. However, given that our costs are proportionate to a game’s usage, and the success of projects is not within our control, we will always need to have some element of pricing based on usage (otherwise projects could cost us a lot more than we make from them). We definitely don’t want to discourage users from experimenting or pushing the boundaries of what’s possible, and this is something we intend to monitor.

Finally, as is the case for many new products, we recognise that it may take us some time and several iterations before we find the best way to charge for SpatialOS. After considering the options available to us, we decided the current pricing approach was the right place for us to start. When we finalise and launch the price points and examples on the website it would be great to understand if this addresses some of your concerns.

Kind regards,


Thanks Jack. Interested to see what comes down the pipe. :wink: