2 smaller scripts vs one large script

Will I see a performance improvement if I split my large script into 2 smaller scripts? Logically it makes sense to based on functionality but that's not really the question.
Does having 2 half sized scripts improve performance over one larger script? And then what about 3 or 4, when does it end?

Thanks,

 

You won't really see any performance change at all, unless both scripts are monobehaviours, in which case you will see a performance decrease. That said, the decrease is so small that you effectively need thousands of them to notice it have any meaningful effect.

 

The different in performance between 1 and 2 Monobehaviour scripts is negligible.

 

Performance is not the problem. Organization and modularization are the two main ones. Generally you ought to keep your class files as concise and modular as possible. My current project has 15 class files, I began writing last thursday. Each file is from 50 lines (minimum) to 160 or 200 lines in length.

Modules make things cohesive and can be loosely coupled (good things).

I've been there before, having a file with 300 or 700 lines of code. The problem you run into with a big file is it gets really difficult to manage both conceptually and organizationally.

 

That is a great question. I'd actually like to see a technical answer on this: Something like ".0000001 ms extra time for two scripts vs. one script" or something like that. I don't know if anyone has ever tested it. Would be very interesting.

I think for 99.9% of people, it won't technically matter. The main thing that matters is if you can keep your code organized and working. Personally I have a few large scripts in all of my games, something like 1000 to 2500 lines of code in some of them. Which professionally probably isn't good at all......but if you can comment your code well and keep things really organized, you can use gigantic scripts if you want.

 

Something tells me you're writing *ahem* crummy code. If you need to comment things... I don't think you're naming things legibly nor "properly", a term I use tentatively because properly is a subjective topic BUT the objective of it to produce clean and readable code that doesn't necessitate commenting.

 

Many scripts don't really matter in terms of performance. Is just for human readability and convenience. Compiler will assemble them anyway, in appropriate way, for CPU/GPU to function.

Is easy to organize. But there were programming environments, where separate files weren't an options.

Modern script editors have capabilities, to collapse and quick jump to relevant scopes, within same file.


Also, comments exist for a reason. They can convey messages, where name of variable, method or otherwise is not enough.

Brief commenting what if, or for loop will be doing can be useful as well. Commenting at beginning, what script may be doing, can be informative too. But is harder to maintain, when scripts evolves. Also can comments can nicely divide script into sections.

For example having multiple methods in one script. Like math. And commenting off vectors, trigonometry etc.

Coming back next year to scrip, can be very time consuming, when there are 0 comments. Regardless of methods, fields etc., naming.

 

...My dude, you've got scripts the size of some of my entire smaller projects. That's not... great.

 

If it works, it works. Of course it's great to keep scripts modular, I do that as well. But sometimes a "module" gets large, especially if it's a large or complex game. I don't have other people working on that particular project, so as long as I can understand it every time I go back to it, and it functions correctly, that's all that matters to me lol.

 

This is a terrible attitude to take because monolithic scripts like this make debugging and refactoring a major nightmare. Even my large, complex special rendering systems don't get to that size.

 

Well, I'll take your advice into consideration. But it works, so I don't know what to say. I've been able to debug it just fine. And as for refactoring, I just havn't had to refactor that much, and it hasn't raised any issues. I know, it's bad form, so I get what you're saying. But to me, the end goal is that it works right?

 

I actually think there are very much times and places for large functions - that is a function that clocks in at like 500+ lines. It really depends though, and most of the time when people do stuff like that they're making a mess.

Some of the code that I found easiest to work with given high complexity was a 700 line function I wrote to handle camera logic. I revised it and added features, etc, and found it quite easy to deal with. Much easier than if I had split it up.

Again though, I wouldn't recommend this kind of thing in general - but there is a time and a place.

 

"Works" does not automatically translate to "works well." Pulling out works, but you should probably just wrap it up instead.

 

Well, you're right. I'm not going to argue with that.

 

Optimisation Guide In Unity https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity.html

Step 1. Profile...

 

I like big scripts and I can not lie.

Some of my functions (methods, whatever, like I care) are freaking huge. Some of my scripts are wickedly long. Come at me bro.

 

I've always seen that a class(like OOP style class, Monobehaviours are a bit different) should do one thing, and one thing only. That paradigm means that most if not all of our classes are too big, though I'm not convinced this "rule" is that big a deal. The point stands though, that we should try to keep things organized, etc... It can often make sense to split a script/class into separate parts, especially if either of those parts could be reused elsewhere. For example, if a player ship and an enemy ship have the same movement patterns/controls, but one is player controlled and the other AI controlled, I would put the movement in one class, and then have separate classes which then access that class, meaning you don't have duplicate code anywhere.

Another thing to consider...besides the abovementioned point that you need to PROFILE before optimizing(pre-optimization is evil, etc... etc...). If you are using Unity, you are already technically taking a performance hit. This applies to any generic engine(UE4, Gamemaker, anything). This doesn't mean that the performance isn't good enough, as when used correctly the performance is almost always good enough. I'd say splitting scripts up where it makes sense is the same way. So you might lose a percentage of a millisecond here and there....totally worth keeping the sanity with organization of the project.

 

I like to budget some time refactoring any time a class gets too long. Several smaller classes will usually be far easier to maintain than one giant class.

Similarly, I always try to keep every function small enough to fit onscreen without scrolling. It is harder to debug functions when you have to scroll to see it all.

In addition to scrolling, large function tend be too long to name effectively. If you have a really long function that needs comments just to make sense, then you should break it down into several smaller well named functions with narrow scope. A bunch of small, well named functions can replace the need for most comments.

 

As for purely performance considerations, there is significant overhead to having many thousands of objects with Update functions on all of the scripts on those objects. However, having three or four classes instead of one will not affect performance in a meaningful way when dealing with a low number of objects.

Side note:
Having 10,000 extra Update functions in a scene will affect performance by a measurable amount. If you need to have 10,000 objects moving around in your scene, use ECS instead of instantiating 10,000 objects with scripts attached to each one.

 

Indeed. And often sometimes, in a team, one person will make choices that are non-obvious because they support a larger architecture or some longer term plan. Our lead often puts these in if something seems weird, he will comment that it is works into a bigger piece.

Although it is sort of weird, our team is fully distributed so our comments often work like a context-based chat system. I'll go in to wire something or build out vfx or whatever and find implementation notes specifically for me (and I do the same). Oddly we have found this works really well. Several of us are in different time-zones, so we pass work back and forth. For example, If our game play engineer needs to tell me something super specific about a new feature and the way he implemented it, he'll leave me messages in code, and I may ask questions or reply to him, in the code. If he were to slack or email or trello it to me, I may or may not see or remember it when I work on that part. In the code, it is right there in front of me, exactly when I need it.

 

Comments definitely have a place in coding. Anytime I do something weird, I will add comments to explain it. That is a great use case for comments.

Sometimes comments get used for the wrong reasons, though. For example, some coders will choose to create a single massive function with a bunch of comments spread throughout that function to explain what each of the many subsections of that function do. That is a bad use case for comments, since the comments are trying to make up for the coder choosing to put too many things into a single function.

 

Ok it seems the general consensus is it doesn't matter (in terms of speed), but I just want to specify a bit more, I have a car changing script like scroll through cars in a garage and a paint the car a color set of functions. If I where to split those up I have to get the car again and call functions between the 2 scripts. I feel gameobject lookup is something to not go crazy with (like find with tag or whatever it is). Am I still being too cautious and should split them up?

 

why would you need that at all? You can set a reference from one component to another in the editor, or a component to GameObject too (They just need to be in the same scene), so you don't actually need to "find" anything at run-time if you have performance concerns about that.

 

I would say yes then later on if you want the players to be able to change the colour of their car in another area of the game or want to change the colour of a car within the game you can without writing a new function.

Often you will need manager scripts that hold the collection of cars it sounds like your car changing script should be or work for one of these scripts in which case it will be passed or know the cars reference.

You might need to make a car script that works as a Utility script that holds the references to all the things within the car that can change then your car changing and painting scripts will just work through the car script and only need a reference to the car.

Hint: if your using lots of Find<Component/GameObject/Tag> code you need a helper script that will store references all of the bits of a car that can be changed.

By breaking apart the separate aspects of what you are doing you can simplify and streamline the process, in programming you know you have a good design when it feels like the code in the system is working with you to solve the problem.

PS for best advice you should post your code, and always profile your code it's the only way you will find out what really needs to be optimised.

 

Silly question: DoEs CoDe ImPaCt PeRfOrMaNcE?? ?

 

This, so much.

I think the bigger question here is "How do I keep things modularized"? And for that, I think DRY is a very powerful technique, since it essentially forces you to modularize your code as that is the only way to prevent repetition.

A problem I've had lately is that even though I'm not violating DRY, some classes might still end up becoming really big. I.e. there are things that are not used anywhere else but in a certain class, but keeping it all in that same file makes it bigger than what's comfortable to work with. This can be a really tough problem, because it's not always obvious where or rather when a class is becoming too big. It sort of sneaks up on you.

A rule I'm running with now is that any one thing, any one concept that could abstracted into its own class with its own variables and functions, should, even though it's only used by a single other class. That can be a bit counter intuitive, as you're essentially modularizing something that doesn't need to be, for the sole purpose of making the class smaller. It's also definitely possible to overdo this, to the point where it's actually becoming harder and more confusing to read the code. There's also the question if refactoring the code to be more beautiful is even necessary for the product to ship. This and more is something the TechLead touched on in this video which I can highly recommend:

Another thing to keep in mind is that writing and organizing code in a beautiful way also makes you more replaceable. So if you wanna make sure you're essentially unfirable, you want to be able to write incomprehensible code that makes you look really smart but that's actually atrocious. This is something the TechLead spoke about in this video:

Spoiler

 

If you need to find anything, do it in the Awake or Start function and cache the result in a class level variable. Do not find the same thing over and over during the Update function.

 

Am I the only one who uses inheritance/OOP/SOLID to architecthis code? I can't be, I'm not sure that's possible.

Reason being is what follows:

Your classes ought to inherit from more semantically abstract base class(es). I'm sure we've all heard of the animal kingdom tree:



This a tired example but I'll explain...

Your concrete classes are the leaves of the tree. Your essential base classes are everything in between (Chordata, and its descendants). You can generalize this idea of a tree diagram to any object type.

In general I would suggest examining what the core class is, and descent to more specific examples from there...

Doing so lets you do cool stuff like:

Code (CSharp):

1. int iValue = 5000;
2.  
3. double dDistance = iValue ;
4.  
5. public class Animal { […] };
6.  
7. public class Mammal : Animal { […] };
8.  
9. public class Cat : Mammal
10. {
11.     […]
12. }
13.  
14. Mammal mammal = new Cat();
15. //Original code: https://en.wikibooks.org/wiki/C_Sharp_Programming/Casting

Which is very useful because with this you don't need to create a ton of 1. ugly 2. repetitive, and 3. annoying statements to handle different class types.

The general rule I think is if you use SOLID, DRY, and OOP principles you should be OK. Don't forget to test though, unit tests/integration tests makes for good robust code, I don't do this yet myself in this project but I've got try...catch, throw, and null ref checks, debug.asserts, and Mathf.Clamp() and Mathf.Abs() , all over the place so that I can find and fix any problems.

It would be awful if your DoDamage() method had the wrong sign, instead increasing the opponents HP to infinity, or the projectile/hitscan got a null-reference on your target upon colliding.

 

Object oriented programming, especially for games, was a mistake.

 

The keyword is: composition over inheritance. If you really want to sink in OOP, do it on a more flat inheritance-way.

 

I think I'd heard of it but its not been part of my designs...

Oh yea? Why's that?

 

I used that, when I was learning OOP. Then soon become nightmare, to expand upon.
Later I kept it to very minimum number of inheritances, which was more manageable. Also more modular.
Now I don't need that with DOTS.
I suppose this is typical way of learning things, to find out whats works and whats not, for particular case.

 

Inheritence is inflexible, and can lead to unnecessary code if you decide you need some of the functionality of a base class but not all of it which can itself lead to performance losses. Composition has performance penalties too but you can much more easily offset them by only bringing in the functionality you need.

Furthermore composition means you can create new functionality at runtime (eg for a mod) whereas inheritence leaves you at the mercy of whatever pre-existing types have been created.

Once upon a time I would have gone with inheritence, as I had never heard or thought of composition before Unity, but now I can't imagine using it beyond what is necessary to make the framework for it (MonoBehaviours inherit from Components, GameObjects inherit from Containers, etc).

 

Sorry to hear that, it's working out quite well for me though I tend to stay away from inheritance unless the relationship is rock solid.

 

I think the issue is definitely more about (overuse of) Inheritance than Object Orientedness itself. After all, composition is just another way to describe objects.

 

People who complain about OOP, because composition is better than inheritance are silly, because Composition over inheritance IS an OOP principle, even mentioned in the Gang of four books, literally in the first chapter..

“Favor object composition over class inheritance.”

 

To be clear, you wrote "books", plural, but there's only 1 book: Design Patterns: Principles of Reusable Object Oriented Software. Its from a paper with 4 authors, which is pretty standard - not gang-like at all.

You're talking about page 19 (plus bottom of page 18 and top of page 20). If you read it, it describes something similar to how Unity works. To get a graphical GUI element, you don't have Image inherit from gameObject. Instead, make it an optional component. But, as the book describes, Unity uses inheritance to make the components - rawImage and Image inherit from MaskableGraphic, all types of Colliders inherit from Collider, and so on. That page is saying that of course we all know inheritance is great, but not for every single thing.

That wiki page - the big bar at the top says it's bad, and it's not kidding. If you click the Talk tab you can see they didn't think very hard - some guys just wrote some stuff and can't explain why.

 

Yeah, books was a typo. But... you realize that they are called the "Gang of Four", right? It's not something I made up..
It's THE book when it comes to OOP.

I don't know what you are one with your Unity example.. No should be dealing in absolutes. It's stupid to fully avoid inheritance, just as it is to use it all the time.. So nothing wrong with that. My point is that the issue of OOP is not the inheritance stuff, because even the foundation of OOP(the go-to lecture) favors composition.

With the key part being:

"Nevertheless, our experience is that designers overuse inheritance as a reuse technique, and designs are often made more reusable (and simpler) by depending more on object composition. You'll see object composition applied again and again in the design patterns." (GOF95)

 

You should realize that no one here was complaining about OOP because of inheritance as opposed to composition. Mostly despite of the composition. OOP is still a bad choice to make a game, however if it has to be OOP, it has to be on the basic principles of composition.

 

If your script does two things then it should be two scripts.
The Single Responsibility Principle is worth adhering to as best as you can because it massively helps code maintainability.
It also helps to keep your public interface separate to your private implementations.

Because of this, writing code in this way will often be more performant because it forces you to encapsulate data properly.

If you ever find yourself copy and pasting from one function to another (we’ve all done it!), then there’s a clue there.

Every programmer is guilty from time to time but as long as you understand why it’s important then it helps you not to ignore that little voice in your head telling you to split your code up better!

 

Read the thread again..

TenKHoursDev said he was using OOP.
Murgilod followed with "Object oriented programming, especially for games, was a mistake."
TenKHoursDev asked "Oh yea? Why's that?"
Ryiah answered with the whole reply based on "Inheritence is inflexible, and can lead to unnecessary code.."
Antypodish said OOP was manageable when he minimized inheritance
Angrypenguin said" I think the issue is definitely more about (overuse of) Inheritance than Object Orientedness itself."

Did I miss anything? So how is it NOT about inheritance?
I mean you people could also just stop making empty claims like that and actually provide arguments.
OOP is bad, but why? Aside from the inheritance argument there was nothing.

 

If anyone is interested, try the Search "OOP overused". Mine even had a StackOverflow question about what "Favor Composition Over Inheritance" really means. You'll also see lots of people talking about how OOP programs spray out interfaces and mediators and message-passing classes ... to do the simplest things. You may not agree with it, but you'll know what the internet thinks OOP means.

 

Indeed, this is what I was trying to point out. People say it's OO that's bad, but the causes for this seem to stem largely from the impacts of poorly used inheritance. To my mind the real underlying problem there isn't that inheritance is "bad", but that it's the wrong tool for the job.

The other reason I see people complain about OO in game dev circles (though it hasn't been mentioned here) is the impact it can have on performance. It can definitely have a very real impact in certain cases. Again, though, I feel it's more an issue of the wrong tool for the job, as opposed to the tool being "bad".

I think that with ECS Unity itself is now a decent example of how to split the two. Use standard OO / components for the stuff where it makes life easier without impacting performance. Use data-oriented stuff where it will have an impact on performance. Same deal with any other tool at our disposal - figure out where it's strong and where it's weak, and use it accordingly.

 

To answer the OP's question... my projects are typically made up of lots of generally tiny scripts.

However, it's worth noting that most of the scripts are dormant most of the time. I use events to "wake" scripts up when they need to do something, and they turn themselves back off when they're done.

 

Why OOP is bad.

 

So he lists a lot of examples of bad OOP code and his solution (at the end of the video) are to write pure, long and nested functions. He is also heavily biased because he doesn't talk about the actual advantages of OOP nor the disadvantages of his solution. Yeah.. totally objective.

Anyway, it also seems that the whole hate on OOP in this thread is pointless and people would just let others use what they are more comfortable with.. Just like the Celeste devs were happy with their 5400 loc Player.cs..

 

In spite of making my first game and it working I still consider myself a beginner programmer. I learned on the job. I don't doubt the code could be better laid out/structured but it works and only I'm going to see it (in theory). If anyone cracks it and manages to figure out the inbuilt obfuscation, i.e beginner code, then they are doing well

Badly written code is badly written code whether on 1x10000 lines or 100x100 lines scripts. Well written code is just that. By the end of the games development I decided that a Keep It Simple principle is best whatever method you settle for.

Just a thought.

Here's a vid explaining with some good humor the same thing but much better explained by one of my favorite youtubers

 

Ok so what useful conclusions did you draw from that video?

The problem with attempting to do away with OOP is a very simple one: to do it, you have to treat every object as a group (i.e. its data structure) rather than individually. The moment you want to identify and single out a particular object (e.g. the enemy boss for some special action) all your perfect abstraction takes a dive out the window (unless you consider a special data structure for a singular object to be not actually an object reference).

Game programming is not a science, it's an art. All the time you have to stick your hand in somewhere and grab an object to do some special behavior just because for some reason it happens to make the game more cool. Just look at a Call of Duty game, every level is a succession of hundreds of carefully crafted individual events and behaviors that sweep the player along in a feeling of non-stop pressure and action. No level of perfect abstraction can achieve this.

I think of functional programming a bit like the idea of procedural generation. It's an attempt to abstract something in a way that reduces the individual identity of things in your game, but you just end up with abstractions that are around about the size, shape and smell of whatever object you should have been dealing with to begin with.

Games are about experiences that people can understand, not computers. That means that they are about objects and things. And lack of individual identity is the enemy of art - art is not about the 99 things that did X, but rather the 1 thing that did Y.

I have not found a better way to program games than to use objects and OOP.

 

Is this a philosophy, or did it just work out that way?

I've found that I just can't remember the names of lots of small scripts, plus they clutter up the editor tabs. I used to have lots of files with utility functions, but combined them into one. It's easier to use #region's and scroll through that one file than to bring up each one. Sure, it wastes the space on the functions I don't need, but only a few K. I was trying to remember what I used to do -- I had paper printouts of everything. In that case it was easier to have them in separate files.

I often need tiny "data" scripts, for example AnimalDataScript would have enum AnimalType and int index (I keep the real data in a List in the controlling script). I'd check that when I collide with it. But instead of that, I switched to a single GenericDataScript, with val0 through val3, num, index, and other common names. The controlling script has dedicated functions like getAnimalType(genericDataScript g) doing the translation.

If sounds more confusing, but if genericDataScript is on something named cow1 on layer animal, it's fine. Plus, without, I'd have dozens of the things.

If the cows need to be smarter, I've found it easier to make a few big combined "do stuff to me" scripts, instead of lots of small ones. So my cows also have useless functions to change their non-existent text (on both sides, even!), text color, and to hide their borders (they don't have borders). It's just easier to remember the standard names, and only have to have that single script in the editor tab for animals, signposts, and so on. Theory says it should be several small scripts, using only the ones I need for each object. But finding the right one for each call is too much of a pain. Plus you always want something like setColor(textColor, bodyColor) which would involve two areas.

 

This is a false argument. The content and the way you work on it are different matter by all means.

That's okay, personal taste is personal taste. No problem with that.