Godot Multiplayer Server Structure Tutorial | Godot Dedicated Server #2

in this second part of the godot multiplayer series we're gonna be teaching you how you can structure your server site functions in a maintainable and manageable way and at the end of the video we'll get into some valuable community feedback on part number one and some questions let's get started so let's first do a super quick recap of what we did last episode and then expand on what we have already so right here i got the i spear script and the isp when we cast it needs to retrieve the damage it should be doing which is stored on the server we're calling the server that is the autoload singleton which is still on the client which is the interface between the server and the client itself so on there we have two functions one to send the request for information to the server through an rpc id call and we have a remote function that is going to be taking the returned skill damage and then pushing that to the original requester when we look at it from the server perspective we have one function for this interaction between client server that's one remote function which is going to be determining what information was requested and by who is going to be determining what that information is and then it's going to be sending that information back now when we look at maintainability and manageability we basically look at manageability how easy is it to make your game and manage your code and keep adding on top of it and the main tab ability is whenever a bug appears whether it's during development or after development specifically whenever something maybe an os android ios something changes and that introduces a buck in your game then you have to hunt that bug down and that is the maintainability so after launch of your game we want to make sure that those two are as high as possible manageability makes your project run shorter maintainability makes that your product that you have spent your blood sweat and tears on stays concurrent stays up to date and stays playable once it has been released into the wide world of the internet so with that said let's first have a look we're back on the client here let's first have a look on the client side for every interaction between the server and the client you're going to get two functions a fetch function and a return function that's how i call them you can call them differently if you want to but that's how i make sure that i recognize everything these two functions are basically going to be as lean as they can get and they are already as lean as they can get we don't have to change anything here because the fetch function is basically going to be one line of code doing the actual rpc id call and then we have the remote function that's going to be take the return value that's basically one line of code that's going to be sending it wherever it needs to be sent super lean super easy manageable and maintainable so now when we switch back to the server on the server things are a little bit different as just mentioned we have one function on the server for every type of interaction between the client and the server that consists of three parts and the middle part being the actual retrieval or determination of the information requested in this case how much damage does the ice spear do right now that's one line of code but we can easily imagine complexities that not are not aren't even that complex that would add more lines to this how much intelligence does the player have as a additional factor or modifier of that damage how much magical resistance does the enemy have for that specific skill or that specific damage type all kinds of things which would be very common for a game like this that are not in here yet but that will add more lines of code on soul whisper the game that i'm developing myself i got one combat simulation function that's about 500 lines of code on the server i wouldn't want this interface here to be clogged up with 500 lines of code on a single function on a single interaction so what you would want you want to make sure that this script just like the interface script on the client stays as lean as possible as we have as much overview as you can possibly get so there's two ways that you can go about that i'm going to teach you both the first method is to make sure that we have more nodes on the node tree to add scripts there and to make those script calls in uh in the function here to make sure that we place that code somewhere else when we go to server we simply add a child that can just be a normal node which we'll do in this case and we're going to rename this to something logical now don't add that's my advice a note for every type of function because before you know it you've got 50 60 70 100 200 no's here for different functions that again is not going to keep your code manageable it is maintainable not manageable so i would suggest that you make this topical or with themes depending on what kind of game you're making i'm requesting damage for a skill that is usually combat related so i'll call this the combat note i'll add a script to this um by just using the shortcut for that or the button and on here we'll be adding this super simple function i'm using exactly the same function name as the original requester uh was on the server interface we only need the skill name in this case this line of code is exactly the same as on the interface script and now we're returning the damage the the value that was determined right here we're going to be returning that to where it was originally requested now when we go to the server we can replace this oh that little piece there with a get note and we don't have that many so we'll choose combat and we'll pick the fetch skill damage and we're going to be pushing the skill man to it now as you can see i'm keeping the var damage is part here because we do want to determine what that damage is so that then we can send it back to the actual player so the damage is going to be determined by the returned oh that's the wrong script by the return value damage that comes out of this script so this way if this retrieval of information were to become more lines of code because of more complexity 5 10 20 100 lines those lines of code are now going to be here the return damage is going to be all the way on the button of that function and the server interface script stays nice and lean with only three lines of code ever okay i have undone everything we just changed so now we're back at the starting position i'm not going to be teaching you the second way the second way is almost exactly the same as the first way the only difference is that instead of adding nodes here to the main node of the server we'll be creating an autoload singleton for these theme scripts so i've got this extra file here scripts i'm going to be adding a new script to it i'm going to be calling it combat stay with that theme we're gonna go to project project settings under the auto load tab i'll navigate to my scripts folder i'm already there i'm gonna be selecting my combat script and adding it as an auto load singleton on the combat script i'll be adding exactly the same function as we just added a moment ago on the other script under that child or server so with this we can now go to the server and instead of doing a get note combat call we're simply going to be calling out the singleton as combat and then we run the fetch skill damage and we run of course our skill name that way it's now going to be requesting that information through the function that lives on the autoload singleton and if that function ever needs to be expanded we're expanding the code base of that autoload singleton and not of the interface for the client server interactions so which one is better option one or option number two well actually there isn't that much difference between them even from a performance perspective the difference is neglectable you don't really have to worry about it both are good options to structure your server and it's really personal preference on what you want to do as you can see i've now rolled back to option number one and i do that because the one advantage this has is that it has a little bit more in-plane view kind of a characteristics the auto load singletons are a little bit more hidden now when you program your own server that's probably not going to be an issue because you're going to be so deep into your server code that you know everything you know it's like your own backyard before this tutorial series it's probably handy for everybody to have that lit there in plain sight so everybody can follow along with what we're doing here now talking about performance just a moment ago and the difference between the two there's no difference between these two or not really anything worth mentioning talking performance of the server in general if you ever worry about your performance while you're coding your server don't that's my advice what you want to do with your server is you want to code it make it functional you want to implement the mechanics of your game and then once you're ready for stress test that's the moment that you'll figure out which parts of the code of your server need work need to be improved now even once you have done that you'll figure out quite quickly that 10 to 20 of the functions on your server are going to be responsible for 80 of the load basically the burrito distribution by mr burrito is going to be applying to this as well what you could do with those 10 to 20 of the functions is you could pour those to c plus plus c plus plus is much faster than gd script at the moment it might improve in the future with gd gdscript but for now c plus plus is way faster so if you have 10 to 20 of your functions that you feel like need some extra love once you are past the stress test and that might take you a long while because it really basically means you have coded the majority of your game and you found some testers to actually do that stress testing only at that moment really worry about that performance and try to focus for now on actually just getting the mechanics that you envision to get those into your game now on to server structure in the last episode i pleased you to just keep calling your main node of the server server and to keep calling the singleton on your client server as well and i haven't actually explained why i said you should do that but after tutorial was already 41 minutes i thought it's better to just save this for the second one so what actually happens when the connection is made between the client and the server and when those rpc calls are made is that the rpc calls are going to be looking for exactly the same node structure so what happens from the client perspective and i currently have my client running as you can see right there the game is running so i have this remote option available here and when i go there i can see the currently loaded node structure you can see that here we have the root of the game and right here we see the scene handler with the map scene and the player on here somewhere these two right here game data and server these are the auto loaded singletons now the server interface is right here on the server autoload singleton when we do this rpc id call basically what it does it says root server fetch skill damage and that path is going to be um added to the to the function call that fetch skill damage that path will be added on top of that when it's sent out to the server so when we look at the server we need to make sure that that path is identical as we are now here on the server as the main note the server is running as well as you can see the big gray box again if i go to remote here you'll see again we have root server data which is the autoloader singleton on this one and then we have the server the server in this case is not an auto load singleton but because it's the main server of this executable it is in exactly the same position as the autoload singleton is on the client side in other words the paths to the node server and to the auto loaded script server between the client and the server is identical and that is crucial for your rpc i call id course to arrive in the right script now in the previous parts when i was explaining you option one and two you might have been wondering can't we just call the combat autoload singleton or the combat node underneath the server straight in the rpc id call thereby cleaning up our interface script even further and therefore the answer is no we can't because the only way we could do that is if we add more child nodes to this interface but that would defeat the purpose of having an interface script so the interface is always going to be root server that is where all the connections are going to go left and right and you can't access the nodes in between there therefore we push the information on the interface from here to the original requester of information and that's why on the server we basically have to receive the request and push the calculation request or the request for information that we have coded on either a child or an autoload singleton that's why we still have to push that through so basically the interfaces are just you know communicators they're the messengers of of the the various rpc id calls but we need them to be there so that the rpc id calls can actually communicate with each other now over to some awesome community feedback in the last episode i told you that every time you make a server change you would have to go to project export you would have to export your server because we can't run both the client and the server through the editor because the output is showing all kinds of artifacts and we only have one output because we only have one output bus that can't run parallel well guess what i was wrong i'm learning too and thanks to scott and thomas parker in the comment section we now know how to do this once you got both of your editors open go in one of your editors to editor editor settings scroll all the way to the button and on the network debug you can change this port value right there normally the ports on both of these editors will be 6007 if you change one of them then the output will be routed to the right editors and you can run both client and server through the editor while you're developing cleaning up your production pipeline talking about port numbers we got another great piece of feedback from ctn fargo over on the discord channel of game development center if you're not on the discord yet we've got a group of over 200 game developers and new people are joining almost every single day learning godot together don't want to miss out on that city and falco said that the port numbers are kind of important to mention and the port numbers he was talking about is the actual port number you use to connect the client and the server together and he's totally right because there's some important information on that because you might be wondering can i just pick any number there do i use to have used at 1909 that i'm using as well well no you don't but you can't just pick any arbitrary number there's actually a wikipedia page on this and that's called the list of tcp and udp port numbers the first 1024 numbers are well known ports and you wouldn't want to be using any of these so don't use any number that is lower than 1024. these are basically reserved port numbers and very often firewalls will block the connection if you would try to connect a server and a client through these port numbers so don't use these then when we scroll further down you see that you also have a lot of rigid port numbers some of these port numbers are officially registered and some of them are unofficially registered what this basically is that various applications have communicated that they use a specific port number and when you connect your server and your client that application if installed on the device that the client is using that the player that you have sold your game or who has downloaded your game is using it might interfere with the connection between client and server now it's very hard to test on this unless you do massive stress tests with a lot of different testers who use all kinds of systems that have a lot of different applications but you can never catch everything and it's only a very small effort to pick a number of this list which is not listed so what you want to do you want to scroll through this list and you basically want to pick a four or five digit number that is not on this list yet that should make you reasonably safe safe enough with reasonable reasonable assurance that there's not going to be any interference with any other software that might be on the client's device that your player is playing on and as you can see there's many gaps here we're jumping from uh 4791 all the way to 5840 that's 49 numbers right there that you could use so pick a four or five digit number from here and be happy the last exciting news that i have for you is that i've activated the channel memberships on the game development center's youtube channel so to all of you who've asked me in the past do i have a patreon how can we support you in creating more of these tutorials now there's a good youtube integrated method click that join button down below next to the subscribe button don't worry nothing happens at that point yet all you're going to get is a pop-up with the information on how you can support me in creating more of these tutorials for the golda community if you like this video please 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 episode in this goldup multiplayer tutorial series in the next episode we're going to be having a look at player authentication how can we make sure that the player logs in with an account name a password then we push that to the server there is a verification process there and that the player is not allowed on the server if the account name doesn't exist or the password is wrong so stay tuned for that should be up next week

Channel: Game Development Center

Views: 13,396

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

Id: KC0PuGB98SE

Length: 18min 48sec (1128 seconds)

Published: Sat Sep 19 2020