This is my first time attempting to create a game engine. I came across a theoretical problem and would like to solve it before implementation. Right now I have a WindowSystem, which opens the window, sets the GL_CONTEXT, etc. I would like it to be responsible for all things window. Then I have another system that manages input called InputSystem. Then I have a BehaviorSystem for game object behavior.

The problem: Consider a game object representing a menu where it has options to change the resolution/other graphics settings. How can I link these three systems with minimal coupling so that a Behavior script can close the window? Normally systems interact through components, but there's no component for the window. From what I've read systems shouldn't know about each other. I haven't a clue how I could go about such a scenario.

  • \$\begingroup\$ Hello and welcome to Gamedev.SE! Questions that are not game development specific, are considered offtopic. In other words, it does not take an expert in gamedev to answer this, but any programmer, thus its more suitable for stackoverflow. However, observer pattern might help. \$\endgroup\$
    – Katu
    Jun 27, 2016 at 6:55
  • \$\begingroup\$ The data for your window configuration should be in a component... \$\endgroup\$
    – Vaillancourt
    Jun 27, 2016 at 12:27
  • \$\begingroup\$ Aye but then is it really worth every entity having a window component? I thought about making it part of the behavior component. The window system during init will give the behavior component a reference. Every update the input system will give the behavior component a list of keys. Then you can use this right in your behavior code like "If (Keys.down['up'])" \$\endgroup\$
    – gjh33
    Jun 28, 2016 at 23:08

1 Answer 1


There's no one right answer for communication between different domains of any piece of software. In your case, it sounds like you want something like an "event" system. You should give your systems the ability to subscribe to events that other systems "raise" with information about the event. The Observer Pattern is a common pattern when implementing events.

For example, System A is interested in Event E from System B. You can pass System A an interface it can use to register a pointer to a function, say EventHandler(Event e), with System B, or it could register a callback interface or a delegate or other similar concept. System B maintains a list of these interfaces/functions and calls them with the event as an argument when it wants to raise the event.

You can also use a "central dispatch" type class that stands in between these two if you think the extra layer of indirection makes your architecture easier to maintain.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .