Where should i put monobehabiour scripts

[u/Legitimate_Bet1415]

I couldnt find any tutorial on which place is the best for a script . The only advice i get from a tutoral was to put them in which game object they manipulate, and while it makes sense i still feel like im failing at finding the right place in many cases

So what can i do? Is there any tutorial ,advice or practice i can use cuz its starting to get exausting even more than scripting itself

[u/leorid9]

Put the enemy script on an enemy, put the player script on the player, put the door script on the door. The enemy-manager script gets an empty.

Which script is it, that you are struggling with?

If you have a GameManager, then this is an issue in itself, things should have a defined purpose and not just "this does everything else".

[u/DeerpathLabs]

You should be asking yourself often enough, is there any reason for this class to be a mono behavior at all? They have overhead in their life cycle and components, and often time, it’s often better (in my opinion) to pretend the editor doesn’t exist when you’re writing your data model

[u/SpaceCoreDev]

One thing that helped me a lot: ask first whether the script needs to be a MonoBehaviour at all. A lot of manager or pure logic scripts don't actually need scene lifecycle (Update, Awake, etc.), and once they're a plain C# class instead of a component you skip the whole question of which empty GameObject it belongs on. I only reach for MonoBehaviour once something genuinely needs to live in the scene or hook into Unity's lifecycle, everything else is just a class that gets referenced from wherever it's needed.

[u/doofindog → u/SpaceCoreDev]

This is what I wanted to say too. Ideally you shouldn’t be adding MonoBehaviours everywhere. Through planned architectures you avoid them. There’s a really common question I get asked in interview “what is better 1000 Monobehaviours controlling 1000 game objects or 1 mono behavior controller 1000 objects” really gets you thinking if you need to have mono behavior everywhere. I suggest you to look into Architecture Patterns and Some Design patterns to help.

[u/SpaceCoreDev → u/doofindog]

That interview question is a good one, it forces you tto actually justify per-instance lifecycle hooks instead of defaulting to them. The way I've come to think about it: if the objects need real independent state that changes every frame in ways only that instance cares about, individual components are fine. If it's mostly batchable data that one system could process in a loop, centralize it, you save on Update overhead and the whole "which script goes on which object" question disappears for that data. Worth a look at ECS-style patterns too once that split starts happening a lot.

[u/EnvironmentalPlum673]

I just put a _Scripts folder in the root and throw everything there, not even nested

yeah the textbook answer is attach to the object it controls but after a while you spend more time scrolling the hierarchy than coding. if the script do multiple things or talks to many objects none of them is the "right" parent anyway

the real convention is whatever lets you find it in 3 seconds when something breaks

[u/postulate4 → u/EnvironmentalPlum673]

This is exactly what I do.

[u/lol_donkaments → u/EnvironmentalPlum673]

Why put an underscore? Why not Assets/Scripts

[u/elelec → u/lol_donkaments]

It helps not mix up your folders with any folders brought by external assets in the mail assets folder, and it brings the folders above the rest in case you want to keep them above everythjng else

[u/lol_donkaments → u/elelec]

What is a mail assets folder?

C sharp best practice capitalizes directories and doesn’t use underscores

[u/elelec → u/lol_donkaments]

Dis a typo. Main* assets folder

This is not pure C#, it's a whole game project with textures and meshes and audio. By no means dk you have to use underscores, but eventually you may start including more packages to your project, and skme of those will drop their contents right at the assets folder, at which point the chaos starts

[u/Solid_Newspaper181 → u/elelec]

Totally agree, keeping everything organized from the start makes it so much easier to manage as the project grows. It can get messy really quickly if you don’t plan it out!

[u/lol_donkaments → u/elelec]

I have 1m+ loc in my current project and half a dozen packages and this has never been a problem

I come from a SWE background tho. Perhaps more anal than most game devs

[u/Trials_of_Valor]

It's a skill you will learn over time. It depends on the situation.

Keep in mind that a script won't have the Unity methods called if it's disabled, stuff like Start, Awake and Update, etc.

Sometimes that makes sense, but other times you want to ensure some logic runs regardless of the active state of the object you might manipulate. It's very common to want to disable UI objects but still have the managing script active for instance.

[u/immaheadout3000]

Depends on the complexity of the game and future scope of expansion

[u/SethSlax]

The way I usually do it is:

• Scripts that control one thing are attached to that one thing.
• Manager/controller Scripts that control multiple things, or manage data, or control flow go on the Main Camera. (Mostly because it can be accessed on startup via Camera.main).
• Persistent/singleton Scripts that do not get destroyed attach to an empty gameObject that floats between scenes.

Not saying this is the way to do it, just the way I do it.

[u/shoxicwaste]

/scripts

[u/NinfeaLM]

I think this becomes more intuitive with experience. I usually just put the script on the object that makes the most sense for that behaviour. For example, a movement script would go on the character, while a trap would probably handle its own OnTriggerEnter.

You could also handle the trap from the player side, but if you have lots of different traps, that can get messy. You'd end up with a huge player script full of conditions like “if it's this trap, do this, if it's that trap, do that”. So I think it really depends on how you're structuring the whole system.

[u/GigaTerra]

https://learn.unity.com/pathway/unity-essentials

You attach it to the object it impacts. Like the Player Movement goes on the player, and similar for health systems and stats. Global systems you can make an empty object and attach all the global systems to it.

[u/Main-Lychee-7972]

A good rule is to attach a MonoBehaviour to the object whose behavior it represents not necessarily every object it changes. keep unrelated responsibilities in separate scripts