Building and Testing Dedicated Servers in Unreal Engine 5

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
in this video i'll show you how to build run and test clients and dedicated servers in unreal engine i'll also show how to find and fix a bug that we added in the last video which comes about when the client and server have different tick rates i'll be building off the flybot project i've created in previous videos there's a link for these down below as well as a link to all the project files on github up until now we've only been running the game inside the editor but now with multiplayer support it can be useful to test clients and servers with multiple processes i'll be showing all the steps but i recommend checking out the unreal documentation on how to do this as well we first need to create some new target files for the unreal build system let's open up our project folder and then go into the source folder in here there are two existing targets the first one the flybot target also known as the game target is a build that includes all the client and server code for the game so you can run a client with an embedded listen server there's also a flybot editor target which builds all the modules needed to edit your game inside of the unreal editor we'll create two new targets by duplicating the editor target and then updating the target configuration we'll add a flybot client target which is the build of your game with only the client code none of the server code we'll also add a flybot server target which is a build of only your server code without any of the client or rendering code back in visual studio go to the solution explorer right click on the source folder and then go to add existing item and then browse to our source folder select the two new target files and then click add we now have our two new target files in the solution if you click on one you'll see their c-sharp files that specify options to the build system for each target for example our flybot target uses the game target type uses version 2 of the build settings and only compiles the flybot module let's open up the new client target replace editor with client and then save it let's also open up the new server target and replace editor with server and then save it let's close visual studio open up our project folder right click on the u project file and then generate visual studio project files this is needed to configure the new target types once it's done let's open the solution file backup with our new targets ready to go let's click on the solution configuration drop-down list this contains all the possible combinations of build configurations and targets build configurations describe what optimizations debugging info and code to include while building your project check out the documentation for a description of what each build configuration includes up until now we've been using the default development configuration with the editor target but now we're going to switch to building the development server when we hit control b to build it's going to take a while because we need to build a bunch of the engine modules for the server target it took me about 15 minutes once done let's go back into windows explorer and see what it built from the project folder let's go into binaries and then win 64. in here you'll see a set of new files starting with flybot server flybotserver.exe is the new executable we run for our dedicated server you'll also see the existing module that was built to run our game under the editor if we go back to visual studio and press ctrl f5 to start up our development server which is basically the same as running that flybotserver.exe file it appears nothing happens this is because by default the dedicated server runs as a background process and does not include any output windows to see what happened let's go back to our project folder open saved logs and then flybot.log this is the log output from running the dedicated server process if we scroll down to the end you can see the process exited because we couldn't load the default engine material this happened because we haven't cooked the content for our project yet content cooking is the process of converting all the files inside of our content folder like levels meshes and materials over to a format that's better for packaged games check out the content cooking documentation for more details we can cook the content from the command line or from inside the editor when trying to do this in the editor i came across a bug that was cooking the wrong content for dedicated servers i found a fix for this up on github and i applied these changes to my copy of the unreal engine source code now let's switch our solution configuration back to development editor and start it up to cook the content we'll first want to go to platforms windows and then select the windows server target we'll also want to make sure the development configuration is selected if it's not already and then go to cook content you can switch over to the output log to see what it's doing and wait for the completed message if you want to see what files this created open up our project folder and then go to saved cooked in windows server in here you'll see all the cooked versions of our project's content while we're in the editor let's open up project settings go to maps and modes and then click the little down arrow under default maps here we want to set the default server map to be the same level that we've been running in the editor now let's close the editor go back to visual studio and select the development server configuration if we press control f5 to run it appears nothing happened again but this time the server actually started one way to see that it's running is to press control alt delete open up the task manager select the users tab and then expand the user to show all tasks if we scroll down we can see the flybot server background task running this would be fine if we just want to run the server for clients to connect and play on but we actually want to be testing it and see the output log let's end this task and go back to visual studio if we instead start the server with a debugger by pressing f5 we can see all the server logging in the output tab this is of course useful when we want to set breakpoints and walk through the code to see what the server is doing another way to run the server without the debugger is to go to the command line go into our project directory and run the flybotserver.exe file with the log flag this runs the server like before but now it's attached to a window that shows the logging output now that we have our server built and know how to run it let's build our client so we can connect to the server back in visual studio let's select the development client configuration this will use the client target that we created earlier when you press ctrl b to build you'll see it takes a while like the server because it needs to build the client versions of all the engine modules like the server this took about 15 minutes for me once it's done you can go back into the project's binaries 164 folder and see all the new flybot client files including flybotclient.exe which is our new client when we try to run it we'll get a message about missing game files because we haven't yet cooked the content for the client to fix this we'll swap back to the development editor configuration start up the editor go to platforms windows and select the windows client target and then cook the content once this is done let's close the editor and open up our project directory in windows explorer if we go to the saved and then cooked folder we can see our client and server cook directories you'll notice that the cook content for the client is 130 megabytes but for the server it's only 10 megabytes this is because the server does not need to include the parts of the content required for rendering graphics keep in mind that anytime you update the content in the editor you're also going to re-cook the content to update the client and server copies of the content now back in visual studio select the development client configuration and run it again with control f5 this time the client starts up as expected keep in mind that we're not actually connecting to a server it's just loading the level locally this is because we haven't told it where to connect to to connect to the server let's go back to the command line we'll start the server like before and now we'll also start a client we'll tell it to connect to this server and ip address which is the server that we just started 127.0.0.1 is always the ip address of the local computer you're working on and port 7777 is the default port that unreal listens on which we can see in the server output log we also tell the client to run in windowed mode instead of full screen and give it a custom window size i recommend checking out the documentation for a list of all the command line arguments you can pass into the client and server when we run it we see our new client window and that it connected in the server log if we start up one more client we'll see it also connects and that the clients can see each other moving in the world now that the server and client are built let's take a look at why testing outside of the editor can be important let's stop these clients and server and go back to visual studio if we open up flybot playerpond.cpp and go to the update server transform implementation function we'll see the speed and movement server verification checks we added in the last video as i mentioned then the speed verification check works fine when running the editor but it's not going to work once we have differing server and client tick rates to demonstrate this let's uncomment the speed update log line let's also make sure the development server configuration is selected when we press f5 to run the server under the debugger and then click on the output tab you'll see the server output log in here you'll see that the server tick rate is set to 30. unlike clients which are usually bound to how fast they can render graphics servers can run at much higher rates because of this servers usually have an artificial limit on how often they update by default unrail uses 30 times per second there's no correct server tickrate to use there's a lot of factors to consider and it really depends on the type of game you're making 30 times a second is a good balance because it's fairly responsive for clients and is not too busy on the server let's go back to the command line and start up our client like before let's bring this in front of the debugger window so we can see the server log while playing we'll also press the tilde key and run stat fps on the client so we can see the client tick rate as you can see the client is usually up over 100 frames per second note that when we're flying at our max speed which is 5000 the server logs aren't showing anything near that speed this is because the server is processing three or four client updates on every server tick and due to the tick rate difference the time between ticks on the server is much larger compared to the client and since we use this to calculate our speed it appears much slower on the server let's stop these and try a much higher server tickrate to see what happens to do this open up the default engine.ini file inside the config directory we'll add a new option at the bottom of this file called net server max tick rate and set it to 200. when we start the server up you can see this new rate take effect in the log when we start up the client and try to move you can see we can't move at all this is because the server thinks we're always trying to move too fast since the time between ticks on the server is only 5 milliseconds this is always going to give a much higher speed compared to the client to fix this let's rework the code in our speed check instead of checking the speed on every update using get delta seconds which as we've seen can be way off compared to the client let's instead average our location over multiple movements and then check the distances between these average locations at a regular timed interval we'll first save the current world time in a variable name now for easy reference next we'll check a new variable that tracks the last time we've done a speed check is set if it's zero it means we haven't done a speed check yet so we'll initialize the last speed check variables to the current translation and the current time we also reset the sum and count variables we used to calculate the average translation for each speed check interval if we have done a speed check before then we add the current translation to the sum and then increase the count next we check to see if enough time is passed to do another speed check if it has we first calculate the average translation by dividing the sum by the count next we calculate the distance from our last translation to our new average translation we then calculate the speed using the distance and the time difference from the last check to now we then set the last time check to now and then reset the sum and count variables for calculating the average during the next time interval we then do the same speed check as before still allowing an extra five percent for time and location variation between the client and server and if we are going too fast we reset the client to the last translation and return if we're not going too fast we save the current translation as the last translation so we can use it for the next speed check we'll need to declare these new variables so back in flybot playerpawn.h we'll first add our speedcheck interval that can be configured in the editor and then at the bottom we'll add the rest as private variables back in flybot playerpond.cpp we'll go to the end of the constructor and add a default value for speedcheck interval we'll set it to 0.5 for now which means we'll do a speed check every half second if we build and run the server and then connect a client you'll see a client speed update log line every half second as expected as we start flying at max speed you'll see our speed calculation sticks right around 5000 which is our default max speed so this is now working with a server tick rate of 200. now let's stop this go back into the default engine.ini file and change the server check rate back to 30. when we run this we can see our speed calculation is still around 5000. now that our speedcheck update is working regardless of our client and server tick rate differences let's go back into the source and comment out that log line that prints on every check we'll run it one more time just to make sure our server log is quiet again while the speed check isn't perfect since it averages out locations over time it should be good enough to catch the biggest invalid moves like teleporting across the level we could have tried using the time when the server received the client update instead of the tick but this could also be inaccurate due to server processing or network delays i tested this a while longer with the dedicated servers just to make sure there weren't any other inconsistencies with the server verification checks there's still a little bit of server correction happening when we slide along large surfaces like i talked about in the last video but other than that it's feeling pretty smooth in the next video i'm going to add the ability for these pawns to shoot lasers out of the front so we can explore all the parts needed for making a weapon firing system if you have any questions be sure to ask in the comments down below thanks for watching [Music]
Info
Channel: Lively Geek
Views: 42,397
Rating: undefined out of 5
Keywords:
Id: DrkG3W8a_ls
Channel Id: undefined
Length: 13min 44sec (824 seconds)
Published: Wed Jan 19 2022
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.