How can I give the mouse position to my GameObject nicely?

Question

I am making a basic Asteroids game in SFML, and I want the Player ship to always look at the mouse. I have a LookAt(x,y) function which works, but I am not sure how to get the mouse position from the Player's Update() method!

I see several possible solutions to this:

• The LookAt(x,y) function is changed to be public, and instead of the Player calling it within its own Update() function, it is called externally (maybe in an Update() function in the GameManager class, which has access to both the Player and the InputManager)

• The Player is given a pointer to the mouse position on creation, which is updated every frame in the InputManager on MouseMotion

• The Player is given a pointer to the InputManager, which it can then use in the Update() function to access mouse coordinates.

• The InputManager class is made 'static', and the Player accesses the mouse position directly via InputManager.GetMousePos()

Ideally I want the Player's behaviour to be contained. I don't feel that it is neat to create new properties, functions or callbacks outside the player class just so that the player has access to two integers. The last solution (making the InputManager static) seems neat to me (especially since it only requires 1 new line of code in the Player class, and doesn't require the Player to hold onto new properties), but I've heard that using singletons is an 'anti-pattern' and should be avoided!

Answer 1

It sounds to me like you want to look into the Components design pattern. This link does a much better job of explaining it than I could ever hope to do however in order to make sure this answer isn't useless in case the link ever dies I'll try to summarize it briefly.

Using a component pattern means that an entity (your player) can interact with another system in your engine(input manager) without ever having to really know each other. This gives you a neatly decoupled system where you could later swap the input component without having to change the player entity or if you wanted to have an enemy ship in your game as well you could use the class already created for the player, just switch the input controlling component from a keyboard/mouse to an AI.

There are of course multiple ways of doing this - my preferred one is to have each Entity have a list of Components that it iterates over each update and let those Components decide what happens to the Entity. This is excellently summarized in the above link as:

A single entity spans multiple domains. To keep the domains isolated, the code for each is placed in its own component class. The entity is reduced to a simple container of components.

In your case I'd say the Pros would be that it looks neat and is extensible as well as works great if you do more components such as physics/sound/etc and the Cons would be it's a lot of new code if you don't plan to do more with it. If you just want a quick and dirty solution I would go with making the input manager a singleton and just call it a day.