Main-loop vs Event driven.

So I come from a c/c++ background, and making games required that you make a main game loop and all of that fun stuff. Recently i decided to learn and make games using C# and OpenTK and while reading the documentation I came across the following.

"If you come from a "main-loop-background" (C/SDL/Allegro etc.) when it comes to coding games, you'll have to rethink that fundamentally. You'll have to change into a mindset of "what event should I hook into, and what events should I trigger, and when?" instead."

So I was wondering, what are the trade off's or what are the benefits? Are event driven games the future? From what i can tell they're a bit more complicated.

Thanks.
Adam.

eh? Not quite following that, SDL is totally equipped to create event driven games and allows low level acces to the event queue, maybe the article is referring to the callback method employed in higher level gui type event handling, which would mean a change in your thinking yes.

For example using the FLTK once a button object has a callback attached to it then GUI events are handled for you whenever the callback is invoked. You do not have to worry about the event loop per se, as it is not exposed, you also do not have to define all fundamental actions
e.g for a button widget, a 'mouseover' type event will not do anything (at the programmer user level), you have to dig deeper to define that, it is only button clicks that are handled by default and you monitor them with a boolean state variable in your callback.

Quote:

---

"If you come from a "main-loop-background" (C/SDL/Allegro etc.) when it comes to coding games, you'll have to rethink that fundamentally.

---

If this approach is not used (the main loop one) then I would call that a fundamental flaw in the design of the system. Events can be used to support the main loop and/or do other 'tasks' the main loop does not care about (usually in the Update() portion of the loop) but you still need a main loop.

A purely event driven system as in the render and update are also event driven is a very poor design for a game engine. You run into all kinds of issues when trying to implement this type of system. Do you really want to fire update and render events every 16.6667 ms to achieve 60 FPS? How can you guarantee your event is the only one in the event queue at the time it is fired? This means events need priority but when you introduce that type of system with multiple users every user tends to think their event has highest priority which essentially boils down to no one has priority. Rendering and updating need to be done as fast as possible and there is no guarantee that is going to happen in a purely event driven system. This is why Windows Forms, MFC, and other GUI APIs are terrible for games - they rely solely on events but games by their very nature are not sitting there waiting for events all the time. A game is constantly rendering...a windows GUI app is not. Even when a game appears to be doing nothing there is a ton of math and other operations being performed just to keep the system running.