• Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
0
Question by sHTiF · Sep 14, 2011 at 01:02 AM · componentspattern

Using multiple components or using single one as manager?

Hello guys, i am new to unity although i have strong programming background from Assembler to C++ some of the Unity workflow is kind of unfamiliar. Most of the advanced implementation patterns possible i gathered from various sources but there are still some i am curious about so bear with me.

Now to the problem, what is more feasible using multiple components on a game object or single one that instantiates/handles other functionality through special classes.

For example lets say i have a generic Enemy what i would do for the sake of decoupling is make EnemyState, EnemyMotor, EnemyAI... classes where State handles its state, hp etc. motor is handling its motion etc.

Should i make all these as separate components and attach them to the enemy or its better to make a single component lets call it EnemyController that will instantiate all the others not necessarily as components and manage everything through it?

Honestly i find the second option more to my liking, not only its more readable its also way more transparent when it comes to reusing classes outside of Unity or vice versa. The downside is overhead in referencing/sending data that would be inherent going the component route.

Thank you.

Comment
Add comment
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

1 Reply

· Add your reply
  • Sort: 
avatar image
0

Answer by aldonaletto · Sep 14, 2011 at 01:27 AM

I usually try to use only one script attached to each object, unless some part of the code can be used by several objects. Using the Enemy example: if you have 3 different enemies, for instance, you can use a common script to take care of damage, and others specific to each monster to implement the AI control, movement, attack etc.
Communication between different scripts is somewhat complicated: you must use GetComponent to get a reference to the other script, then use this reference to access its variables or functions. It's slower than accessing variables inside the same script - and a lot more complicated, for sure.
An additional reason to concentrate things in one script: after some time, your project will become crowded with lots of scripts - much of them you just can't remember exactly for what were written!

Comment
Add comment · Show 5 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image sHTiF · Sep 14, 2011 at 01:43 AM 0
Share

Thanks for the answer but thats nice when working on small projects or when you don't need modularity. For anything more complex you can end up with huge single Enemy script that would be hardly readable. Having a lot of classes is not a problem if you know what you are doing and if you want to change something you can go to that specific module and change it.

avatar image syclamoth · Sep 14, 2011 at 03:51 AM 0
Share

You can have one $$anonymous$$onoBehaviour attached to each object, but here's the trick- there's no reason why you can't just use normal modularity inside of that! Especially if you use the [System.Serializable] attribute on your classes, which allows them to be modified from the editor. Also, if you know where the other Component is going to be ahead of time, you can get around having to use GetComponent by assigning as much as you can inside the editor.

avatar image aldonaletto · Sep 14, 2011 at 12:46 PM 0
Share

You must find a middle point: a too complex script may drive you crazy when making changes, and too many simple scripts may be highly inefficient. Life with lots of scripts is expensive: periodic functions like Update (the worst case), FixedUpdate, OnGUI, LateUpdate etc. must be called in all scripts where they are declared - five simple Updates will consume more time than a single complex one due to the calling process. Things go worse if they must exchange data - even if you get the script references during Start, because you'll have an extra indirection addressing level anyway.

avatar image sHTiF · Sep 14, 2011 at 04:05 PM 0
Share

Thanks guys for the tips.

@syclamoth yes thats what i was saying as an option 2 thats why i said all the other classes would be managed not necessarily as components. This way i can bring for example behavior classes from my other projects with almost zero code rewrite. And simply call their respective methods from the EnemyController Update.

@aldonaletto thanks i was aware of that but its nice to have it confirmed. I would resolve in decoupling on project level as much as possible. For example since all enemies use waypoint motor i will inject this code directly into enemy super class rather than instancing it separately. I will do some profiling as well really curious about the difference.

Just to be on the safe side here one more question whats the priority of Update calls for components on game object, are they called in the order they were attached?

avatar image CraptainRob · Sep 23, 2012 at 09:11 PM 0
Share

Here is the documentation relating to your question about execution order... http://docs.unity3d.com/Documentation/$$anonymous$$anual/ExecutionOrder.html http://docs.unity3d.com/Documentation/Components/class-ScriptExecution.html

I, too, am struggling with the balance between lots of modular components vs several larger components. Generally I've been trying to keep fewer components at first and split them up if they get too complex or I find a need for part of one to be used by many other components.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Welcome to Unity Answers

If you’re new to Unity Answers, please check our User Guide to help you navigate through our website and refer to our FAQ for more information.

Before posting, make sure to check out our Knowledge Base for commonly asked Unity questions.

Check our Moderator Guidelines if you’re a new moderator and want to work together in an effort to improve Unity Answers and support our users.

Follow this Question

Answers Answers and Comments

5 People are following this question.

avatar image avatar image avatar image avatar image avatar image

Related Questions

trouble accessing components from handles 2 Answers

Animated character FBX workflow question 1 Answer

Retrieving Script component from gameobject. 0 Answers

Model - get mesh component 0 Answers

Character controller not fitting through door 0 Answers


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges