Godot Multiplayer Tutorial - Spawning Other Players | Godot Dedicated Server #10

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

Thanks for this, I've been working on a multiplayer card game and it's been hard to find tutorials that go further than a basic example that assumes everyone is on a LAN. I'll definitely spend the next day or two watching the series, maybe it'll help keep me from coding myself into a corner again :)

šŸ‘ļøŽ︎ 4 šŸ‘¤ļøŽ︎ u/DownvoteHappyCakeday šŸ“…ļøŽ︎ Nov 23 2020 šŸ—«︎ replies
Captions
in this goldup multiplayer tutorial i'll teach you how you can spawn players into the map so that the players can see each other let's get started before we can start spawning in players we need to make sure that our scenes are ready we need to make sure that the map has a container that can receive these players and we need a sort of a player template that we can spawn in for every other player which is not the player itself so let's get started with the map i'm right here on the map scene where i have my tile maps i got my y swords my trees my player and the enemies which in this case would be the mobs the npcs and under this y sword i'll add another child note that will be a y sword and i'll conveniently rename this y sword into other players so we have a place to spawn them and they'll be y sorted with the rest of the assets now we need to make sure we gotta play a template so let's move on to that now for the player template we can make use of the player scene that we already got both players can do pretty much exactly the same else we wouldn't have an equal game so we need exactly the same note structure or almost we need to make a couple of slight changes the first thing i'll do is i'll duplicate the player scene so i have two separate scenes both for other players and the player itself so we'll duplicate the scene we'll call this scene player template and we'll have it right here make sure you open it and that you adjust only the player template scene not the player scene as you're gonna be in for some surprises under the player template scene we need to make a couple of adjustments first of all we don't need a camera on other players we only need a camera on ourselves so we're going to be deleting the camera node out of the player template scene now we also want to recognize these different plays at least while we're testing it we can't have yet or we won't program yet that we see a visual representation of the equipment the other player will wear we'll need a lot more data for that but let's at least make sure that we can differentiate between one and the other so i'm going to select the head sprite this is a stacked sprite sheet and you can see here i have the hat i have the off hand i'll have the main hand and i have the armor so for the head sprite i'll go to the visibility stats right here and under modulate i'll give this a little bit of a red color so our other players that will spawn in will have a red hat now with that done we currently have the player script still connected to this player template as we copied it from the player scene but a lot of this code is not necessary for the spawned in players in fact if we were to leave this here we'll see both players move at the same time when we're moving our own character which is the last thing we want so under the player here i'm going to be removing the script with the delete script button right there and at the same time i'll rename this oh if it wants to cooperate i'll rename this to player template so i have more indications whenever i'm working in which scene because these things are going to look so familiar to each other we've got to make sure that we're working in the right scene right we're going to do another couple of things right here we have the layers for the coalition and of course these are copied from the player but we want the player and the other players to be able to bump into each other so we need to make sure that they can see each other so this player doesn't have to see anybody because we're not going to be programming any movement on the other players those will be moved by the other players behind their clients and then the server will tell us where they are we're not going to move them ourselves so we don't need any masks on this player we don't need it to be in the npc layer either because basically that's what the server will decide who is attacking where and colliding where we only need to make sure that our player can see that player so that they can bump into each other so with that said camera removed layers adjusted the head adjusted the script gone the scene renamed um and of course we can also add a script here we're not gonna do much with that yet in this tutorial but have a place to start storing some code in the next couple of tutorials that are coming up so that's done we have a player template now i guess we're ready to spawn in some players now the only place to know when we have to spawn a player is of course the game server when another player is actually making a connection to the server so i'm right here on the game server in the network architecture and i'm on the main game server script which is the interface with the player right here we have well when i pair disconnects to start with we are pretty sure we have to despawn a player at that point and also when we have the verification results that we are sending off to the player we can also say that well okay if we have a positive verification result on the token level which is the last step in logging in then we're pretty sure that we need to spawn a new player for now we don't have a player location yet as we don't have any world state or player state from the other players yet so for now i've hard coded in this vector which will replace in a future tutorial with a player position that actually comes from the server so that's for later for now hard coded so that means that we're going to have two functions the spawn new player and the dspawn player which needs to be programmed on the interface on the other side on the client so switching to the client we now have two new functions we have the spawn new player and the spawn new player the spawn new player receives the player id and the spawn location and the dspawn player also receives that player id that player id is not the id of actually this client that is the player id of the player that actually logged in because we got that player id from the return verification results which would be for any player logging in so that's an important thing there these two connections are made to the map scene so we are pushing these functions forward to the map scene because the map has to be spawning them in so that's a logical place to put the code so going back to the actual map scene right here i've added a new script on the top and this is pretty much all i'm doing currently because it's of course to a very simplistic game only to demonstrate these multiplayer functions to you i'm preloading on the top that player template scene that we've just made then i have the function new a spawn new player and a function d spawn player for the new spawn player we're first going to check if the received player id is equal to the peer id of this player because of course this function is also going to be firing when the player that's actually logging in that's going to get that function as well and we don't want two players of the same player because then we would have like a sort of we'll be ghosting ourselves i guess sort of so whenever the player id of the player that's logging in is the same as this client's pair id then we know we have to pass we have to let it go we don't have to do anything because that's ourselves logging in in any other circumstance that's not equal it means that it's another player logging in we create a new instance of the player spawn we set the position to the spawn position which is now that hard code coded vector2 we rename the node so that would be actually that player template right there that name on the top we rename that into the player id by renaming that into the player id it will be very easy to reference this particular note in the future when we have to update the position of this player whenever we get a new world state from the game server what a world status we'll get into in a moment then we're going to get the note y sort other players that player container or other player container we create at the start of this tutorial and we add the child pretty easy when we despawn a player we get the player id again of the player that has been disconnected and then we are simply going to get the note y sword other players we find that particular player representation that template and we free it and that's pretty much all there is to it now of course uav wise asks for demonstration so let's do that the game server the authentication server and the gateway server are already running in the background so i'm just going to hit press on this client and log in with this player account that i've created for this demo i'll drag this window over here then i'll go down and open up another godot instance i'll open up another client and with this client i'll hit play as well we'll make that smaller we'll make that smaller and now you can see whether the player is going to be logging in there of course i have to make use of a different user and i'll log in now as you can see we have an issue because right here we got the second player with the red hat spawning in and we can walk around here and well have fun and we'll bump into this player because we set those collision layers but right here we don't actually have that second player the person with the well let's say brown hat is of course the player itself now they're not in exactly the same location because i've changed the spawn location right here hard coded so that's why their location is not on sync that's expected but the problem is we don't see the other player so that's the elephant in the room let's address that right now this player is already logged in and it's listening for any other player logging in but the moment we actually make a login we also have to retrieve all the players that have already logged in before us that are already populating the game world and we're not doing that right now in order for us to do that we'll need the world state we need a list of all the players with their positions and all the other stuff and that's pretty much where we already get into how are we going to build this world state which is probably the next tutorial so right now we're not going to do that in this tutorial but it is why you see these differences and it indicates what we're going to be doing in the future we have similar issues because when we kill this weber here this where that on the other player doesn't die and this player can kill it as well that's because that wear bear is governed by the client it's hp is on the client position is on the client everything is on the client and that's of course not what we want that weber is supposed to be living somewhere on the game server so one player kills it the world state is updated and other players can see it die as well so i've mentioned world state a couple of times i've mentioned future tutorials a couple of times so i think it's a good moment to explain to you how how we are going to get those world states what exactly we're going to do what you can expect in the next couple of tutorials and then you'll probably understand why i don't do it all now right here because things are going to get well complex because this is multiplayer you didn't expect it was going to be easy right so with that said let's have a look at the diagram right so this is pretty much the situation we are in i've taken out the authentication server and the gateway from the network architecture diagram because once we have a connection with the game server that's pretty much the two entities we're dealing with so to start off this world state and syncing of location of players we're going to start with a client they'll have an outbound signal that is going to be communicating the player state to the server we're going to sync that with the physics process engine so it's going to be send out about 60 times per second on top of that we'll do a local execution of the movement code so the player has a smooth feeling of a smooth response as soon as he presses any buttons or moves his bass player character so with those outbound signals the game server is going to be receiving these signals it's going to be receiving all the player states plural because of course we're going to have multiple clients connecting to one game server it's going to be receiving those signals 60 times per second minus any possible packet loss and we're going to be saving that into a collection the reason why we save it into a collection because we're going to kind of process it as these states come in it could be that the client 1 is sending it on one particular millisecond and then the next client is going to be sending it one millisecond later because the physics process engines of all the clients are not synchronized now these signals are going to come in random at any millisecond and if you have 100 players connected to that game server the game server is going to be receiving signals pretty much every single millisecond so if we were to process all of those signals as we go then the game servers pretty much has to do things every single millisecond instead of 60 times per second says a thousand times per second instead of 60. and 60 is even way too much it's not necessary so we're going to be doing 20 times per second and because we do it 20 times per second we're accounting for possible packet loss like i stated here there's chance as there's packet loss so basically the client has free chances to get a packet through which is more than enough like packet loss tends to max out that about two percent in normal circumstances if you get much more than that then there's definitely something wrong with the connection so there's more than enough time to collect um the states of the player if the player sends a state well there's already a state an unprocessed state in the collection and he'll just override that and whenever we are processing the collection 20 times per second we'll just take the most recent states we have received from all the players and we'll start generating a new world state so with that said we are going to be processing states in the collection into a world state and will also retain a history of a number of world states so that we can go back in time for lag compensation that's a more complex topic that we'll do at the end of this series probably so with that done now we can have an outbound signal from the game server that is going to be communicating the world or chunk states that's an option here if you got a big game you of course don't want to send to every single player every single other player's position because maybe some other players are kilometers away and that that packet this world state is of course going to be much much bigger than the packet that is unbound here right here is a couple of variables player position player rotation and maybe some other things but not much when you have the outbound signal here going back to the client this is going to be the rotation and position of every single other player every single mob maybe even every resource note which has been mined or not and maybe some other things that you know we have to make sure that that's all communicated so we're going to have an outbound signal that's gonna go to the player and that player is going to buffer it and that is really important because you may have been wondering well if we do this 20 times per second isn't it going to get laggy well yes if we wouldn't compensate for that so we're going to be saving these states in a buffer so at least the current state and the next state and we might even do the previous state as well if that is necessary we'll figure that out as we go now with that buffer what we're going to do is we're going to render everything which happens in the world state with 100 milliseconds in the past basically so the client will always see whatever happened 100 milliseconds in the past we'll make sure through this method that there's an as high as possible chance that there's always a future state in the buffer for the client to interpolate between now that's a lot of difficult world or words so let me explain it a little bit basically what we're gonna do is that the client is gonna process these world states and it's gonna look okay let's say the last packet arrived 100 milliseconds back and i have a packet that's maybe 20 milliseconds in the future just to say something to say some numbers that means that whatever happened or whatever i have to display now is between 100 milliseconds in the past and 20 milliseconds in the future because it has both these states it can interpolate in between it can basically tween in between these two states and therefore still display smooth motion even though we're only sending these signals 20 times per second so if of course we for some reason don't have a world state we can also extrapolate we can take the velocity and the rotation of every single entity and we can say okay we don't know where it's going to be in the future but based on history we know its direction we know its velocity so we can predict best guess that it's going to be there now if that happens which we hopefully can reduce with this buffer but if it happens of course it's going to be small deviations from reality a player may have turned during those couple of milliseconds or a mob may have stopped and started attacking so what we'll do will update the world and if we had any extrapolation which resulted into deviations we're going to rubber band you probably played mmos a couple of times or other games that you suddenly see a mob just sort of being dragged over the terrain and suddenly it's somewhere very different from where it used to be some games use teleportation then that map is just suddenly there but more and more modern games use rubber banding because then you can sort of see what's going on and you're not completely surprised you just okay that was lag well that's pretty much what rubber banding is so we're going to rub a bend any deviations that are a result of the extrapolation which hopefully we can avoid by interpolating between the various states in the buffer because we are rendering a situation in the past that's that's like in one full sentence that's it so that means that the player is going to have because of this local execution that means that the player is basically playing in a world that is 100 milliseconds in the past that also means especially if you're making a shooter that when you do that headshot the head may not actually be there anymore because you're looking at where the head was a hundred milliseconds ago and that is why we're retaining the history of an x number of world states so that when the player shoots we know exactly when the player shoots when we send that to the game server the game server can look back in the past with these various world states and we can see if that head was indeed in the scope of the player when the player was looking at it in the past and then we can still award that player the headshot if indeed it was a hit so all that all that is what we'll be doing in this tutorial series but that is of course just a little bit too much to put into a single tutorial right after spawning in some players so we're gonna take this step by step and in the next tutorial we're already gonna go full circle and make sure that we can see the two players move around in the world it will probably be still very choppy very laggy but this is where we're going to introduce those various elements both on the client and on the game server step by step we'll build it up until we got the smooth motion that we're looking for hey and you may be going like hey i heard a couple of other things you can also send input and houses with cheating is this safe those are all good questions um so i would say right now the player can cheat because the player for example could say on the client hey i can walk twice as fast it's just sending its new position in the player state and if we don't check for that in the game server then yeah the player would suddenly be moving twice as fast so on the processing of the collection into the world state that is where we would be implementing anti-cheats maybe verify that based on the amount of time that has passed between two states or between two inbound player states we can check like hey your movement speed is 300 but you've moved 600 pixels that's not possible so you must be doing some really funky stuff for that to happen and we're gonna ban you kick you disconnect you whatever it is also possible to send the actual input that the player makes i press w i press s or a or d or arrows or i clicked here i click there the problem with that is is that you're still going to be running into an issue with packet laws because basically if one player has a lot more packet loss than the other player that means that less states are gonna come through with the command i press w and let's say you're in a chase area where one player is chasing the other air player basically it would mean that one player might run a little bit slower because he's losing more packets and that means that input commands are being lost on the internet and they're not being processed by the game server and of course that sort of means that if you want to play competitive well if you live closer to the nearest data center where we store our game server you're gonna have a more competitive play which of course just that wouldn't make any sense or that wouldn't be fair at least i wouldn't create any competitive inviting competitive play so that's a couple of like what if or can we do it otherwise it's a couple of probably answers to some of the comments you may have in the comment section keep them coming now let me take a quick moment to thank all of you that have become a member of the game development center channel it is absolutely amazing to see how many people are willing to support the creation of all these tutorials if you haven't checked out the memberships yet or if you're just curious what it is it's sort of like a patreon but right here on youtube so you don't have to go to any other websites you can check it down below if you click that join button that's pretty much it today for this tutorial i hope you're as excited as i am to see other players walking around and moving around each other in the next tutorial i sure am so make sure you check that one out make sure you're subscribed and until next time keep on gaming keep on coding see you later guys
Info
Channel: Game Development Center
Views: 6,174
Rating: undefined out of 5
Keywords: Godot Multiplayer, Godot Spawning Players, Godot Spawning Other Players, Godot Multiplayer Tutorial, Godot Multiplayer Syncing, Godot Network, Godot Networking, Godot Dedicated Server, Godot Multiplayer Server, How to make a multiplayer game, Godot MMO, Godot Beginner Tutorial, Godot 2d Tutorial, Godot Tutorial, Godot
Id: SZIsXbXUfyc
Channel Id: undefined
Length: 22min 2sec (1322 seconds)
Published: Sun Nov 22 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.