General overall script/object design question

Please bear with me, I'm still barely scratching the surface of Unity.
I'm coming from more of a programming background (rather than the artistic side), and am trying to get my head around the best practices of efficient Unity scripting. I've gone through most of the tutorials, but would still like a bit more clarification if possible...

From the way I understand it, you need to create a separate script (javascript, c#, whatever) for each main object that you want to do something with; if that makes sense. Mainly I guess, I wouldn't want to create a single script for my entire project and put hundreds of functions in it for each different "thing" to do.

For the most part, since a script needs to be attached to each object that will be affected (Again - I think?), it would be wise to create many, many small scripts. Along this thinking, is the general practice to create a script then for each individual object separately (not counting instances, just the main object)?

While there are of course other aspects to consider and personal preferences, say for example I have a scene with 20 objects that all do something unique. Would the best approach to this be to make 20 scripts (each attached to 1 object); rather than only a few scripts that take care of everything?

And lastly, if I've made any sense so far...
I'm sure it's mentioned somewhere obvious, but when a game is run, is it essentially just running frame by frame and calling Update() on every object that has a script attached to it on each frame?

Hopefully I explained that enough to make some sense to someone :?
Thanks again.

 

Sort of...Update() is only called if a script actually has an Update function. There's lots of other stuff that can happen...if you have any loops with yield in them, then that code is running every frame too. InvokeRepeating() calls are done at the defined intervals, and OnCollisionEnter() etc. calls are done when appropriate.

As far as few scripts vs. many, I'd say the definitive answer is: it depends. In my Space Invaders clone, the invaders are all controlled from one script, while everything else has its own script. But that was just what was easiest for me.

--Eric

 

Personally I try to write scripts that do a certain task. Then make it as flexible as I can to take param's so that it can work with many different types of my gameObjects.

- My code style uses 3 types of scripts -
* Game-Controller Scripts <-- tend to be larger and talk to the other scripts (and they talk to this)
* Shared-Task Scripts <-- tend to be small
* Unique-Task Scripts <-- from tiny to maybe too big

a gameObject (aka gO) may have more than one script on it.

Cheers,

 

I personally use this design pattern:

I have one global Game Controller in the scene on an empty GameObject. The Game Controller then runs a game state FSM, and controls all main aspects of the game.

Under that, I then have a selection of Managers. Each Manager handles it's own section/task and reports to the Game Controller.

Under each Manager is a selection of very specific scripts that handle a small selection of tasks each. These report to the section Manager.

This way, each Manager keeps track of the individual scripts under it's command, and only reports to the Game Controller when it needs to.

This setup is just like the chain of command of the military or any company. You have the CEO, several Managers, and several employees who each perform a specific task and report up the chain.

That's just what I do, and it also depends on your project. After messing with Unity for a while, you will find a method that is most comfortable for you. It just takes a while to "get" how Unity scripting gells.

HTH,
-Jeremy

 

Very usefull info for noobs like me, thank you. This kind of general vision of the game developing methods with Unity is what I miss more. The docs and tutos released with the program are really excelent, but for people coming from the artistic side this more general aproach is very helpfull.

 

Great info, many thanks.
The way Unity goes about everything seems so straightforward in most ways, it's just a matter of figuring it out I guess like you said (And also trying to forget some of the bad habits I've picked up from other languages over the years).

Thanks again for the advice and examples.

 

Like Jeremy, I make a master Game Controller script that is attached to an empty game object that lives from the start of the game through every scene.

In each major scene I have an empty game object that I label Scene Controller that has scripts important to that one scene.

And many objects (either in scene ones or prefabs ones used in lots of places) then have their own smaller scripts attached.

But this works for me.

 

It really comes down to preference. There aren't really many restrictions placed on you aside from the very basic way Unity's scripting engine works, and how to make use of the inspector, things like that.

After that, you are really free to work how you like. I code in C#, so that's why I choose to go crazy with the OOP structure, it is actually easier for me to manage, design and so on, but using JS will prob require a slightly different design.

My opinion is, if it works, is clear and readable, efficient enough for your use, and you can come back to it in 4 months and actually understand it, then it's perfect. But that's me. ;-)

-Jeremy