Homing Missile with Loose Coupling

[Alpha Remex]

So I am creating a side scrolling Gradius-esque game using OOP techniques. I've got a pretty good set up so far: I have a CollisionManager class that tracks all enemies, bullets, and the "hero"... it dispatches an event when a collision occurs so that each object can independently handle animations and status changes without having to be tightly coupled with other classes.

The problem I am running into is the issue of bullet behavior. I have different types of bullets (i.e., blaster, missiles, etc). And I want to give the missiles a homing effect without giving it a reference to it's target object which would mean that the bullet would always have to be aware of where the target is.

Instead, I would guess that the path to loose coupling would take me to an MVC type design with a Controller determining the behavior of the bullet.

Am I over-thinking this here? I wanted to throw out my conceptual dilemma to see if anyone has an easy design solution...

Let me know what you think.
AR

[IQAndreas]

Instead of the homing missile containing a reference to the "target" (who I'm guessing is either the hero or enemies), the bullet asks the CollisionManager for where to attack.


Or you could still put a "target" property (x and y coordinate, or a Point) in the bullet class, and when it is added to the CollisionManager, each frame (or set period of time) the CollisionManager updates this property in the bullet class to reflect the new location of the item.


Or, if all enemies, bullets, and hero subclass a specific class, such as CollisionObject (which might be a good idea), the bullet can contain a reference to a CollisionObject. Whenever the target is destroyed or changes, the CollisionManager updates the property on all bullet instances.

That way, if you swap out the hero with another class, or want to use the bullet with another project, since you are guaranteed to be using a CollisionObject (since you will be needing one for the bullet's class), and as long as the bullet only needs access to CollisionObject properties and not any properties unique to the hero or enemy class, it should work quite smoothly.


I'm not sure of the best technique though, and I'm still learning design patterns and efficient coding, but I'm sure there are others with more professional experience who have two cents as well.

[Alpha Remex]

Instead of the homing missile containing a reference to the "target" (who I'm guessing is either the hero or enemies), the bullet asks the CollisionManager for where to attack.


Or you could still put a "target" property (x and y coordinate, or a Point) in the bullet class, and when it is added to the CollisionManager, each frame (or set period of time) the CollisionManager updates this property in the bullet class to reflect the new location of the item.


Or, if all enemies, bullets, and hero subclass a specific class, such as CollisionObject (which might be a good idea), the bullet can contain a reference to a CollisionObject. Whenever the target is destroyed or changes, the CollisionManager updates the property on all bullet instances.

That way, if you swap out the hero with another class, or want to use the bullet with another project, since you are guaranteed to be using a CollisionObject (since you will be needing one for the bullet's class), and as long as the bullet only needs access to CollisionObject properties and not any properties unique to the hero or enemy class, it should work quite smoothly.


I'm not sure of the best technique though, and I'm still learning design patterns and efficient coding, but I'm sure there are others with more professional experience who have two cents as well.

This is exactly what I was looking for. You just blew my mind!

Thanks for the help!
AR

[efos]

Or you could still put a "target" property (x and y coordinate, or a Point) in the bullet class,

You could also extend the Point class to include course and speed; this allows the homing object to lead the target as needed.