It's been a while since I spun up a dedicated server but how is this anything special compared to just spinning up normal server instances?
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.
Thanks, that's what I thought and was trying to figure out if I missed any reason this was staying on the front page given it's just a re-branding of an existing open source solution.
Hi there! I'm the founder of Agones, so wanted to give some additional perspective.
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
Oh yeah, I didn't mean it to be a knock against Agones, more that there seemed to be a fair amount of marketing speak in the google copy("supercharged", "Companies like Activision Blizzard are benefiting from our ... artificial intelligence (AI) capabilities") and it wasn't clear what the value was.
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.
Gameservers are very different in nature from the the rest of the industry ( like web services ), first of all everything is custom so it's not lile there are tools proprietary or open source for that. Even inside the same company you can have different engine with different matchmaking solution etc ... then you have to hook all of that on some platform ( cloud or bare metal ).
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.
So... it's the same problems that we've always had hosting a dedicated game server fleet.
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.
Cool, Google created a cloud-native solution for people who want to create games for Google Stadia. You can buy into the ecosystem, built on top of Kubernetes - the system recommended for large scale projects and teams with hundreds of servers (but not more then ~5,000). An ecosystem most knowledgeable SREs will recommend your team not use unless you are able to do a relatively large amount of due diligence and have dedicated staff who are domain experts for kubernetes. For Google Stadia. Which is pivoting into really pushing for exclusive titles, and was the driving force for some studios removing their games from Geforce Now, because unlike Google Stadia Geforce Now allows you to bring your own games which you already own and avoid re-buying the same game twice.
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.
> An ecosystem most knowledgeable SREs will recommend your team not use unless you are able to do a relatively large amount of due diligence and have dedicated staff who are domain experts for kubernetes
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.
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).
At the risk of contributing to the thing I'm railing against, these google sunset comments are so boring, especially when discussing Google Cloud products.
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.