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

What is an elegant / common way to build a relationship between the game scene / environment / world and the HUD that usually sits on top of it? I have thought about this for a while, and though there are ways to accomplish this that are easy to implement, they always seem to expose too much unrelated information between the two, or end up being too coupled. An example of this that I have used in the past would be to simply pass reference from the HUD to the Environment and vice-versa (which is obviously not a good apporach for many reasons, especially when aiming for low coupling).

What I want to end up with is a clean, uncoupled way to do things like:

  1. From the HUD; reference and manipulate objects within the environment, change the state of the Environment itself.
  2. From the environment; update the HUD to reflect the current state of the environment.

Maybe passing reference between the two is the way to go about this, but I feel like there's some pattern that I am missing for this type of task. Any insights into past experience and implementations concerning this type of problem would be very helpful.

share|improve this question
Looking at standard UI architecture patterns like MVC and observer might be helpful to you. – Nathan Reed Feb 4 '14 at 2:26

The game⟷HUD relationship can be pretty well-expressed using the Model-View-Controller (MVC) paradigm. The Model is the programming logic, and has no concept of user interaction. A View is a way of somehow communicating information from the Model to the user, while a Controller is used to let the user interact with the Model.

MVC outline

We can think of the game logic as the Model in this instance. Actually, many game architectures already use an approach similar to MVC. The rendering, sound, and input systems are usually decoupled from the physics and logic, and so it is easy to fit in the HUD as a combination of a View and Controller (in many games the HUD doesn't even need to be a Controller).

The implementation of an MVC architecture varies wildly. A simple game will likely have the Views directly read data from the Model and the Controller will call certain functions that the Model exposes. If your game uses a physics engine, it's likely that you'll have split up your game loop so that the physics and logic runs at a constant rate, while the input and rendering are synchronized with the monitor refresh rate. In this case, the Model will spit out game state snapshots which the View will read and interpolate between, and the Controller will queue up events into a buffer.

The advantage of using MVC is that your game engine is separated into two main decoupled areas. The Model is one, and it is isolated from the workings of the View and Controller. In many cases, the View and Controller overlap, such as with the HUD, so they are the second layer. It's usually fine for stuff like that to be coupled more tightly, as the Controller needs to know that you've actually clicked within some rectangle to build a unit, for example.

Incidentally, the View-Controller layer is the only one that should need to change if you are porting from one platform to another. The Model doesn't care whether you're playing on a PC, a Mac, a Playstation, or an iPhone. You can build different Views and Controllers to deal with different rendering libraries or input devices, and use them with the same Model.

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.