Simplified global game management: Introducing Game Servers
cloud.google.com
cloud.google.com
I see a lot of buzzwords but nothing that stands out technically. Throw some cpu+memory, open a udp socket, register with the matchmaker coordinator and away you go.
That overview describes it well. You can already run a game server as a standard Kubernetes service but this wraps it with some more primitives around gaming features like matchmaking, session maintenance, fleets, allocation of warm servers, etc.
GCGS provides a lot of functionality over the top of Agones. The big win here is that while Agones works great within a single Kubernetes cluster, it requires a lot of manual work to orchestrate across multiple clusters.
This is what Google Cloud Game Servers brings to the table - flexible ways to orchestrate and manage multiple Agones clusters around the world, and the Fleets of warm Game Servers on them.
We also work really hard so that is it's easy to move from open source Agones -> GCGS, but also move back out of you no longer want our management layer.
There's more stuff on top of that, but I hope that helps clear things up
Honestly, your comment is much clearer than most of the linked article.
I just don't see what makes this special, dedicated servers don't require GPUs, just a good amount of cpu and a moderate amount of network bandwidth. This just feels more like branding existing things because games are "cool".
I left that industry a few years back so maybe things have changed but I'm not seeing it.
The biggest hurdle is the cost, that the #1 issue people will have running gameservers. Imagine your game is using 1 core for 16 players, how many ec2 instance you need to accomodate 150K concurent users? ( and that's just the cost for gameservers it does not includes online services ).
Now what's hard for example? DDoS protection, matchmaking, scaling up/down ( scaling down is challenging depending of the game because of server fragmentation), performance optimization, most dev use Windows to dev games but gameservers are more and more running on Linux now so how do you test that locally. The biggest challenge is that every games are different and you need something "custom" very often. Also game devs have NIH syndrom which doesn't help.
Running gameservers for a serious game is not trivial, currently more challenging that puting some Java app behind a load balancer on an auto-scaling group.
Game solutions have always been custom because there's never some one-size-fits-all engine(although bless Unreal and Unity for taking a shot at it). I speak from real experience here here and not just some hypothetical stance. The design and structure of your game will have implications on how your matchmaking/sharding plays out across a region.
Just because gamedev uses windows to a degree doesn't make Linux some big scary thing. PS3 was closer to Linux than anything else. I was running dedicated Linux servers for Half-Life/Quake/etc over 20 years ago so it's not like that's anything new.
If you're doing matchmaking based servers that's the easy case. You don't have any shared state, you can scale down when a match ends. When you start crossing into the shared state(MMO, non-sharded worlds, etc) that's where it's not easy to just horizontally scale out.
Google is trying to get a juicy bite of the games industry by building a walled garden around exclusive titles and proprietary cloud setups. Microsoft and Sony have used the same tactics (particularly exclusive titles). The chief argument is access, the idea that more people can now game who previously couldn't, but I don't buy it.
Who are those 'knowledgeable SREs' and what are they recommending instead? Docker Swarm? VMs?
There is a place for those approaches, but people often underestimate the amount of work that is involved to bring large services into production, work that has been packaged and commoditized by K8s, by domain experts.
Moreover, it allows people to speak the same language and easily share their solutions.
Actual domain experts are required (today) if you want to bring databases and other stateful workloads to Kubernetes. But stateless? I'll run MicroK8s in a Raspberry Pi if I need to run containers. There is so much stuff that's taken care of by K8s that I can't'see why one wouldn't use it, unless they need to just run a single container somewhere.
> and proprietary cloud setups.
Proprietary? https://github.com/googleforgames/agones
You don't have to run it on GKE, you know. You can manage it yourself. Which I'm not sure why you would do, since you are complaining about the lack of domain expertise.
It's open-source software (Agones) designed to run any kind of game server (packaged as a Docker container) on top of Kubernetes with easier management around things like scaling, rolling updates, session management, metrics, lifecycle SDK, etc. Google Cloud is just offering a managed version of this on top of GKE.
AWS and Azure offer similar platforms and even more products (like AWS Lumberyard game engine).
> Agones, an open source game server hosting and scaling project