I am presently working on a game in Unity3d and have come to a cross road regarding scripting for repetitive child objects. Should these child objects handle its own scripting for best practice?

For example, I have a parent game object, Game Board, that spawns repetitive child objects, Tiles, on the board. Right now, I let these child objects handle its own position on the board and its own animation when the tiles move. However, I can just as easily do this with the parent object's scripting class.

The reason I chose to let the child object do so is because I believe that child objects should be as independent to the parent object as much as possible. But since these are repetitive child objects, I start to wonder if it is just as easy to do all the scripting in the parent object. This way I decrease the number of class instances in the child objects.

According the component-based programming, which method is recommended?

  • \$\begingroup\$ What do tiles do that are so complicated as to warrant them being whole game objects? That would maybe alter the answer I'd give, but in general, one script for the whole logical unit of "game board" is probably best (also, the tiles are really just part of a generated game board mesh if they don't animate, they don't need to be separate objects at all in that case). \$\endgroup\$ Jul 22, 2013 at 7:37
  • \$\begingroup\$ answers.unity3d.com PS: you shouldn't worry too much, Unity itself cuts corners on component-oriented design. \$\endgroup\$
    – Den
    Jul 26, 2013 at 18:21

1 Answer 1


The "recommended" method here is going to depend heavily upon what your tiles are actually used for/doing. As Sean says, there's no explicit need to treat the tiles as components if they aren't behaviorally distinct. I.e., are tiles just a visual backdrop for the real action, as in chess?

That said, since you mention the tiles "moving," it seems unlikely that this represents a traditional physical board game. In that case, you'll want to err on the side of clarity - if it makes sense to you (and to any other devs on the project) to treat the tiles as components, do so. The overhead from additional scripts whirring away isn't generally significant [citation needed], but you can optimize away from that later if it becomes necessary.

(In my own games, I haven't yet noticed any kind of performance hit from running many hundreds, even thousands, of component-y scripts. I keep them light. Raw draw calls and unnecessary instantiations have had a much larger impact on frame rate. Even then, I do lump together some methods/data for clarity and ease of implementation.)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .