CAST II Game Engine

   ОПИСАНИЕ       ВОЗМОЖНОСТИ       СКРИНШОТЫ       ФОРУМ       ДОКУМЕНТАЦИЯ       ФАЙЛЫ       КОНТАКТ   

Содержание

Введение в CAST II

Справочник

Уроки


Введение в CAST II

Данная статья должна дать читателю общее представление о движке CAST II, оставляя многое за кадром и не особо вдаваясь в детали. 

Ядро

Важнейшая часть CAST II -- это его ядро, являющееся экземпляром класса TCore. Именно через него управляется движок. Ядро, по большей части, занимается управлением подсистемами и сущностями.

Подсистемы

Каждая подсистема реализует какую-либо функцию (визуализация, ввод, таймер и т.п.). Если реализация функций подсистемы зависит от платформы (и/или API), то такая подсистема реализуется в виде не зависящего от платформы базового класса и классов-наследников, которые содержат зависящую от платформы часть кода.

Подсистемы могут подключаться и отключаться во время выполнения приложения.

Сцена

В CAST II основная работа происходит со сценой, которая представляет из себя иерархию сущностей. 

Обычно сцены собираются в специальном редакторе CASTEd и хранится в файле, с расширением .cbf. Отдельные части сцены (например, уровни), могут храниться в отдельных файлах и подгружаться по мере надобности.

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

Работа со сценой осуществляется через экземпляр класса ядра -- TCore. Например, загрузить сцену можно с помощью метода TCore.LoadScene().

Сущности

Видимые объекты, камеры, текстуры, звуки и т.п. это все сущности -- производные от класса TItem.

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

Также сущности могут обмениваться сообщениями друг с другом, с ядром и программой (игрой).

Сущности имеют ряд свойств, определяющих различные параметры. Получить список свойств можно с помощью метода TItem.AddProperties(), установить, с помощью метода TItem.SetProperties(). Установить конкретное свойство можно с помощью TItem.SetProperty(). Хотя гораздо удобнее делать все это в редакторе.

Игровые объекты (т.е. относящиеся к конкретной игре), наследуются/собираются из подходящих классов сущностей.

Игровой цикл

Каждую итерацию (далее фрейм) основного цикла программы должен вызываться метод ядра TCore.Process(), выполняющий следующие задачи:

  • синхронизация подсистем
  • опрос подсистем на предмет сообщений
  • обновление сцены
  • визуализация сцены
  • отсылка асинхронных сообщений

Т.е. для выполнения вышеперечисленных задач достаточно вызвать этот метод из основного цикла программы.

Сообщения

Разнообразные события, такие как ввод пользователя, сообщения от ОС, различные игровые события и т.п. в CAST II преобразуются в сообщения для дальнейшей обработки. Приложение может добавить свой обработчик сообщений. Хотя многие сообщения обрабатываются движком, тем не менее, сообщения, относящиеся к конкретной игре, должна обрабатывать сама игра. 

Сообщения в CAST II объектно-ориентированные, т.е. каждое сообщение представляет собой экземпляр определенного класса, наследуемого от TMessage. Класс сообщения является его идентификатором. Все это позволяет включать произвольный набор данных в сообщении, а также организовывать их обработку иерархически.

Отправляются сообщения посредством метода SendMessage(), который есть у сущностей, а также у ядра. Комбинируя различные флаги, посылать сообщения можно:

  • конкретному объекту (mfRecipient)
  • непосредственным дочерним объектам какого-либо объекта (mfChilds)
  • всем объектам по иерархии, начиная с определенного, либо с корневого (mfBroadcast)
  • в обработчик ядра, откуда оно попадет и в обработчик приложения (mfCore)

Флаг mfAsync означает, что сообщение будет отправлено адресату не немедленно, а в конце рабочего цикла движка.

Обрабатываются сообщения в виртуальном методе HandleMessage(), который присутствует у сущностей, подсистем и ядра. Аналогичный метод обычно существует и где-то в приложении для включения его в цепочку обработки сообщений.

Обновление сцены

Объекты в сцене должны время от времени изменять свое состояние - координаты, фрейм анимации, текущая задача ИИ и т.п. Для возможности обновления, сущность должна быть производной класса TProcessing (все видимые объекты таковы) и переопределять метод TProcessing.Process(), который и будет вызван при наступлении момента обновления.

Частота и последовательность обновления каждой конкретной сущности зависит от настроек т.н. класса обработки, присвоенного ей. Обработка может учитывать или не учитывать режим паузы, а также происходить фиксированное количество раз в секунду, либо каждый фрейм (т.н. delta time based).

Для отсчета времени ядром используется подсистема таймера TCore.Timer.

В редакторе CASTEd класс обработки выбирается в свойствах сущности (свойство Processing class), а сами классы обработки создаются и настраиваются в свойствах корневого объекта сцены (группа свойств Processing).

Физика

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

За физическое представление сущностей отвечает объект TProcessing.Colliding. Он содержит информацию о геометрии, используемой при расчете физических взаимодействий (набор ограничивающих объемов, например) и прочие параметры. 

В случае, если у сущности задан набор ограничивающих объемов, встроенная в движок система проверки столкновений вызовет метод TProcessing.OnCollision(), а также сгенерирует сообщение при обнаружении столкновения сущностей.

Визуализация

За визуализацию отвечает подсистема TCore.Renderer. На текущий момент, присутствует её реализация через DirectX 8.1. В будущем планируются реализации, основанные на DirectX 9.0c и OpenGL 2.0.

Визуализируются сцены через камеры (TCamera). Поэтому, для визуализации сцены необходимо, чтобы в ней была по крайней мере одна камера. Активная камера определяется значением свойства TCore.Renderer.MainCamera. Любая камера может быть использована в материале (см. ниже) в качестве текстуры.

Сущность будет визуализирована при выполнении следующих условий:

  • сущность является наследником класса TVisible
  • у сущности установлен т.н. тесселятор - вспомогательный объект, отвечающий за геометрическое представление объекта. Обычно создается автоматически.
  • у сущности установлена валидная ссылка на материал - другую сущность, отвечающую за настройки отображения
  • у сущности, а также всех родительских в иерархии сцены сущностей, установлен флаг видимости (isVisible присутствует в TItem.State)
  • сущность попадает в раструб камеры

Материал

Материал это трехуровневая (TMaterial, TTechnique, TRenderPass) структура сущностей, которая инкапсулирует настройки внешнего вида объектов на уровне настроек визуализатора и API.

Материал сам по себе (TMaterial) просто содержит набор т.н. техник и по крайней мере одна из них должна быть валидна (см. ниже).

Техника (TTechnique) определяет один из путей, которым можно визуализировать материал. Таких путей может быть несколько с различной детализацией и требования к аппаратуре. Таким образом, задавая материалу различные техники, можно добиться высокой совместимости с различными конфигурациями аппаратного обеспечения. При визуализации, обычно будет выбрана первая валидная техника, но также на выбор может повлиять требуемый уровень детализации. К примеру, для камеры, создающей текстуру отражений, может быть задана пониженная детализация. Техника содержит набор проходов (TRenderPass), а также имеет присвоенный ей уровень детальности, который может быть (и будет) использован для регулирования детальности выводимых объектов, например, с расстоянием. Техника, все проходы которой по каким-либо причинам не могут быть использованы (не соответствие оборудованию и т.п.), помечается как невалидная. При прорисовке используется первая валидная техника.

Проходы определяет прорисовку геометрии сущности с конкретными настройки визуализатора, текстурами, шейдерами и т.д. Сколько у техники проходов, столько раз будет прорисована геометрия.

Ввод

Ввод в CAST II обеспечивает подсистема TCore.Input, которая позволяет привязывать к событиям ввода (нажатия клавиш, передвижения мыши и т.п.), а также их произвольной последовательности, одно из следующих действий:

  • отсылка сообщения -- привязка происходит методом TInput.BindCommand()
  • вызов делегата (указатель на метод класса) -- TInput.BindDelegate()
  • операция над областью памяти, задаваемой указателем (небезопасна, поэтому не рекомендуется к использованию) -- TInput.BindPointer()

События ввода в привязках описываются строкой со следующим синтаксисом (в EBNF):

ЭлементПривязки = (<Клавиша><Спецификатор>) | <Жест>"^"
Клавиша = Имя клавиши
Спецификатор = ","|"+"|"-"|":" - может быть опущен в конце, в этом случае будет подставлено "," 
Жест = "MouseMove" | "MouseMoveH" | "MouseMoveV" | "MouseRoll" | "MouseStrokeLeft" | "MouseStrokeRight" | "MouseStrokeUp" | "MouseStrokeDown" | "MouseStrokeLeftUp" | "MouseStrokeRightUp" | "MouseStrokeLeftDown" | "MouseStrokeRightDown"
Привязка= <ЭлементПривязки> {<ЭлементПривязки>}

Спецификаторы:
"," - нажатие и отпускание клавиши (клик)
"+" - нажатие клавиши
"-" - отпускание клавиши
":" - двойной клик

Примеры привязок: 

Alt+Q - действие будет выполнено, если пользователь нажмет клавишу Alt, а затем, не отпуская Alt, нажмет Q
A,B,C - действие будет выполнено, если пользователь последовательно нажмет и отпустит клавиши A, B и C.
A+B,A- - действие будет выполнено, если пользователь нажмет клавишу A, затем нажмет и отпустит B, затем отпустит A.
RMB+MouseStrokeDown^MouseStrokeRight^RMB- - действие будет выполнено, если пользователь, зажав правую кнопку мыши, передвинет мышь вниз, а затем вправо, отпустив правую кнопку. Этот "жест" используется для закрытия окон в популярном браузере Опера.

Схема разработки

Схема разработки игр на CAST II выглядит так:

Игровой контент (модели, текстуры и т.п.) импортируется в редактор CAST II Editor. Там создаются и настраиваются камеры, источники света, материалы и другие объекты и собираются игровые сцены.

Если игре необходимы собственные классы игровых объектов (что вполне вероятно), то они создаются и импортируются в редактор через плагины. После этого, становится возможно создавать объекты данных классов в редакторе.

Далее, полученная сцена сохраняется на диск и загружается уже в игровом приложении.

 

 

Copyright (C) 2006-2011, casteng.com