Return to Answer

2. Read this answer on composition over inheritance.
3. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So avoid createPlayer(), createEnemyOne(), createAsteroid(), in favour of createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
4. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).
5. Read this answer on collision detection and entity destruction.

2. Read this answer on composition over inheritance.
3. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So avoid createPlayer(), createEnemyOne(), createAsteroid(), in favour of createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
4. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).
5. Read this answer on collision detection and entity destruction.

1. Read Evolve Your Hierarchy.
2. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So not createPlayer(), createEnemyOne(), createAsteroid(), but instead createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, HealthComponent health, WeaponComponent weapon, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
3. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).

Also see these answers on collision detection, entity destruction and composition over inheritance. They should clear up some of that funk you're in.

2. Read this answer on composition over inheritance.
3. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So avoid createPlayer(), createEnemyOne(), createAsteroid(), in favour of createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
4. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).
5. Read this answer on collision detection and entity destruction.

1. Read Evolve Your Hierarchy.
2. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So not createPlayer(), createEnemyOne(), createAsteroid(), but instead createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, HealthComponent health, WeaponComponent weapon, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
3. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).

1. Read Evolve Your Hierarchy.
2. Use one single method to create different entities, this leads to more maintainable code since configuration-specifics belong in external data files, not in code. So not createPlayer(), createEnemyOne(), createAsteroid(), but instead createEntity(int id, string type, PhysicsComponent physics, SpriteComponent sprite, HealthComponent health, WeaponComponent weapon, ...) with parameters being either primitives or complex objects themselves, and collectively specifying a unique object such as an asteroid.
3. Use the builder pattern specifically because you need a class dedicated to translating said configuration data into concrete entities, while maintaining separation of concerns between classes (e.g. your game class "Main" should not be constructing entities, but it should be delegating the task to another class).

Also see these answers on collision detection, entity destruction and composition over inheritance. They should clear up some of that funk you're in.