Игровой цикл это общая и наиболее важна часть всех существующих игр. Хорошо спроектированная структура игры значительно упрощает разработку. В этой главе будет приведен пример реализации структуры игрового цикла для Series 60 Avkon приложения.

Архитектура представления вида документа Series 60 Avkon вполне подходит для использования в играх. Типичная структура игры выглядит следующим образом:

• AppUI: контроллер игры. Этот блок управляет представлением игры и меню, а также другими действиями пользователя (можно сказать, что это менеджер, обеспечивающий переключение между различными экранами).
• Вид: Это часть игрового движка, которая отвечает за отображение игры (в зависимость от состояния движка), элементов пользовательского интерфейса и обработку действий пользователя.
• Документ: Используется для сохранения игрового состояния движка. На практике этот блок реализуется редко.
• Движок: Этот вынесенный в отдельный класс блок отвечает за логику игры. Движок иногда объединяется вместе с Видом.

Существует два подхода к реализации разных экранов (игровых режимов) в приложении:

1. Использовать несколько видов (например, в главном меню, меню опций, собственно игре).
2. Использовать один вид.

Если используется второй вариант, то упрощается реализация движка, поскольку он сливается с appUI. AppUI и вид совместно обрабатывают пользовательский ввод, вид отображает текущее игровое состояние. Это делает структуру игры нечеткой.

Когда игра разбивается на несколько логически обоснованных видов, обработка пользовательского ввода и рисование могут быть размещены по разным классам, например:

• Вид для заставки перед игрой.
• Вид для главного меню игры.
• Вид для меню настроек.
• Вид для самой игры.

Архитектура Avkon предоставляет среду, уже готовую для реализации нескольких видов. Этот подход относительно прост в реализации и позволяет четко обозначить структуру игры. При использовании этого подхода AppUI просто обеспечивает переключение между различными видами.

Каждый из описанных методов имеет свои достоинства и недостатки. Разработчик должен решить, какой подход использовать. Особенно важно продумать реализацию работы с классами изображений и звуков. Практика показывает, что получение доступа к этим классам из разных видов может вызвать проблемы.

Обычно игровой цикл использует таймер, который обновляет состояние игры. Пользовательские действия обрабатываются независимо от таймера. Как правило, таймер реализуется внутри вида, который передает события от таймера движку и периодически обновляет вид.

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

Есть еще одна возможность. Внутренние таймеры можно реализовать внутри игрового движка, однако, проще использовать отдельный таймер в каждом из видов. В противном случае логика становится запутанной - движок должен обновлять вид, а вид должен передавать пользовательский ввод на движок. Неосторожность в кодировании может привести к непредсказуемым последствиям.

Перевод:aRix.