Godot Multiplayer - Network Architecture | Godot Dedicated Server #5

in this tutorial i'll teach you various network architecture solutions for your game server we'll have a look at various real games and how they have approached the problems and we'll take a look at the various bottlenecks that you need to consider when choosing one of these solutions as well as the bottleneck that you need to consider when you choose to instance or shard your world let's get started game development is super cool however there's also a couple of topics which are a little bit more on the boring side and i'm afraid that this tutorial covers one of those so there's going to be a lot of talking powerpoint and still standing images in this tutorial so that's a warning for you i hope you sit through this one so that you can make this knowledge your own and implement it in your multiplayer game so let's start out with the bottlenecks that we may encounter when we're designing for our network architecture the first one is the ccu or the concurrently connected users we talked a little bit about this in episode number one of this tutorial series that the servers we're programming in this series using the network multiplayer in-app notes of godot can handle up to 4095 concurrently connected users that is a hard limit we have to design around now that limit is just applicable to any kind of game server there is some rare situations out there with a lot of customization and optimization that a server can handle maybe up to 25 000 players but you won't see much higher than that and usually the upper limit is about 10 000. that is not a problem we simply have to connect several servers together to create room for more concurrent players now the number 4000 is rarely the limit that you are going to be encountering because there is a limit that usually pops up much earlier and that is the second bottleneck the second bottleneck is the rps the requests per second that the server is able to handle from a performance perspective getting a hold of this number and what that is going to be for your situation is a little bit harder because not every request is made equal one request could be as simple as setting a variable on the player account another request might be shooting a bullet that requires the simulation of physics to determine where it's going to impact to request but very different in their server load or the amount of calculations necessary to determine the outcome now we have to keep in mind that the maximum amount of requests per second is adjustable by us what we can do is we can increase the server hardware get a cpu with a faster clock speed get more memory or get more cpus and make use of multi-threading also the code optimization that we can implement making sure that our code is as easy on the calculations as possible or even if you're considering to go one step further you could opt to take some of the most performance intensive calculations or functions on your server and convert them from gd script to c plus plus as that currently goes much faster than gd script now you may be wondering how is the rps ever going to be a bottleneck sooner than the ccu to illustrate let's take two games and compare them on one side we'll take farmville an idle game and on the other side we'll take pop g a mobile fps when you're walking around in pub g your position your player position is going to be updated tens of times per second to the server so that the server can then update your position to the other players now what we're most interested in is not how much request the server is going to be receiving by all players but what we're interested in is the average amount of requests a single player is going to be doing per second so we have already tens of times per second the player position then whenever you use items kits med kits red bulls and whatnot the server is going to get requests when you're driving around creating all kinds of physic coalitions and where you're shooting all of that is related to a single player and will also be requested to the server so with all that in mind let's take an arbitrary number and say that the average player in pub g makes a hundred requests per second to the server now with that said let's now have a look at farmville in farmville i believe you can visit your friend's farm and in that case i do believe you have like two players walking around so we also have to update those positions to the server however maybe only five percent of the player at any given time in farmview is visiting a friend's farm most of the time they'll be looking at their own farm and simply clicking harvest and crops and milk the cows and i don't know what more the amount of requests per second is mostly going to be limited to the amount of clicks a player is able to do on his farm that means there's much fewer requests to the server per player per second than in pubg now of course we would also have to compare the kinds of requests and i expect that the requests for farmview are likely to be lighter because there's no single physics or anything related to that however just for the sake of simplicity let's say that the type of requests and how difficult they are for the server are equal still we're looking at maybe 10 requests per second per player for farmville and 100 for pubg now let's say that the server with all its calculation power is able to handle up to 100 thousand requests per second that means that we could based on the rps accommodate ten thousand farmville players but only a thousand pubg players now with pubg being a hundred 100 players per battlefield that means you could instance 10 battlefields and then your server is full not because of the ccu but simply because of the calculation power of your server and otherwise your players will experience a lot of lag for farmville on the other hand you see that we can handle much more players regarding rps and ccu becomes a problem for us so in that case we can either go with a different kind of server that might be able to handle more ccu or we can go really cheap on the kind of servers we got or simply run more instances of that server on the same kind of server hardware so these are like examples that you need to consider when you look at ccu and rps and how you're going to code your game when different instances need to come alive and also where those instances on which server hardware or which cpu core are going to be running now thirdly the last bottleneck is not related to server hardware or networking but it is a very important element to consider when you shard or instance your world which is something you have to code in your load balances that are going to be on top of the network architecture so i did want to mention it here that last bottleneck is the number of players that your map or your world is able to support and let me illustrate this to make you understand this let's say you have a map a plane of 10 by 10 kilometers and you put 300 spawn points on there let's say that these spawn points have half a second of respawn time allowing a player to simply stand next to it and continually kill that enemy and loot an experience and all that other good stuff now this is not a great player experience but in this situation your map will be able to accommodate 300 let's say hunter type players now we may add some resources and some quests to this map increasing that number a little bit but we also want to make sure we have a good player experience so let's say we randomize the spawn locations and we randomize the spawn timer and now you'll see that players need to maybe walk a small circle with a troll path and maybe they'll take care of six spawn points to ensure they have a continuous content that they can chew through in your game now that means that from those 300 hunter players your map was able to accommodate a moment ago suddenly we can only accommodate 50 players of the hunter type now combined with those resources and those quests you may be able to accommodate 80 people on your map but let's say we get player number 81 or 82 or 83 the moment we get more players and the content on our map is able to support the player experience of all the players on that map will deteriorate because everybody will start to experience that there's not enough content for everybody and everybody experience is going to be worse for that so the amount of players that your map is able to support the amount of content that is on there is an important design element for your network architecture because that will determine when you have to start instancing or sharding your world so now that we have the bottlenecks out of the way let's start looking at some of the network architecture solutions that you could implement in your game now i will be using a couple of example video games to better illustrate for education purposes but i can't be a hundred percent sure that the back end of these games is indeed programmed like that i only saying that it could be programmed like this so a little bit of a disclaimer there the first network solution that you may opt to implement is the network architecture you see right here and it's the same network architecture that i presented to you in episode number three of this tutorial series let's have a look we got three different servers which are all incensing the same world that you have created so we got world one two and three each of these worlds have their own database which allows these worlds to develop separately from each other the advantages of this architecture is that whenever you're running out of space for your players you can very easily add another server instance world number four with its own database and you'll be able to put players on there which will then be able to develop that world also when one of your servers goes down you don't affect the entire player base but only the players that are on that particular server downsides are definitely here as well because the worlds can develop separately from each other there's very often very little interaction possible between the various players at most you're going to have a global chat but finding your friends if they're already playing the game on another server is going to be near impossible also a disadvantage is that when one server has developed and the players are of a higher level but then some of the players get less interested and are moving away from the world the world may be experienced as very empty and putting new players on that particular server might be hard due to the gap between the new players and the all players so it's a solution it's great for scalability but it's not great for player interaction let's move on to solution number two now the second solution that i'm going to be presenting to you is basically taking solution number one as the base what we changed is that instead of having various databases we're going to be combining all the databases together into one database this allows for a lot more player interaction so that you can find your friends if they were already playing the game very often what you'll see is in the login screen you can select the world that you want to join the disadvantage of this though is that you are less free in the kind of features that you can put in your game usually these games are a lot more living in a world kind of games instead of being able to influence the world kind of games in the previous example where you had separate databases we could allow the players to have permanent effect on the map for example destroy a building and the building is gone however with the instances if a building is destroyed on one instance but players are able to transverse different instances it would be really weird if in one instance that building is there in the other instance it is not so the amount of permanent influence that you allow players to have on the world is usually very limited however if that is not a feature you are planning for your game in the first place then this could be a fine architecture to implement while allowing more player interaction for solution number three we're going to be combining the advantages of solution number one and two together in a single package solution number one having the permanent influence on the map and solution number two having the player interaction in the entire player base possible in order to do this we have to reduce the number of truths what i mean by that is that every world we instance is a different truth about how that world is going to look if we allow the player to permanently influence it so we need to reduce that number to only one world one truth in order to do that we're gonna cut up our map into different regions and we're gonna make a server responsible for a particular region that way we're still spreading out our concurrently connected users and the requests per seconds that are each server needs to be able to handle now of course this doesn't come without its disadvantages this is going to have a serious impact on the scalability of your server network architecture in the previous solutions one would simply be able to add another server and instance another world on top of it right now we could add another server but we don't have another region we would have to recut our map world map up into four regions or five or six before we would be able to assign particular servers to a particular map again so that is going to take more downtime and more work from you as a game developer a great example of this in the real world is eve online in eve online you have about 5 000 different star systems and star systems with a historical high player activity have their dedicated servers assigned to them while star systems with a lower player activity are bundled together in clusters and then assigned as a cluster to a server the fourth network solution and the last one i'll share with you is when that bottleneck number three comes into play the amount of players that your map is able to support if your map runs out of space for the player then you have to instance another version of that map now that instance can be run on the same server if that server still has headroom in terms of concurrently connected users and rps but it could also be the case that server is full also from a technical perspective and you have to add another server to then take care of that other instance of that same map a great example of this is world of warcraft where the soft cap is usually about 80 to 120 players depending on the map soft cap in this case means that when you are a party member of a party that is already on that map you can still join that map and the game will allow you but the hard cap which tends to be around 150 players for a single map in world of warcraft is when simply no other player is allowed to be on that map anymore now this of course allows you to have smaller maps which is great from a game design perspective because you don't have to create immense maps that are super big and it is just going to be taking you a lot of time and that will create also a very big game package to download the downside however is because we are reintroducing instances and therefore reintroducing various truths it is again very hard to create permanent player influence on the map so from that perspective it is limiting you again in that element well guys that was a lot of talking and i hope that this has given you a better understanding of how various network architectures work and how they can influence your game and the game development process now these four solutions are of course not all solutions out there and these four solutions are more geared towards rpgs and maybe the first one to idle games if you are creating a better royale game that is going to be looking different again however with a battle royale game you usually have a lot more fixed parameters and you only have to instance that map for a short period of time usually making things a lot easier i can imagine that after hearing all of this you want some advice or just a healthy discussion which network architecture may fit your game best the best advice i can give you in that case is to look out for another group of game developers and just have that discussion with them if you want to have that discussion with the game development center community you're more than welcome on our discord i hope to see you there that was it for today guys hope you like it if you did smash that like button hit subscribe don't forget that little bell icon to make sure that you don't miss out on the next video if you want to support the tutorial creation here at the game development center we got something a little bit like patreon but then right here on youtube go check out that join button down below to see the various level that you can support the channel at and the benefits that come with that thanks to all of you that have already chosen to do so i hope to see you next time on the next tutorial and until then keep on gaming keep on coding see you later guys

Channel: Game Development Center

Views: 4,768

Keywords: Godot Multiplayer, Godot Network, Godot Network Architecture, Godot Multiplayer Tutorial, Godot Multiplayer Network, Godot Server, Godot Dedicated Server, Godot Multiplayer Server, How to make a multiplayer game, Godot MMO, Godot Beginner Tutorial, Godot 2d Tutorial, Godot Tutorial, Godot

Id: Xua4QXd2C_s

Length: 17min 39sec (1059 seconds)

Published: Sun Oct 11 2020