koobas.hobune.stream
One large script or break it up into many
Is it better to have everything in one large 1000+ line javascript or break it up into a bunch of smaller files? Are there any speed loss in invoking content from other scripts?
You should break things up so that you can see how the game fits together, so that you understand code when you come back to it later, and so that other people on your team can also navigate and understand the code.
Each component you want to attach to game objects in the scene needs to be a separate script, so that already requires you to break things up somewhat.
For other code supporting your game, you should break it up into blocks of logical functionality. These blocks should be big enough to do something useful, and small enough to make sense. Typically a script should represent an object in the world of your game (character, prop, building, ...), or a system that helps implement the game (input, user interface, event manager, ...).
If you can't think of a good name for a script file, it probably means it's doing too many things.
There should be no loss of speed for splitting things up into multiple files.
For more information on splitting up your code, look for object-oriented design references.
(FWIW, the project I'm currently working on contains 183 C# source files.)
"There should be no loss of speed for splitting things up into multiple files."
I suspect calling Update() on 1,000 files is slower than calling Update() on one, even if that function is 1,000 times bigger.
Yes, but using multiple scripts doesn't mean you have to use Unity's event system ;) You can simply reference other scripts and call functions on them the same way you call functions in the same script.
It's a matter of design. Some things are very hard to spllit up into several files, but in most cases that should be no problem. I have only one file that's larger than 1000 lines but it's a GUI framework i've written. It contains a lot sub classes which could be places in seperate files but this way it's easier to copy around ;)
Hey hello.
I would really reccomend you having big scripts but very well organizde and commented.
Maybe it "depends"...
Here's what happened to me recently:
I'm doing a special character rig. I really wanted to do something simple: have a character's bone position interact with another bone's rotation, using a graph. To illustrate it was looking similar this: (someObject.transform.position.x = myGraph.Evaluate(anotherObject.transform.rotation.y)
It was pretty straight forward, and simple. Among other things I wanted my script to do, I got it working the way I wanted in about 5 minutes.
...But I wondered, what if I want to reuse this code?
I've progressively ran against issues and problems. What if I want other axis to interact with each other? What if I wanted other parameter than position to interact with rotation, or interact with something else? What if I wanted more than one object to interact with the same value??
I went crazy, it was a complex task for me, since I'm not a professional programmer. I used functions to read and set parameters, classes with individual relationship graphs, the axis, parameter type, local/world space, a result multiplier to tweak it, etc. It wasn't easy, but I did it!
I managed to have little "parameter reactor" going on. Not sure how long it'd take a professional programmer to do this, but it took me 2-3 whole days. But hey, I got it working, I could have any parameter affect any other parameter using a graph.
I replaced my specific non-reusable code with my little system, and it worked like a charm. I felt the win.
I was at peace.
It wasn't until I really needed something slightly different: to have an object interact with the proximity of a local position.
So I had to go crazy again. This time I had a system with three scripts. A MasterParameter, a SlaveParameter, and a ParameterLinker... then I made 4th script called ProximityParameter, so now I was able to interact any parameter, with either another parameter, or the proximity, took me long enough, but I did it.
It worked! I was happy again, although a was already a little concerned. This thing was getting a bit complex, I couldn't tell if this was making things simpler or actually making it worse, in the long run.
As I kept working on my project, I realized some stuff wasn't really looking the way I wanted. I needed the position to interact not with a single parameter, but a combination of parameters. Was I ready to go crazy again? Use more time?
Setting up these scripts was getting kind of complex and time consuming... all this without perfectly desirable results?
And I was also realizing it would be a lot easier if I could just code specifically what I needed!
So yeah... after a week of work, I came back to my old code, that I did in 5 minutes.
Its always better to break you code for simplicity and better understanding of its functions as well as code that u can reuse on other gameObjects
Like for instance you have a big big code for a player where you got Movement Life Damage Perception
But lets say something its not working and u have to disable the life... doing it on a complex script its hard if its not properly made but if you have your HP controller apart then u just disable the component for debugging purposes, and disabling HP should be easier for people that didnt wrote that script. Besides if you really do an Life controller then u can reuse it on other objects like lets say "enemies" or NPC, but u cant reuse ur hole big 1000+ line javascript on other than that specific object
