 Yeah, I have not tried to pronounce the full name of Krishna. At least I can pronounce Krishna correctly, but I'm not sure I can pronounce the rest of the name correctly. You can just call me Casey. So Krishna is a senior personal engineer at Google. And I think he is currently based out of New York in the US, right? Yes. Awesome. Thank you very much for joining us. And Krishna will be talking to us about how to build your first multiplayer dedicated game server on Cuba. This is an exciting thing. We have a lot of gamers in the community here. So we definitely want to know how to do this. So over to you, Krishna. Definitely. Hi, everyone. Let me show my screen. Please let me know if everyone can see my screen. I'm just sharing my whole screen. It's not up yet. OK, it's up now. Excellent. I can go ahead and start the session, right? Yes, please. Yeah, OK, great. By the way, I'll be presenting the screen. If there is any pings, please feel free to stop me. But here's our agenda. So we'll just do some small intro. I'll be talking about the game infrastructure as a whole, how the game back and up front looks like. I'll take you through building a game step by step. By the way, I have a code script which I already executed given the time. But also, I have the code script which will explain you how to build or deploy a game server on Kubernetes. I'll also talk to talk you through another way of doing that using Agnes, which is an open source project. And I'll tell you the difference between doing the hardware versus Agnes way. And I'll summarize that, and we'll leave there. So within half an hour, I'll try to cover as much as possible. I have some simulation. I have two demos for you to look into and understand how the game infrastructure looks like. So intros, my name is Krishnichetanya. You can call me KC. That should be good enough. I'm a senior customer engineer working with Google. I've been with Google for the last four and a half years. Did a lot of roles in a random startup program in India. Moved to US, now working with enterprise customers. And their sales belongs to enterprise sales division. So that's me. Love working with startups. Love working with community. I love sharing what I learned. That's all about me. Now let's talk about the game infrastructure. So what you see on the screen is a typical, very high level game infrastructure. The way it looks like is you have multiple clients. It can be mobile, PC, handhold, whatever the client you use. You have a front end and you have a back end. And the front end have two components, game platform services and dedicated game servers. Dedicated game servers is a place where your game is actually deployed. Now analytics and game database is, again, at back end. Now, if you go deep dive into what is game platform services, this is where a lot of things happen, like leaderboard, matchmaking. So imagine I wanted to play a game with Abu Bakr. Now, we both actually join online. Someone has to match us for a game onto a dedicated server nearby so that we can play. So that kind of services happen on game platform. I mean, these combined together are called game platform services. This can be like online lobby, chat, inventory management, all the, you know, axillary services which you see on top of the games are kind of like, we can bundle them into something called game platform services. We have dedicated game servers. This is exactly where the game is actually hosted. This can be thousands, thousands of servers based on the game you're playing. It can be deployed in multiple regions. It can be deployed in multiple hardware, no matter where the game is residing on. Now coming to the game database, this is where, you know, game also comes with compute and all as well as assets. The assets are something where the images, the video files, all the assets which are like very heavy in size. They typically actually can be residing. I mean, you can create shared state where you can store the game assets in a game database and finally you have analytics pack. So where the query is, you understand what's happening within the game, the events within the game, all that information which are real-time happening can be captured in analytics pack. So these are like four major blocks. I just simplified a lot of gaming infrastructure for your understanding, but try looking at these are four foundational building blocks to build any kind of backend for a game server. Now this entire backend can be deployed anywhere. Like you can deploy it in on private cloud, you can deploy it on public cloud, you can actually do even make a fully managed solution. Doesn't matter. It's like you're running on Kubernetes, you can run it anywhere for this session. A lot of demos you will see, I created Kubernetes engine on Google Cloud. Just, it just makes my, you know, deployment easy, but you can choose to deploy that anywhere in any cloud or any public data center. I mean your own private data center. Now let's go through what happens when two players wanted to play. Now, this is kind of a traditional workflow where when two players, if you look at, I'm just turning on the laser pointer. So here are the two players who wanted to play a game. So there will be something called matchmaker who will decide who two players would be playing with each other or kind of match them, send a request to a service called a server manager, which essentially takes a game server from the machine cluster and then dedicate, I mean, send the request back to matchmaker, which will allocate two players on the dedicated game server. Now, rephrasing it, you send a request to matchmaker, matchmaker talks to server manager, server manager talks to machine cluster, dedicates a game server, I mean, takes out a game server, which is near to the players, send the request back, players directly connect to the machine cluster, I mean, dedicated game server, which the server manager decided, and then they start playing. Why don't you use load balancer and et cetera? Obviously, the latency is very, very important. The typical architecture of having a load balancer between clusters, all this doesn't work. So you need to think differently in terms of how two players talk, I mean, connect to a game. It's more like a server manager, some sort of code, which I would say the server manager talking to a cluster, taking the game server, sending it back to two people. That's how the workflow looks like. Now, the highlighted part on the right is what we need to concentrate on. What do we do to create a server manager, which will take a game server or how this deployment of cluster of game servers versus a server manager looks like? Now, I'm gonna show you a simple demo of a first bit of open arena, a game which I deployed on Kubernetes Engine. Now, the whole, there are so many constraints, don't look at this game as like a fully production game, but more or less a smaller version of a dedicated game server I deployed just before joining this call. So what I'll show, it runs one match, I mean, you can look at the constraints, it's not, what I wanted to showcase is this is not a production grade gaming, but obviously this is exactly what I just showed you on this screen, I'm gonna deploy that, I already deployed that and I'll show you. So before we go there, what is the step by step process of building this architecture? First of all, you can take open arena game server, you can set up, I mean, you can containerize it before you deploy into Kubernetes cluster and setting up a Kubernetes cluster, I did it on Google Cloud, you can, I had something called scale manager, scale manager is a service which will look into the cluster, scales the cluster if there is a huge load, that is an optional service, I did it because you just need to have that scaling on workloads, like you need to have more virtual machines available to you if the game is actually scaling. So scale manager is a service which runs on top of Kubernetes which will scale the cluster if at all needed and we verify the setup, we connect to the game server, we start playing the game. Now most of them is one-time work, setting up Kubernetes cluster is obviously done on cloud, we verify connecting to game servers, that's what we do it, like let me show you the script first of all, before I take you through the demo part. So I hope everyone can see my screen, right, like the game server, can see? Okay. As we can see your screen. Excellent, so if you look at the script for which the first time you install the tools, there are, I mean obviously the tools are Cubelet and Docker, you start actually downloading the game server from the storage which we have, once you have that, the second step is containerizing this. I don't want to go deep dive into individual commands but giving you a high level idea that this part is about containerizing and uploading it to content registry. Once you have that, this is an important step. As I mentioned, if you remember the first slide of what I showed you, there is a game server, game state and a game database. So the game assets has to be deployed on a storage which is shared with Kubernetes. So I created a virtual machine, attached a file, attached a storage file onto it and then, you know, cleansed, formatted the disk, set up my assets into it, deleted the virtual machine, had the disk ready, set up firewall network, created a Kubernetes cluster on Google Cloud and then attached the disk as a volume and volume claim. By the way, whoever is new to Kubernetes, think of it as a declarative programming way of, it's a container orchestration engine for containers. So what we are, for you to summarize the assets, volume is where the assets like the videos, audios, all that file assets of the game are located on. So I'm sharing that assets with Kubernetes engine so that I can start using them. Now the scale manager is something where, as I mentioned, I would use this program to scale my Kubernetes cluster, whenever it is needed, the nodes when it is needed. And finally, I deploy open arena using the Q, open arena which are already containerized, deployed R2 as my content registry. I'll go ahead and deploy. Let me show you my screen of where I deployed this. So if you can see my screen, this is a cluster which I created and here is, let me show you Kubernetes cluster. Kubernetes engine. So this is the cluster which I created open arena. If you look at, it has couple of nodes located in US. So now I've been running this before we joined the call. So what I did is if you look at, let's get the nodes, okay, let me show you. Now Qubectl pods. So you can see there are scale manager, which is running and there is open arena DNS, which is actually the node which, sort of the pod which is running. So this already executed and it's done. Now let's delete that Qubectl delete pod open arena DNS. Let's redeploy that open arena DNS pod again. Now let's deploy the pod again. If you wanted to see how the pod looks like, it's very simple. This is how the pod looks like. There is, it's talking to a volume claim where the assets are located and then starting actual in play is opening up a container with certain arguments, which says, hey, run this container, run this game server on a specific pod and make it ready. So it's a very simple service. Now if you go ahead and look at pods again, you'll see open arena running. Now let's do this. This is where my open arena is running. Now, so I just had open arena client installed and connect, let's connect to the server. It might be a small glitch, but you see it's connecting to the same server which I have and my game started. So let's exit the game. So this game is connected or running on an open arena cluster which I already deployed on Kubernetes, on Google Cloud and you can see the whole setup launching here. So if I delete the pod, imagine if I wanted to delete the pod again. Let's get the pods and let's delete the pod and let's start connecting the game again. You'll not be able to connect to the game. You see that? So what did we do? I'll just summarize the information again for you. I'm sorry, the console's open. Did I lost you guys? Can someone say hi? Yeah, hi. So what did we do just to summarize? It's impossible for you to like maybe reduce your resolution because there's some folks on the live stream that are seeing they can barely see the text. Sure, I'll expand that. So maybe I'll zoom it again for you. Yeah, thank you. Sure, thanks. So you missed nothing, by the way, if you don't even see the text because I'll share this script later, but for your information, what I did is I just deployed the game server. Like I just deployed, I just did the same steps. I containerized a game server which is an open arena game server. I set up a Kubernetes cluster, I set up a scale manager, I verified the setup, I connected to a game server and started showing you the connection directly. So it's a very simple task, step by step. This is how you can actually build a game server if you wanted to do of your own. And as I said, the Kubernetes cluster can be deployed anywhere. I chose Google Cloud. You can set up on your laptop, it can be done. Now the challenge with this kind of approach is if you look at the whole architecture, you're building everything of your own. You're actually building your game machine cluster, the server, matchmaker. The best part is you're getting all the benefits of Kubernetes, your parts are deployed, it's scalable, you can run anywhere, it's a hybrid cloud. Now what if I tell you there is a better way of doing this? So this is absolutely a perfect way of doing, but there is another way of doing that. So that's called Agonis way. Agonis is an open source project. Let me show you what Agonis looks like. Agonis.dev, so if you look at, this is an open source project dedicated to run dedicated games overs on Kubernetes. It was done by Ubisoft and Google Cloud. You can find all the kinds of examples, all sort of documentation on it, it's as good as a Kubernetes project. Now what Agonis does is, Agonis is a batteries included open source dedicated game server hosting and scaling project, which runs on top of Kubernetes. So basically what Agonis does is, if you are familiar with Kubernetes, it takes the controller part of it, creates a new controller for game servers, which it extends Kubernetes for gaming. So you don't need to do all that cluster deployment, it will do, I mean, Agonis can do it for you. Now, how does the game server looks in Agonis world? So the way a game server looks in Agonis world is obviously you take a game server application, create a, declaratively create a game server, and then actually send it to Kubernetes API. The benefits of that is, again, it can be deployed in hybrid environments, physical missions can reduce the cost, cloud bus can handle the capacity. Now, comparing that with the traditional architecture, traditional architecture, send them, it requires a matchmaker, send a request to server manager, server manager dedicates a game server, clients connect to the game server and you start playing. That's what we saw in our demo. Now compare that with Agonis, Agonis looks like this. Everything now is part of Kubernetes. So if you look at back and forth, there is nothing like, the machine cluster is only in Kubernetes, everything is actually outside, I mean components within Kubernetes. Now, if you look at Agonis architecture, now Agonis have, still have custom matchmaker. I'll talk about custom matchmaker in a while. There is another open source project called open match, which can do a better job of talking to Agonis and does matchmaking for you. But imagine you have a custom matchmaker again, now client wanted to play a game, like I wanted to play a game, I send my mission sensor request to custom matchmaker, Abu Bakr wanted to play a game, he sends his request goes to custom matchmaker. Now the request, the matchmaking is done there and the request would be sent to Kubernetes API. Kubernetes API will talks to Agonis controller, where Agonis controller will talk to a fleet, I'll talk about fleet in a short while, but Agonis controller will talk to a fleet, takes a dedicated game server, allocates a dedicated game server for us, send the request back to custom matchmaker, will custom matchmaker send that information to the clients and the clients connect to game server. Same process, traditional architecture, in an Agonis way, everything is Kubernetes. Now how you deploy a game in Agonis is very simple. By the way, before we go, how we can deploy Agonis has SDK integrations in different languages, have different functionalities. The reason why you need this kind of SDK functionalities if your game server wanted to talk to Agonis, wanted to integrate to Agonis to do a lot of activities, SDKs really help. So you can actually build your own, integrate your own custom game server with Agonis, start playing that. So it kind of gives you, it takes away the problem of you managing the entire cluster, Agonis does that for you. Your game server actually can talk to Agonis, can do a lot of functionality using SDKs. Now, it works across cloud providers, it does auto scaling, its auto scaling is very easy, it has local tool deployments and you'll have a dashboard and metrics for Agonis. This is how it's typical game server deployment, declaration looks like. So, let's take a first person shooter FPS game called Zanotec and if you wanted to dedicate or deploy a game server, you can now deploy a game server using same as what Kubernetes does. You can have a game server kind and you can specify the ports where the name obviously and you can specify the ports where the game server will actually open and run and the template of image of the Zanotec example, I mean, Zanotec game server, which you wanted to containerize and deploy. So previously, if you look at the script which I did, you do a lot of stuff for actually deploying, containerizing, deploying that, managing that and all that stuff, nothing. You just say, I want a game server like how you wanted a pod, you can say I want a kind of game server and this is my container, this is my pod and Agonis will be able to deploy that for you. So game server deployment is easy. Now, you want a fleet of game servers, you need multiple game servers, not just one. Now, you have another template called like another declarative way of creating fleet. So fleet is more like multiple game servers, same as how you look at deployment in Kubernetes. Fleet has multiple replicas, have a template where you can specify the ports and the template for image, which will run the fleet for you. So things boiled down to very simple. Now, the controller will be running that, running fleet, running game server for you. And the last one is game server allocation. Now, you have a fleet of game servers. Kubernetes API wanted to allocate a game server for you and send the request back to matchmaker based on whether the game server is available for connection or not. You don't want to delete a game server in which players are running. So these kind of requests are done using game server allocation. So game server allocation is another request which you can actually send where you will be matching with the name. The fleet, within the fleet, help me with a cluster image called Zonetic. You will be able to get a request, a game server back for you. So putting this together, it's the biggest difference what you have seen from traditional way of deploying is you don't need to do everything of your own. Your extending Kubernetes functionality to build something called Agnes, which is a cluster, which is again having a controller of its own which will do the job for you of creating a fleet, creating a game server, creating a fleet, and then actually doing multiple game server allocations and then give you the back request again. So everything is now handled within Kubernetes instead of you managing it of your own. So it just makes the backend development so, so, so easy. Now combining this with something called Open Match will give you much more advanced features. So Open Match, you can write custom logic within your console, custom logic to create or find compatible players. Agnes with Open Match running together can actually build, you can build a better game server within very short period of time. Now to summarize, obviously, the request comes to Open Match. You can write custom match logic within Open Match, talks to Kubernetes, Kubernetes talks to Agnes controller and Agnes controller finds a dedicated game server within the fleet, takes the game server, send the request back to controllers where the people, the clients get connected. Now let me show you Agnes script again. So let me show you Agnes before we go to Agnes script. Here is what, how you can deploy that in Agnes. So I have shown you a big script for gaming on the hardware. So Agnes script is very simple. Create a cluster and, you know, call the cluster, give a cluster a name. And this is, let me quickly run that for you. I know we are running out of time, but let me show you a demo quickly. So what we are doing is I just created a Kubernetes cluster, and deployed, installed Agnes onto it and then deployed a game, that's it. So three-step process, very, very simple. Rest of everything is handled by the scaling, the deployment of a game server, everything is the packaging of solution, and then deploying that, everything is handled by Agnes. So you don't need to do a lot of hard lifting on your part. So I already created a cluster. If you look at the, sorry, I already created a cluster called Agnes demo cluster. I'm just reusing the same for this demo. And let me create a firewall. I mean, this is a tricky part because obviously I need to dedicate, open up a port with a firewall and then deploy Agnes into it. Okay, now let me go to boot engine. So this is a simple game. What it is doing is I am gonna send a, whatever I type, it will send me back the request. So it's a simple server, game server running on Kubernetes cluster, on Agnes, that we created. So let me open a virtual machine and then send a request to this terminal and see what it does. I have five more minutes. Just give me a moment. I just wanted to show you this demo and we can close this. So meanwhile, if you have any questions, maybe I'll start answering them and then I can show you the demo before it loads. Any questions? I don't have any questions from the audience yet. You can probably go complete what you want to do before. I think I have a particular question I need to ask. I'm sorry, you have? Yeah, you can complete the rest of the demo first. Sure, sure. So this is what we did. I deployed a service. Now let's open a virtual machine and start pinging the cluster and see what it does. Okay, and this is where we are. This is where I always pray to God and see whether it works or not. First demo works perfectly. Now let's get the game server. This is the IP address on the port which I need to get connected to. And let's call this and see type in new. Okay. So I'm actually pinging the game server. I'm actually deploying. So if you observe this, let me zoom it a little. So if you observe, now I can say cube CTL gets game servers. Game server is another declarative but if I install organize, you will get game servers as another type actually. So I'm saying, hello world. Okay, it has a community. So you can see that I'm actually playing with, I mean, I'm able to ping the game server on a UDP port and then get the request. So if I wanted to shut down the game server, I can do that. I can say exit. And if you see the game servers, you'll be seeing it is getting shut down. So essentially what we did is I deployed a game server. I installed organize. I deployed a game server on top of it. I connected to the game server and then started actually playing with that from another virtual machine. So to summarize, the component is like the agonist way of doing this, again, clients request and agonist will do the fleet management to get the game server back to it. So this is what the two ways of like, if we go back to our agenda, what we discussed so far is to summarize. I explained you the game server, then I explained you how you can build the game from scratch by creating multiple services, like by containerizing game server and then deploying on Kubernetes cluster. Then I showed you the difference between that and agonist. Agonist is an open source project and how it is differentiates, how it extends Kubernetes API to give you much more functionality and how there is an SDK integration where your game servers can work with agonist and then explain to you multiple terminologies in agonist. There are a lot of examples for agonist. You can build, you can start playing a lot of games by deploying that. That is, you can play zonetics game on agonist very short time. All the examples are there in GitHub and you can find more information at agonist.dev and if you wanted to, I can actually share the script for deploying games over without agonist also and you can compare and contrast these two and understand how the game server works. So this is, I'll stop here and write out of time but over to you if you have any questions or else, this is it. Yeah, that's awesome. I think what we'll be looking forward to is sharing the scripts and your slides so we can share to the community. We'll send it to everyone that is VP and also when we are uploading your video online to also share the scripts and the first that you shared. Thank you very much for your time and it's been awesome having you. Thanks, thanks everyone. Thanks for your time. Yeah, I'm ready. Sure.