Script length vs Script amount

Hello Everyone,

I have some general questions I wanted to ask the community and get their opinion on their feelings towards script optimization. The questions are: How long should a script be? Do you split your scripts into multiple smaller scripts or try and keep things contained in one? What are some indicators for you that a script is getting too large in scale and needs to be refined? Or have too many scripts that it can become hard to track them?

Would like to hear your opinion on these ideas.

Hope you are all staying safe and healthy out there.

-Noxirus

 

The length of a script is less an optimization issue, and more an organization issue. For example, taking a large script and splitting it up into multiple scripts on its own doesn't really optimize anything, since you're still calling all the same code, but just in different files.

But as far as when to split up a script, I try to keep code in a script which is related in some way to each other. When I end up with seemingly unrelated blocks of code, I consider it a candidate for splitting it up.

 

I find that the more scripts you have it can make all other scripts more complex. Being that you need scripts to communicate between each other they need to have more functions/variables that are public and accessible, which can add a layer of difficulty.

But a monolithic script can also be difficult to navigate and figure out where events occur, scrolling through hundreds of lines of code can also be difficult.

 

I don't quite understand what you mean by this.
From what I'm gathering, that just means changing this:

Code (CSharp):

1. private void DoSomething() {
2.  
3. }

To this:

Code (CSharp):

1. public void DoSomething() {
2.  
3. }

To answer the question though, I wouldn't worry about how long a script is, rather what task a script needs to accomplish. Monolithic scripts are often the result of the script having to perform too many tasks, and that's where debugging becomes a headache. It also means that much of the rest of your software likely relies on this one script, which makes refactoring difficult as well; changing one thing may cause something else seemingly unrelated to behave differently.

As long as you keep your scripts simple - only needing to perform one specific task - you avoid the monolithic script problem altogether.

As an example, I have my own custom movement MonoBehaviour scripts that I made with the intention of them being able to be used universally across most genres of games, such as:

• TranslatePositioner - Translates a GameObject in the scene with a given Vector3 value.
• FollowPositioner - Makes a GameObject follow another assigned GameObject in the scene.
• SpinRotator - Just rotates a GameObject in the scene.
• VelocityRotator - Makes a GameObject rotate to face the direction it's moving in.

With simple components like these, it's easy to just plug-and-play them to create desired behaviours.
Maybe I want to create a homing missile GameObject that attacks the player? Give it a FollowPositioner and VelocityRotator. Done. Maybe later down the line I want to remove the homing capability and just make it a dumb-fire missile? Replace the FollowPositioner with a TranslatePositioner. Done again.

 

Ah that makes sense, I guess to elaborate more on the observation I had with making more things public is it can be difficult over time to figure out how much outside influence the component if having (maybe you get to a point where too many scripts are trying to change the variables of another script and it becomes harder to control the current state of that script) (might be overthinking it a bit much, for some reason I have it in my head that its usually best to try and keep everything contained within the script).

One thing I am seeing with one of my scripts becoming too big is with my AI (enemy computers) they all need to have necessary logic like movement, shooting, going for the win condition, this can make the script quite large.

 

Rarely should you change a variable in a script from another script for exactly this reason. Each script should manage its own state as much as possible.

Where necessary, access to internal state should be controlled via curated public methods and properties.