Breaking up Code in Unity (Important game dev tips for beginners)

maybe haven't experienced these issues you will eventually run into this and this is a fact and there's a few ways to deal with it and so listen up because this this will potentially save you a lot of trouble hey what's up everyone John States Kyle here welcome back to another game dev tutorial so today we're going to talk about a very interesting topic script separation and that's the idea of having say a player controller but instead of having one big massive file that blows out breaking it up into logic groups that is to say input movement collision animation things like that and having them all talking to each other through this centralized player script so we're going to look at how to set that up and all the things you need to know alright let's get into it hello guys welcome back to another game there video so today we gonna be looking at an interesting topic script separation and how it applies to your player controller because this is where more often than not you will want to or consider separating your scripts because play controllers can get quite bulky with a lot of different logic categories and collision movement input or going off at once and quite often that play controller file can grow very big so you may want to kind of break it up into different sections but it's not always so easy and we'll get into why so in this sample scene here you'll see I have a player and on that player I have a player script so I'll just run that first to show you guys what it's doing so the player can move left right and when you touches the spikes he gets all sad cool ok so let's look at that code now so it's all taking place in one script file so it's a very typical situation here I'm nothing too unusual so we have the top we got a bunch of properties a start function where we mapped the animator and rigidbody component a little mini state machine an update function where we check for the input for the left and right which we then store as a bunch of properties and move the player in the fixed update for a bunch of functions here and at the bottom here we have some collision code which checks for the spikes so we have collision one section movement another and input up here so three different kind of code categories and for a little mini script like this it's not a problem because the game isn't doing much but if you run into if you make a really big 2d play again like currently blood and made my game the the player script is or was massive this is huge just thousands of lines of of different intricate logic pretty primarily of these three kind of categories and this topic came up on my discord I think was chrome 5 chromate but we had an interesting game to have a discussion about this so shout out to you man hopefully this will be insightful so let me show you guys a little diagram I set up that will put in perspective so here we have the player script the main on which we just have so we want to break out that sub logic into three extra components an input script component a movement script and a collision script and we want them all to be linked to the player script and essentially what we want to do is we want then these scripts to communicate through that player script so if the movement script wants to check the input it doesn't do it directly they don't communicate like this rather they have to go through the play script and access the other controller so this is a nice way of just keeping the flow kind of clean and having just a centralized location where we can pass all our stuff through because it you you can imagine if this talks with this this talks with this this with this yes it'll work but it could cause just a lot of spaghetti as it's called in programming spaghetti code so jumping back into our script file let's now remove all this code here and we're going to dump it in separate files based on these categories so we don't need the fixed updates we don't need the inputs we don't even need the update we'll leave the state manager so I'm now going to attach the additional script files which I've just created earlier for convenience so we go in put my anklet script play our movement script and a player collision script so before we can do anything with those I want to create references to these in the main player script so we're just going there and I've just got in my clipboard a copy and paste so here I'm just creating the three serialized references to those three scripts I just added the input script the player sorry the movement script and the collision script so now if we jump back over here we can now drag these scripts to those serialized fields so this is really cool it's quite powerful input movement and collision so now let's actually go into these scripts to show you what's in there this is the input script what have I got here I've got a I've got it importantly I've got a reference to that main player script because as I mentioned we're going to want to go up if we want to communicate with the manager without the script files the collision manager or moving manager will want to go through the player script so we need reference to the play script we also might want to reference some of those properties on the player script like the health the walk speed the rigid body or the animator we might need to reference those there's no particular reason at the moment but so each of those files has a reference to the player script it's like the parent right and those good files are the children so they want to know who the parent is so if they want to ask to eat or they want to ask watch some TV they've got to go with apparent y'all just assign the player script into each of these now sums reversing that drag order dragging the player into those cool so I'll just open our movement script so in the movement script I've just got a bunch of movement code and nothing else you see it's very clean it's just handling the movement it doesn't want to know about collision it doesn't want to know about input well he wants to know what's happening with the input but it wasn't doesn't want to manage it itself so you can see here this script to move left or right is checking the input manager so it's going through the player script and it's accessing this input manager so we're now in the player script you see we're now accessing this input manager and we're checking the state of is left pressed or is right pressed and the movement control is then firing off some functions based on that and what does check what's in the collision manager so here I've just separated out that condition logic you see so if the player runs into a object with a does damage tag it tells the main play script to change its state to sad or happy depending on if it's colliding or not so we just hold ctrl and press click to go to that function to see that so we're now in the play script so you can see there's this perfect communication between these three modules with it where the input gets essentially kind of dispatched in in a way where the movement script can pick it up the collision script is then communicating with the player script to tell it to do change States and stuff like that so that's very cool but does it work right listen so let's run it now and find out all right so that's working exactly as it was so there is one critical thing I want to point out here it's very very relevant and it's going to potentially snag people who try to go into this code separation situation without understanding so all these scripts here have a start function as you're aware and starter gets fired when level start or games start so you can see here in each start function I've just put a console log that it's starting up ok and yeah right and the player has one too so look what happens now when we run this check this out look at the log the player controller is firing first the player movement controller is firing next the play input third and the actual main player script which should be firing first is firing a last when I say should I mean theoretically we wanted to fire first because the play script is the main one and it needs to be established first so that's a problem right try to keep up with this I know it might be a little bit much to understand right now because you maybe haven't experienced these issues but you will eventually run into this and this is a fact and there's a few ways to deal with it but so listen up because this this will potentially save you a lot of trouble just on another topic guys I just released a unity asset called the ultimate 2d car game kit it's just the massive pack that lets you get into making car games really quickly without getting bogged down for hundreds of hours with all the initial setup process yeah I mean you still need to do a plenty of your own code it's not like a complete game it's a it's completely functional but you know you still have to turn it into some cool game project you know whoever it be a car RPG or a Formula One racing game and all that so it's this a really good starting point for anyone who is interested in getting into car games and it'll be useful for you and it'll support me so this movement script right it needs to know about the rigidbody component on that main player script so this is also something else I love relevance the main player script is holding a rigidbody component this movement script is referencing that rigidbody through that player I mean I could define an avid rigidbody up here which is basically just another reference but it's kind of redundant there's desert acronym in programming dr why don't repeat yourself now that this is not a really violation of that per se because quite often you might need to establish the same component reference twice whether it be the animator component or the rigidbody or something of that kind of nature but in this case I've opted to try to be a bit clean and go through the play script and access that one so there's only one rigidbody reference and all those other subscripts have to access that here we are checking for the rigidbody 2d but by the time we press left or right all the scripts have established themselves and of all startups there's no problem but say in the start function I tried to reference the rigidbody on the main script what do you think is going to happen so what if I said rigidbody 2d dot velocity equals spectre to zero zero why do you think is going to happen I mean it works over here right so it should work here yeah but because this script is starting up before that main player script this rigidbody reference is going to be dead it's not gonna it's not gonna exist yet so now when we run this we should get an error boom look at that the movement script started up it tried to look for the rigidbody and it says nope this thing does not this thing you're looking for does not exist yet and you can see later on the player script starts right so this execution order is critical and it's funny because some people they see this move up and move down functionality in the inspector and they think that maybe this determines the script execution order wouldn't that be nice that would be something maybe you need to should consider but this is more just for visual organization if you want to solve that problem of execution you can do it in two ways just jumping over to the player you guys might be aware of this function called awake so awake gets fired before the start before any start so if you had 10 different components they all had a start function no matter what order they forget get fired in this awake function on this particular script will always fire beforehand so we can just test it out right that's script or player script awake and the idea is that we move these definitions outside of a start and put them into the awake function and that should theoretically fix our problem so we just test that out let's clear the console let's run and you can see here no errors and he works again you see so that was one solution we moved these very important declarations that the other scripts need access to into the awake function so that's one solution what is the other so I'll just move these back into the start function just to get that error back let's run that quickly just see we've got the error yes got that error again right it's a script execution order this is an interesting one so good file or rather edit project settings and down here hidden away nicely is this tab across script execution order so you press this little plus button here and you can find all the scripts in your project and here we've only got four custom scripts so we'll put the player script I'll just put them all just to make it a bit easier to understand collision script and movement script so as I showed you in the console window here when the unity starts whatever whatever scripts are attached to the object it fires them arbitrarily like it it comes up with some random order which is not particularly useful because it doesn't know it doesn't know what you deem more important than something else so here these times here are the milliseconds that have passed since you press start okay so here you can if we set well the idea is to set all those other scripts higher to a higher number than the player script so we've got the player script starting at 100 milliseconds the input script is starting at 200 collision of 300 and player movement at 400 and you can use any any numbers here as long as they are higher then that player script we are good so I just hit apply on that let's run this now so in the console window we should see the play script starting first look at that player script collision script input script movement script player script collision script in prescriptive miss cribben so they are the exact we've we've told it what order e should start up in which is another way to solve our problem without having to move the code into the awake function so that's pretty cool right so let's just run that and make sure everything is cool so that's it guys that's how you can manage code separation on your game objects and it's not a bad thing to do because if something goes wrong in one file the error will show here on what file it's in I can go to that file directly I can fix the problem so it's just a nice way to organize your code and it's a bit more manageable alright guys so I hope you've enjoyed this video if you have make sure you give it a big thumbs up down below and make sure you sub if you haven't already and thanks to my patreon supporters who have been generously donating to me every month you guys are absolutely fantastic if any of you guys want to support this channel I'll put a patreon link down below doing so will give you access to all different player scripts and project files from all the previous tutorials AI files and interesting kind of a little bit saloons that you can use in your own projects alright guys all the best see you in the next video and wishing you all the best on your game dev adventures [Music]

Channel: Lost Relic Games

Views: 56,943

Keywords: breaking up code in unity, code separation, game dev tutorial, lost relic games, c# coding for unity, how to code c# in unity, one script or many in unity, indie game developer tips, unity3d, howto, make a player move, game dev classroom, 2d player controller, tutorial, unity project setup, unity player setup, best unity tutorials 2020, multiple script files in unity, game dev advice, john stejskal, dani, Brackeys

Id: _vj1GASSO9U

Length: 18min 36sec (1116 seconds)

Published: Sat Feb 15 2020

Reddit Comments

[u/Orava]

Good practice, but the execution could use some further polish.

The reference clutter in the inspector and manual fiddling to set it all up could be automated to make it foolproof and a lot cleaner.

Using [RequireComponent] would make it so it can't be set up wrong, and make it quite a bit simpler to set up further characters, since you could simply drop any of the scripts on a GO and the others will be added automatically.

Manually messing with the execution order can end up getting really bloated as the project grows. It's nice to see things visually in the execution order, but it's further manual and error-prone work you might as well skip. The main script could be initializing all the modules ensuring that things exist in the order you need them.

[u/MegaStegz]

edited: The audio sync has self corrected. some youtube glitch. Thanks to those who let me know.

[u/Gonzako]

I always do this! I mostly do it so the AI moves more or less the same way as the player and they feel "in the same world". Also, interface everything and you got an Iterators dream