Improbable Icon

SpatialOS Forums

Deployment of the matchmaker (and future service offerings)

Hi there,

That new matchmaker framework as blogged looks interesting. Certainly flexible.

One question I have is the deployment. The blog mentions several times of a deployment to “public cloud” Kubernetes cluster. Does this mean there won’t be an option for it to be deployed in the same Kubernetes cluster as our game instance, with you managing everything as part of the Platform as a Service (PaaS)?

For small studios that don’t yet have an infrastructure, I’m sure this would be highly desirable, especially in the months/years leading up to going live where a global infrastructure / multiple datacenters are simply not yet needed. In fact, for some games that are latency tolerant, it may not even be desirable to deploy to multiple datacenters (turn-based games, for example).

Or to look at it another way: Improbable forces people who want to use the SpatialOS simulation tech to use you as a hosting provider of that simulation tech. While larger, established studios may find that problematic, small studios that don’t have or want to manage a cloud-deployed infrastructure love the idea of the entire game being hosted by somebody else.

However, if they are building their own Platform on top of the services you provide in lieu of using somebody else’s Platform as a Service (such as PlayerIO), then they won’t want to get into the hosting game. After all, you’re already hosting the simulation…why would they want to be subjected to a hodge-podge where they are responsible for managing part of the game, and you part of another? I’m sure most small studios will prefer to have one provider to host and manage the entire Simulation and the Platform. One bill. One management point.

Furthermore, there would be no outbound bandwidth cost with pushing from the simulation workers to the services platform if they were all hosted by you in the same GCC Region/Zone, as that wouldn’t be counted as egress traffic because it stays in the same environment under the same Google account.

Even if somebody deploys their services into the same Google Region/Zone as their SpatialOS simulation is deployed to, my understanding is that egress would still have to be paid to you as it could be cross-account traffic, and thus counted as “outbound” even though it technically doesn’t leave the Zone.

Maybe I’m simply reading more into the words “public cloud” in the blog post than is actually intended…but if I’m not, is there any plan to provide a way for you to host these containerized services?

Thanks in advance!

1 Like

Hey @VV_Rhino,

You’re correct; our current plan for the short-term is not to provide the Matchmaker as a managed service alongside the game instances. Instead, we’re focussing on making it as easy as possible for developers to set up and host it themselves, via documentation, tutorials and APIs.

The reason for this is twofold. Firstly, the priority based on developer feedback is to provide as flexible a solution as possible. If we were to build a managed service, we would have to be very opinionated in how the matchmaker logic, and other services, work. This is opposed to what we hear developers asking for.

Secondly, we’ve not yet received sufficient demand for a managed matchmaker to prioritise its development. Instead, we’re prioritizing the APIs to enable developers to integrate their own or third party systems, as well as additional Online Services, such as match-lifecycle management tools and analytics.

The blog is very much our short-term plan for the Matchmaker. We are investigating turning it into a hosted service over a longer timeframe, depending on feedback on the current iteration of the Matchmaker, and general developer interest overall.

We will take your feedback on board, thanks for sharing it with us! Also very happy to chat further about this via DM as well if that helps :slight_smile: