Opinions on scripting please

[Nubz]

So I have a few scripts that could easily be combined into one bigger script.
The language I use is C#.
What I am wondering is does it make a difference if they are separate or one script(aside from debugging or finding errors easily if something goes wrong).

Just curious if performance would be better or worse one way or the other or if it is even a good idea.
Thank you in advance for any opinions or info.

[willemsenzo]

I don’t think it matters that much but sometimes having everything in one script isn’t the most ideal. It clutters up real easy which can make it a visual mess but it all depends on your personal preference or the project structure you have in mind.

[Polymorphik]

what @willemsenzo said

[Nubz]

@willemsenzo

I don’t think it matters that much but sometimes having everything in one script isn’t the most ideal. It clutters up real easy which can make it a visual mess but it all depends on your personal preference or the project structure you have in mind.

Well it wasn’t that I wanted the entire project in one big script that would be a nightmare lol.

I do see your point and it was actually what I thought would be the case.

[Tomnnn]

There’s probably a very very minor benefit to performance / organization if you reduce the number of update functions you have. If these classes are all running their own update function, then it could help to merge them. If the classes are separate and you call className.Function() from a main class’s update, then there’s probably zero difference.

[Nubz]

@Tomnnn

There’s probably a very very minor benefit to performance / organization if you reduce the number of update functions you have. If these classes are all running their own update function, then it could help to merge them. If the classes are separate and you call className.Function() from a main class’s update, then there’s probably zero difference.

What I was actually thinking is I have 5 different scripts that control my gun such as recoil weapon sway shooting etc.
Just thought it might be better to add them as one.

Thanks for the replys.

[Jessy]

I shoot for having a single line of code in all my classes. The closer, the better. Unity’s Component system is a great workaround to not having mixins or even traits in C#; instead of making a big class, you can form a scripted Game Object Hierarchy using code chunks.

[Tomnnn]

@Jessy

I shoot for having a single line of code in all my classes. The closer, the better. Unity’s Component system is a great workaround to not having mixins or even traits in C#; instead of making a big class, you can form a scripted Game Object Hierarchy using code chunks.

Never thought of doing such a thing with the object hierarchy, haha!

[Meltdown]

Look up what SOLID means regarding programming, and understand each principle, it will give you a better idea of how to write your scripts.

[Nubz]

@Meltdown

Look up what SOLID means regarding programming, and understand each principle, it will give you a better idea of how to write your scripts.

Thanks for bringing that to my attention I actually read about that before and it made so much sense yet I had forgotten about it.

So it according to that it was pretty much a silly idea in the first place and I should leave each class doing it’s own thing and not confuse it by combining stuff together.
At least that is what I got from it.

[angrypenguin]

Yeah, pretty much. I make many, single-purpose, often replaceable and reusable components. An “enemy” isn’t a monolithic class that has damage, health, pathfinding, etc. etc. all in one thing. Instead it’s a bunch of different components each providing one and only one of those things.

This also makes your game highly flexible. You can often create new things by making new configurations of existing components.

[Nubz]

@angrypenguin

This also makes your game highly flexible. You can often create new things by making new configurations of existing components.

This alone is pretty important to me I like to be able to reuse something and not have to edit it for an hour so it will work without the 5 other scripts I didn’t want to use.

[Tomnnn]

My high school C++ teacher called that high cohesion.

[lordofduct]

I too split everything up into a lot of different classes/scripts.

My designer though hated all the various scripts cluttering up the gameobjects, nor did he like not knowing where everything was.

So we devised a hierarchal structure for all entities that I call an ‘entity’, where the base GameObject is considered the ‘root’ of the entity. And I have functions that mimic ‘GetComponent’ and the sort to search the entire entity instead.

Image of Inspector showing organization:

Note that object like MobileMotor, Attributes, CombatMotor, Events, etc are non visual GameObjects just there to organize scripts apart from one another.

MobileMotor, which I have highlighted, is where all the ‘movement’ scripts are.

Those scripts are split into things like ‘Resolvers’, which handle minor tasks like gravity (GravityResolver), moving platforms (MovingPlatformResolver), facing the character (FacingResolver).

Another are the Movement Styles, splitting up the various movement styles that may occur. For instance this character has 2 modes currently (and more to come, like swimming). AdvancedPlayerMovementStyle (the default style) and HeavyLatchedMovementStyle (you can grab a hold of enemies and ride them around, this is that mode)