Why do we have to make a child in the enemy ship game object?

So this has been bugging me since the first lecture where Gary made a Game Object called Enemy Ship, then created another inside Enemy Ship 1 to add in a sprite render that has the ship sprite. Then we still have to prefab the whole thing, so why don’t we just make 1 game object? put everything into it (scripts, sprite renderer, rigidbody, colliders…etc) then prefab it? so that we don’t have to have a child in the enemy ship prefab?

or maybe I’m dead wrong and later on, Gary add a ton of enemy ship inside that Enemy prefab of his? But if so, then why did he name it Enemy 0?

Enlighten me guys


The name ‘Enemy 0’ is a pure matter of personal preference. I think that he did that because Unity automatically increments the 0 when the object gets instantiated in the Hierarchy and/or duplicated.

Regarding the parent-child structure, that’s good practice in Unity. We tend to make the visual things part of the child, and move the parent via code. This allows us to animate the game objects without having to worry that the animation overrides the changes applied by our code. A common problem with animations in Unity is that the code ‘does not work’ anymore. It usually does still work but the animation undoes everything, which is unexpected if you don’t know this problem in Unity.

Gary doesn’t animate the enemies in his game but maybe you want to do that in yours. If you keep this parent-child structure and keep the movement in the scene and the visual part separate, you are usually on the safe side.

Did this make sense?

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms