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

I'm programming a basic Pacman clone to teach myself game programming. However, I'm struggling with the best way to have the game objects communicate/interact without my code becoming a huge mess.

Right now, I have a stack (implemented as a list) of objects in my base Game class. These objects include components such as Graphics, Input, etc. as well as "actual objects" such as Map, Pacman, etc. While running the game, the Game class loops through all of the objects and updates the ones which want to be updated and draws the ones which want to be drawn.

However, these objects must obviously interact. I implemented a Link function on the objects which allows one object to be "linked" to another; i.e. it gives one class a pointer to the other class so interaction can take place. For example, the Pacman class may use Link to be given a pointer to the Map class so Pacman can determine whether or not it can move in a certain direction.

With a game as simple as Pacman, this structure probably won't be too challenging to maintain, but were a game to have many interacting objects, I suspect the code would get out of hand. Is the method I am using right now alright, or should I look at another implementation of object communication? If so, what would you recommend?

I've looked at Communication between objects in games?, but whenever I try to implement the mediator pattern, I end up with a giant mediator class which is a challenge to maintain. Is the mediator pattern what I should be using?

share|improve this question
Could you list all the specific game elements and how they are supposed to interact? Then we could propose a specific OO design instead of just providing links to design patterns and the like. – BerndBrot Aug 25 '12 at 13:15

In a small game like Tetris and perhaps Pacman, having everything know about everything is probably ok. In a larger game, an RPG, RTS, or any game with many subsystems and interactions, an event system can help. You lose some typesafety in the programming language, but you can decouple dependencies.

Instead of explicit function calls, game objects communicate by creating and consuming events. The event can be a single string, or a string/desciption of the event pluss one or more parameters. This is up to you. By using strings, your program will become more error-prone (typos) and maybe slower (an optimization is to use hashed strings). You could define events using a specific type in C++, allowing you to take advantage of compiler typechecks, but you lose the flexibility of defining new events at runtime. Plus, all users of that event will have to include it.

Here are some links:

Java Entity-framework

C++-based entity-event system in development

Mike McShaffry has a chapter on event-systems in his book Game Coding Complete.

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.