How should I design game object dependencies between windowing, input and behavior systems?

Question

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.

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.