S60第二版(FP2)SDK帮助,开发者指南译文（游戏开发部分）（二）

游戏的结构和游戏循环
游戏循环和游戏的整体结构是任何游戏最重要的事情。适当的结构设计会使游戏开发更加简单。这一章给出了S60 Avkon的程序结构和游戏循环的实现。

S60 Avkon程序的document-view结构比较适合游戏，一个游戏的典型结构如下：
        AppUI：游戏的控制器。它来控制游戏的视图，菜单命令和其他的用户输入（通过传递它们来实现动态视图）。
        View：拥有游戏的引擎（或者是一部分），从引擎来显示游戏状态，处理视图的UI控制和其他用户输入。
        Document：用来存储游戏引擎的状态。然而很少在实际中应用。
        Engine：游戏引擎自己。用来在单独的类里面实现游戏的逻辑部分—不是全部到UI里面（AppUI 或者view）。这就澄清了一个程序里的结构和类的职责。引擎有时候和视图混在一起，这是不可避免的，因为视图处理用户输入和为引擎画游戏画面。

有两种方法实现程序中的多状态和多屏：
        使用多视图（例如，介绍，主菜单，设置，游戏画面）。
        使用单视图。

如果使用单视图贯穿游戏，那可能会使引擎的实现变得简单，那样它就是被appUI所拥有。因为appUI和view处理用户输入，view显示游戏状态，通常在创建engine时在view中加以引用。这使游戏的结构有些模糊。

使用单视图使处理用户输入和画图非常零乱，因为单视图需要有条件的依赖程序状态，特别是大游戏。

当游戏被分为多个逻辑视图，用户的输入和画图就能够被清晰的封装在单独的类中，例如：
        游戏介绍视图。
        主菜单视图。
        设置窗口视图。
        游戏视图。

既然Avkon结构提供了现成的显示多视图的框架，上述的方法就相对容易实现并且使游戏结构清晰。在这种方法中，AppUI的功能仅仅是用来管理多视图。

两种方法都有它们的利弊，由开发者来决定是否使用多视图。特别是图片容器和声音类，如何从每一个视图读取它们可能会引起问题。

典型的游戏循环是由计时器构造的，计时器更新游戏状态，用户输入的处理不受计时器的约束。通常计时器在视图中实现，视图传递计时器事件给引擎并且定期更新视图：

void MyGameView::MyTimer()
   {
   iMyEngine->NextFrame(frameTime);
   UpdateDisplay();
   }

另外一种可能性是程序的引擎有内部计时器，但是通常在视图中保持一个单独的计时器会容易些-否则执行可能变得混乱，因为引擎会更新视图，视图会传递用户输 入给引擎（两种方法寻址）。如果游戏引擎包含动态对象（多任务），当动态对象准备好时，那就可能有必要在引擎更新屏幕之前缓冲的时候调用方法，视图总是显 示最新的整桢—可能出现的情况几乎是无限的。