> Although Pokemon Go has fewer latency concerns than a FPS/MMO
I wouldn't phrase things quite like that. While FPSes and MMOs might require low-latency links between individual servers and individual players, those links are usually long-lived enough for the ARP tables, TCP window sizes, etc. to get comfortable.
Pokemon Go, and other medium-bandwidth casual mobile games, have players expecting low-latency even while constantly having their phone kill and reopen the app, while also travelling between different cells (and thus ending up with different IPs and having their local-most IP switch have to re-path their connections.) And they only play for three minutes at a stretch. This causes a large share of the message traffic to hit at least one "un-warmed" leg on its journey, even if you do all your server architecture correctly.
Of course, things could be even worse: you could have a casual, mobile FPS.
I feel like it's fairly novel (not to say unpredecented?) that one of the top game publishers (Ubisoft) is collaborating with Google on this open-source product.
Most game publishers have specialized divisions - Demonware for Activision, EA no doubt has one too - that build closely guarded proprietary multiplayer networking toolkits, as it becomes part of their competitive advantage..
There is nothing super exited in there, it's just running a game server on Kubernetes which probably a lot of companies already do. The interesting part is the scheduling / healthcheck ( done by integrating the SDK into your engine )
I'm working on a massive-scale game server deployment engine that utilizes docker for a new startup, and the fact that this is open source is tremendously beneficial to the scalable gameserver community. Currently we're deeply integrated in the Google cloud platform and are currently expecting a release within the next few weeks or so, which is one of the reasons this post came as such a surprise to me! We're planning on releasing most of our codebase under the Apache and MIT licenses, but doing so has been complex and slow. Hats off to them!
These are fairly different offerings. Improbable is about enabling the creation of massive worlds with various actors and players interacting in the same world server - effectively large-scale MMO's with a lack of sharding. But it is also proprietary technology, so your game is entirely dependent on them sticking around and maintaining the software.
Agones is focused more on massive scaling for individual servers. i.e. making it significantly easier to scale up and down servers based on demand (similar to AWS GameLift), but from what I see there is no world-sharing across them as that isn't the point of this specific project.
It's an interesting solution to a common problem. We work in a similar space and use Kubernetes extensively for managing our services behind the scenes, it's particularly useful for mobile games as they have a lot of peak/trough traffic throughout the course of a day, let alone during a featuring on an App Store or a live event which drives traffic through the roof for a very brief period of time.
This looks more like a competitor to AWS GameLift, infrastructure designed for hosting game servers which are different than your typical web server (almost always stateful versus stateless). Improbable is more a developer level SDK to drop in your game and wire up functionality to their 'cloud processing'.
I was working for a Japanese mobile game company back in 2016 and proposed using Kubernetes for my project. They really warmed up once they understood Pokemon Go was doing exactly this (I had no idea beforehand, but was happy to see it support my decision). Sadly the company folded long before my project made it to release.
Really cool to see this go open source. I really miss working on stuff like that. Sigh.