I am designing window management for my engine and I have a dilemma. I don't know if I should make the Window Manager part of the engine, or keep Window Manager as an gateway between user and the engine which sends window events to the engine. And the engine does all the work.

In my current design, there is an Engine object, which on its own is a FiniteStateMachine, so its responsible for changing the game states. It also performs the main loop in my game. Then I attach a WindowInterface to my engine (can be SFML or SDL or whatever). The MainLoop of an engine is implemented this way:

int Engine::run() {
    Timer timer;
        
    while(running) {
        auto event = window->pollEvents();
        if(event) {
            if(event->getName() == "closed") stopRunning();
            peekState()->sendBeforeUpdateEvent(event);
        }
            
        peekState()->update(timer.getElapsedTime<Timer::seconds>());
        window->preRender();
        peekState()->render();
        window->postRender();
        timer.reset();
    }
        
    return 0;
}

But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.

So, every simple implementation (whether its SDL or SFML or something else), the "run" function must be implemented over and over; from programmer point of view it sounds more work. But It makes more sense to have something similar to that from Engine Design point of view, instead of more code writing point of view.

Please give me advice on this situation. I don't know how to keep it. Its not about anything but the actual Engine design.

Thanks,

Gasim Gasimzada

But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.

Then you are second-guessing yourself for no reason.
Normal applications may be event-driven, but games are not. Not even when input is concerned.

There is little need for a window manager at all. A window is simply a gateway for the operating system to send external information to the game. The game does not need to be a slave to this; this information (whether it be inputs or anything else) should be retrieved by the engine at its own convenience at a specific and well defined point within the game loop.
Until that point, all inputs should be cached and the game loop should keep running.

It may be possible to glean some ideas from my post on General Game/Engine Structure.


L. Spiro

Thank you for the help! I was thinking in the wrong direction but not it all makes sense.