所有这些几乎都有一个循环 - 但在大多数开发过程中，这不是您会考虑的东西。

如果您退一步思考，您的Web应用程序是基于循环构建的 - Web服务器的accept()循环。

while(listening) {
     get a socket connection;
     handle it;
}

作为一名Web开发者，你可以屏蔽它，编写事件驱动的代码-当有人请求此URL时，执行此操作。

GUIs are also event driven, and the events are also detected by a loop somewhere:

while(running) {
    get mouse/keyboard/whatever event
    handle it
}

但GUI开发人员不需要太考虑循环。他们会写：当鼠标点击发生在此时，做这个。

游戏，再一次。有人必须写一个循环：

while(game is in progress) {
    invoke every game object s  move one frame  method;
    poll for an input event;
}

当其他代码以更事件驱动的风格编写时：当子弹对象与此对象相遇时，触发爆炸事件。

对于应用程序和游戏来说，软件是事件驱动的。用户通过键盘或鼠标操作"做某事"，并将该事件发送给软件的其余部分。

在游戏中，游戏循环非常重要，因为它专注于处理屏幕和游戏状态。许多游戏需要实时性能。随着现代3D图形API的出现，许多屏幕处理工作可以转嫁到GPU上。然而，游戏状态由主要循环跟踪。游戏团队的努力大部分集中在使循环处理非常流畅。

对于应用程序，通常在一个线程上派生重量级处理。这是一个复杂的主题，因为两个尝试访问相同数据的问题。关于这个问题有整本书。

对于应用程序，顺序是：

1. user does X, X and associated information (like X,Y coordinates) is sent to the UI_Controller.
2. The UI decides which command to execute.
3. The Command is Executed.
4. The model/data is modified.
5. The Command tells the UI_Controller to update various areas of the UI.
6. The UI_Controller redraws the UI.
7. The Command returns.
8. The Application waits for the next event.

这有几个变种。该模型可以让听众等待数据的更改。当数据改变时，监听器会执行并重新绘制 UI。

就游戏编程而言，我只是个业余爱好者，但这通常是我所做的事情：

我有一个代表游戏中"场景"非常通用概念的物体。所有游戏中不同的主要部分都源自这个场景对象。一个场景可以是任何东西，取决于是什么类型的游戏。无论如何，每个派生自场景的更具体场景都有一个过程来加载该场景所需的所有元素。

当游戏需要切换场景时，指向活跃场景的指针被设置为新场景，随后新场景将加载所有所需的对象。

通用的场景对象有虚函数，如Load，Draw和Logic，它们在游戏循环中从活动场景指针调用。每个特定的场景都有自己实现这些方法的方式。

我不知道那是否是该怎么做的方式，但对我来说，这是个非常容易控制事物流程的方法。 场景概念也让我能够将多个场景存储为集合。同时，多个场景指针存储在某种堆栈中，场景可以被储存备用，并在返回时保持其完整状态，甚至可以像调暗一样持续绘制，而活动场景则会以某种叠加的形式覆盖在其上。

无论如何，如果你像那样做，它并不完全像一个网页，但我想如果你以正确的方式思考，它是足够相似的。