为什么游戏大都用循环而不是事件？

我个人的观点是

不管你是不是循环，总会有个循环在控制着一切，而且主流操作系统本身就是循环的。
中断结构（基于事件驱动）更加复杂而且有着更多的不确定性，在开发期间需要控制的东西更多
比如优先级、连续触发中断的限制、中断细分到何种程度等等
所以使用循环可以节约很多脑细胞

链接中的高票答案大致意思是：

虽然『事件驱动本身也是基于循环的』这个论点是真实的，但是做为这个回答的答案并不成立。完全基于事件驱动的系统理论是存在的
但循环仍是相对事件驱动的更优解

循环可以很好的确定软件的行为，保证系统的各个部分获得的操作合理，比如AI不会比玩家多出更多CPU占用导致游戏操纵流畅度下降。使得游戏流程十分可控

保证游戏按照预定的顺序进行，提供一部分给AI决定动作，提供一部分给玩家的输入来获取玩家输入信息，以及提供一部分时间渲染
在一个100帧的环境下，一个循环需要控制在10ms（一帧）之内。开发者花费更多时间在每一步的动作上，而不用考虑实时的东西

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.

/\__/\