- Home /
Component-based design: Do I have the right idea?
I'm wondering if I have the correct idea of what a component-based design pattern looks like, and figured I'd ask here.
The way I understand it is as follows.
Each component is a separate class, and our 'entity' is the class that contains these components.
For example, we might have three components: a DoMove class, a Combat class, and an AI class.
Entity A might represent the player, and so Entity A has no need for the AI class, hence, his 'entity container class' contains only the DoMove and Combat classes.
Entity B might represent an enemy who needs AI, and thusly has all three classes.
This is where I get confused, though. Is the entity 'container class' used to do anything, or is it simply a container class that some other class (GameManager? CombatManager? Some kind of state-machine?) might make use of?
For example...
//Our entity container. Would this be appropriate in traditional component-based design?
class Player : MonoBehavior {
private DoMove move;
private Combat combat;
void Start(){
move = gameObject.GetComponent<DoMove>(); //Get our DoMove script on our gameObject
combat = gameObject.GetComponent<Combat>(); //Get our Combat script on gameObject
}
void Update(){
if (Input.GetAxis("Vertical" > 0 && !move.isMoving) //If we're not already moving, allow move.
move.StartMove(transform.forward);
if (combat.combatStart)
combat.DoCombat();
}
}
Hopefully I'm making some sort of sense here.
Answer by srivello · Sep 01, 2013 at 04:13 PM
What you are doing is architecturally logical and in the spirit of Unity's component based design.
An alternative idea, that I think is MORE commonly used is here; Your DoMove and Combat components have their own script and thus their own Update() handler. You can put code in the Update() of each and NOT call it from the Update of Player.