The argument that you "need a loop because otherwise what calls the event listener" does not hold water. Admittedly on any mainstream OS, you do indeed have such a loop, and event listeners do work that way, but it is entirely possible to make an interrupt driven system that works without any loops of any kind.

But you still would not want to structure a game that way.

The thing that makes a loop the most appealing solution is that your loop becomes what in real-time programming is referred to as a cyclic executive . The idea is that you can make the relative execution rates of the various system activities deterministic with respect to one another. The overall rate of the loop may be controlled by a timer, and that timer may ultimately be an interrupt, but with modern OS s, you will likely see evidence of that interrupt as code that waits for a semaphore (or some other synchronization mechanism) as part of your "main loop".

So why do you want deterministic behavior? Consider the relative rates of processing of your user s inputs and the baddies AIs. If you put everything into a purely event based system, there s no guarantee that the AIs won t get more CPU time than your user, or the other way round, unless you have some control over thread priorities, and even then, you re apt to have difficulty keeping timing consistent.

Put everything in a loop, however, and you guarantee that your AIs time-lines are going to proceed in fixed relationship with respect to your user s time. This is accomplished by making a call out from your loop to give the AIs a timeslice in which to decide what to do, a call out to your user input routines, to poll the input devices to find out how your user wants to behave, and call out to do your rendering.

With such a loop, you have to watch that you are not taking more time processing each pass than actually goes by in real time. If you re trying to cycle your loop at 100Hz, all your loop s processing had better finish up in under 10msec, otherwise your system is going to get jerky. In real-time programming, it s called overrunning your time frame. A good system will let you monitor how close you are to overrunning, and you can then mitigate the processing load however you see fit.

An event listener is also dependent on some invocation loop whether you see it or not. Who else is going to call the listener?

Building an explicit game loop gives you absolute control on what s going on so you won t be dependent on whatever some toolkit/event handling library does in its event loop.

A game loop (highly simplified is as follows)

initialise
do
     input
     update
     render
loop
clean up

This will happen every frame the game is drawn. So for games that run at 60fps the above is performed sixty times every second.

This means the game runs smoothly, the game stays in sync and the updates/draws per cycle happen frequently enough. Animation is simply a trick of the eye, objects move between locations but when played quickly enough they appear to be travelling between these locations.

If you were to only update on user input, the game would only react when the user was providing input. Other game components such as A.I game objects would not react on their own. A loop is therefore the easiest and best way of updating a game.

It s not true that all kind of games require a dedicated main game loop.

Action games need such a loop due to frequent object updates and game input precision.

On the other hand, I implemented a minesweeper game and I used window
messages for the notifications.

It s because current operating systems aren t fully event based. Even though things are often represented as events, you ll still have to create a loop where you wait for the next event and process it indefinitely (as an example the Windows event loop). Unix signals are probably the closest thing you get to events on an OS level, but they re not really efficient enough for things like this.

In practical terms, as other people have indicated, a loop is needed.

However, your idea is theoretically sound. You don t need a loop. You need event-based operations.

At a simple level, you can conceptualize the CPU to have a several timers;

• one fires on the rising edge of 60Hz and calls the blitting code.
• Another might be ticking at 60kHz and be rendering the latest updates of the objects in the game world to the blitter buffer.
• Another might be ticking at 10kHz and be taking input from the user. (pretty high resolution, lol)
• Another might be the game heartbeat and ticks at 60MHz; AI and physics might operate at heartbeat time.

Of course these timers can be tuned.

Practically, what would be happening is your would be (somewhat elided) like this:

void int_handler1();
//...
int main() 
{ 
  //install interrupt handlers
  //configure settings
  while(1);
}

The nature of games is that they re typically simulations, and are not just reacting based on external events but on internal processes as well. You could represent these internal processes by recurring events instead of polling, but they re practically equivalent:

schedule(updateEvent, 33ms)

function updateEvent:
    for monster in game:
        monster.update()
    render()

vs:

while 1:
    for monster in game:
        monster.update()
    wait(33ms)
    render()

Interestingly, pyglet implements the event-based method instead of the more traditional loop. And while this works well a lot of the time, sometimes it causes performance problems or unpredictable behaviour caused by the clock resolution, vsync, etc. The loop is more predictable and easier to understand (unless you come from an exclusively web programming background, perhaps).

Any program that can just sit there indefinitely and respond to user s input needs some kind of loop. Otherwise it will just reach the end of program and will exit.

The main loop calls the event listener. If you are lucky enough to have an event-driven operating system or window manager, the event loop resides there. Otherwise, you write a main loop to mediate the "impedance mismatch" between an system-call interfaces that is based on I/O, poll, or select, and a traditional event-driven application.

P.S. Since you tagged your question with functional-programming, you might want to check out Functional Reactive Programming, which does a great job connecting high-level abstractions to low-level, event-based implementations.

A game needs to run in real-time, so it works best if it is running on one CPU/core continuously. An event-driven application will typically yield the CPU to another thread when there is no event in the queue. There may be a considerable wait before the CPU switches back to your process. In a game, this would mean brief stalls and jittery animation.

Two reasons -

Even event driven systems usually need a loop of some kind that reads events from a queue of some kind and dispatches them to a handler so you end up with an event loop in windows for example anyway and might was well extend it.

For the purposes of animation you d need to handle some kind of even for every frame of the animation. You could certainly do this with a timer or some kind of idle event, but you d probably end up creating those in some kind of loop anyway so it s just easier to use the loop directly.

I ve seen systems that do handle it all using events, they have a frame listener that listens to an event dispatched at the start of each frame. They still have a tiny game loop internally but it does little more than handle windowing system events, and create frame events,