Search Unity

Any recommended books/resources on component-based design?

Discussion in 'Scripting' started by Deleted User, Jun 25, 2012.

  1. Deleted User

    Deleted User

    Guest

    Hey all :)

    I come from a background with heavy use of the classical object-oriented paradigm for software development.

    The company I am a part of switched to Unity not too long ago, and we're all very excited to get started using it :) However, one aspect that have sparked my interested, and which I think will become a very important part of our future development, is Unity's approach to component-based design with scripting; with less focus on typical hierarchical aspect.

    I was wondering if anyone could recommend any good books on this subject? I have had trouble finding any books or books with reliable reviews, and was wondering if anyone more experienced here had something to say on the issue? :)

    Any other kind of resource would be excellent too, I'm just interested in getting to learn everything I can about it.

    Thank you all for your time!
     
  2. leonardozimbres

    leonardozimbres

    Joined:
    Jul 9, 2012
    Posts:
    29
    Im on the same boat. Discovered some nice articles around the web, like this one: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy

    But I'm feeling a little afraid to step on the water. I would love to read more about the component based design, instead of dumb tutorials about "how to do a fps"or things like that.
     
  3. LightStriker

    LightStriker

    Joined:
    Aug 3, 2013
    Posts:
    2,717
    My 2 cents...

    Don't try to "fit" in the component mentality without understand why something is done in a specific way. Also, don't force your design into pure component, because it will come back bite you in the ass later. Polymorphism and class hierarchy is simply too big a feature to put it aside.

    Components are there to help you when they make sense to be used. The idea of having an object with visual and/or collision is a good example. It makes no sense to hard-code something that handle both visual rendering and collision detection in the same package. Sometimes you'll want one, or the other, or both at the same time. Alright... You got an object that can collide and/or be rendered. How about skeleton and animation? Sound emitter? FX emitter? Components are there to answer the problematic of endless possibility of combination of the different behaviour that can be put on an object.

    However, the combination has to make sense. Putting a FX emitter and a collider on an object is fine. Those two components perform such a different task that they don't need any communication. It becomes a bit more problematic when you create a "Path Finding" component and a "Enemy Attack Behaviour" component. Those two will have to talk to each other and one may need to drive the other. At that point, maybe "Path Finding" shouldn't be a GameObject component, but a sub-component of "Enemy Attack". Or if every character in your game perform path finding the same way, maybe it should be implemented in the character base class and not be a component at all.

    You have to ask yourself, does it makes sense to make it as a building block that can be miss-matched with every other building blocks, or should it be part of a bigger block?