Improbable Icon

Thinking about SpatialOS for a project but some concerns

pricing
unreal
world

#1

Hi,

I’m looking at doing a multiplayer project using SpatialOS and using the Unreal Engine (4.17) but there are a few points where I have some concerns. These are all things that I think are necessary to know before using SpatialOS, simply because it seems that this is a system that once you’ve developed the game, you’re pretty much locked in. The effort to redevelop everything associated with this is fairly high.

Note, that’s not a criticism. It’s the same with engine choice and many other things. But it does make having as much info available before starting work, crucial.

  1. First is price. I’ve read a couple of posts that request pricing but so far there’s been nothing concrete, just that details would be released in February (the post was in Jan.) Has there been any movement on this? Can you share what the per hour cost of a worker is?

  2. The persistence model bothers me a little. I’m concerned that snapshots are not sufficient for an online game. If something happens: The servers crash, or the data center goes down, or something else unforeseen occurs, then players can lose progress made since the last snapshot.

    The thing is, that is a nightmare scenario. A player doesn’t care that someone tripped over a power cord, or that a tornado wiped out a data center. They care that the last four hours of progress are lost, and they’ll blame the developer for it, not the platform or infrastructure providers.

    There is definitely a requirement for continuous persistence, even if it is storing the contents of the memory db objects every few minutes. If this can’t happen, there needs to be a robust solution for storing persistent objects to an external db of some sort. How feasible is it to connect to say an AWS database to do this?

  3. I chose UE4 because it is open source and if I need to (unlikely but possible) I can make changes to the engine source. Or, I can add plugins to extend the engine functionality. Can I incorporate these changes in the backend onto the SpatialOS workers?

  4. The discussions on huge world sizes that I’ve seen so far have related mostly to space games. Can we have huge continuous landbased worlds? Or do they need to be zoned? (This isn’t such a big deal, UE4 itself has some limitations on map size, I wonder if this is overcome in SpatialOS?)

  5. Are there any data that shows the relationships between the number of users that can be supported and the number of workers required? How many users can be in a single location before things get chunky?

    Are there any case studies with hard data available?

If anyone from Improbable can answer these questions, I’d be most grateful. I reckon SpatialOS would be a great benefit to my project, especially in saving development time. But I don’t want to sink time into something that I’d later need to redevelop. This is my due diligence. Hope you understand.

PS.

Another thing I just thought of. Is it possible to connect to external services?

For example, if I developed an AI storyteller service that generated missions based on player attributes and past behaviour, and that ran on an external server, would it be difficult to integrate that into a SpatialOS game?


#4

Hello @Ripsnorta,

Even though I am not an employee of Improbable, I hope I can guide you on your way with some answers that I can provide.

First is price. I’ve read a couple of posts that request pricing but so far there’s been nothing concrete, just that details would be released in February (the post was in Jan.) Has there been any movement on this? Can you share what the per hour cost of a worker is?

As far as I know Improbable is still working on setting up a pricing model that is competitive and would support the mission of democratisation of the space. I know they are actively researching the issue but no further information is available at this moment.

The persistence model bothers me a little. I’m concerned that snapshots are not sufficient for an online game. If something happens: The servers crash, or the data center goes down, or something else unforeseen occurs, then players can lose progress made since the last snapshot.

The thing is, that is a nightmare scenario. A player doesn’t care that someone tripped over a power cord, or that a tornado wiped out a data center. They care that the last four hours of progress are lost, and they’ll blame the developer for it, not the platform or infrastructure providers.

There is definitely a requirement for continuous persistence, even if it is storing the contents of the memory db objects every few minutes. If this can’t happen, there needs to be a robust solution for storing persistent objects to an external db of some sort. How feasible is it to connect to say an AWS database to do this?

An AWS database would be inconvenient as your database would need to have its ports open for the world (SpatialOS runs on GC). However, it is not a significant amount of work to use a hosted service such as PlayFab or GameSparks. There is a tutorial in the documentation on how to make use of PlayFab with Unity (https://docs.improbable.io/reference/12.0/workers/unity/playfab-integration), but that should be relatively easy to port to UE.

You are right that the snapshot mechanism is not meant to be used as a persistent storage solution for your game. Improbable employees have been quite clear in the past that it recommended to use a BAAS, for example, to store your data in.

I chose UE4 because it is open source and if I need to (unlikely but possible) I can make changes to the engine source. Or, I can add plugins to extend the engine functionality. Can I incorporate these changes in the backend onto the SpatialOS workers?

At this point, the UE integration is not open source. Last I heard was that the UE integration is heavily worked on and as such Improbable prefers to keep it closed source, at least for now, because OSS contributions may go out of date as soon as a PR is ready. What the future plans are, I don’t know.

The discussions on huge world sizes that I’ve seen so far have related mostly to space games. Can we have huge continuous landbased worlds? Or do they need to be zoned? (This isn’t such a big deal, UE4 itself has some limitations on map size, I wonder if this is overcome in SpatialOS?)

This may be my fault since I am working on a space game and am very open on discussing this. Space games have such amazingly abso****inglutely ridiculous large scales that they are more challenging in that department than ground-based games.

Most of the games developed are land-based and have huge continuous worlds. An example of this would be World’s Adrift. This is actually one of the strengths of SpatialOS; since you are technically not bound to an engine you could make a world larger than you normally would. Zoning is actually a ‘weakness’ of SpatialOS since everything is just one open world; for zones, you would introduce that concept yourself with your own code.

Are there any data that shows the relationships between the number of users that can be supported and the number of workers required? How many users can be in a single location before things get chunky?

Are there any case studies with hard data available?

I know that Lazarus and World’s Adrift have done stress tests; perhaps one of them can help you with clear numbers. Otherwise I need to defer this to the good people from Improbable.

Another thing I just thought of. Is it possible to connect to external services?

For example, if I developed an AI storyteller service that generated missions based on player attributes and past behaviour, and that ran on an external server, would it be difficult to integrate that into a SpatialOS game?

You have all the facilities that you would normally have with your engine of choice; or when developing in C#, C++ or Java. As such you can communicate with any external server as long as you have a client library that can talk to it.

Again, an example is the PlayFab tutorial at https://docs.improbable.io/reference/12.0/workers/unity/playfab-integration; this should give you a nice idea how this would work.


#5

Hello @Ripsnorta ,

First of all I wish you a happy arrival on the SpatialOS forums! It is exciting to have you checking out our platform and if your goal is to create a multiplayer game then there is definitely a chance that SpatialOS can help you alleviate a lot of the issues that such project usually create.

I certainly understand your desire to do your due diligence before undertaking any significant development. Our good friend @draconigra (many kudos to him) has already given most of the answers I was going to write but still, so that you also hear it from Improbable. I apologise in advance for any double ups with respect to what @draconigra has already written.

  1. We do not currently have public pricing information available. Our open platform is structured to encourage experimentation, and to help us to learn how developers use SpatialOS. This is why the forums, documentation and development tools are free for you to use as well as the ability to run limited cloud deployments that are enough for small-scale testing and building prototypes. If you need more space than this further down the development road, or if you would like to release / monetise your project, we ask you to contact us at developer@improbable.io.

    In the meantime the community here is always keen on discussing any projects that you might have (up to the point of course where you want to disclose anything :slight_smile: ) and exchange ideas.

  2. You are definitely right about the fact that snapshots are not reliable enough for the most important player data as you definitely do not want to lose any progress that players make. They are actually not even designed to alleviate the specific issue that you are describing. We recommend hybrid solutions that rely on an external database service for your most critical information. You can read the following post that should answer most of the questions you might have and we even have a tutorial about integrating Playfab into a Unity project as a way of safeguarding the progress of your players.

  3. It is definitely possible for you to modify Unreal’s source code and recompile while using SpatialOS. Our engine integration works as a plugin itself and we do not modify the source of the engine.

  4. Even if there are, without question, space-based games that are being developed on our platform this is definitely not a strong constraint. Other game projects under development on SpatialOS play in vast areas of land. For example Seed by Klang and Chronicles of Elyria by Soulbound studios. Zoning is not necessary from SpatialOS’s perspective as one of the main premises of the platform is to lift exactly that requirement. The biggest challenge here that people have to deal with is not limits imposed by SpatialOS but rather the generation of the world content as there is now so much space that you can use. One of the obvious tricks to use here is procedural generation but that might not fit all projects.

  5. The density question, although very understandable, is very hard to answer. It is not possible to give hard data elements in this perspective due to the early-stage character of the platform (i.e any data we would give now would be out-of-date shortly after, as we continuously make improvements to the runtime and the SDKs). Moreover, the answer to this question depends on a very large set of variables (level of detail, behavioural complexity, …) such that making any hard predictions around this is tricky at best. It is also largely dependent on the user’s game code so that even for similar games the performances could vary considerably. The best practical answer I can give, while still considering the above caveats, is for you to have a look at World Adrift by Bossa Studios. This is currently in closed beta but keys are regularly made available, and you can find plenty of videos around the web.

  6. It is entirely possible to connect to external services (see for example the Playfab integration tutorial referenced above). There are no real limitations for connections that you set up from within your simulation logic to third-party services.

I hope these points give you the information that you were looking for. In any case do feel free to ask any further questions you might have! Having a further look around the discussions that the community is having is also a good way to get a glimpse of some of the possibilities that SpatialOS opens up to game developers and designers.

Best regards,

Duco


#6

Hi @dvanamst and @draconigra

Thanks for responding to my query. After I posted this I spent some time trawling the forums, documentation, and blog posts, and along with your answers to my questions, I’m a bit more familiar with the whole thing now.

I understand with the pricing you haven’t fully worked it out yet. Do you have an estimate of when you can tell us this info? Do you have an estimate of when SpatialOS will be ‘released?’

In regards to running external services, am I correct in assuming that you use Google Compute Engine to run SpatialOS?

If that’s the case, it would probably be better to host things like external databases (not directly, I’d create an API of some sorts, possibly RESTful to access it) on GCE rather than AWS. Which leads me to another question, is there a way of determining which region my SpatialOS workers are running in?

I reckon it would be more efficient to run a DB service in the same datacenter that my workers run in.

Also, I was wondering what you guys have planned in case Improbable fails. Will you release the SpatialOS software as open source so that we can keep running elsewhere, or will that be it?

I ask this, not to offend, but stuff does happen. Promising startups do fail, or get bought up and get shut down. Google has done that to more than a few services that it has bought. I’d hate to get into a couple years of operation and find myself without hosting.

One final question, for now at least :wink: , will SpatialOS be able to some point in the future incorporate third party addins to its business model?

I’m used to working with a PaaS called Heroku which provides a service very similar to yours. You develop a web application and run it on workers called dynos. The addin model allows an application to plugin services ranging from non-standard database like Redis and Mongo, to analytics, logging, even credit card payment services. This is all done from the Heroku app control panel. Nice and easy.

It would be nice to have similar functionality in SpatialOS.


#7

I could be wrong as I’ve only been here little over a week, but I recall Improbable saying they have no plans to provide add-ons directly as there are other providers doing a great job in this regard.

For example, the aforementioned PlayFab has a good number of add-ons available: https://playfab.com/add-ons/


#8

Hey again @Ripsnorta,

Sorry for the delayed response, was not around for last few days.

With respect to your follow-up question on the pricing: our current position is, as explained by @draconigra and in my first post, that you should contact Improbable to get the conversation going. This is neither a “more info by date X” or a “never” but rather a “I do not have that information available”. I understand that this can be a concern for you, hence the advice to contact us. :slightly_smiling_face:

SpatialOS is cloud-provider agnostic in the sense that we are not specifically reliant on the APIs or features of a specific provider. As a result, and a deliberate choice we strongly encourage you not to rely on the fact that we may run on provider X or Y for the choice of any external services as there is no hard guarantee that this situation will not change.

You can determine the SpatialOS “region” (i.e not a GCE / AWS / … region) for each of your deployments (i.e game worlds) as we currently have us and eu available.

With regards to the “Improbable fails” scenario: to be honest even if this was more of a concern a year ago, since then we have acquired 500M $ in funding which gives us considerable breathing room.

Finally, with respect to the third-party add-ons, we do not go further at this point than the few tutorials that we have put up on how to integrate some frequently used services. This says nothing about whether we are going to provide stronger integration or alternative options further down the road but it would be wishful thinking to start providing you with timelines. Keep in mind that we are still in “Beta” and that we are learning and adapting quickly. We would rather not give any false hopes and / or expectations. I hope you understand. :wink:

Best regards,
Duco