Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

To teach myself basic game programming, I am going to program a clone of Pong. I will use the Observer design pattern, with an interface between the input and the game engine. However, I'm not sure what the interface should do. One idea I had was for the input interface to tell the game engine that (e.g.) the screen was clicked, then to let the game engine decide what to do with that information (shoot a bullet, for example). Another idea I had was for the input interface, having caught the mouse click, to tell the game engine to shoot a bullet.

Which method would be better for me to use?

share|improve this question
+1 You could not have picked a better place to start – John McDonald Jun 15 '12 at 3:18
Bullets in Pong sounds interesting. – Byte56 Jun 15 '12 at 6:09
In future I suggest adding implementation language(s) to your tags since architecture might be affected and example given can be tailored to your needs, plus commenting on how experienced a programmer you are in that language will help responders talk with you at the right level. – Patrick Hughes Jun 16 '12 at 14:41
up vote 7 down vote accepted

The first method is an implementation of the observer pattern, the second is not. The observed object (your input interface) should not need to know what the observing object (your game engine) will do with the notification, only that it wants to be notified.

However, I am not sure why you have decided to use the observer pattern here. Unless you are going to be having multiple observers, it seems like a complication that can be avoided. If clicking always does the same thing, then just have the interface tell the game engine to do that one thing. Keeping things as simple as possible makes it easier on yourself. This is not to say never use design patterns, but generally you approach their application in the opposite direction from what you are doing. IE: start with the problem and pick the design pattern to solve it, rather than starting with the design pattern and figuring out how to solve your problem with it.

share|improve this answer
Using new ideas like Observers on simple projects is a good way to learn patterns; since learning is the desired outcome here, not simply getting a Pong game working, I think it would be nice to pad the answer to cover both. – Patrick Hughes Jun 16 '12 at 14:38
As he stated he wanted to learn basic game programming, not design patterns, I think it is easier to focus on that aspect only. If you try to learn too much at once, you end up learning very little. Specifically in this case though, where the pattern might not actually be useful, learning when NOT to use a design pattern is just as valuable as the opposite. – Chewy Gumball Jun 16 '12 at 17:22
I presaged that objection with a comment at the main question for him to include some info on current expertise level in other areas, to avoid confusion in future questions. Based on his wording and appearance of having done some reading ahead I can't agree with you 100%, but can agree enough for a +1 because it is a useful answer nonetheless =) – Patrick Hughes Jun 16 '12 at 20:56

If you want to stick with the Observer pattern, then it has to be the first idea. The strongest argument I could think of is that the input interface is a generic component that you will probably want to reuse in other games too. So it makes sense to keep it free from any game specific information, otherwise you wouldn't be able to use it in another context. In general, think carefully about the responsibilities of your classes, and try to keep them focused, and limited to the context of the class.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.