Вы находитесь на странице: 1из 167

РУКОВОДСТВО

ПО РЕДАКТОРУ ИГРЫ
«KING'S BOUNTY: ПРИНЦЕССА В ДОСПЕХАХ»
Содержание:
1. Начало работы с редактором. Введение.
1.1. Определение и свойства игровой сессии.
1.2. Интерфейс редактора.
1.3. Главное меню.
1.4. Панель инструментов.

2. Дизайн локации.
2.1. Редактирование ландшафта.
2.1.1. Рельеф.
2.1.2. Уровни (Levels).
2.2. Редактирование текстуры ландшафта.
2.2.1. Наложение текстуры. Виды кистей.
2.2.2. Материалы и слои.
2.2.3. Заливка регионов.
2.2.4. Декали.
2.2.5. Текстура как выразительное средство.
2.3. Расстановка объектов.
2.3.1. Базовые операции над объектами.
2.3.2. Перегрузка свойств объекта.
2.4. Настройка воды.
2.4.1. Базовые свойства воды.
2.4.2. Глубокая вода.
2.4.3. Шаблоны воды, несколько видов воды на локации.
2.5. Освещение локации.
2.5.1. Виды освещения в игре.
2.5.2. Настройка глобального освещения локации по времени суток.
2.5.3. Настройки тумана.
2.5.4. Локальные источники света. Omni Lights.
2.5.5. Зоны локального изменения освещенности.
2.5.6. Имитация света/тени с помощью раскраски текстур. Lumi layer.
2.6. Логические карты ландшафта.
2.6.1. Карта проходимости.
2.6.2. Типы ландшафта, арены и освещения.
2.7. Общие свойства локации.
3. Логика локации.
3.1. Атомы.
3.1.1. Классы атомов.
3.1.2. Основные параметры атомов.
3.1.3. Взаимоотношение атомов, эмбрионов и логических объектов.
3.2. Логические объекты (Logic Units).
3.2.1. Свойства логического объекта.
3.2.2. Игровая логика. Сообщения и ловушки.
3.2.3. Игровая логика. Condition editor.
3.2.4. Игровая логика. Action editor.
3.2.5. Игровая логика. Сценарии и события.
3.2.6. Игровая логика. Внутренний скриптовый язык игры.
3.2.7. Разбор избранных логических объектов.
3.3. Эмбрионы.
3.3.1. Общие свойства и смысл эмбриона.
3.3.2. Эмбрион магазина/замка.
3.3.3. Эмбрион армии.
3.3.4. Эмбрион бокса/клада.

4. Логика сессии.
4.1. Актеры и герои противника.
4.2. Диалоги.
4.2.1. Создание диалога для актера.
4.2.2. Редактирование диалога, двухмерное представление.
4.2.3. Основная логика диалога.
4.2.4. Изменения игрового мира через диалог.
4.3. Квесты.
4.3.1. Редактирование квеста, двухмерное представление.
4.3.2. Работа с этапами квеста в диалогах и другой логике.
4.4. Редактор предметов.

5. Дополнительные аспекты редактирования локации.


5.1. Монорельсовая система, платформы.
5.2. Пути патрулирования армий.
5.3. Поверхность для полета.
6. Редактирование арен.
6.1. Дополнительные свойства арены как локации.
6.2. Настройка гексагональной сетки.
6.3. Настройка камеры.
6.4. Специфичные для арен группы атомов.

7. Взаимодействие с игрой.
7.1. Структура папок сессии. Методы распространения.
7.2. Редактирование sessiontxt, properties.txt и других важных для сессии текстовых
файлов.
7.3. Интеграция в глобальную карту.
7.4. Загрузка сессии в игре.

8. Приложения.
8.1. Редактор аттачментов.
8.2. Конфигурационные файлы игры и редактора.
8.3. Lua-скрипты.
8.4. Обзор структуры ресурсов игры.
8.5. Дополнительная настройка редактора.
8.6. Горячие клавиши в редакторе.
1. Начало работы с редактором. Введение
Этот документ представляет собой одновременно и учебник по созданию
пользовательских дополнений, и справочник по возможностям редактора игры «King’s
Bounty: Принцесса в доспехах». Главы документа сгруппированы примерно в том порядке,
в котором происходит реальная работа при создании дополнения к игре в виде локации,
наполненной персонажами, заданиями и врагами – то есть полноценной игровой локации.
Созданная в процессе изучения документа локация вполне играбельна, она легко
интегрируется в игру и прилагается к руководству для практического ознакомления.
Поздние главы посвящены более продвинутым и тонким настройкам редактора и
рекомендуются для изучения опытным пользователям, которые уже уверенно владеют
основами работы в редакторе.
Данное руководство предполагает некоторый уровень подготовки читателя. В первую
очередь, он должен быть знаком с предметом разработки – играми «King’s Bounty: Легенда о
Рыцаре» и «King’s Bounty: Принцесса в Доспехах». Необходимо представлять себе основы
игровой механики и структуру игровых локаций. С точки зрения разработчика модификаций
никаких специальных знаний не потребуется – они либо не нужны, либо будут описаны в
процессе. Во вторую очередь, крайне желателен опыт работы с какими-либо игровыми
редакторами уровней либо с редакторами трехмерной графики. Отдельные разделы будет
сложно усвоить без знания основ трехмерной графики и работы с изображениями, но ничего
невозможного в этом тоже нет.
Тем, кто хочет реализовать максимум своих фантазий, придется работать не только с
редактором, но и с текстовыми конфигурационными файлами игры. В этом нет ничего
сложного, и в руководстве будет описана структура некоторых таких файлов.
В этой главе будут описаны именно основы работы с редактором: как, что и зачем
редактируется, какой инструментарий включает в себя игровой редактор и как им
пользоваться. Центральным понятием этой главы является игровая сессия. Также именно в
этой главе мы создадим демонстрационную сессию, на примере которой будем осваивать
работу с редактором на практике.

1.1. Определение и свойства игровой сессии.

При первом запуске редактор предложит вам сделать несколько операций. Во-первых,
выбрать папку sourcemedia, это папка, в которой хранятся текстуры ландшафта. Из-за
своего большого размера она устанавливается отдельно от редактора. Чтобы установить ее,
нужно распаковать находящийся на диске с игрой архив setup_media.exe в удобное для вас
место. И потом, при запуске редактора, нужно будет указать путь к этой папке.
В этом архиве помимо кистей и шаблонов, находятся текстуры всех локаций
"Принцессы", за исключением боевых арен. В распакованном виде sourcemedia займет 14
гигабайт – учитывайте это! Несжатые текстуры локаций находятся в папке
sourcemedia\terrain\in_progress\ и вы можете просто удалить те локации, текстуры которых
править не собираетесь.
Во-вторых, будет предложено создать новую сессию. Что такое игровая сессия?
Фактически, это сама игра, и она включает в себя практически все, кроме контента игры
(контент – неизменяемые графические, звуковые и прочие ресурсы). Игровые локации со
всей логикой и структурой, тексты, LUA скрипы, конфигурационные файлы – все это
относится непосредственно к игровой сессии. В техническом плане новая сессия,
создаваемая в редакторе, – дополнительная. В ней используется все, что есть в основной
игровой сессии (для ЛоР это base, для ПвД – addon) плюс дополнительные данные вашей
сессии. Если вы изменяете или дублируете данные оригинальной сессии, то все эти
изменения сохраняются в вашу, пользовательскую, сессию, и измененные данные будут
загружаться именно из нее. Сама сессия – это просто папка, в которой хранятся все
создаваемые и редактируемые файлы данных. Попробуем создать тестовую сессию с
именем «tutor» (она нужна нам для обучения работе с редактором). Это имя одновременно
и будет названием папки. В этой папке также можно хранить любые модифицированные или
дополнительные игровые файлы, в том числе и те, оригинал которых находится в папке
data. Игра будет загружать файлы только той дополнительной сессии, которая в данный
момент подключена в игре. Таким образом, сессия – это еще и хранилище любых файлов,
которые нужны для ее нормальной работы.
В идеологическом плане сессия
– это дополнение к игре. Основная
мощь возможностей редактора
направлена на то, чтобы создавать
распространяемые дополнения с
новыми локациями, квестами,
предметами и диалогами к игре
«King’s Bounty: Принцесса в
Доспехах». Для того, чтобы сделать
что-то более масштабное
(например, полноценную новую
игру или существенно изменить
игровую механику и контент),
только редактора будет
недостаточно.

Рис. 1.1. Выбор сессии.

Одновременно редактор может работать только с одной сессией; для того, чтобы
работать с другой, его необходимо перезапустить. Редактирование оригинальной сессии
addon не допускается, однако, вы можете открывать любые локации из нее и делать любые
изменения – дубликаты измененных данных запишутся в вашу сессию. При создании новой
сессии можно задать ее имя и описание, которые будут использоваться в игре. Отметив
галочкой пункт Stand alone в этом окне, вы отключите все локации и все данные сессии
addon (включая предметы, персонажей и их диалоги, героев и так далее…). Таким образом
можно создать отдельное приключение принцессы Амели в каком-нибудь другом мире, но
мы сейчас не будем этого делать. Дадим сессии имя «Остров Заходящего Солнца», а в
описании напишем «Обучающая сессия». Далее нам предложат выбрать локацию для
редактирования. Локации бывают двух типов – обычные и боевые арены. Мы не будем
ничего выбирать, а сразу создадим новую – нажмем кнопку New Map. Новой локации нужно
дать техническое имя на латинице. Мы будем делать дополнительный остров для
«Принцессы в Доспехах» – Остров Заходящего Солнца. Соответственно, его техническое
имя будет sunset_isle.
1.2. Интерфейс редактора.

Рис. 1.2. Интерфейс редактора.

Интерфейс состоит из несколько частей. В верхней части рабочего окна редактора


находится главное меню, пункты которого описаны в разделе 1.3. Чуть ниже находится
панель локаций. Там отображаются все локации, загруженные в данный момент. Правый
клик на пустое место в этой панели позволяет выбрать локацию для открытия, клик на
заголовке открытой локации вызывает меню. Unload – выгружает локацию из памяти, по
умолчанию без сохранения сделанных изменений, Discard – сбрасывает все несохраненные
изменения и перезагружает локацию, Save – сохраняет все изменения в локации. Клик с
зажатой клавишей Ctrl по заголовку неактивной локации делает ее активной для
редактирования.
Справа находится панель инструментов, которая подробно описана в пункте 1.4. На этой
панели находятся инструменты для рисования локации, расстановки на ней объектов и
логики. Непосредственно под окном редактирования локации, внизу экрана, находится
техническая информационная панель. На ней отображается текущий FPS, процент
заполненности буфера Undo (эта операция, как и везде, проводится сочетанием клавиш Ctrl-
Z) и характеристики выбранного объекта – тег и класс атома, название эмбриона при его
наличии и уникальный идентификатор.
Ну и, наконец, в центре располагается окно трехмерного отображения редактируемой
локации (5), где мы и проведем большую часть времени.
1.3. Главное меню.
Данный раздел является в первую очередь обзорным – в принципе, нет никакой нужды
при первом знакомстве с редактором изучать все, что здесь написано. Сюда полезно
возвращаться позже, чтобы узнать, что делает конкретный пункт меню, а также можно
использовать этот список для быстрого доступа к разделам, в которых детально описана
работа тех или иных функций, доступных через меню.

Закладка General:
Settings:
Глобальные настройки редактора. Не влияет на текущую сессию как таковую, имеет
отношение именно к редактору и отображению в нем локации.
Вкладка General:
Render Buffer отвечает за размер области, в которой происходит отрисовка локации.
Галочка Dock отвечает за привязку панели инструментов к экрану. Галочка Count Atoms
выводит статистику количества атомов на локации в списке атомов. Shadow Resolution –
разрешение карты теней. Меньшее значение ухудшает качество теней, но повышает
скорость работы редактора.
Вкладка Show:
Позволяет показать/скрыть определенные группы объектов на локации.
Show Grid – координатная сетка локации. Удобно для оценки высотных уровней.
Дублируется сочетанием клавиш Ctrl-G.
Show Helpers – показывает специальные вспомогательные объекты. Как правило, это
пометки над логическими юнитами. Также показывает логические юниты, не имеющие
модели в игре (такие, как, например, порталы для перемещения между локациями).
Дублируется сочетанием клавиш Ctrl-R.
Show Hidden Objects – отображение скрытых объектов. Любой объект на карте может
быть скрыт до поры до времени (например, это может быть квестовый объект, который
появляется только после получения квеста). Скрытие их в редакторе позволяет получить
представление о том, как это будет выглядеть в игре.
Show Chess Cells – только для арен. Показывает разметку арены.
Show Collision Meshes – показывает упрощенные модели объектов, по которым
рассчитываются коллизии (проходимость). Работает только для объектов, имеющих
сложный тип коллизии (собственный colshape-файл), многие объекты в игре имеют
коллизию по радиусу от их центра.
Show Selection Highlight – простой графический эффект подсветки объекта, который в
данный момент выбран.
Show Water – показывает поверхность воды. Цветовой градиент «глубины» воды
отключить невозможно, только поверхность. Отключение поверхности экономит ресурсы
графического процессора и позволяет лучше разглядеть дно. Дублируется сочетанием
клавиш Ctrl-W.

Вкладка Camera:
Настройки камеры внутри редактора. Существует несколько типов камер, и работа с
ними отличается, по сути, лишь удобством. Горячие клавиши для избранных режимов
управления камерой можно посмотреть в приложении 8.6.

Вкладка Misc:
Здесь есть только одна степень свободы – это Moving Atom. Необходима она при расчете
поиска путей для конкретного атома. Пути можно отобразить на карте нажатием Ctrl-H, при
включенном Moving Atom для выбранного атома будет отрисована область «условной
проходимости» желтого цвета. Для того чтобы карта была проходима для данного атома,
необходимо, чтобы желтые области не смыкались.
Switch to Game:
Переключается в игру, причем активной будет текущая локация, открытая в редакторе –
для тестирования.
Lua IDE:
Запускает редактор Lua-скриптов. Абсолютно аналогичен тому, что можно вызвать в
режиме отладки игры. Для стабильной работы редактора необходимо, чтобы все скриптовые
файлы игры были распакованы из ресурсов.
Exit:
Покинуть редактор. Предварительно спросит, хотите ли вы сохранить текущую сессию.

Закладка View:
Полностью дублирует вкладку Show из Settings.

Закладка Session:
Позволяет манипулировать состоянием сессии. Те настройки, которые находятся здесь,
специфичны не для конкретной локации, а для игровой сессии в целом. В частности, здесь
можно настроить список локаций в сессии, актеров, диалоги, предметы и квесты.
Save Session:
Сохраняет сессию, все изменения на локациях и изменения внутри сессии, все
автоматически.
Save Session Advanced:
То же самое, что и выше, только вместо автоматического сохранения всего
предоставляет пользователю список всех локаций и/или изменения в сессии (Session
Internals), в котором он может выбрать, что именно сохранить.
Save Current:
Сохраняет изменения в текущей локации. Если, однако, кроме локации были затронуты
внутренние данные сессии (Session Internals), вместо этого вызовется Save Session
Advanced.
Clone Current Location:
Создает точную копию данной локации, включая всю логику локации. Нужно задать имя
новой локации. В редакторе нет возможности переименовать локацию, но для этого можно
использовать клоны.
Insert New Map:
Создает и добавляет в сессию новую локацию с указанным именем (ID).
Insert New Arena:
Создает новую арену внутри сессии. Требуется только название. В соответствии с
негласным правилом, таким локациям рекомендуется добавлять префикс «a» и имя
локации, которой принадлежит арена - a<location>_arena,. Например, abolo_arena_1 это
первая арена на острове Боло.
Delete Location:
Удаляет следы локации в сессии. Никакого физического удаления файлов локации не
происходит, удаляются только ссылки на нее внутри сессии.
Locations List:
Список локаций в сессии.
Items:
Редактор предметов сессии (редактируется items.txt в более удобном виде). Более
подробно см. 4.4.
Dialogs:
Редактор диалогов сессии. Более подробно см. 4.2.
Quests:
Редактор квестов сессии. Более подробно см. 4.3.
Actors:
Редактор актеров сессии. Более подробно см. 4.1.
Heros:
Редактор героев противника в сессии. Более подробно см. 4.1.
Texts:
Глобальные строковые переменные сессии. Позволяет задать строки, не привязанные ни
к какому диалогу или квесту, для использования, например, во всплывающих окошках. Как
пример, на некоторых локациях есть здания, войти в которые нельзя. При нажатии на них
всплывает окошко с надписью «Дом закрыт на замок». Эта и подобные ей надписи как раз и
хранятся в этих строковых переменных.

Закладка Location:
Здесь определяются настройки текущей локации. Они включают в себя, но не
ограничиваются освещением, свойствами арены и мониторингом атомов.
Light:
Свойства освещения локации. Более подробно о настройках света в локации см. 2.5.
Board:
Настройки конфигурации арены. Более подробно см. 6.
Minimap:
Экспорт мини-карты. Позволяет сделать автоматический снимок локации с высоты
птичьего полета для использования в качестве радара или мини-карты. Можно указать
разрешение, тип объектов, которые будут на радаре, границу (не рекомендуется изменять
существующие границы, чтобы не портить привязку радара к местности) и коэффициенты
усиления рассеянного и диффузного освещения (см. 2.5.1). Типы объектов, которые
визуализируются на радаре:

Landscape – сам ландшафт, создается проекция текстуры без учета рельефа;


Static – статичные объекты, декорации (деревья, камни и проч.);
Dynamic – объекты с анимацией;
Castle – все здания на карте, не только замки.

Для нормальной работы радара в игре его картинка должна быть сохранена либо в
папке \data (что не рекомендуется), либо внутри текущей сессии.
Paths:
Интерфейс для просмотра и редактирования маршрутов вражеских войск на карте.
Дублирует инструмент Paths, более подробно см. 5.2.

Embryos:
Список всех эмбрионов на локации. Здесь же можно их редактировать и создавать
новые эмбрионы, которые затем можно использовать в логике. Например, динамически
загружать отсюда настройки отрядов или наград. Более подробно см. 3.3.
Atoms List:
Список всех атомов на локации. Показывает все атомы, которые где-то размещены, для
быстрого поиска. Выбранный атом будет подсвечен красным ореолом, а двойной клик на
атоме в списке отцентрирует экран на нем. Красным цветом в списке помечены
«потерянные» атомы – атомы, которые размещены за пределами локации или слишком
далеко от поверхности ландшафта. Такие атомы могут быть скрыты от взгляда, но при этом
будут своей проекцией влиять на проходимость. Следует заметить, что не всегда такое их
поведение является следствием ошибки разработчика, подчас удаленность от поверхности
задумана, так что этот инструмент служит лишь для дополнительной проверки. Галочка
Show only lost atoms оставит в списке только «потерянные» атомы. В поле внизу можно
вводить тег атома, тогда будет выбран первый в списке атом с этим тегом. Можно просто
ввести вне поля первую букву тега атома – результат будет аналогичным. Вверху можно
выбрать класс атомов для отображения в списке. Подробнее о классах атомов см. 3.1.

Properties:
Здесь задаются свойства локации в целом. См. 2.7.
Switch to Map:
Позволяет открыть и перейти в режим редактирования еще одной локации.
Switch to Arena:
Позволяет открыть и перейти в режим редактирования еще одной арены.
Закладка Misc:
View storage file:
Из локации/объекта можно экспортировать storage-файлы с расширением .strg. В этих
файлах хранятся данные, которые сам редактор может интерпретировать и импортировать.
Например, в такие файлы можно выгрузить настройки воды, настройки освещения и
некоторые другие сложные параметры для последующего использования на других
локациях. Данная опция позволяет просматривать содержимое таких файлов вне
зависимости от того, что именно было экспортировано.
Scan for:
Сканер логики. Можно просматривать внутренние скрипты игры на предмет поиска в них
ключевых слов. Так, если известно, что в каком-то скрипте (например, зашитом в диалог)
используется переменная с названием «megavar», ввод ключевого слова «megavar»
позволит отыскать сам скрипт.
Mego-Chekker:
Эта штука проверяет все и вся, ищет всевозможные ошибки, как то: пустые здания,
актеры без портретов и диалогов, пути без армий и прочее.

1.4. Панель инструментов.


На данной панели доступно несколько вкладок, каждая из которых отвечает за
отдельную группу инструментов. Все инструменты будут описаны далее по ходу изучения
редактора, здесь же приводится только их список для того, чтобы знать, что где находится.
Monorail system – настройка логики летающих/плавающих платформ (как в Демонисе) и
путей для них на локации.
Omni lights – настройка локальных источников освещения.
Paths – настройка путей патрулирования армий противника или НПЦ.
Atoms – расстановка различных объектов на карте.
Landscape – рисование ландшафта: настройка рельефа и текстурирование. Здесь
же производится настройка логических карт локации.
Flight surface – рисование поверхности для полета.
Water – настройка воды, глобальная и локальная.
Arena – настройки арены. Доступно только на локациях-аренах.
Logic units – список используемых в сессии глобальных логических объектов и
локальных – на локации.

Сначала остановимся на внешнем виде локации. В следующей главе будет описано, как
с помощью инструментов вкладки Landscape создать локацию и придать ей уникальный вид.

Практическая часть.

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


Вы можете попробовать как создать полностью свою локацию, так и попытаться повторить
создание той, что описана в данном руководстве, поэтапно. В первом разделе мы еще
ничего не умеем делать непосредственно в редакторе, однако пройдем одну из самых
важных стадий – проектирование. Мы уже создали тестовую сессию и даже локацию в ней,
однако пока непонятно, что же там рисовать.
Предварительно обговорим список того, что будет сделано:
– локация «Остров Заходящего Солнца». Чтобы не усложнять себе работу, сделаем
маленькую локацию – островок с минимумом персонажей и декораций. Допустим, локация
будет размером 4х4 тайла (для сравнения, Алый Ветер занимает площадь 8х8 тайлов).
Максимальный комфортный для игры размер локации считается примерно 14х14, хотя
может быть и существенно больше;
– портал на Дебире, который через условную подводную пещеру (мы ее рисовать не
будем) приведет игрока на нашу локацию. Соответственно, и на нашем острове тоже должен
быть портал, ведущий обратно;
– один NPC (неигровой персонаж – non player character), сидящий в домике. С ним можно
будет поговорить и получить от него квест;
– одно задание (квест – от quest, англ.) на убийство некоторого чудовища, выдаваемый
вышеуказанным NPC. Для лучшей иллюстрации этот квест будет не контрактом –
необходимо будет вернуться к персонажу, чтобы отчитаться о выполнении и закрыть
задание;
– один вражеский герой – то самое «заказанное» чудовище;
– несколько случайных подбираемых объектов, сокровища или алтари, дающие бонусы
герою;
– две враждебные армии, которые просто патрулируют остров;
– маяк, здание, в котором находится обычный магазин.
Перед тем, как рисовать локацию, можно нарисовать ее схему, план. Наш план будет
выглядеть следующим образом:

Сначала рисуется примерная


тайловая сетка, чтобы представлять
масштабы, а под ней уже контур локации.
Локация заливается цветом или
текстурой. На карте рисунком перца
отмечены различные объекты, которые
подписаны для удобства. Такой план
позволяет нам в общих чертах
представить, что же мы хотим создать.
План локации не нужно делать слишком
подробным и отмечать каждый сундучок,
все равно в процессе непосредственного
создания локации будут вноситься
поправки, тогда же вы и наполните ее
деталями.

План Острова Заходящего Солнца.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


2. Дизайн локации.

Первоочередная задача сессии – добавление нового игрового контента, и самое


захватывающее в этом – создавать и наполнять новые миры и локации, по которым будет
путешествовать герой. При создании новой сессии нам будет предложено создать новую
локацию, над которой мы будем работать. Новые локации и арены можно в любой момент
добавить в существующую сессию через пункт меню Session/Insert new map (arena).
Создание локации – долгий и кропотливый процесс, который можно условно разбить на
этапы. Для удобства желательно сначала создать основу локации: создать рельеф, сделать
предварительную покраску, наметив все дороги и поляны, расставить основные
декоративные объекты, создающие внешний вид и проходимость, – горы, деревья и т.п.
Потом можно настроить такие глобальные вещи, как освещение и вода. Затем можно
переходить к созданию «чистовика» ландшафта – расставить на нем уникальные и
интерактивные объекты (NPC, магазины, отряды врагов, сокровища), локальные источники
освещения, аккуратно раскрасить территорию. После этого можно настроить содержимое
эмбрионов (армии, магазины, сокровища) и переходить к тонкой настройке логики – задания,
диалоги, уникальные интерактивные объекты, предметы. И финальный штрих – насыщение
локации деталями, создание атмосферы за счет тонкой настройки тумана, источников
освещения и звуков, подключения музыки и так далее.

2.1. Редактирование ландшафта.

Bсе, что относится к редактированию ландшафта, доступно через инструмент Landscape


в панели инструментов. Быстро переключиться в этот режим можно с помощью сочетания
клавиш Shift-L. Когда мы создаем локацию, ей присваивается размер по умолчанию, поэтому
первое, что необходимо сделать – изменить размер до запланированного (у вас ведь есть
схема локации, нарисованная в каком-либо из графических редакторов или на бумаге, не
так ли?). Для этого на панели ландшафта есть кнопка, на которой написан текущий размер
локации. Нажатием на эту кнопку можно изменить количество квадратов, из которых состоит
рельеф, в произвольном направлении. Крайне не рекомендуется выполнять эту операцию
на локации, на которой уже что-то нарисовано, так что планировать размер нужно заранее.
Также не рекомендуется делать локации площадью больше 150 квадратов (это примерно
12х12) – чем больше размер локации и количество разнообразных объектов на ней, тем
выше будут системные требования у вашего дополнения.
Сдвинуть ландшафт можно с помощью кнопки move, скрыть его с помощью кнопки hide и
выставить глобальные настройки для воды в локации. Undulating Water позволяет настроить
для воды неплоский рельеф, но в текущей версии игры/редактора работает нестабильно, так
что ее лучше не трогать. Deep Water включает глубокую воду, а Deep Water Settings
дублирует ее настройки в инструменте Water, об этом ниже. Также в самом низу идет Global
Blend Factor, который позволяет в редакторе выставить прозрачность для всех объектов,
чтобы лучше рассмотреть ландшафт под ними.
На вкладке Landscape доступны четыре основных инструмента: рельеф (Height tool),
уровни (Levels tool), текстурирование (Texturing tool) и логика ландшафта (Landscape logic).
О последних двух речь пойдет дальше, а пока что остановимся на двух первых.
2.1.1. Рельеф.

Редактирование рельефа осуществляется с помощью набора инструментов Height tool.


Каждый большой тайл (квадрат) ландшафта разбит на 256 более мелких квадратов (то есть
большой тайл имеет сторону в 16 маленьких). Инструмент редактирования рельефа в
первую очередь позволяет управлять высотами вершин маленьких квадратов – рельефной
сетки. Таким образом, рельеф в игре – это большая поверхность, которая задается
совокупностью высот этих вершин (высотная карта).
В режиме создания рельефа нам доступна одна кисть, у которой есть два радиуса –
внутренний и внешний. Нажатие левой кнопкой мыши на ландшафт поднимет рельеф во
внутреннем радиусе кисти. Если при этом зажать Shift – высота, наоборот, уменьшится.
Сила изменения ландшафта кликом мышки регулируется параметром Raise Strength: чем он
больше, тем сильнее будет изменение рельефа при нажатии. Можно быстро изменять этот
параметр нажатием цифровых клавиш – на каждую из клавиш 1..0 задан некоторый
эталонный уровень силы кисти. Радиус кисти увеличивается/уменьшается клавишами [ и ]
или устанавливается напрямую в полях Outer size/Inner Size. По умолчанию кисть имеет
квадратную форму, однако при помощи галочки Circular shape можно сделать ее круглой.
Клик с одновременно зажатым Ctrl выровняет высоту во всем внутреннем радиусе кисти
с высотой вершины, на которой сейчас находится курсор – это удобно, если нужно
поднять/опустить область ландшафта до уровня уже существующей зоны. Клик с зажатым
Alt сделает уровень во внутреннем радиусе равным тому, что задан в поле Fixed Height, по
умолчанию 0 – своеобразный «уровень моря» (однако, этот ноль не является фактически
уровнем воды – это просто ноль по вертикальной оси в абсолютных координатах локации,
уровень воды создатель локации может выставить как выше, так и ниже нуля).
До сих пор все преобразования ландшафта происходили во внутреннем радиусе кисти,
однако есть еще и внешний. За что он отвечает? Для внешнего радиуса есть галочка Smooth
outside, которая по умолчанию включена. Это означает, что при любом преобразовании
рельефа в области, принадлежащей внешнему радиусу кисти и не принадлежащей
внутреннему, будет проводиться сглаживание рельефа с целью устранения острых углов.
Если эту галочку убрать, внешний радиус не будет оказывать вообще никакого влияния на
преобразования ландшафта. Если выставить галочку Smooth inside, сглаживание
ландшафта будет производиться и во внутреннем радиусе. Учтите, что при большом
внешнем радиусе и малом внутреннем очень сложно сделать высокие горы – сглаживание
будет «съедать» все резкие изменения рельефа, которые мы сделаем. Для создания
высоких гор лучше сначала поднять большую область без сглаживания, а потом уже с малой
силой кисти разглаживать ее края. Сила сглаживания всегда максимальна и от силы кисти
не зависит.
С большими областями часто удобно работать не отдельными кликами, а двигая кисть с
зажатой левой кнопкой мыши. Однако к изменению рельефа приводит не просто зажатая
кнопка мыши, но и одновременное ее движение, что может сделать неудобным поднятие
только того пространства, что находится во внутреннем радиусе. Для этого есть галочка
Position Lock, которая запрещает движение кисти при зажатой левой кнопке мыши.
Галочка Water edit mode (режим редактирования высотной карты воды) приведет к
какому-либо эффекту только в том случае, если включена опция Undulating Water,
описанная выше. Сочетание Undulating Water и Deep Water вообще невозможно, так что
пользоваться этим вряд ли придется. Land/Deepwater bottom heights устанавливает высоту
ландшафта равной высоте плоскости воды (не ноль в абсолютных координатах, а именно
текущая высота воды). Причем регулируется ландшафт по четырем краям локации, а число
– количество маленьких тайлов от края, в пределах которых происходит выравнивание. Так,
если в поле Up задано число 10, то при нажатии Adjust Height все квадраты на расстоянии
меньше или равном 10 от верхнего края локации выставятся на уровень воды.
Настоятельно не рекомендуется делать резких перепадов высот. Связано это с
особенностями наложения текстуры на поверхность ландшафта. Максимальное разрешение
текстуры одного большого тайла – 1024 на 1024. Она накладывается равномерно, так что
каждому маленькому тайлу достается фрагмент текстуры в 64 на 64 пиксела. При больших
перепадах высот маленькие тайлы и, как следствие, текстуры на них сильно растягиваются.
Такие текстуры выглядят размыто и некрасиво, поэтому таких перепадов лучше избегать,
либо маскировать их под объектами. Посмотреть сетку ландшафта можно, нажав сочетание
клавиш Ctrl-G.

2.1.2. Уровни (Levels).

Инструмент Levels tool позволяет создавать уровни ландшафта: резкие перепады высот
с высокой детализацией текстуры и рельефа «стен». Сами «стены» уровней – это набор
разнообразных заранее заготовленных объектов, которые маскируют резкие перепады
высот. Без уровней невозможно создавать, в частности, подземелья и темницы, для которых
существуют свои наборы «стен».
Сначала необходимо выбрать набор, который определяет внешний вид уровня и его
высоту (глубину). Затем нужно выбрать порядок вашего уровня в настройке Level.
Изначально уровень локации – 0. Все типы стен делятся на два класса – обычные и
инвертированные. Обычные делают зону локации выше, инвертированные – ниже. Для
обычных Level должен быть установлен в «+1», для инвертированных – в «-1». Для создания
«ступенек» с помощью уровней, каждая следующая ступенька будет рисоваться с
параметром Level больше (или меньше) на единицу.
Размер кисти, как и всегда, регулируется клавишами [ и ], или напрямую в поле Brush
size. Но удобнее для этого использовать сочетание Shift-Click. Режим Ramp создает на уже
нарисованном фрагменте уровня спуск – область, где герой может подняться на ступеньку
уровня или спуститься с него. Не для всех типов стен существуют такие подъемы-спуски, и
их наличие устанавливается экспериментальным путем.
Уровни можно стирать, либо просто водя кистью со включенной галочкой Erase, либо
зажав клавишу Shift. Первый режим автоматически стирает и рампы, второй – стирает
только при включенном режиме Ramp. Учтите, что стирается только тот тип стен, который
выбран в палитре. Так что, если вы нарисовали уровень со стеной cave2, то стереть его
можно будет только в том случае, если в палитре тоже выбран cave2.
Режим Customize позволяет вручную выбирать из списка один из элементов набора. Это
удобно при создании в конкретных местах специальных объектов, например дверей,
лестниц или входов в пещеру. Также можно изменить внешний вид участка стены просто
повторным кликом по нему, тогда фрагмент выбирается случайным образом. Некоторые
наборы уровней отличаются только текстурами (например, стены королевского замка и
стены тюрьмы), тогда при выборе такого набора под кнопками Ramp и Customize появляется
список доступных наборов текстур, в котором можно выбрать нужный.
При работе с уровнями рекомендуется заранее сохраниться и в дальнейшем делать это
как можно чаще, если вы создаете сложные структуры. Использовать уровни лучше только
тогда, когда в них есть необходимость; в других случаях решить проблему возвышенностей
можно простым изменением рельефа и текстуры или добавлением объектов-гор на карту.
Практическая часть.

Итак, мы создаем локацию размером 4х4 тайла, который выставляется по умолчанию.


Вначале не стоит создавать сложных рельефов: где необходима тонкая настройка высоты, и
необходима ли она вообще, станет ясно уже в процессе создания и наполнения локации, а
пока воспользуемся стандартной кистью с радиусами 5-9 и силой нажатия по умолчанию. На
данном этапе мы постараемся максимально точно воссоздать контуры локации согласно
нашей схеме. В этом нам очень поможет сочетание клавиш Ctrl-G, которое на время
редактирования рельефа включит сетку. Получившийся результат можно увидеть на рисунке:

Ландшафтная сетка локации.


Попытайтесь достичь схожего результата. Тут следует отметить, что мы заранее создаем
небольшие возвышенности в районе портала и на южном мысе, где стоит маяк. В принципе,
при редактировании любой локации на данной стадии создания рельефа можно и
остановиться – его все равно нужно будет дополнительно подгонять под атомы и объекты,
но это уже позже. Уровни на нашей локации мы использовать не будем.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


2.2. Редактирование текстуры ландшафта.

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

Инструмент текстурирования.

Режим работы с текстурой доступен через инструмент Texture Tool во вкладке Landscape
панели инструментов. Всего существует три метода раскрашивания поверхности (группа
кнопок 1 на рис. 2.3): кисть (кнопка brush), заливка текстурой региона (кнопка region) и
наложение декали (кнопка decal). Также в режиме работы с текстурой появляется
дополнительное окно (2) – окно выбора материалов. Для того, чтобы добавить сюда
палитры текстур, нужно либо импортировать вручную материалы из заранее нарисованных
текстур, либо скачать с сайта игры пакет sourcemedia, содержащий все текстуры,
используемые в игре. Также необходимо учесть, что текстуры ландшафта редактор хранит в
несжатом виде и они занимают немало места на жестком диске. Так, текстура ландшафта
Дебира в исходном виде занимает почти 400 мегабайт. Несжатая текстура хранится в папке
sourcemedia/terrain/in_progress/<имя локации>, и если такой папки нет или она пуста, то
редактировать текстуры ландшафта невозможно.
Сверху находятся кнопки Save и Save Packet. Сейчас мы их не используем, текстура
сохраняется в sourcemedia автоматически, но первую кнопку можно использовать для того,
чтобы взглянуть на текстуру ландшафта «с высоты птичьего полета». Это может позволить
получить представление об общей цветовой гамме локации, однако в этом окне не
используется ни рельеф, ни освещение, так что это представление будет как минимум
приблизительным.

2.2.1. Наложение текстуры. Виды кистей.

Остановимся на самом первом методе редактирования текстур – при помощи кисти. В


отличие от редактирования ландшафта, здесь у нас большая свобода в выборе кисти: есть
три типа (группа кнопок Mode, 3 на рис 2.3) и четыре ее формы (группа кнопок Type, 4 на рис
2.3). Самая простая форма кисти – круглая, она включена по умолчанию. Также можно
использовать кисть квадратной формы, в виде звезды или текстурную. Последняя
предполагает рисование кистью специальной формы, которых на выбор есть несколько
штук: тут есть и кусты, и песчаные проплешины на ландшафте, и тени деревьев. В отличие
от других форм, текстурные кисти можно создавать самим и импортировать в редактор
(подробнее об этом в приложении 8.5). Размер кисти регулируется клавишами [ и ] либо
вручную через поле Size.
Типы кисти: обычная, ластик и смешивающая. Первые две самоочевидны, а третья,
вместо того чтобы наложить новый материал поверх существующего, смешивает его с
предыдущим слоем.
Следующая важнейшая настройка – прозрачность текстуры. Чем больше значение в
поле Alpha, тем больше будет сила кисти при наложении. Следует заметить, однако, что при
наложении текстуры на один участок многократно непрозрачности суммируются, так что
регулировка Alpha позволит ослабить только каждый клик мышью. Поэтому для
равномерного наложения прозрачных материалов нужно использовать смешивающую кисть
или непрерывно рисовать кистью с зажатой клавишей мыши. Значение поля Angle
определяет поворот кисти, но не влияет на угол поворота самой текстуры, который всегда
одинаков. Следует понимать, что вся текстура уже нарисована на тайле, а кистью мы просто
«проявляем» ее. Вследствие этого хорошо заметны стыки некоторых текстур на границах
тайлов, поэтому рекомендуется не заливать все одной текстурой, а варьировать их. Также
Angle меняет ориентацию декалей, но об этом позже.
Галочка Affect Current Tile сразу же применит изменения к текущему редактируемому
тайлу, а Random Angle будет использовать произвольный угол поворота кисти.
Особняком стоит Lumi Layer – этот слой не работает с текстурой, а высвечивает
ландшафт определенным цветом. Использование этой возможности позволит вам создавать
освещенные и затемненные участки (тени) без использования источников света, а также
перекрашивать текстуры в нужные вам цвета (см. 2.5.6).
2.2.2. Материалы и слои.

В самой нижней области панели редактирования текстур находится поле слоев.


Параметр Scale отвечает за масштабирование текстуры на тайле, и позволяет экономить
память там, где текстура все равно не видна, будучи скрыта под водой или скалами. Далее
отображаются слои материалов, которые наложены на текущий тайл. Отображаются только
три верхних слоя, причем в нижнем поле находится текущий, редактируемый текстурный
слой. Нажатие кнопки Layers позволяет посмотреть все слои, которые есть на тайле, и
поменять их местами. Каждый слой соответствует определенному материалу и создается в
тот момент, когда мы прикасаемся кистью к поверхности тайла. Ластик стирает только самый
верхний слой, что достаточно удобно, если мы где-то ошиблись. Если же ошибка в нижнем
слое, можно поменять их местами и стереть ненужные части ластиком или добавить новые
кистью, а потом снова поменять слои местами. Порядок слоев в конечном итоге определяет
и порядок их отрисовки на поверхности.
Также важно, что каждый слой – это отдельный полноразмерный текстурный файл в
sourcemedia, который не только занимает место на диске, но и загружается при
редактировании в видеопамять. Поэтому рекомендуется периодически использовать кнопку
merge map, которая склеит все слои в один, уничтожив информацию о них и вместе с тем
разгрузив локацию. Merge map склеивает слои сразу для всех тайлов на карте, не забывайте
об этом!
Выбирая текстуру, мы выбираем материал. Материалы хранятся в папках внутри
редактора, например LizzardLand. Обычно в папках сгруппированы материалы для локаций
определенной тематики: например, странно в волшебном лесу использовать текстуры
пещеры или заснеженных гор. Однако никто этого и не запрещает, все ограничивается лишь
вашей фантазией. В палитру можно добавить одну или несколько папок, в диалоге выбора
необходимо кликнуть на папку дважды, и она отметится жирным шрифтом. Каждому
материалу соответствует свой ID внутри редактора (так определяется уникальность слоя
для материала), имя файла текстуры и комментарий. Материалы можно импортировать,
если среди имеющихся нет такого, который вам нужен. Для этого в палитре нужно нажать на
пустом месте правой кнопкой мыши и выбрать New. Для импортирования материала
необходим только его графический файл – иконка для использования в палитре создастся
автоматически.
Текстуры локации можно редактировать в любых графических редакторах, понимающих
формат *.dds. Например, можно из нескольких текстур тайла склеить одну, итоговую –
конечному файлу нужно дать такое же название, какое было у файла нулевого (самого
глубокого) слоя. В имени файла текстуры содержится префикс (a – lumi layer, m – обычный
слой), имя локации, координаты тайла и номер слоя. Lumi layer живет отдельной жизнью и
всегда есть в локации, соединить его с другими слоями невозможно.

2.2.3. Заливка регионов.

Этот режим включается кнопкой region. Он удобен для заливки какой-то области
определенной текстурой. При этом контур области может быть очень сложным,
составленным из коротких отрезков. Сначала нужно создать регион последовательными
кликами мышки – каждый следующий создаст новую точку многоугольника. Если подвести
курсор к существующей вершине, линия станет зеленого цвета и кликом мышки регион
можно замкнуть. Shift-клик на замкнутом регионе зальет его текстурой выбранного
материала, Ctrl-клик удалит регион (но не текстуру, которой он залит!). Следует отметить,
однако, что покраска региона ничем принципиально не отличается от покраски кистью, так
что для него будут работать те же правила, что и для обычной кисти, – слои материалов и
привязка текстуры к тайлам. Вообще, если вы пытаетесь рисовать текстурой на области
ландшафта, но почему-то ничего не происходит, это значит, что этот материал уже
применялся к тайлу и лежит в каком-нибудь нижнем слое, где его не видно под другими.
Ситуация разрешается либо поднятием слоя, либо при помощи операции merge map.

2.2.4. Декали.

Декали – одна из возможностей наполнить локацию уникальными деталями. Этот режим


позволяет накладывать на ландшафт произвольные картинки в произвольных местах.
Например, типичными декалями являются «пеньки» под деревьями, которые делают
слияние деревьев с травой под ними более естественным. В редакторе уже доступен ряд
декалей, которые можно использовать в своих локациях, но ничто не мешает импортировать
свои. После выбора конкретной картинки для использования левый клик на карте поместит
туда декаль. Кликнув на центр рисунка, ее можно выбрать. Доступен ряд операций над
декалями:
– перемещение (горячая клавиша M);
– трансформация (осуществляется перемещением вершин декали);
– поворот (R), причем вращать можно декаль как вокруг центра, так и вокруг одной из
вершин;
– изменение масштаба ( клавиша S). Движение вверх и влево увеличивает масштаб,
вниз и вправо уменьшает, движение по одной оси изменяет масштаб по этой же оси.
Декали не подчиняются правилам слоев и каждая живет в своем слое, правда
регулировать их порядок нельзя, так что не стоит создавать декали, пересекающиеся друг с
другом.

2.2.5. Текстура как выразительное средство.

При рисовании локации нужно всегда держать в голове один факт – необходимо
заботиться о нервах пользователей со слабыми компьютерами. Каждый пенек, каждое
дерево на локации – это дополнительная нагрузка на видеосистему. То же самое относится
и к источникам света, и к просто большим локациям. А потому текстурирование является
самым «дешевым» и одновременно очень выразительным средством при создании локации.
При работе с редактором карт в «King’s Bounty» необходимо избавиться от стереотипов,
закрепившихся при работе с редакторами для игр вроде «Warcraft 3» или «Heroes of Might
and Magic”. Там есть трава, есть песок и есть снег с небольшими автоматическими
вариациями, а уникальность ландшафтов создается исключительно объектами. Здесь же
возможности работы с текстурами практически не ограничены, и все зависит от
воображения и таланта дизайнера. Палитра редактора содержит несколько сотен
разнообразных текстур и их вариаций на любой вкус. Помимо обычных сплошных текстур,
представлены также декоративные прозрачные, которые можно и нужно накладывать поверх
основных – опавшая листва, камни, ракушки, цветы и т.д.
С помощью текстур даже можно создавать иллюзии объема: мелкие камушки, корни,
выступающие из земли плиты, овраги или лужи. Для того, чтобы освоить искусство
украшения локаций и понять, какие наборы и текстуры можно органично сочетать друг с
другом, рекомендуется изучить уже созданные для игры локации и посмотреть, как они
устроены, как сделаны те или иные переходы и каким образом достигается ощущение
уникальности каждого места.

Практическая часть.

Как уже было сказано выше, текстура – одно из основных выразительных средств,
которым владеет дизайнер локаций. Грамотное сочетание текстур и объектов даст нам
полную власть над ощущениями, которые вызывает локация у игрока.
Нам необходимо подключить пакеты текстур, которые лучше всего отражают настроение
локации – места, где царит вечный закат. Нам нужны закатные, оранжевые тона, поэтому
будем использовать пакеты текстур humenlands и autumn. Для начала наложим базовую
текстуру на локацию – это будет наша основа.

Рис. 2.4. Базовая текстура.


В качестве базовой мы используем текстуру песка – материал Ground_A_02. Закрасим
им большую часть локации, кроме тех областей, где будут горы. Теперь при дальнейшем
рисовании необходимо накладывать другие текстуры и обеспечивать качественные
переходы между ними, используя на швах промежуточные текстуры. Попробуем нарисовать
гору на северо-западе, в которой будет вход в пещеру. Используем для этого текстуру камня
humen_stone_10 (см. рис. 2.4 – эта текстура выделена цифрой 1). Для перехода этой
текстуры в песчаную хорошо подойдут мелкие камушки двух тонов – более темного и более
светлого, это – материалы humen_stone_2 (2 на рисунке) и humen_stone_4 (3). Для того
чтобы текстуры мягко перетекали друг в друга, выставим маленькую альфу для кисти –
около 30.

Рис. 2.5. Горы.

Теперь финальный штрих – выделим верхушки гор более светлой вариацией текстуры
камня – humen_stone_10a. Не то чтобы это было катастрофически важно, но использование
вариаций текстуры немного другого тона – основной способ имитации освещенности наряду
с lumi-слоем.
Рис. 2.6. Подсветка вершин гор более светлой вариацией текстуры.

Аналогично поступим и с южным мысом: точно так же сначала наложим текстуру камня,
потом создадим переход к песчаной текстуре мелкими камушками и, наконец, подсветим
выступающие части гор более светлой вариацией текстуры.
Мы разобрались с горами и тем, как их рисовать с помощью текстур. А еще с тем, как
можно обеспечивать переходы разных текстур друг в друга с помощью дополнительной
детализации. Конечно, можно делать переходы за счет полупрозрачной кисти, но это ведет к
смешению двух текстур, что не всегда выглядит красиво и логично. Теперь займемся
островком, примыкающим к основной локации.
Рис. 2.8. Берег островка.

Поскольку на нем у нас будет жить чудовище, имеет смысл сделать его темным и
страшным, поэтому для него мы будем использовать группу текстур темного леса (она
находится в уже подключенном наборе humenlands). Для начала возьмем материал
humen_darkstone_1 и сделаем с его помощью скалистый берег на юго-востоке островка (на
северо-западе у нас будет вход через мост). Сетка включена для того, чтобы видеть, где
начинается спад уровня высоты, – там уместнее рисовать скалу. На следующем рисунке
изображен уже полностью покрашенный островок.
Рис. 2.9. Базовая текстура островка.

Для получения такой картинки были использованы два материала – основную


поверхность островка мы красили материалом humen_darkgrass_6 (1), а оставшуюся часть
берега – все теми же мелкими камушками, но уже темно-синего оттенка, материалом
humen_darkstone_2 (2). Теперь необходимо немного разнообразить поверхность островка и
добавить дорожку. Посмотрим на следующий рисунок.
Рис. 2.10. Дорожка на островке.

Помимо самой дорожки, сделанной материалом humen_darkdirt_4 (3), мы слегка


разнообразили однотонную траву на острове вкраплениями текстур humen_darkgrass_2 (2) и
humen_darkgrass_1 (4), это просто другие виды травы. Кроме этого, мы сделали так, что
дорожка выходит на поляну, которая ограничена возвышенностью. Имитация склона
сделана с помощью корней humen_darkroot_03 (1). Однако на данный момент этот склон
выглядит незавершенным, потому что перепад высот на нем недостаточен. Вернемся в
режим редактирования высот и слегка опустим (взяв уже меньшую по размеру кисть)
область поляны и тропинки. В завершение текстурирования островка добавим на дорожку
маленькие болотные камешки swamp_08a.
Рис. 2.11. Полностью текстурированный островок.

Использовав материал камешков, мы впервые столкнулись с декоративной текстурой.


Такие текстуры имеют прозрачные области, а потому могут быть наложены только поверх
других текстур и служат для улучшения внешнего вида поверхности и создания иллюзии
того, что на ней есть объекты. Таких текстур немало, и их непременно стоит использовать –
это прямой способ разнообразить локацию без загромождения ее атомами и проблем с
проходимостью. Теперь вернемся к основному острову, предварительно нажав merge map, –
склеим наши слои, чтобы разгрузить видеопамять.
Рис. 2.12. Растительные области.

На рис. 2.12 изображена покраска текстурой растительных областей локации. Мы будем


использовать материал Ground_D_01 – траву желто-оранжевого оттенка, которая хорошо
сочетается с «закатной» темой локации. Соответствующим образом позже мы выберем
деревья для локации, а пока закрасим растительные области этой текстурой, оставив место
у самого берега для сшивания с водой. Саму текстуру будем немного разбавлять похожими
по цвету и фактуре материалами Grass_00, Grass_01 и Grass_Big_00-04, которые в палитре
находятся чуть выше. Нарисуем траву ровно до того места, где у нее будет край (не
оставляя места под блендинг), а потом снова положим мелкие камушки на это место, но
слоем ниже (мы можем менять слои местами при помощи кнопки layers). Так мы можем
достаточно свободно накладывать текстуру камушков, не опасаясь за то, что другой слой
будет испорчен. Сами камушки уйдут в воду через текстуру камня, с которой мы и начали
редактирование локации.
Рис. 2.13. Береговая линия.

Подобным образом сделаем береговую линию и в других областях локации, оставив


пару спусков на воду. Самая большая травянистая область, таким образом, у нас получится
на северном мысе локации (от него до горы, с маленькой дорожкой), в центре оставим
песок, а южный мыс тоже покрасим травой, оставив свободной небольшую площадку около
маяка и дорожку до него. Теперь займемся разукрашиванием этих самых дорожек. Для
создания темной каменистой дороги хорошо подходит материал Ground_A_03 (1 на рис.
2.14), им мы закрасим центральную «площадь», спуск к воде и дорожку на север, дорогу же
на юг и площадку маяка покрасим светлой текстурой потрескавшейся земли humen_dirt_7b
(3) или ее аналогом с меньшими трещинами humen_dirt_6a (3), накладывая их с очень
маленькой альфой. В данном случае маленькая альфа вполне приемлема. Наконец, сверху
на них положим декоративную текстуру больших дорожных камней Ground_A_04 (2).
Рис. 2.14. Дороги.

Теперь перейдем к более детальному декорированию областей склейки травы с песком


и других областей локации.
Рис. 2.15. Декорирование.
Для начала о стыке травы с песком. Здесь мы можем значительно улучшить внешний
вид локации, используя декоративную текстуру Ground_D_08 (1). Этот материал
представляет собой маленькие кустики травы с альфой, которые можно накладывать поверх
основной текстуры. Второй декоративный элемент – пучки травы, как будто проросшие
между дорожными плитами – материал Ground_B_11 (3). Эту декоративную текстуру лучше
всего накладывать на дороги, но можно использовать ее и не по прямому назначению,
декорируя стык травы с песком. Этой текстурой закрасим (естественно, с альфой) дорожку к
маяку. Наконец, будем использовать мелкие камушки для декорирования всей площади
локации. Их можно накладывать на траву, на песок и даже на горы. Очень полезный
материал – Ground_A_05 (2).
На данном этапе можно считать предварительное текстурирование законченным. Как и в
случае с рельефом, это не финальный штрих, нам еще не раз придется изменять текстуру
при постановке на карту объектов (которые точно так же должны хорошо стыковаться с
текстурой под ними), при финальном декорировании (когда все объекты расставлены, имеет
смысл пройтись по локации еще раз для создания завершающих деталей), да и по ходу
изменения локации всегда могут возникнуть новые идеи, как сделать ее лучше.
При наличии терпения, воображения и желания можно уделить больше внимания
детализации ландшафта. Можно имитировать отдельные кустики травы, выросшие на краю
обрыва, с помощью текстурной кисти, нарисовать затененные области или модифицировать
цвет поверхности с помощью lumi-слоя. Даже можно нарисовать объемные камушки, плиты
или корни, выступающие из земли. В общем, творите!
СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >
2.3. Расстановка объектов.

В этом разделе пойдет речь, прежде всего, о статичных объектах ландшафта. Любой
объект в игре в общем случае состоит из двух частей – атома и логического объекта. Атом –
это то, что определяет базовые свойства объекта в мире: его внешний вид, размер, то, как
он влияет на проходимость локации. Логический объект определяет уже характер его
взаимодействия с игроком, его реакцию на клики мышкой и так далее. Прототип объекта –
его атом-файл. В строгом смысле атом и атом-файл – это не одно и то же, так как атом-файл
также содержит базовую информацию о логике, но мы будем пользоваться термином «атом»
для обозначения и того, и другого.
Атомы обладают целым рядом свойств, но, прежде всего, каждый атом принадлежит
определенному классу. В этом разделе мы рассмотрим классы атомов static, dynamic, hollow
и bridge.
Static – атомы, которые не имеют ни анимации, ни логики. Это камни, деревья, заборы и
прочие неподвижные объекты, никак не взаимодействующие с игроком.
Dynamic – это анимированные объекты, которые также не имеют логики. Например,
кролик, который бегает по земле, или указатель с раскачивающимся от ветра фонарем – это
все динамические атомы.
Hollow – атом, который не имеет модели. Как правило, это спецэффекты, созданные на
основе частиц. Облако тумана, дым, пламя, столб солнечного света – это все атомы класса
hollow. С помощью этой группы атомов, например, создается звуковая атмосфера на
локации – к невидимому объекту прикреплен звуковой ambient-файл, имитирующий плеск
волн или щебет птиц.
Bridge – статический или динамический атом, который обладает дополнительным
свойством – он служит «площадкой», по которой может бегать игрок. При этом карта высот
ландшафта подгоняется под эти объекты: нельзя пройти под мостом, и если вы попробуете
это сделать, то герой ”запрыгнет” на мост. Например, с помощью таких мостов сделаны
ступени огромных лестниц, по которым может бегать герой, или острова в Демонисе,
парящие в воздухе.

Рис. 2.16.
Инструмент атомов.
Для декораций прежде всего используются статические атомы. Найти такие атомы
можно во вкладке Atoms (Shift-A) в панели инструментов. Когда мы открываем эту вкладку,
появляется дерево всех атомов. Чуть выше можно выбрать представление папок дерева –
либо через иконки атомов (thumbnails), либо через список по тегу (названию файла-
прототипа). Instances выведет нам список всех атомов, которые есть на карте, для быстрого
поиска. Выбрав атом и нажав кнопку Insert – она похожа на Play (обычно это делается
автоматически, но стоит следить, включена ли эта опция), – мы можем поставить атом на
карту. Это можно сделать и простым левым кликом.
Структура папок достаточно проста: обычно в папке хранятся атомы определенного
класса, разбитые на подпапки по тематике локаций. Например, пальмы будут находиться в
папке пустыни, а елки – в папке «человеческих» локаций. Можно создавать свои папки
правым кликом на дереве атомов и перекидывать по папкам атомы при помощи правого
клика на атоме и выбора команды Move to.
В Decorations хранятся атомы, ответственные за декорацию. Это елки, пеньки, трава,
камни и прочие объекты, необходимые для создания дизайна локаций. Отдельно стоит
отметить папку Decorations/land/bridge, где хранится большинство мостов. В Resources
хранятся различные алтари, золото/кристаллы, сундуки и прочие интерактивные объекты,
которые может подбирать игрок, получая при этом различные бонусы и ресурсы. В категории
Units хранятся армии (монстры на карте), герои противника (уникальные модели,
отмеченные специальным эффектом) и NPC. В Environment хранятся атомы класса hollow –
спецэффекты, водопады и прочее. Там же хранятся атомы, ответственные за звуки на карте,
такие как журчание воды. В Buildings хранятся активные (не декоративные) строения на
карте, включая замки. В Logic хранятся объекты с логикой, так, например, сам герой
(необходим на самой первой локации для генерации) или лифты/платформы. В папке Arena
содержатся атомы, специфичные для арен (о них ниже), далее идут Old (атомы из «Легенды
о Рыцаре») и Uncategorized, которые не попали ни в какую категорию.

2.3.1. Базовые операции с объектами.

Все атомы на карте поддерживают следующие операции: перемещение, поворот и


масштабирование. Крайне рекомендуется запомнить используемые горячие клавиши:
M переключает в режим перемещения атомов. В этом режиме движения мышью с
выбранным объектом и зажатой левой кнопкой мыши приведет к перемещению объекта.
Если же в дополнение к этому зажать Alt, объект будет перемещаться не в горизонтальной, а
в вертикальной плоскости;
R переключает в режим поворота атомов. В этом режиме движение мышью приводит к
повороту объекта вокруг вертикальной оси Z. Если зажать клавишу Alt, то можно вращать
объект вокруг других осей, но уже в пределах 180 градусов. Для поворота на большие или
заданные углы необходимо использовать ручную настройку поворота;
S переключает в режим масштабирования атомов. В этом режиме движение мышью
приводит к изменению размера атома по всем трем осям.

Это самые используемые операции над объектами. По умолчанию любой объект,


поставленный на карту, будет поставлен вертикально и привязан к ландшафту по высоте.
Масштаб объекта задан в конфигурации самого атома, и многие атомы выставляют
случайное значение угла поворота и масштаба, в заранее заданных пределах. Попробуйте
выбрать дерево и поставить его десять раз на карту, и вы поймете, как это работает.
Клавиша N с выбранным объектом (выбранным считается тот, на котором находится
курсор) переносит нас к следующему атому с тем же именем (тегом), V создает другую
вариацию атома с тем же тегом (атомы с одинаковым тегом могут варьироваться в
ориентировании/размере), F находит атом в палитре. Для более сложных атомов E
редактирует эмбрион, а L – логический объект, но об этом ниже. Открыть окно свойств
объекта можно нажатием клавиши пробел.

2.3.2. Изменение свойств объекта.

Каждому объекту выдаются значения параметров по умолчанию, полученные из атом-


файла объекта. Как уже было сказано выше, по нажатию пробела мы вызываем свойства
объекта. Все объекты имеют вкладку Origin – это положение объекта на локации. Здесь
можно вручную и очень точно отрегулировать положение объекта по всем трем осям, его
поворот вокруг этих осей и масштаб.
Вкладка Overrides позволяет перегрузить некоторые псевдологические свойства объекта
на карте. В ней есть ряд разделов, для подавляющего большинства объектов это Main и
Collision Shapes.
Параметры Main:
Is hidden – отвечает за то, скрыт ли сейчас объект на карте. Необходим для квестовых
объектов, которые появляются или скрываются с помощью специальных логических команд;
Mapicon – вид иконки на карте локации. Только для зданий/NPC/порталов.
Параметры Collision Shapes:
Ground collision – вид и размер коллизии объекта, определяет физические свойства
объекта и влияет на его проходимость. Если задать число, то область непроходимости будет
окружностью с этим радиусом, если задать colshape-файл, то будет сложная проходимость,
заданная в файле, если ничего не задать (не 0, а именно пустое поле) – объект будет
полностью проходим;
Passability Area – то же самое, но для перемещающихся по воздуху существ. В игре эта
возможность не используется. Теоретически можно создавать существ, перелетающих на
карте через невысокие препятствия;
Layer #0 (buildings or boxes) – область интерактивного взаимодействия «вплотную» для
зданий или контейнеров. Радиус или colshape;
Layer #1 (Army/NPC impact) – область взаимодействия «вплотную» для армий или NPC.
Радиус или colshape;
Layer #2 (radius smell) – радиус обоняния и слуха армии, то есть тот, в котором враг
«замечает» героя даже в том случае, если он подходит со спины.;
Layer #3 (radius vision) – радиус видимости армии, на котором отряд замечает героя, если
он находится в его поле зрения. Только для армий;
Layer #4 (radius lost) – радиус, вне которого должен оказаться герой, чтобы вражеская
армия перестала его преследовать;
Layer #5,6 – зарезервированные, можно использовать на свое усмотрение;
Layer #7 (boat with hero) – радиус взаимодействия лодки с героем.
Также у ряда объектов есть дополнительная вкладка Text, позволяющая добавлять к
нему описания на карте. Hint – сообщение, которое всплывет, если навести на объект
указатель мышки. Message – отображается в окошке по правому клику на объект. Если
Message не задавать, то вместо него будет использоваться Hint.
Еще одна вкладка, общая для многих объектов – Variables. Там можно посмотреть и
отредактировать записанные в объект переменные.

Практическая часть.

Итак, мы нарисовали текстуры и сделали сложный и интересный рельеф. Теперь самое


время наполнить локацию объектами и жизнью, то есть статичными и активными объектами.
Для начала поставим на карту маяк. Пока что он будет стоять как декорация, логику же мы
настроим позже. Сам маяк находится в категории Buildings/Human/lighthouse_02, выставим
его на возвышенность на южном мысе. По необходимости с помощью операции Alt-Move
слегка утопим его в ландшафт. Вообще при выставлении объекты ориентируются по высоте
той точки, на которую указывают курсор. Вследствие этого, если объект протяженный в
пространстве, а ставится на самую верхушку возвышенности, его края могут повиснуть в
воздухе, и его нужно будет опустить. Обратите внимание, в верхней части панели есть
несколько очень полезных опций:
Objects follows landscape – если она активна, то при установке и перемещении объект
будет «скользить» по ландшафту, следуя карте высот. При этом вы не сможете поднять или
опустить объект относительно уровня ландшафта;
Addition – эта кнопка открывает пару дополнительных возможностей. На данный момент
нам нужна строка поиска Find. Вводя в ней имена или части имен объектов через пробел,
мы включим фильтр. Кнопка справа показывает количество объектов, соответствующих
заданному условию. Нажав на нее, мы вызовем список найденных объектов. Выбрав
нужный объект, мы переместимся к нему в палитре атомов;
Обратите внимание на тень от поставленных объектов: она сейчас выглядит
неестественно и некрасиво, поэтому слегка забежим вперед, залезем в главное меню в
Location/Light и уменьшим shadow transparency c 1 до 0.5 во вкладках для каждого времени
суток, так тени будут более прозрачными и не будут мешать восприятию. Поставив маяк,
наполним наши лесные области рядом с ним деревьями. Деревья нам нужны схожего с
травой цвета, то есть осеннего, и близких к нему цветов – для разнообразия. Такие деревья
можно найти в папках Decorations/land/human/trees и Decorations/land/human/trees/highpoly
(там находятся деревья с большим количеством полигонов). Получится что-то вроде того,
что изображено ниже на рис. 2.17:
Рис. 2.17. Первоначальная расстановка объектов.

У нас готова основа локации, наполненной объектами. Теперь нужно будет все это
детализировать, но пока сделаем то же самое и с северо-востоком основного острова и
заодно поставим там домик, в котором будет жить наш NPC. Домик возьмем из папки
Buildings/Pirate_robber/building_pirate_house03, он вполне соответствует внешнему виду
«обычного жилища». Небольшой участок на северном мысе пока оставим нетронутым.
Рис. 2.18. Объекты на севере острова.

Теперь займемся пещерой. Нам нужен красивый вход в нее, его можно либо слепить из
отдельных камней самостоятельно, либо взять готовый, уже сделанный за нас художниками
Katauri. Мы пойдем по второму пути и «вклеим» в уже нарисованную гору вход в пещеру из
папки Decorations/cave/cave_cyclop. Но вот беда, он немного отличается по цвету от горы под
ним. Прежде чем искать другой вход подходящего цвета (такого на самом деле нет) или
переделывать гору целиком, зададимся вопросом: а настолько ли велика разница в цветах?
Возьмем текстуру мелких камушков зеленоватого оттенка (здесь и далее читателю
предлагается найти ее в палитре самостоятельно) и подкрасим гору вокруг входа в пещеру,
создавая плавный переход от объекта к текстуре.
Рис. 2.19. Вход в пещеру.

Получилось неплохо. Необходимо только покрасить и сам вход: для этого в палитре есть
текстура черного цвета, ею закрасим стену горы, которая находится внутри входа в пещеру.
Доработаем это место, добавив на самый верх горы атомы из группы
Decorations/human/stone/mountain. Не нужно стесняться погружать их в ландшафт и
масштабировать в широких пределах: поскольку область априори непроходима, нас
интересует только внешний вид. Если все сделать правильно, поверхность горы станет
несколько более неоднородной и с резкими перепадами высот без потери качества
текстуры.
Рис. 2.20. Сочетание текстуры горы и атомов.

Теперь проделаем ту же процедуру со скалой у маяка, добавив туда горы-объекты.


Можно использовать очень большие горы, погружая большую их часть в ландшафт, однако
необходимо помнить, что, даже сидя под ландшафтом, они будут блокировать перемещение
персонажей, поэтому при необходимости colshape таких атомов нужно отключать (метод
описан выше), а непроходимую область рисовать вручную на карте проходимостей. Если
необходимо, подкрасим ландшафт вокруг, чтобы сдвинуть гористую область.
Рис. 2.21. Скалы на южном мысе.

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


мелких декоративных объектов.
Рис. 2.22. Маленькое декорирование юга острова.

Тут уже все определяется полетом фантазии дизайнера, но можно описать то, что было
сделано на рисунке. Во-первых, пространство за маяком было заполнено ананасовыми
кустами из Decorations/land/desert_land. Потом вокруг маяка были раскиданы бочки/тюки из
группы Decorations/land/human/town/port, а по лесу – трава из Decorations/land/human/grass,
плюс ограждение. Можно ставить много однотипных объектов в одном месте, но всякие
заросли папоротника выглядят куда лучше, если входящие в их состав кусты имеют разный
масштаб.
Рис. 2.23. Мелкое декорирование входа в пещеру.

Точно так же оформим вход в пещеру, используя деревья, кусты и корни. Не стесняйтесь
экспериментировать и использовать атомы из разных групп и категорий, даже если они
тематически не оправданы. В конечном итоге, единственный критерий – это внешний вид
локации, и даже если атом из папки декораций для Мира Мертвых, но при этом хорошо
смотрится на локации – его можно и нужно использовать.
Рис. 2.24. Достопримечательности.

Локация во многом выиграет, если на ней будет не только «просто лес» или «просто
камни», но и какие-то выдающиеся объекты, которые будут радовать глаз и придавать месту,
где они находятся, уникальность, узнаваемость. Например, гигантский якорь на острове
Ржавый Якорь не несет никакой логической нагрузки, с ним нельзя взаимодействовать,
однако он создает впечатление того, что локация представляет собой какое-то реальное,
уникальное место, а не просто собрана из типовых кусочков типовыми средствами (под
такими достопримечательностями, кстати, можно закапывать клады). На нашей локации мы
создадим такой объект: это будет гигантский пень в лесу. Пень возьмем здесь:
Decorations/land/human/tress/stub/stub02, в Decorations/land/human/plants возьмем грибы,
которые будут расти рядом с ним. Наконец, пространство под ним можно покрасить другой
текстурой с корнями (материал находится рядом с материалом травы, который мы
использовали). Теперь, выставив этот объект на карту, создадим к нему тропинку в лесу от
домика нашего NPC.
Рис. 2.25. Тропинка в лесу.

Это еще не совсем тропинка. Тропинку мы сделаем, взяв из палитры текстуру


потрескавшейся земли. Также немного разнообразим пространство вокруг дома, поставив
туда стол и тюки с мукой. Ну и весь остальной лес тоже оформим аналогично предыдущему.
Рис. 2.26. Облагороженная тропинка.
Теперь самое время снова взяться за декоративные текстуры, на этот раз совмещая их с
объектами. Например, можно сделать полянку с цветами:

Рис. 2.27. Цветочная поляна.

Над поляной поместим бабочек – атом класса hollow по адресу


Environment/visual_fx/hll_butterfly. Это вышеупомянутый атом без модели, для того, чтобы
отобразить в редакторе его центр, необходимо, чтобы было включено отображение скрытых
объектов (View/Hidden в главном меню). В глубине леса расставим атомы hll_firefly
(светлячки) и проделаем похожую операцию с нашим гигантским пнем. Там мы поставим
несколько атомов hll_leaves_summer_c (падающие листья). Для того чтобы листья не
создавались выше крон деревьев, уменьшим масштаб выставленных атомов (атомы класса
hollow поддерживают те же операции, что и обычные) и, для завершения эффекта
присутствия, раскрасим ландшафт вокруг них текстурой опавших листьев.
Рис. 2.28. Листопад вокруг волшебного пня.

Наконец, завершим постановку статичных атомов на локацию созданием эффекта


портала у входа в пещеру. Эффект портала и специальный невидимый атом, содержащий
логику портала, возьмем по адресу Logic/portal/portal_test_ground и аккуратно утопим внутрь
арки пещеры. Ориентация портала в данном случае не важна, потому что это будет портал
на вход (как мы выясним позже, лучше делать так, чтобы вход и выход из портала не
совпадали).
Рис. 2.29. Эффект портала.

Наконец расставим объекты на маленьком острове. Здесь необходимо использовать


несколько иной набор атомов, нежели на основном острове, да и текстура далека от
совершенства и нуждается в корректировке. Читателю предлагается сделать это
самостоятельно.
Рис. 2.30. Островок неподалеку.

Остался лишь один вопрос: как связать маленький остров с основной локацией?
Попробуем поставить между ними мост, однако расстояние оказывается слишком большим,
чтобы поместился какой-либо деревянный мост, а каменный не вписывается в тему локации.
Что же делать? Мы поступим просто: сделаем плот. Подробно этот процесс будет описан
ниже, в 5.1, уже после рассмотрения логических объектов и принципов работы
монорельсовой системы. Сейчас же мы займемся настройкой воды.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


2.4. Настройка воды.

Вода – еще одна сильная сторона движка «King’s Bounty». Доступно достаточно много
параметров ее настройки, но необходимо учитывать, что это почти прямой интерфейс к
настройке воды SkyFallen, так что не все функции адекватно работают в игре, а некоторые
не работают вообще. Настройки воды доступны в игре из трех мест: инструмент Water в
панели инструментов, там доступен шаблон default, который отвечает за основную воду на
локации; кнопка Deep Water Settings в Landscape (на самом деле редактируется тот же
самый шаблон default) и дополнительные настройки воды в Location/Light в главном меню. О
последнем речь пойдет позже, а сейчас немного теории о первых двух.
Вода делится на два типа – основная и дополнительная. Основная вода определяется
шаблоном default и по умолчанию «заливает» всю локацию, дополнительная определяется
другими шаблонами и может существовать на локации в отрыве от основной. Можно
заливать локацию дополнительной водой кликами мышкой с выбранным шаблоном – можно
заливать целиком каждый текстурный тайл локации. Основная вода и дополнительная
значительно отличаются в настройке.

2.4.1. Базовые свойства воды.

Настраивая воду, мы настраиваем как бы два отдельных объекта: толщу воды и ее


поверхность. Сначала немного о том, как устроена вода. Толща воды представляет собой
цветовой градиент от поверхности ко дну, и мы можем настроить величину градиента и его
цвет. Также толща воды отвечает за размытие объектов и ландшафта, которые находятся
под поверхностью. Поверхность воды несколько сложнее. На ней может быть текстура
отраженного неба, которая дополнительно подкрашивается цветом поверхности воды. Потом
эта текстура модифицируется динамическим эффектом, ответственным за плещущиеся
волны на поверхности. Наконец, сверху на все это накладывается анимированная текстура
волн у берега. Вода – объект достаточно сложный, поэтому для достижения необходимого
эффекта придется много играть с настройками, потому как поведение воды с различными
значениями параметров может сильно отличаться от ожидаемого. Сложность в работе с
водой еще и в том, что основной шаблон воды и дополнительный достаточно сильно
отличаются в настройке, одни и те же параметры могут иметь разный смысл. Для того,
чтобы не запутаться, рекомендуется сначала поиграть с настройками уже существующей
воды, импортируя ее из другой локации. Импорт/экспорт настроек воды осуществляется
кнопками Load from file/Save to file.

2.4.2. Глубокая вода.


В 99% случаев, если вам необходимо пользоваться основным шаблоном воды, кнопка
Deep Water должна быть включена. Это обусловлено тем, что основной шаблон имеет
совсем другие настройки, нежели дополнительный: он связан с освещением локации, ряд
его параметров зависит от времени суток. Более того, именно основной шаблон находится
за краями локации, но в отсутствии Deep Water вода не будет прорисовываться «до
бесконечности». Именно глубокая вода ответственна за бескрайние водные просторы и
линию горизонта. Сам шаблон default лучше не трогать, а всю настройку проводить через
Deep Water Settings во вкладке Landscape. Какие настройки нам доступны?
Рис. 2.31. Настройки воды.

Water level – самое простое, уровень воды относительно нуля оси Z. Не рекомендуется
менять в процессе создания локации.
Water color – четыре слайдера в формате RGBA. Влияют на подкраску поверхности (!)
воды, последний слайдер (альфа) не работает.
Texture scale – для глубокой воды не работает.
Diffuse texture rotation – для глубокой воды не работает.
Texture speed – для глубокой воды не работает, при определенном значении может
отключить волны у берега, так что лучше не трогать.
Fresnel bias – определяет прозрачность поверхности воды. Чем больше величина этого
параметра, тем менее прозрачна поверхность. Если выставить ноль, поверхности воды
вместе с рябью вообще не будет, останется только цветовой градиент глубины. Если же
поставить максимум – наоборот, на поверхности будет видно только текстуру отраженного
неба и рябь на ней, вода будет абсолютно непрозрачна.
Fresnel scale – не работает для глубокой воды.
Fresnel depth alpha – вопреки своему названию, определяет вовсе не прозрачность
воды, а интенсивность ряби. Чем больше величина этого параметра, тем более мелкой
будет рябь на воде.
Bump scale – визуально дублирует предыдущую настройку. Их эффект суммируется, так
что для лучшего вида воды необходимо, чтобы обе были скручены влево.
Depth alpha – для глубокой воды не работает.
Depth scale – определяет интенсивность цветового градиента. Чем меньше значение,
тем более прозрачна толща (не поверхность) воды.
Environment cubemap – одна из важнейших настроек. Для того чтобы поверхность воды
выглядела натурально, в ней должно что-то отражаться, например небо. Выбор в данной
настройке – как раз выбор того самого неба.
Refraction – при включенной галочке на воде будут отражаться близлежащие
объекты/элементы ландшафта. При низкой интенсивности ряби выглядит красиво, но, к
сожалению, есть баг – порой отдаленные объекты вылезают на воде с края экрана. Плюс к
тому, нагружает видеокарту.
Refraction scale – интенсивность отражения объектов в воде. Баг с краем экрана можно
увидеть, если выставить этот параметр близким к единице.
Bump scale (vector) – ни на что не влияет.
Bump map – не используется.
Water speed – определяет скорость движения волн, интенсивность ряби.
Water direction – изменяет направление движения волн (не работает в данной версии
редактора).
Bump map (secondary) – не используется.
Water speed (secondary) – не используется.
Water direction (secondary) – не используется.

Вкладка Swash позволяет задать разлетающиеся брызги при столкновении воды с


берегом. В игре не используется, так что экспериментируйте с этой настройкой на свой страх
и риск.

Вкладка Foam позволяет задать волны, которые будут создаваться у берега. К


сожалению, эту настройку нельзя задавать локально и делать отдельные места с более
бурной водой, однако доступно три слоя волн, что позволяет создать интересную береговую
линию. Нужно отметить, что волны образуются только вокруг ландшафта, игнорируя при
этом любые объекты. С технической стороны волны – это просто анимированная текстура,
которая дополнительно накладывается на воду у берега.
Настройки каждого из слоев прибрежных волн:

Foam width – определяет ширину текстуры волн от берега. Если поставить параметр на
максимум, увеличится расстояние от начала волны до берега и скорость волны;
Foam jitter – определяет то, насколько отдельные участки текстуры волны
синхронизированы друг с другом. Если этот параметр близок к нулю, то все волны будут как
бы слиты в одну большую. Высокие значения параметра увеличат разброс;
Foam speed – скорость анимации текстуры волн.
Для всех трех слоев также есть общие настройки:

Foam opacity – прозрачность текстуры волны;


Foam opacity bias – при ненулевом значении этого параметра текстура волны будет
иметь повышенную прозрачность у берега;
Foam margin – латеральное (тангенциальное) масштабирование текстуры волны. Чем
больше значение, тем более вытянута вдоль берега будет каждая волна;
Foam scale – нормальное масштабирование текстуры волны. Каждая отдельная волна
станет меньше, но область их генерации не меняется. Влияет на скорость генерации волн;
Foam thresh – определяет количество волн, которые создаются вокруг участков берега.
При большом значении параметра создается меньше волн вдоль берега.

Таким образом, глубокую воду можно настроить достаточно гибко, однако в первую
очередь нужно ориентироваться на итоговый внешний вид: чем привлекательнее и
естественнее, тем лучше. Один из важнейших ее параметров – цвет толщи воды –
недоступен через настройки самой воды, его нужно настраивать через свойства освещения
(Location/Light/Water Settings/Deep Color). Следует также заметить, что глубокую воду можно
использовать и творчески: например, можно убрать ее поверхность и выставить цвет толщи
черным – тогда ее можно использовать как бездонную пропасть.

2.4.3. Шаблоны воды, несколько видов воды на локации.

Все вышенаписанное относится к шаблону default. Пока что мы редактировали только


его и уже выяснили, что он практически всегда должен быть настроен на глубокую воду.
Однако изредка нам нужно несколько разных видов воды на одной локации. Рассмотрим
ограничения, которые накладываются на воду при таком использовании. Далее везде
считается, что глубокая вода включена.
Шаблон default присутствует всегда, его нельзя удалить, более того – его нельзя
заменить. В списке шаблонов по правому клику мы можем создать новый, однако если мы
попытаемся рисовать им поверх default, ничего у нас не выйдет, хотя и будет писаться, что
на данном текстурном тайле используется другой шаблон. Таким образом, на одном тайле у
нас есть либо шаблон default, либо default и еще какой-то другой. Отсюда вытекает ряд
правил. Во-первых, используя вторую воду, мы должны поднимать ее уровень, иначе ее
просто не будет видно под default. Во-вторых, неглубокая вода не обладает цветовым
градиентом (то есть мы сможем разглядеть ландшафт под ней вне зависимости от того, как
глубоко он находится, хотя на деле все несколько сложнее – об этом ниже), а,
следовательно, уровень ландшафта под настраиваемой водой должен быть выше уровня
воды default. Ощущение глубины, однако, можно и нужно создавать подкраской текстуры
дна, то есть воду, которая выглядит, как глубокая, мы создать-таки можем, но это достаточно
трудоемко. В «Принцессе» такая вода вообще не используется. В ЛоР, однако, такая
методика используется на Моршанских Топях, можно запустить игру и посмотреть, как
именно это сделано.
Итак, мы выяснили, что есть принципиальная разница между шаблоном default и другими
шаблонами, расположение таких на локации нужно очень хорошо продумывать заранее.
Самое главное различие все-таки в отсутствии цветового градиента и, как следствие,
глубины. Для такой воды есть настройки, которые изменяют ее оптические свойства в
зависимости от глубины, но глубина тут рассчитывается именно от рельефа, так что сделать
объекты, часть которых находится под водой и оттого едва различима, тут нельзя. Главное в
такой воде – ее поверхность и размытие, которое применяется ко всем объектам под ней,
создавая ощущение того, что они находятся под водой. Если default нужно применять для
создания морей и океанов, то другие шаблоны лучше всего подходят для создания
статичных изолированных водоемов: горных озер с кристально чистой водой, мутных болот
или омутов, небольших цветных луж. Можно делать и реки, но это уже очень и очень
непросто. Для имитации эффекта движущейся воды в группе атомов hollow
(Environment/visual_fx/waterfall) есть ряд спецэффектов, но увлекаться ими не следует.
Кроме того, настраиваемый шаблон воды резко отличается от default в параметрах.
Рассмотрим изменения:

Water level – то же самое, что и для default;


Water color – то же самое, что и для default, однако, поскольку у нас не используется
цветовой градиент глубины, эта настройка куда больше влияет на цвет воды. Это не цвет
воды как таковой, это – подкраска текстуры неба;
Texture scale – определяет масштаб текстуры волн. Она будет различима при значении
параметров, очень близких к нулю, поэтому имеет смысл выкрутить оба до нуля, а потом уже
настраивать не через слайдер, а вводя вручную необходимые малые значения;
Diffuse texture rotation – поворот текстуры ряби в градусах;
Texture speed – на практике ни на что не влияет;
Fresnel bias – определяет то, насколько вид текстуры поверхности воды зависит от
текстуры неба и заданного выше цвета воды. При 0 превалирует текстура неба, при 1 – цвет
воды;
Fresnel scale – определяет общую прозрачность поверхности воды;
Fresnel depth alpha – зависимость прозрачности текстуры поверхности от глубины.
Важно понимать, что для неглубокой воды глубина всегда считается как разница уровня
ландшафта и воды в точке. В «глубокой» воде можно увидеть прозрачность и на объектах,
частично погруженных в воду (например, гора), даже если ландшафт под ними очень
глубоко. Здесь то, как глубоко мы увидим ствол дерева, стоящего в воде, зависит только от
того, как глубоко находится ландшафт под ним. Если ландшафт глубоко под водой, то
объект «пропадет» даже на минимальной глубине;
Bump scale – тоже определяет масштаб текстуры ряби, но уже по другому алгоритму.
Реалистичная поверхность воды получается при очень малом значении этого параметра.;
Depth alpha – определяет то, насколько вода становится прозрачной с глубиной. Больше
влияет на зоны с малой глубиной, чем с большой;
Depth scale – определяет масштаб глубины воды. При больших значениях параметра
все остальные настройки, влияющие на глубину, будут действовать сильнее, и наоборот;
Environment cubemap – выбор текстуры неба для поверхности воды;
Refraction – в отличие от глубокой воды, здесь этот параметр определяет динамическое
размытие объектов под водой. Рекомендуется включать: объекты под водой выглядят
реалистичнее;
Refraction scale – интенсивность действия предыдущей настройки;
Bump scale (vector) – ни на что не влияет;
Bump map – не используется;
Water speed – не используется;
Water direction – не используется;
Bump map (secondary) – не используется;
Water speed (secondary) – не используется;
Water direction (secondary) – не используется.

Данная совокупность настроек позволяет сделать воду достаточно красивой. Учтите, что
текстура неба не движется с передвижением камеры, так что некоторые текстуры заранее
рассчитаны на использование в специфических условиях, например, humen_underwater.
Побольше экспериментируйте, порой с помощью настроек воды можно достигнуть
удивительных результатов.
Практическая часть.

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


Landscape и нажимаем кнопку Deep Water, включая глубокую воду. Далее редактировать
воду будем тоже отсюда, через Deep Water Settings. Вода, которая получилась по
умолчанию, достаточно красива, но не реалистична. Попробуем это исправить.

Рис. 2.32. Вода по умолчанию.

Первым делом выберем текстуру неба. Можно оставить текущую, а можно выбрать и
другую, это не столь важно. Хотя следует предварительно условиться, что, раз уж мы
используем закатную гамму, то и вода должна быть соответствующая, поэтому будем
использовать более мягкую текстуру water_cube_sky_2.dds. Также сделаем цвет
поверхности более мягким, поставив все слайдеры примерно на 0.15, слегка выдвинув
красный. Чтобы увеличить прозрачность поверхности, Fresnel bias поставим приблизительно
0.25.
Рис. 2.33. Регулировка цвета воды.
Несколько увеличим количество волн на воде слайдерами Fresnel depth alpha и Bump
scale. Также нужно запустить движение ряби параметром Water speed. Получится что-то
вроде того, что изображено на рис. 2.34.

Рис. 2.34. Регулировка ряби.

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

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


2.5. Освещение локации.

Освещение может сделать локацию интересной или, наоборот, скучной. В игре


достаточно настроек света и, на первый взгляд, очень много различных параметров. В
данном разделе будет объяснено, какие из параметров отвечают за создание определенного
визуального эффекта. В вашем распоряжении есть уже созданные разработчиками игры
файлы-образцы, и вы можете создавать свои конфигурации. Перед тем как рисовать
локацию, имеет смысл хотя бы предварительно настроить то освещение, которое в ней
планируете, чтобы потом не обнаружить, что нарисованный ландшафт выглядит не так, как
вы предполагали. Завершающую доработку света, напротив, лучше оставить на потом.
Таким образом, свет необходимо настраивать дважды: в самом начале и в самом конце.

2.5.1. Виды освещения в игре.

King’s Bounty использует достаточно современный и технически продвинутый движок,


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

Ambient Light – это освещение, не имеющее направления. Рассеянный свет


дополнительно окрашивает объекты со всех сторон. Изменение этого освещения повлияет
на цвет всех объектов примерно одинаково, в том числе и на те, что находятся в тени. Это
наименее ресурсоемкий свет, который всегда есть на локации;
Diffuse Light – глобальное освещение, которое имеет направление и формирует тени,
отбрасываемые объектами. Как и предыдущий, этот тип освещения есть на любой локации,
даже в подземельях;
Omni Light – это локальный точечный источник света. Яркость его максимальна в центре
и падает до нуля на границе радиуса освещения. Таких источников на карте мы можем
использовать множество, в любых местах, однако злоупотребление ими может существенно
повысить нагрузку на видеокарту. Желательно, чтобы один объект освещался только одним
omni-источником одновременно, для экономии ресурсов;
Specular Light – отраженный свет. Он не только перекрашивает объекты, но и может
создавать отдельные лучи, направленные в камеру. В редакторе есть только одна
настройка, связанная с ним, однако важно понимать, что именно этот вид освещения
ответственен за реалистичный металлический блеск и вообще за светоотражающие
свойства материала. Каждый объект с металлической текстурой имеет дополнительную
текстуру, ответственную за отраженный свет. Самый «дорогой» вид освещения, он же
требует наличия у пользователя видеокарты последнего поколения, поддерживающей
шейдеры 2.0. Актуально только для объектов с материалами, имитирующими эффект
блеска и отражения;
Bloom Light – дополнительный световой эффект, ответственный за яркие блики и
засветку некоторых материалов. В отличие от предыдущих видов освещения, Bloom
является постэффектом, накладываемым на всю итоговую картинку. С его помощью,
например, можно создавать эффект легкого золотистого свечения всех объектов на закате.

2.5.2. Настройка глобального освещения локации по


времени суток.

Итак, мы переходим в режим глобального освещения, выбрав пункт Light во вкладке


Location в главном меню редактора. У диалогового окна есть несколько вкладок, рассмотрим
их по очереди. Сначала изучим общие для всех настройки. Внизу окна есть поле Time line;
нажав рядом кнопку Test, мы можем посмотреть, как изменяется освещение с течением
времени. Есть очевидная кнопка Load Defaults и чуть менее очевидные Load и Save, которые
позволяют экспортировать настройки света в .strg-файл и потом импортировать заново.
Учитывая, что настройка света – довольно трудоемкий процесс, порой бывает логично взять
настройки света от другой локации, если предполагается, что они будут похожи. Так,
настройка пещер, очевидно, всегда будет схожей.
Common – настройки солнца и видов тумана.

Рис. 2.35. Основные настройки света.


Настройки солнца отвечают за положение источника Diffuse Light на локации и
изменение этого положения с течением времени. Pitch – угол над поверхностью, другие
настройки отвечают за прочие углы, если вы хотите их задать. С помощью Min Pitch и Max
Pitch можно сделать более длинные или, наоборот, короткие тени, если в этом есть
необходимость. Параметр Time Speed по умолчанию заблокирован и задан в
конфигурационных файлах игры.
Scenetime – настройки времени суток на локации. Поставив галочку Don’t use default
times, можно задать свою длительность времен суток. Также эта галочка разблокирует
настройку Time Speed в Common, что позволяет замедлить/ускорить течение времени на
локации.
Night/Morning/Day/Evening – настройки света на локации в конкретное время суток. Во
всех четырех панелях настройки абсолютно одинаковые, так что мы рассмотрим только
одну. Необходимо учесть, что смена времени суток происходит плавно, то есть резкого
изменения освещения при помощи этого параметра не добиться.

Рис. 2.36. Настройка панели времени суток.

Ambient Color – цвет рассеянного освещения. Таким цветом будут подкрашены все
объекты на локации.
Diffuse Color – цвет, которым будут окрашены объекты при падении на них прямых
солнечных лучей. Интенсивность и цвет рассеянного и диффузного освещения позволяют
создавать общую атмосферу локации. Для создания лунной ночи, например, стоит
использовать более темный оттенок голубого для Ambient, и чуть более светлый – для
Diffuse. В силу того, что весь ландшафт оказывается освещенным обоими типами света,
Diffuse больше действует на ландшафт, а Ambient – на объекты.
Landscape Shadow – цвет теней на ландшафте.
Object Shadow – цвет теней на объектах. Если не хочется, чтобы локация выглядела
аляповато, не должен сильно отличаться от Landscape Shadow.
Specular Power – модификатор отраженного света. В игре не так много объектов, которые
его используют (по сути, он есть только на юнитах), поэтому лучше не трогать этот параметр.
Shadow Transparency – прозрачность теней. Этим слайдером можно выставить
интенсивность теней от полной прозрачности (теней нет) до полной непрозрачности (тени
того цвета, который выставлен выше). Если необходимо избавиться от теней отдельных
типов объектов, лучше использовать группы атомов в настройках локации. Локально тени
можно убирать с помощью omni-источников света.
Bloom Cutoff Threshhold, Bloom Factor, Bloom Factor (for indoors), Clouds Intensity –
настройки Bloom-освещения. Манипулируя ими, можно слегка подсветить картинку или
добиться яркой кислотности и размытости изображения на локации, создавая уникальную
атмосферу.
Fog Settings – настройки тумана, о них чуть ниже.
Water Settings – настройки освещения воды. Здесь можно управлять изменением ее
внешнего вида со временем суток.
Deep Color – цвет глубокой воды.
Horizon Line Color – цвет линии горизонта. Для того, чтобы она выглядела натурально,
необходимо, чтобы цвет неба (задаваемый его текстурой в настройках локации), цвет линии
горизонта и цвет тумана приблизительно совпадали.
Tint – подкраска настраиваемой текстуры воды. В данный момент не используется.
Env Map – настраиваемая текстура воды для времени суток. Подробнее в разделе
«Настройка воды».
Save/Load Panel Settings – экспорт/импорт настроек освещения уже для конкретного
времени суток в .strg-файлы. При создании локаций, на которых свет не зависит от времени
суток, удобно сделать только освещение для одного времени суток, потом экспортировать
его и импортировать во все остальные времена суток.

2.5.3. Настройки тумана.

Для начала нужно отметить, что туман в игре необходим. Туман не только создает
атмосферу на локации, но и позволяет скрыть границу отрисовки объектов, за пределами
которой объекты перестают отображаться. Настраивается туман в двух местах: во вкладке
Common и в настройках света для конкретного времени суток.
Во вкладке Common можно выбрать тип тумана. Не все типы работают корректно. Нас
прежде всего интересуют Depth Fog, Height Fog и Depth Fog (angle dependent). Первый и
второй отличаются только насыщенностью («высотный» туман более густой). А свойства
тумана третьего типа зависят от направления.
В настройках для конкретного времени суток есть поле Fog Properties. В закладке Normal
в этом поле можно настроить цвет тумана, его прозрачность, переднюю и заднюю плоскости.
Near plane – расстояние, на котором начнется сгущение тумана (до этого расстояния тумана
нет), Far Plane – расстояние, на котором его насыщенность станет равной Transparency.
Если последняя установлена в 1, то именно на расстоянии Far Plane от камеры туман
полностью «съест» объекты и ландшафт и сольется с горизонтом.
Другие четыре закладки в Fog Properties (South, East, West, North) будут работать только
при включенном angle dependent fog. Тогда придется настраивать свойства тумана не по
всем направлениям сразу, а по каждому в отдельности.

2.5.4. Локальные источники света. Omni Lights.

Как уже было описано выше, данный вид освещения ответственен за точечные
источники света. Важным замечанием тут является то, что этот свет не заставляет объекты
отбрасывать тени.
Перейти в режим редактирования omni-освещения
можно, выбрав в панели инструментов вкладку Omni
Lights. С omni-источниками можно проводить простые
операции: Insert создаст новый источник, Del – удалит
существующий, а с помощью мыши его можно двигать в
одной плоскости (ЛКМ) или в другой (Alt-ЛКМ) и
масштабировать (Ctrl-ЛКМ), одновременно изменяя
радиус и силу освещения.
Space, как и в случае с атомами, позволяет
редактировать настройки omni-источника.
Color – цвет omni-источника, основная настройка.
Amplification – сила omni-источника. Чем она
больше, тем выше яркость освещения.
Range – расстояние, на котором эффект источника
падает до нуля. Чем ближе освещаемый объект
находится к центру источника, тем больше света на него
падает и тем сильнее засветка.
Max Radius Delta – определяет, насколько сильно
радиус освещения изменяется во времени. 0.2 означает,
что радиус будет меняться от номинального до 0.8. Сам
радиус меняется хаотически в заданном интервале.
Radius Delta Frequency – определяет, с какой частотой будет меняться освещенность при
ненулевой дельте. На деле функция изменения радиуса от времени далеко не
гармоническая, так что этот слайдер лучше всего использовать экспериментально.
Light Landscape – если отключить эту галочку, то omni-источник будет освещать только
объекты, но не ландшафт. Незначительно снижает аппаратную нагрузку.
Four States – если эта настройка включена, можно указать другие свойства omni-
источника, в зависимости от времени суток, например цвет или интенсивность. Фактически,
их можно даже включать или выключать при смене времени суток!
Грамотное использование omni-источников на локации поможет сделать ее интереснее и
красивее. Например, объекты, которые обладают визуальной светимостью (например,
пламя) можно дополнять omni-источниками света для придания атмосферы. Особенно
красиво выглядят фонари, зажигающиеся с приходом ночи, или освещенные мистическим
светом волшебные полянки.

2.5.5. Зоны локального изменения освещенности.

В редакторе можно сделать так, чтобы на определенной области локации освещение


отличалось от глобального. Подобный трюк используется, например, в темном лесу в
Гринворте в «Легенде о Рыцаре». Для этого необходимо выбрать вкладку Landscape на
панели инструментов и в ней выбрать Landscape Logic (четвертая и последняя иконка) ->
Light Zones. Снизу появится список разных зон, и для начала нам нужно создать новую зону.
Настройка зоны освещения полностью идентична настройке глобального света – именно эти
параметры плавно изменятся при входе героя в зону со специальным освещением. Менять
можно все – цвет воды, рассеянное и диффузное освещение, даже туман.
Создав настройки зоны, новую зону можно использовать как кисть. Далее этой кистью
можно раскрашивать ландшафт, создавая на нем реальную зону. Shift-Click, соответственно,
стирает зону. Галочка Override Mode необходима, если вы хотите закрасить одну зону другой
– по умолчанию редактор не даст этого сделать.
Следует учесть, что зоны измененного освещения должны быть достаточно большими и
в точках перехода от одной зоны в другую должны быть горы или лес, скрывающие от игрока
объекты вне зоны. В отличие от omni-освещения, здесь освещенность объектов зависит не
от их координат, а от координат игрока, то есть при входе в такую зону объекты, которые
находятся вне ее, тоже изменят освещенность. Если не закрывать от игрока то, что
находится вне зоны, он может удивиться, как это находящаяся неподалеку яркая поляна с
цветами вдруг становится темной и блеклой. В общем и целом, зоны освещения
одновременно требуют тонкого подхода (скрытие) и длительной настройки, так что
злоупотреблять ими не стоит.

2.5.6. Имитация света/тени с помощью раскраски текстур.


Lumi layer.

Как уже было сказано, omni-освещение накладывает дополнительную нагрузку на


видеокарту, а зоны освещенности ограничены в возможностях и трудоемки в настройке. В
некоторых случаях того же самого эффекта можно добиться и «дешевым» путем, просто
дополнительно подкрашивая текстуру. Основным инструментом для этого является
luminosity-слой (или просто lumi-слой) в панели текстурирования. В отличие от других слоев,
в этом слое идет наложение не текстуры, а просто определенного цвета, только наложение
идет не обычным путем, а высвечиванием поверхности. Lumi-слой всегда находится поверх
остальных слоев и не объединяется с ними по нажатию Merge Map. Если на локации у вас
есть локальные возвышенности, например песчаная дюна, можно придать ей более
реалистичный вид и для этого добавить чуть-чуть желтого/оранжевого в lumi-слой над ней.
Это создаст эффект высвечивания выпуклой части ландшафта, и при этом без
использования omni-источников освещения.
Похожего эффекта можно добиться, используя просто более светлые варианты текстур.
Многие текстуры материалов поставляются не в одном варианте, а в нескольких,
различающихся оттенком или интенсивностью освещения. Можно, опять же, высвечивать
участки на кочках и холмах, создавая большую иллюзию объема.
Наконец, в игре частенько используется и черная текстура для создания рощиц деревьев
или входов в пещеры. В роще несколько деревьев часто не отбрасывают достаточно тени,
чтобы создать необходимую затененность. Можно выбрать текстурную кисть в форме тени
дерева (такая уже есть в наборе текстурных кистей), выбрать черную текстуру и небольшую
альфу – тогда рисование такой текстурой по ландшафту под деревьями создаст нужный нам
эффект затенения.
В этом параграфе, по сути, изложена та же самая идея, что и выше: если что-то можно
сделать с помощью текстурирования, разгрузив вычислительную мощность компьютера, то
лучше это сделать с помощью текстурирования.

Практическая часть.
Для упрощения задачи настройки света наложим на него дополнительное условие: на
локации всегда будет закат, и время суток меняться не будет. Настроим это. Заходим в
Location/Light в главном меню. Нас интересует параметр Sun dir scale – именно он отвечает
за количество оборотов солнца вокруг локации за день. По умолчанию он равен 1, а мы
сейчас выставим его в 0 – тогда солнце перестанет вращаться. Само направление
недвижимого солнца выставим параметром Sun time – поставим его так, чтобы вход в маяк
был не в тени – в 3.30. Наконец, нам нужно мягкое освещение и длинные тени, поэтому
параметры Min pitch и Max pitch поставим оба в 1.

Рис. 2.37. Общие настройки


освещения локации.
Не забудем также указать Position dependent в настройке выбора тумана. Бесконечный
вечер на локации у нас будет волшебным: существа продолжат получать бонусы в
зависимости от времени суток. Для этого мы просто сделаем настройки для всех времен
суток одинаковыми. Это не очень реалистично (будут выключаться окна в домах безо всякой
видимой причины), зато легко воплощается. Просто настроим весь свет для вечера и
скопируем его в другие времена суток.

Рис. 2.38. Настройки света


вечером.

Слегка сгладим цвет теней, добавив в него серого. К цвету диффузного и рассеянного
освещения добавим немного оранжевого для более реалистичного освещения. Наконец,
таким же оранжевым выставим цвет линии горизонта (пока смотрится диковато, но это
ненадолго) и цвет тумана. Приблизим ближнюю и дальнюю плоскости тумана так, чтобы он
слегка проявился на локации. Ну и напоследок выставим более темный, чем стоит по
умолчанию, цвет глубокой воды. Вечером вода почти непрозрачна, это создаст хороший
эффект присутствия. Теперь экспортируем все это в файл (Save panel settings) и загрузим
для всех других времен суток.
Самое время заняться локальным освещением. Расставим несколько omni-источников
на локации. Необязательно делать их в реалистичных местах (хотя и логично, что маяк
освещает окрестности вокруг себя). Наша задача в том, чтобы заставить локацию выглядеть
интересно и подсветить те места и объекты, которые в силу их расположения оказались в
тени своей лицевой стороной, например наш волшебный пень и домик NPC. На основном
острове будем пользоваться преимущественно бледно-желтыми тонами, а на близлежащем
островке – красными и синими, там у нас живет чудовище, а потому освещение может быть
более причудливым.

Рис 2.39. omni-источники на островке.

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

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


2.6. Логические карты ландшафта.

Каждый рельефный тайл ландшафта, помимо наложенной на него текстуры и высоты,


имеет еще и ряд логический свойств. С настройкой таких свойств мы уже сталкивались
однажды, когда настраивали зоны освещения. Есть еще четыре логические карты
ландшафта, с которыми придется работать. Такие карты доступны через инструмент
Landscape Logic во вкладке Landscape. Это карты проходимости, типа поверхности, типа
арены и триггеры. Везде можно настраивать размер и тип кисти (не забываем про горячие
клавиши [ и ], которые меняют размер кисти) и при помощи галочки Override mode можно
перекрасить уже покрашенный ландшафт другой кистью (сначала нужно стереть
предыдушую покраску с помощью Shift-Click).

2.6.1. Карта проходимости.

Карта проходимости доступна в режиме passability. В этом режиме мы можем вручную


настроить проходимость каждого рельефного тайла. Проходимости всего два вида: для
героя и для корабля. Внизу есть две кнопки, которые определяют, какую именно из видов
проходимости мы сейчас настраиваем. Рассмотрим сначала воду. Закрашивая тайлы в этом
режиме, мы делаем тайлы автоматически непроходимыми для героя и проходимыми для
корабля. Это долгая и нудная работа, но есть функция, которая призвана ее упростить.
Выбрав фиксированный уровень глубины воды (Depth), мы можем нажатием кнопки Apply
сделать все тайлы, расположенные ниже этого уровня, водными, а «спорные» уже потом
настроить вручную.
В режиме Land покраска тайла сделает его непроходимым. Проходимость в игре
определяется не только логикой ландшафта, но и объектами – теми самыми колшейпами*, о
которых упоминалось выше. Покраской тайлов мы делаем дополнительно непроходимым
ландшафт: это нужно для склонов, сделанных с помощью складок ландшафта, а не
объектов. Однако нужно учитывать, для чего именно та или иная зона будет проходима,
ведь разные персонажи (герои, армии) могут иметь разные размеры. Так, спешившаяся
Амели может пролезть в куда более узкие проходы, чем Амели на коне, а у корабля еще
больший размер. Для того, чтобы увидеть реальную проходимость для конкретного вида
движущегося атома, нужно сделать две вещи: выбрать этот атом в настройках редактора
(General/Settings/Misc/Moving Atom) и включить отображение логических радиусов объектов
сочетанием клавиш Ctrl-H (не дублируется в настройках, так что это сочетание необходимо
запомнить). Появятся несколько групп вспомогательных объектов. Желтые квадраты на
поверхности – область условной проходимости, в ней герою будет сложно пролезть. Для
того, чтобы проблем с проходимостью не было, желтые квадраты не должны смыкаться в
области, которую необходимо сделать проходимой. Зеленая окантовка – физические
колшейпы объектов, они тоже создают вокруг себя области полной и условной
непроходимости на ландшафте. Желтая окантовка – логические колшейпы (о них шла речь в
настройках объектов на карте). Также следует избегать «ребристых» краев области
непроходимости – в то время как обход объектов дается герою легко, ведь их колшейпы
имеют более-менее гладкую форму, обилие острых углов в проходимости ландшафта будет
связано с застреванием героя и усложнением поиска пути. Если действительно необходимо
сделать область непроходимости с такой границей, для улучшения проходимости ее лучше
заставить гладкими колшейпами объектов или сделать проходы широкими.
*Collision shape - контур физического или логического взаимодействия с объектом. Может
задаваться числом (радиус окружности) или примитивным контуром (shape), загружаемым
из файла.
2.6.2. Типы ландшафта, арены и освещения.

Мы уже столкнулись с Light Zones выше, в настройках освещения локации. Другие типы
логических карт очень похожи в работе: необходимо создать или выбрать тип «заливки» и
покрасить им поверхность. Рассмотрим их по порядку:

Triggers – позволяет создать зоны, в которых можно отслеживать через логику игры
наличие или отсутствие героя или других объектов. Необходимо создать уникальный
идентификатор зоны, далее можно использовать его в логике на локации и красить им
ландшафт.
Surface Type – задание типа поверхности. От того, что мы зададим, зависит тип частиц,
которые возникают при движении по поверхности (на песке лошадь поднимает в воздух
пыль, в воде – брызги и т.п.) и звук копыт.
Arena Type – тип арены для конкретного участка поверхности. Доступны абсолютно все,
но, из соображений дизайна, лучше использовать только те, что созданы на том же типе
ландшафта. Игрок должен хорошо понимать, почему меняется тип арены, например, он
сбежал с побережья в лес, где морские создания не получают бонусов, так что тип арены
логичнее всего привязывать к текстуре. Если тип арены на участке ландшафта не задан,
будет использована арена по умолчанию для локации. Последняя задается в
Location/Properties/Map. Желательно всегда задавать такую арену для локации, во
избежание ошибок в случае, если где-то окажется непомеченный участок.

Практическая часть.

Здесь нам нужно настроить только три вещи из пяти – карту проходимостей, карту арен и
карту типов поверхности. Не забудем сначала поставить в General/Settings правильный
Moving atom, а именно героя. Тогда по нажатии Ctrl-H у нас высветятся правильные области
проходимости. Закрасим все море (у нас не планируется корабля, так что настраивать
водную проходимость не надо), скалы, возвышенности и непроходимый с нашей точки
зрения лес. Получиться должно что-то вроде того, что приведено на рис. 2.40. Большая
часть задачи за нас уже решена колшейпами объектов, но, тем не менее, нужно проделать
некоторое количество работы.
Рис 2.40. Карта проходимости локации.
Не сразу получится сделать без ошибок, это, к сожалению, возможно только после
нескольких запусков игры и проверки проходимости уже в ней. Аналогично настроим карту
типов поверхности – будем использовать типы Grass, Sand и Ground для соответствующих
текстур. Наконец, поставим на маленьком острове арену темного леса –
Uncategorized/adarion_1_forest_5. Свою рисовать долго и накладно, но можно и постараться,
если есть такое желание. Красивые арены, предназначенные для конкретного места,
придают локации дополнительную уникальность.
СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >
2.7. Общие свойства локации.

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

Рис. 2.41. Настройки локации.

System:
No shadow – классы объектов, которые на локации не будут отбрасывать тень.
Выбирается один или несколько классов атомов. Это нужно для пещер, где отсутствует
глобальное освещение, в таких локациях отбрасываемые объектами или ландшафтом тени
выглядят, как минимум, странно.
Music playlist – список музыкальных тем для локации. Плейлист выбирается из списка,
который прописан в файле playlists.txt. Этот файл можно вручную отредактировать и
включить в сессию. В каждом плейлисте есть несколько музыкальных тем, которые могут
играть на локации с разной вероятностью (число перед названием темы – статистический
вес темы, если у нее вес равен 1, а у двух других тем - по 50, она будет играть в 1 из 101
случае).
Sky mesh properties – настройки неба локации. В пустом изначально списке справа
можно создавать ключевые временные точки неба – небо будет иметь заданный вид
начиная с числа, заданного в точке, и до следующей точки, если таковая есть. Заданные
точки 0, 12, 18 будут означать, что небо будет иметь один вид с 0 до 12 часов дня, другой – с
12 до 18, третий – с 18 до 24. Единственная заданная точка означает, что небо над локацией
неизменно, это актуально для некромантских или демонических локаций, где не меняется
время суток, или для пещер. Для каждой точки необходимо выбрать текстуру неба – Mesh
file.
Sky scale – настройка высоты неба и тумана над горизонтом. Zero height позволяет
выставить высоту самой текстуры неба над горизонтом, Fog level – уровень тумана над
горизонтом, а Fog height – высоту цветового градиента тумана.
Location Bias – настройка использования разной детализации текстур для объектов на
локации. Видеокарта автоматически для удаленных от камеры объектов использует
текстуры меньшего разрешения. Этими настройками можно отрегулировать уровень
снижения детализации текстур при удалении. Это сделает детализацию объектов более
размытой, но при этом разгрузит графический процессор. При увеличении порога
детализации – наоборот, повышается четкость узоров и видеокарта сильно нагружается.
Учтите, что при высокой детализации текстур картинка начинает рябить, а объекты в
движении неприятно «переливаются», поэтому применять эти настройки следует с умом.

Common Logic:
Здесь есть единственная настройка – уровень сложности локации. Уровень сложности
определяет генерацию золота/свитков, лежащих на локации. Самая сложная локация в игре
будет иметь уровень сложности 100, самая легкая – 1. Соответственно, количество золота в
отдельно взятом сундуке на локации будет зависеть от этого числа, согласно настройкам
конфигурационного файла. Рекомендуется задавать значения от 5 с шагом 10 – 5, 15, 25…

Map:
Special Hero Atom – определяет, будет ли на локации использоваться модель
«спешившейся» Амели. Также запрещает полет. Рекомендуется включать в пещерах и
зданиях.
Force Flymode – по прибытии на локацию герой будет сразу в режиме полета, и не
сможет из него выйти. Реально в игре используется только в диалоге с черепахой Теаной,
так как в режиме полета больше нечего делать.
Default Arena – арена по умолчанию на локации. В разных зонах локации могут быть
настроены разные арены, настройка же здесь определит тип используемой арены для
областей локации, которые не принадлежат никакой зоне. Настоятельно рекомендуется
задавать здесь какую-нибудь универсальную для локации арену.
Enable Custom Game Camera – включает особенную камеру для игры. Подробности
параметров камеры можно посмотреть, изменяя либо их, либо содержимое файла
camera.txt. Особая настройка камеры необходима в ряде пещер, где коридоры узкие и не
хочется, чтобы на экране у игрока большую часть площади занимал черный цвет.

Практическая часть.

Здесь нам необходимо настроить не так много параметров: небо, сложность локации и
тип арены. Начнем с неба. На закладке System в поле Time key point генерируем новую точку
правым кликом. После этого редактируем ее и выбираем небо skyarena_day. Теперь нужно
выставить еще три важных настройки: поставим Zero height значение 3.5 для того, чтобы
увидеть самые красивые облака над поверхностью, Fog level – минус 4, а Fog height – 2. И
вот, небо стало оранжево-закатным. Теперь можно еще немного поиграть с цветом тумана и
линии горизонта в настройках света, чтобы получить наилучший эффект. На этой же вкладке
необходимо выставить плейлист для локации – пусть это будет debir.
Рис 2.42. Небо над локацией.

Теперь нужно установить уровень сложности локации на вкладке Common Logic. Пусть
будет на уровне Алого Ветра – 15. Осталось лишь залезть в третью вкладку – Map – и
выставить там арену по умолчанию. Хотя арены, точно соответствующей нашей локации, не
существует, выберем наиболее подходящую – aisland_2_coast_1.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


3. Логика локации.
В предыдущей главе мы научились создавать красивый, но статичный и безжизненный
мир. Теперь пришло время населить его персонажами и монстрами, расставить сундуки и
алтари, написать квесты и диалоги. В этой главе пойдет речь о той части логики, которая
специфична для конкретной локации. Есть и другая часть логики – которая принадлежит
сессии целиком, ее мы тоже немного затронем уже на этом этапе. Локации принадлежит то,
что непосредственно на ней находится. Например, мы ставим на локацию какой-нибудь дом.
Его логика будет настроена как часть локации, и храниться он будет в локации. Однако
чтобы посадить в него персонажа, нам придется обратиться уже к общей логике сессии
(подробнее об этом смотри 4). Персонаж живет в сессии со своими квестами и диалогами,
мы можем с легкостью выселить его из дома на одной локации и посадить в дом на другой,
причем непосредственно во время игры: например, по выполнении задания. Более того,
столь резкое разграничение связано и с сохранением данных: модифицируя дом, мы будем
сохранять только локацию, модифицируя персонажа – только сессию. Логические данные,
специфичные для сессии, называются session internals, и для их модификации не работает
Undo, так что будьте осторожны.

Практическая часть.

Определимся, какая у нас будет логика на Острове Заходящего Солнца. Мы уже


говорили, что у нас будет NPC, сидящий в домике, с редким магазином, который он откроет
только по выполнении квеста. Будет чудовище, которое будет сидеть на маленьком острове
и ждать, пока его не убьют. Будет плот, на котором можно переплыть на островок и обратно.
Несколько разбросанных алтарей и сундуков, маяк без диалога, но с магазином, ну и
наконец, две армии, патрулирующие остров. Разумеется, без портала, возвращающего нас
на Дебир, тоже не обойтись.
Теперь разберемся, что же из этого – логика локации, а что – логика сессии. Во-первых,
в зданиях будут жить актеры (вы, наверное, замечали, что при торговле с каким-то домом
нам все равно отображается некое «лицо» актера, которого зовут «Дом»), то есть два актера
– маяк и NPC (назовем его Джо Грибник). Плюс еще есть чудовище, герой, возглавляющий
вражеский отряд. Для героя противника нам тоже нужен будет актер, итого три актера. Джо
Грибнику нужен будет диалог – это тоже логика сессии, ну и квест на убийство монстра.
Например, Джо на маленьком острове любил собирать грибы для своего грибного супа, но
теперь там поселилось чудовище, которое мало того что не дает Джо собирать грибы, так
еще и жрет их само. Все остальное – логика локации.
Итого нужно сделать:
– логика маяка. При клике на него вызывается магазин. Магазин тоже нужно настроить;
– логика домика Джо. При клике на него вызывается диалог с Джо, в котором потом
можно будет вызвать магазин (его тоже нужно настроить);
– несколько разнообразных бонусов, лежащих на карте. Клад под большим пнем;
– плот для переправы на островок. Пусть работает только после того, как Джо даст квест,
чтобы не убить нужную зверюшку до получения квеста на нее;
– армия героя противника – чудовище;
– две армии, патрулирующие путь до маяка и лесную тропинку;
– двусторонний портал до Дебира.

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

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >

3.1. Атомы.

Мир состоит из атомов. Точно так же трехмерный мир King’s Bounty состоит из атомов.
Атомы – это кирпичики, элементарные частицы конструктора, из которого слеплена игра. По
сути своей атом – это некоторый объект, который обладает следующими свойствами:
1) он рендерится (визуализируется) движком игры, как целое.
2) он обладает физическими параметрами: размером, трехмерной моделью, звуком или
спецэффектом.
3) в нем может храниться логический объект.
Существует несколько разных классов атомов, и, как мы уже говорили, прототип атома
определяется его атом-файлом. От класса атома и ряда параметров его атом-файла
зависит то, какие возможности для него будут доступны в редакторе и в игре. Для начала
рассмотрим те классы атомов, которые есть в игре.

3.1.1. Классы атомов.

Их достаточно много, и они определяют прежде всего доступность для атома той или
иной настройки, а также то, какая логика будет настроена в атоме по умолчанию при
помещении его на карту. Список классов:

static – статичные атомы. Обладают только моделью и физическим размером.


Единственный вид логики, который может быть им доступен, – всплывающая подсказка.
Пример: трава, камни, деревья.
dynamic – то же самое, что и static, только у этих атомов есть анимация.
Пример: белка, указатель с раскачивающимся фонарем, ветряк.
hollow – атом такого класса не имеет модели, зато может иметь прикрепленный
спецэффект. Используются как на карте, так и в бою.
Пример: луч солнечного света, светлячки, водопад и брызги от него.
bridge – это динамический атом (впрочем, у динамического атома может и не быть
анимации), который обладает только одним исключительным свойством – в области, где он
находится, высота рассчитывается исходя не из заданной высоты рельефа, а напрямую от
его модели.
Пример: любые мосты, деревянный пирс, острова Демониса.
platform – тот же bridge, только обладает логическими настройками и может двигаться
вместе с героем.
Пример: плот, летающие демонические платформы.
Multistate – динамический атом, который обладает состоянием. Есть несколько
состояний, в которых он может пребывать, их можно переключать через скрипт, и от этого
будет зависеть модель и/или анимация объекта. Может обладать своей логикой.
Пример: открывающиеся ворота, поезд, разбивающаяся статуя.
hero – специальный тип движущегося атома (все такие атомы обладают скоростью
ходьбы), которым управляет игрок. Установка этого атома на локации означает то, что
персонаж игрока появляется в этом месте. Необходимо только для самой первой локации,
дальше мы уже приходим на локацию через портал. Также хранит в себе логический объект
с кучей специфичных для героя переменных.
boat – лодка для использования героем. По сути, тоже движущийся атом, только с более
простой логикой.
army – армия противника на карте. Не путать с юнитом на поле боя, это совсем разные
атомы. Для армий доступны специальные эмбрионы. В обязательном порядке имеет
логические шейпы.
box – сокровище на карте или в бою. Тоже обладает особенным типом эмбриона для
бокса. Имеет логические шейпы.
Пример: сундук, кучка золота, магический кристалл, фонтан Маны, алтарь Битвы.
castle – здание. В эту категорию попадают как замки, так и обычные домики с
магазинами. По умолчанию в нем находится эмбрион здания, который можно настраивать.
npc – самый «пространный» и универсальный из атомов с настраиваемой логикой. В
отличие от предыдущих, npc обладает только логическим шейпом, но может не обладать
эмбрионом. Настраивать его необходимо, таким образом, вручную. Он может ходить,
драться, умирать, выполнять функции портала и магазина, в общем, обладает широким
спектром возможностей.
Пример: персонаж на карте, портал.
throwable – специальный тип атома для разнообразных снарядов и спецэффектов,
которые используются в бою. Такие атомы рождаются и умирают автоматически и не могут
постоянно присутствовать в игре. Ставить их в редакторе нельзя, используются они в
анимациях или в скриптах.
Пример: стрела лучника в бою, эффекты заклинаний и ударов.
chesspiece – боевая единица. Не путать с армией, этот тип атомов тоже не стоит
использовать в редакторе: они рождаются в бою сами. Самый настраиваемый из типов
атомов, потому как параметров у юнитов очень много.
pawn – тоже боевая единица, но, в отличие от chesspiece, не имеет никаких заранее
настроенных функций в бою. Pawn не знает, как ходить, стрелять или даже умирать. Вся его
логика и поведение на арене настраиваются вручную через скрипты Lua, и область
применения pawn зависит только от вашего воображения и владения скриптовыми языками.
Универсальный класс, как и npc.
Пример: пчелиный улей, тотем, пороховая бочка, шаровая молния, яйцо хайтерранта,
все боссы и даже Ручной Дракончик!
spirit – особая боевая единица, которая обладает расширенными возможностями в
плане атаки, но не обладает возможностью получать урон или умирать, то есть не
присутствует на арене в явном виде. Это Духи из ЛоР, в Принцессе этот класс атомов не
используется.
embryo – эмбрион как самостоятельная сущность. Подробнее об эмбрионах чуть ниже.
land – очень интересный и редкий класс. Доступных атомов этого класса почти нет в
редакторе, они используются только в особых случаях. По сути своей этот класс – чисто
декоративный, однако, в отличие от static, он может вызывать искривление рельефа
поверхности и использовать текстуру ландшафта как свою.
Пример: яма-Молотилка на Боло, гномьи спусковые лифты.

Данный список стоит воспринимать как ознакомительный. Это прежде всего необходимо,
если вы хотите изменять свойства объектов, например, сделать из обычного камня
говорящий или что-то еще в том же роде. Класс атома static не даст вам приделать к камню
никакую логику, в том числе и диалог, так что придется делать дубликат атома с другими
свойствами, например, классом npc.

3.1.2. Основные параметры атомов.

Итак, в меню выбора атома можно на любом из них кликнуть правой кнопкой мыши.
Всплывет некоторое меню, в котором вы сможете посмотреть/изменить настройки атомов.
Edit thumbnail, Explore thumbnail, Reread thumbnail и Replace thumbnail with отвечают за
иконку атома в списке, Move to позволяет переместить атом в другое место в папках, Clone
создает дубликат атома, Attachments вызывает редактор аттачментов (см. приложение 8.1).
В любой момент можно посмотреть атом в текстовом виде через Edit atom file или Explore
atom file, но для этого ресурсы игры должны быть распакованы. Нас интересует сейчас Atom
properties и соотношение настроек, представленных там, с тем, что есть в атом-файле.
Внутри каждого атома есть блок main. Рассмотрим параметры, которые могут быть в
этом блоке атома (не все, но большинство):

class – класс атома, описан выше;


model – трехмерная модель с текстурой и анимацией. У класса hollow отсутствует.
Формат *.bms (статичный) или *.bma (анимированный);
nodimming – если этот параметр равен единице, то атом не становится прозрачным,
если он попадает в камеру, перегораживая собой значимые объекты;
cullcat – категория «важности» атома при отдалении камеры. Атомы с малым
значением этого параметра видны на больших дистанциях;
instanced – технический параметр для рендеринга;
spawnscale – масштаб атома при его генерации непосредственно в игре (в редакторе за
это отвечает другой параметр);
offline – если 1, атом при начале игры будет невидим и выключен, его нужно будет
включать через логику;
camcol – является ли этот атом препятствием для камеры. Если 0, камера свободно
проходит сквозь него;
blend – стартовая величина прозрачности при генерации атома в игре;
decal – если здесь выбран номер декали, то при установки атома на карту она
автоматически появляется на ландшафте. Так сделаны пни под деревьями;
colmesh – задает колижн-меш – примитивную трехмерную модель, которая
отображает физический объем объекта. По этой модели отслеживается
наведение курсора мыши и перекрывание объектом области видимости
камеры;
ttl – для атомов класса hollow задает время существования. Такие атомы
появляются, спецэффект срабатывает, и они сразу исчезают;
apass – на арене задает проходимость гекса, в котором находится атом;
cursor – вид курсора при наведении на атом;
walk_speed – скорость передвижения атома. Актуально только для движущихся атомов
вроде hero, army или npc;
turn_speed – скорость поворота атома. Аналогично предыдущей;
lutemplate – шаблон логического объекта в атоме. Берется из библиотеки шаблонов.
Такой шаблон является также составной частью эмбриона;
mapicon – иконка на карте. Только для castle или npc.

В атомах есть и другие блоки. Блок arena_params присущ только тем атомам, что
появляются на арене (например, chesspiece или pawn). Блок attachments отвечает за
прикрепленные к атомам графические объекты или звуки (так, например, аттачментом к
атому является иконка квеста или горящие глаза импа), scripts – специфические Lua-скрипты
поведения атома, collision – физические и логические шейпы атома. Рассмотрим еще один
блок, который важен для редактора, – блок editor. Там может быть один или два блока, map
и arena, которые отвечают за поведении атома на обычной локации и арене соответственно.

align – отвечает за привязку атома к тому или иному виду сетки. Если задан grid, то
атом будет привязан к координатной сетке. Настройка по умолчанию
grid/0/0/0.1/0.1 отвечает за смещение (нули) и возможный инкремент
координаты атома (0.1). Такая настройка дает почти полную свободу. Если же
задан chessboard, атом будет жестко привязан к клеткам арены.
angle – задается тремя числами, например, 0:1:360. Первое и последнее числа –
начальный и конечный углы поворота, а среднее – доступный минимальный
относительный поворот. Так, если задать 45:90:315, то атом сможет быть
повернут только в одну из четырех сторон: северо-восток, северо-запад и так
далее.
scale – задается диапазон масштабирования объекта. 0.5:2 означает, что объект
может быть масштабирован от половины размера до двойного размера.
spawnscale – по сути тот же параметр, но влияет на то, какое значение масштаба получит
объект при постановке на карту случайным образом. Так, типична ситуация –
scale=0.1:10; spawnscale=0.9:1.1. В этом случае при установке на карту объект
будет иметь масштаб от 0.9 до 1.1 от эталонного, но уже вручную мы можем
сделать его до десяти раз больше или меньше эталона.
spawnangle – аналогично предыдущему.
spawnalign – аналогично предыдущему.

Эти настройки помогут, если непонятно, как сделать «очень большое дерево» или «очень
маленькую гору». Существует масса других параметров в атомах (их всего несколько сотен),
но перед нами не стоит задача разобраться во всех них.

3.1.3. Взаимодействие атомов, эмбрионов и логических


объектов.

Итак, чуть выше было впервые упомянуто понятие «эмбрион», сейчас попробуем
разобраться, что же это такое. Когда мы имеем конечную, итоговую генерацию игры, на
локациях у нас есть атомы и логические объекты внутри них (есть и объекты, которые не
принадлежат никаким атомам, но это – редкость). Как уже было сказано выше, атом – это
модель и самые базовые свойства объекта в игровом мире, а логический объект – его
поведение. В логическом объекте может быть настроено то, как атом реагирует на клик
мышкой, какие переменные внутри него хранятся, например, армия, предметы, персонаж, а
сама логика определяет то, как эти переменные используются для взаимодействия с
игровым миром. То есть логический объект – это набор некоторых значений переменных и
набор некоторых функций, которые срабатывают при определенных событиях в игровом
мире. Однако тут сразу же очевидны некоторые проблемы:
1) у нас есть дом, который настроен на то, что клик мышкой вызовет форму торговли, где
есть 10 импов и 20 церберов. Ставим соседний дом и настраиваем все то же самое заново.
Это долго и очень трудоемко;
2) мы настраиваем на карте объект, в котором как переменные содержатся 20
архидемонов и 100 злобоглазов. При левом клике вызывается сражение, в котором из этих
переменных берется армия врага. В каждой генерации игры это будет одинаковый объект, а
мы хотим разнообразия. Как быть?
Для решения этих двух проблем есть специальная сущность, которая называется
«эмбрион». Эмбрион существует только в редакторе. Поставив на карту эмбрион, мы можем
настроить то, чем он в игре станет, и при генерации игры эмбрион превратится в атом с
логическим объектом внутри. Существует несколько стандартных видов эмбрионов со
стандартными формами настройки, нам нужно только вбить числа, логика уже задана за
нас, притом эмбрион содержит в себе не только логику будущего логического объекта, но и
логику генерации. Настроив эмбрион армии, в игре мы получим результат – армию, состав
которой может очень сильно варьироваться, зависит от уровня сложности и так далее, в
общем, именно то, что нам нужно. По умолчанию многие классы атомов имеют
прикрепленный тип эмбриона – есть эмбрион замка, эмбрион армии и эмбрион контейнера.
Настраивая логику такого объекта на карте, мы на самом деле настраиваем его эмбрион. В
редакторе объект может иметь либо эмбрион, либо логический объект, и никогда – оба
одновременно. Поскольку эмбрион – прообраз логического объекта, одновременное
существование их в объекте бессмысленно. Настроить эмбрион выбранного объекта мы
можем, нажав клавишу E, логического объекта – L.
Строение эмбриона таково: есть атом, который мы ставим на карту. В простом режиме
этот же атом будет сгенерирован в игре. Есть прототип логического объекта, который
берется из библиотеки и задается параметром lutemplate в атом-файле. Есть механизм
генерации эмбриона из его параметров, который жестко задан, и менять его нельзя. И,
наконец, есть набор этих самых параметров, которые мы и задаем. Ниже будет разобрана
параметризация различных видов эмбрионов, пока что ограничимся пониманием структуры.

Нажатие на вкладку Logic в настройках атома на локации выдаст нам три больших
кнопки. По умолчанию не нажата ни одна, это значит, что будут использованы настройки
эмбриона по умолчанию. Это не такая хорошая идея, потому как большинство эмбрионов по
умолчанию пусты, у них нет ни магазинного ассортимента, ни состава армии, ничего.
Исключение здесь представляют собой контейнеры, настройки которых зависят от
сложности локации, а потому мы будем получать из них золото/бриллианты даже в том
случае, если вообще ничего не настроим. Нажатие кнопки Independently значит, что для
данного объекта мы используем локальную копию эмбриона и можем ее настроить.
Advanced Mode – режим, когда мы в эмбрионе задаем не только параметры, но и сам атом,
таким образом создаются магазины, в разных генерациях имеющие разный внешний вид. В
этом режиме в одном месте на локации находится несколько пар атом-эмбрион и при
генерации будет использована одна из них. Третий режим, Custom Logic, означает, что,
вдобавок к настройке эмбриона (который генерирует параметры логического объекта) мы
используем еще и самостоятельный локальный логический объект, правила поведения
которого в игровом мире и реакция на действия игрока будут отличаться от того, что для
данного атома используется в качестве шаблона. Здесь много непонятных слов, но на деле
эмбрионы достаточно просты в настройке.
Учтите, что нажатие L на атоме с эмбрионом все-таки вызовет логический объект для
настройки, но это будет не локальный логический объект, который хранится в атоме
(помним, что при наличии эмбриона логический объект возникает только в момент
генерации), а шаблон логического объекта, который использует эмбрион. Редактировать его
крайне не рекомендуется, потому что это повлияет на все эмбрионы в игре, где используется
этот же шаблон. Если мы изменим шаблон магазина, сломаются абсолютно все магазины на
всех локациях, так что лучше залезать в шаблоны только с целью ознакомления, но никак не
редактирования. Есть у эмбрионов еще одно важное свойство – уникальность. Если
несколько объектов используют один эмбрион (не одинаковый, а именно один и тот же),
сгенерируется только один из них. У каждого эмбриона есть номер, можно посмотреть его в
статусной панели, наведя на содержащий его атом курсор. Если у двух атомов одинаковый
номер эмбриона, случайным образом сгенерируется лишь один из них. Так сделаны
навигационные карты – на локации карта может лежать в нескольких разных местах, но
всегда в единственном экземпляре. Этот механизм в редакторе называется вариациями
(Variations).
Есть и еще один механизм, исключительно для удобства. Мы можем создавать в палитре
мета-атом (по правому клику выбрать пункт Meta atom) и добавлять в него обычные. Это
функция, которая существует только в редакторе. При установке на карту такого атома будет
выбран случайный реальный атом, содержащийся в нем. Например, так можно сделать
«кисть», которая рисует случайные деревья из списка. Здесь выбор производится именно на
стадии установки объекта на карту в редакторе, нельзя путать этот механизм с эмбрионами,
генерация содержимого которых происходит в начале игры.

3.2. Логические объекты (Logic Units).

Как мы уже выяснили выше, логический объект представляет собой совокупность


некоторых переменных, которые хранятся внутри атома, и правил взаимодействия объекта с
миром. Существует несколько типов логических объектов, деление на которые
осуществляется исходя из механизма их возникновения. Во-первых, есть шаблоны
логических объектов или виртуальные логические объекты (далее ЛО), которые хранятся в
библиотеке шаблонов. Непосредственно в игре они нигде не используются напрямую, но
атом, обладающий эмбрионом, может использовать такой ЛО как прототип логики (шаблоны
ЛО могут существовать не только в библиотеке, но и в сессии, тогда шаблон из сессии будет
использоваться вместо того, что есть в библиотеке, например, – шаблон героя). Далее, есть
глобальные логические объекты. Они не привязаны ни к какому реальному атому вообще,
а существуют внутри сессии как отдельные сущности. В них хранятся глобальные
переменные сессии. Есть ЛО, которые локальны для локации. Вся сессия целиком их не
«видит», они видимы только на локации, на которой существуют. У них может быть или не
быть местоположение на локации (если им дать местоположение, то они могут выступать
генераторами, создавая в своих координатах реальные атомы). Их можно назвать
свободными локальными ЛО. Далее, есть ЛО, которые создаются автоматически при
установке объекта с логикой на карту, их можно назвать прикрепленными ЛО. В списке такие
ЛО отмечены синим цветом. Они уже обладают привязкой к своему объекту и удаляются
автоматически при удалении содержащего их объекта.
Наконец, есть прототипы ЛО, которые живут в эмбрионах. Они жестко привязаны к
конкретному эмбриону на карте, удаляются вместе с ним и не фигурируют в списке. По
умолчанию эмбрион использует некий шаблон ЛО из библиотеки, который жестко привязан к
типу эмбриона, но, если выбрать в настройках эмбриона Custom Logic, то этот эмбрион уже
будет использовать независимый ЛО, который мы настроим ему сами, он будет храниться в
нем. Такие ЛО можно редактировать только через настройки эмбрионов, в которых они
лежат, в списке они не отображаются.
Логические объекты содержатся во всех интерактивных объектах, которые находятся на
карте. Это здания, триггеры, NPC, сундуки и прочие интерактивные объекты, с которыми
можно взаимодействовать и которые способны хранить в себе логические данные. Важно
понимать, что правила взаимодействия, которые описываются логикой ЛО, – это не столько
механизм взаимодействия с героем, сколько именно с игровым миром. В игре это не
используется, но вообще монстры (армии) на карте могли бы с таким же успехом бегать и
собирать сундуки, кататься на движущихся платформах, заходить в телепорты, закупаться в
магазинах и делать многие другие вещи. Игрок является центром игры идеологически, но
реальных механизмов, редуцирующих логику до взаимодействия именно с ним, очень и
очень мало.

3.2.1. Свойства логического объекта.

Логические объекты можно найти на вкладке Logic Units (Shift-U) на панели


инструментов. Доступны для редактирования логические объекты текущей сессии (точнее,
текущей локации и глобальные), это Source:Session и библиотека шаблонов Source:Library.
Смысл в том, что у разных логических объектов может быть разная область существования:
глобальные объекты видны везде и отовсюду, локальные, как правило, только при
непосредственном редактировании локации, в которой они находятся. При этом локальные,
как мы выяснили, делятся еще на прикрепленные к игровым объектам и свободные. Таким
образом, в Session есть минимум две папки: логические объекты текущей локации и
глобальные логические объекты. Мы же сейчас обратимся к шаблонам логических объектов,
которые хранятся в Library. Рассмотрим свойства логического объекта map (это шаблон
навигационной карты), кликнув на него мышкой дважды.
Рис. 3.1.
Настройка ЛО.

На вкладке Properties задается имя логического объекта, указывается, является ли он


шаблоном, уточняется его область видимости и местоположение. Для шаблонов,
библиотечных ЛО или созданных по умолчанию при установке на карту атома
соответствующего класса, область видимости определяется автоматически. Для тех же,
которые мы создаем в сессии вручную, она может быть либо сессией, либо конкретной
локацией. Вкладка Traps ответственна за правила взаимодействия объекта с игровым
миром, это в своем роде скрипты, и они заслуживают отдельного рассмотрения далее.
Вкладка Castle содержит в себе актеров (те, что сидят в замке) и задник картинки. На
вкладке NPC то же самое можно настроить для NPC внутри ЛО. Вкладка portal ответственна
за точку выхода из портала, тут можно остановиться несколько подробнее. Для того, чтобы
ЛО стал точкой выхода из портала, ему нужно присвоить portal tag – уникальный
идентификатор портала для использования в скриптах. Три слайдера чуть ниже
ответственны за изначальное положение камеры при выходе из портала. Вообще для точек
выхода рекомендуется использовать специальные атомы – trigger_zone, потому что
ориентация модели героя при выходе из портала зависит и от ориентации атома в том
числе. Все порталы в игре односторонние, двусторонний делается через две пары вход-
выход.
Следующей вкладкой идет Shop. Здесь настраиваются доступные для покупки юниты,
предметы и свитки. Потом идет Skills (на самом деле это актуально только для героя, но
универсальность настройки ЛО требует того, чтобы у каждого был весь диапазон
необходимых настроек) и, наконец, Variables. Есть три типа переменных: user, game и
scripted. Первая – пользовательские переменные, их можно менять, и они имеют свой смысл
в зависимости от названия, обычно создаются самим редактором при изменении настроек,
но именно здесь их можно создать и самому. Например, align или path есть у всех ЛО армий,
эти переменные отвечают за враждебность и путь патрулирования соответственно. Вторая
группа – переменные игры, они автоматически создаются внутри ЛО, когда мы редактируем
какие-то настройки, начинаются с точки и недоступны для прямого редактирования.
Например, если мы залезем во вкладку Portal, появится переменная .portal, хранящая
данные о портале. Третья группа – скриптовые переменные. Это тоже пользовательские
переменные, только они хранят в себе не значение, а скрипт, который вычисляется в тот
момент, когда используется переменная.
3.2.2. Игровая логика. Сообщения и ловушки.

Сначала мы сделаем обзор доступных возможностей, а потом для закрепления


рассмотрим пару примеров. Для того, чтобы посмотреть, как все устроено, лучше всего
вручную создать в списке новый ЛО и открыть в нем вкладку Traps. Что это такое? Trap – это
ловушка для сообщения. Игра постоянно генерирует сообщения и события, которые
способен отлавливать ЛО. Для чего это нужно? Получив такое сообщение, ЛО может
обработать его и отреагировать. То есть проверить набор каких-то условий и выполнить ряд
действий. Обработка условий и выполнение действий осуществляется с помощью
Action/Condition editor, внутреннего логического «конструктора» игры. В то время как ловушки
специфичны только для ЛО и предметов, Action и Condition editor используется во многих
местах в игре, от диалогов и квестов до логики предметов. Попробуем создать какую-то
ловушку в ЛО. Правый клик на поле вызывает небольшое меню. Add msg trap позволяет
добавить ловушку в чистом виде – то есть вы создаете ловушку и задаете событие, на
которое она сработает. Add trap ref создает ссылку на ловушку в другом ЛО. Import from и
Replace all from создают копии ловушек, настроенных в другом ЛО, вторая – с удалением
имеющихся. Наконец, Save preset сохраняет текущие настройки в .strg-файл, Load preset –
загружает их из файла, а Append preset – добавляет загруженные из файла к текущим.
Нажимаем Add msg trap.
Перед нами появляется меню, в верхней части которого можно добавить комментарий к
ловушке и выбрать отлавливаемое ловушкой событие. Выберем, например, Capture Click.
Теперь ловушка «взведена» и отреагирует на клик левой кнопкой мышки по текущему
игровому объекту. Forwarder нужен для предварительной загрузки логики, когда мы
динамически на карте создаем прототип ЛО. Поле чуть ниже определяет дополнительные
условия, проверяемые при срабатывания ловушки, пока что оставим его пустым. Еще ниже
есть возможность задать задержку в миллисекундах между срабатыванием ловушки и
выполнением действий, а галочка в самом низу запрещает срабатывание других ловушек,
пока не выполнятся условия текущей.
Нажимаем OK, ловушка появляется в списке. Теперь нужно кликнуть на нее правой
кнопкой и нажать Add Action, чтобы добавить новое действие, которое запустит сработавшая
ловушка. Появится список доступных действий. Выбираем, скажем, Begin Dialog. Там по
умолчанию стоит by current active actor, то есть диалог начнется с тем актером, который
сейчас активен, – как правило это тот, что сидит в ЛО. Все, ловушка с действием готова,
теперь клик левой кнопкой мыши запустит диалог с актером.
Проверим, правильно ли мы все сделали, и откроем какой-нибудь ЛО с уже настроенной
логикой. Выбираем Source:Library, там папку npc и ЛО NPC_example. Выясняется, что
неправильно. Правильная ловушка в данном случае состоит из двух. Рассмотрим те, что
есть, подробно.

В качестве первой ловушки выбран все тот же CLICK_CAPTURE (левый клик мыши),
однако, действие там совсем другое – Send for Hero. Действительно, когда мы нажимаем на
персонажа или здание, не вызывается никаких форм, герой просто бежит к зданию.
Взаимодействие определяется уже второй ловушкой INTERACTION_PASSIVE_ON, которая
определяет то, что в некоторую область вокруг ЛО попал другой ЛО. На ловушку наложено
дополнительное условие – логическое, из двух составляющих его условий. Первое – Send
for hero in progress, то есть герой в данный момент бежит к зданию. Второе – логическое
ИЛИ от двух вариантов – либо герой, либо лодка находятся внутри логического шейпа атома
(мы о них неоднократно упоминали выше), это и есть область действия ловушки. Таким
образом, действие будет выполнено тогда и только тогда, когда герой, посланный левым
кликом мыши к зданию, достигнет зоны логического шейпа. Именно так и ведут себя
объекты в игре. Важно понять, какой именно уровень логики мы настраиваем – очень и
очень низкий. Идет обработка кликов мыши и физических координат героя в мире, на одних
этих параметрах можно сконструировать очень разную и интересную логику. Разработчики
порой шутят, что при должном старании из игры можно сделать шутер.
В качестве действия есть два варианта: если некоторая переменная trader текущего ЛО
равна 0 или 2, вызывается диалог от имени текущего актера. Если же значение этой
переменной равно 1, то вызывается форма торговли. Данный пример должен показать, как
именно устроена логика в игре, дальше уже необходимо рассматривать один за одним
разные логические объекты, чтобы понять принципы их работы, но все они сделаны именно
из этих простых кирпичиков – ловушки и Condition/Action. Рассмотрим типы ловушек,
которые нам доступны. Также учтем тот факт, что почти для каждого типа ловушки в
Condition editor есть дополнительный тип условия – Trap specific. Обычно без него ловушка
работать не будет. Вообще для ловушки есть два типа условия – ORC (On receive condition),
то есть условие при получении сообщения, и PDC (Post delay condition) – условие для тех
скриптов, которые выполняются с задержкой. Если его выставить, то сначала ловушка
пройдет проверку на ORC, запустит таймер, по истечении его проверит PDC и только в
случае прохождения обеих проверок запустит какие-то действия.

Start game (START_GAME) – объект получает при старте игры. Дополнительного


условия нет.
Arena end: hero wins (ARENA_WIN) – объект получает, когда герой выиграл сражение на
арене. Сражение должно быть инициировано именно этим объектом. Дополнительного
условия нет.
Arena end: hero loose (ARENA_LOOSE) – объект получает, когда герой проиграл
сражение на арене, аналогично предыдущему. Безусловная ловушка.
Arena end: cancel (ARENA_CANCEL) – герой вышел из сражения в режиме отладки. Не
используется.
Client spawned (SPAWNED) – объект получает, когда он родился в игре. Некий вольный
эквивалент START_GAME для тех атомов, которые возникают на карте динамически во
время игры, по каким-то событиям, а при генерации игры их еще не существует. Безусловно.
Logic unit activated (ACTIVATED) – объект получает в момент своей активации в
текущем запуске игры. То есть когда загружается локация с объектом. Безусловно.
On dead (ONDEAD) – ЛО уничтожен (не спрятан, а именно уничтожен). Безусловно.
Information click (CLICK_INFO) – объект отлавливает клик правой кнопкой мыши по
нему. Безусловно.
Capture click (CLICK_CAPTURE) – объект отлавливает клик левой кнопкой мыши по
нему. Безусловно.
Active interaction on (INTERACTION_ACTIVE_ON) – ЛО попал в зону действия другого
атома. Необходимо указать, какого именно, и тип логического шейпа. Галочка Path must be
present отвечает за то, можно ли проложить путь от одного ЛО до другого (то есть, в случае,
когда герой попал в радиус видимости монстра, но тот стоит на другом берегу реки и встреча
невозможна, эта галочка поможет отключить взаимодействие).
Active interaction off (INTERACTION_ACTIVE_OFF) – ЛО вышел из зоны действия
другого атома. Необходимо указать, какие именно атомы или объекты отслеживаются, и тип
логического шейпа, на который нужно реагировать.
Passive interaction on (INTERACTION_PASSIVE_ON) – другой атом попал в зону
действия текущего. Необходимо указать, какие именно атомы или объекты отслеживаются, и
тип логического шейпа, на который нужно реагировать.
Passive interaction off (INTERACTION_PASSIVE_OFF) – другой атом вышел из зоны
действия текущего. Необходимо указать, какие именно атомы или объекты отслеживаются, и
тип логического шейпа, на который нужно реагировать.
In chase radius (IN_CHASE) – отслеживает положение героя. Объект получает его, когда
герой внутри радиуса преследования ЛО. Безусловно.
Out of chase radius (OUT_CHASE) – отслеживает положение героя. Объект получает
его, когда герой вне радиуса преследования ЛО. Безусловно.
End client scenario (SCENARIO_END) – объект завершил выполнение сценария.
Условием является тип сценария.
New day part (NEW_DAY) – объект получает при смене времени суток. На какое именно
время суток нужно реагировать – указываем в условии из четырех вариантов.
On timer event (TIMER) – объект отлавливает срабатывание таймера. В условии
указываем, какой именно таймер отслеживать. Объект отслеживает только те таймеры,
которые перед этим были запущены внутри него самого.
Custom event (CUSTOM_EVENT) – Объект отлавливает направленный непосредственно
к нему приказ. Фактически он получает только номер приказа, но в редакторе для удобства
они имеют различные смысловые названия. Условием является тип приказа, список типов
особых событий (это имена приказов или их номера) ниже.
Logic event (LOGIC_EVENT) – Объект может отлавливать ряд игровых логических
событий. Условием является тип отслеживаемого события, список типов логических событий
ниже.
Quest node changed (QCHANGE) – Объект отслеживает состояние узлов квеста. Квест,
узел квеста и тип отслеживаемого состояния выбираем как дополнительное условие.
Box taken (arena event) (TAKEN) – Объект класса box получает это сообщение, когда его
подбирают. Работает только на арене, безусловно.
Teleportation complete (ON_TELEPORT) – Объект получает, когда кто-нибудь (герой,
монстр, NPC) воспользовался им как точкой выхода из портала. Срабатывает по
завершению процесса переноса. Безусловно.
Unload boat (UNBOAT) – Текущий объект получает это сообщение, когда герой или актер
вылез из лодки. Безусловно.
<any> (hz) – срабатывает просто при выполнении некоего Condition-условия.
Естественно, нет своего условия, но без любого дополнительного работать не будет.

Совет: для понимания вышеизложенного материала изучите работу как можно большего
количества уже настроенных ЛО – их достаточно много, и многие из ловушек так или иначе
реализованы в них.
3.2.3. Игровая логика. Condition editor.

Здесь мы рассмотрим редактор условий для выполнения логики в игре. В отличие от


ловушек, условия используются не только в ЛО, но и вообще во всех местах, где есть логика
– в диалогах, квестах и т.п. Любое условие возвращает логическое true или false, мы можем
настраивать и сложные условия с дополнительными логическими операциями, и логические
комбинации из нескольких условий. Создадим еще одну ловушку. В поле ORC правым
кликом создадим новое условие, и появится список доступных условий. Рассмотрим каждое
по отдельности:

Рис. 3.2.
Редактор условий.

Use – группа условных операций.


Complex – логическая суперпозиция от нескольких условий. Доступны шесть различных
логических операций, все поддерживают произвольное число аргументов. Подобного
эффекта можно добиться, просто кликнув на условие в списке и выбрав Complicate.
Expression – проверка истинности некоторого выражения. Все операнды лучше
использовать как переменные, давая им буквенные имена и заключая в квадратные скобки,
тогда в поле ниже можно выбирать, откуда их брать. Например, выражение [a]==[b]. Где a –
это некоторый параметр героя, а b – константа. Expression – это универсальный и очень
мощный инструмент для работы с математическими и логическими операторами, который
может манипулировать огромным количеством игровых переменных. Подробнее о его
возможностях рассказано ниже в параграфе 3.2.6.
Quest – группа условий на квесты.
Is quest online – находится ли указанный квест в каком-то состоянии. Выбираем квест из
списка. Выбираем проверку состояния из нескольких возможных вариантов.
Quest chip place – проверка состояния логического узла квеста. Выбираем квест, его
узел и проверяемое состояние.
Special – группа специальных условий.
Check item – проверка наличия предмета у ЛО. На выбор есть сам ЛО, для которого
настраивается логика, источник сообщения для ловушки или герой. Можно смотреть
наличие предмета как в рюкзаке, так и на теле, тело есть только у героя.
Army death – проверка, умерла ли армия у актера или эмбриона.
Logic interaction – проверка на логическое взаимодействие текущего ЛО с неким
объектом. Выбираем логический шейп и тип объекта.
Other – прочие условия.
Random – генерирует случайное число, а потом условие проверяет, попало ли
сгенерированное число в заданный нами интервал от 0 до N<=1. То есть мы задаем
вероятность срабатывания условия.
Script – проверяет значение, возвращаемое Lua-скриптом. Для того чтобы Lua-скрипт
можно было использовать в этом условии, необходимо, чтобы он имел рядом с именем
функции следующий комментарий: “--ftag:if”
Trap – группа специальных условий для текущей ловушки.
trap – специфичное условие для данного типа ловушки. Для каждого типа ловушки свое,
у целого ряда ловушек такового нет.
hidden – скрытые условия, их можно показать, выставив галочку Show rare conditions.
* key pressed – зажата клавиша Ctrl, Shift или Alt.
* is custom event canceled – некое пользовательское событие было отменено.
Выбираем тип события.
* skill – проверка наличия конкретного уровня навыка у героя. Выбираем навык.
* variable – сравнение двух переменных или константы с переменной. Синтаксис
var=@this?blabla означает, что берется переменная blabla из логического объекта this.
Ключевое слово self определяет сам ЛО, однако можно использовать просто blabla,
результат будет тот же. Можно проверять значения счетчиков с синтаксисом itm=@this?
itmname.itmvalue. Например, itm=@hero?rage.count – из героя hero берется счетчик ярости
rage и его текущее значение count. itm=@hero?rage.limit, соответственно, будет означать
максимальное количество ярости у героя, и так далее.
* platform – проверяет состояние платформ (движущиеся платформы а-ля Демонис).
test logic bits – проверка некоторых логических флагов игры. В частности, здесь
проверяется send for hero in progress, наличие жены у героя и ряд других состояний.

3.2.4. Игровая логика. Action editor.

Редактор действий практически абсолютно аналогичен редактору условий. В каком-то


смысле тут доступны не только действия, но и условия, поэтому это – более общий редактор
логики. Он обладает той же самой универсальностью, что и Condition editor. Доступные
действия:
Рис. 3.3.
Редактор действий.

Use – группа условных операций.


Multiaction – создает на выполнение действия из группы действий некоторое условие. В
правой части появится поле условий, там можно использовать все возможности Condition
editor. Потом на условие прицепляются собственно и сами действия – правый клик на
условие и выбираем в меню add subaction.
Expression – аналогично похожей опции в Condition editor, только не оценивает
выражение на истинность, а выполняет его. Синтаксис присваивания паскалевский – “:=”,
все остальные правила работы с переменными аналогичны.
Quest – группа работы с квестами.
Begin quest – запускает квест и добавляет его в журнал (если квест видимый).
Quest – позволяет манипулировать состояниями логических узлов одного или
нескольких квестов. При манипуляции состоянием узлов, отвечающих за выполнение,
провал и отмену заданий, задания соответственно будут выполнены, провалены или
отменены. Аналогично и с узлами, отвечающими за этапы заданий.
End quest – экстренное завершение квеста с одним из трех статусов – провален,
выполнен и отказан. Не рекомендуется использовать для нормального завершения квеста,
лучше через этапы (логические узлы, настроенные на завершение). А вот проваливать
квесты желательно как раз через эту функцию.
Dialogs – группа работы с диалогами и интерфейсными формами.
Begin dialog – начинает диалог с актером. Либо начинает со стартовой фразы с текущим
актером, либо позволяет выбрать актера, его диалог, и стартовую фразу в нем.
Show form – показывает некоторую интерфейсную форму. Самые часто используемые –
buy_from, buy_from_s – формы продажи, и building – окно замка.
Show message box – показывает диалоговое окно, аналогично Lua-функции
Game.InvokeMsgBox(“warning”, text). Позволяет выбрать одну из глобальных строк для
использования в нем в качестве отображаемого текста. Freeze logic заморозит игровой мир,
пока игрок не среагирует на диалоговое окно, Question вызовет окно с вопросом и двумя
кнопками: Ok и Cancel. На нажатие каждой кнопки можно привязать какое-нибудь
пользовательское событие (custom event), и оно будет отслеживаться текущим логическим
объектом.
Fight – группа работы с боевой системой.
Self-destruct – атом с ЛО умрет либо с анимацией смерти, либо постепенно исчезнет.
Актуально для NPC, которых мы победили в бою, или просто для удаляемых навсегда
объектов, в том числе и невидимых/скрытых.
Enter fight mode – переводит нас в боевой режим. Тонкость: необходимо одновременно
с этим запустить Change location без параметров. Необходимая арена игре уже известна, но
героя нужно на нее перенести.
Change aggressive – меняет отношение эмбриона к игроку. Сражаться можно только с
агрессивными эмбрионами.
Embryos – группа работы с эмбрионами.
Embryo/Atom switch – включает и выключает эмбрион на карте. Отключенный эмбрион
полностью невидим, его логика пассивна и он не влияет на рисунок проходимости карты.
Включение мгновенно проявляет объект, активирует всю его логику и включает его в расчет
поиска пути. Эту операцию можно проделывать не только с эмбрионами, но и вообще с
любым объектом, даже деревьями или заборами. Выставить состояние Включен/Выключен
так же можно для каждого объекта вручную на карте – из меню объекта по правому клику
или в закладке свойств объекта. Чтобы делать switch для нелогических объектов, нужно
обязательно выставить на карте Atom visible в свойствах объекта true или false.
Flush embryo – Выдает заранее прописанный предмет-эмбрион из актера (выбираем
любого в списке) или из текущей локации герою.
Remove item – удаляет указанный предмет. Можно выбрать объект, из которого удаляем
предмет (герой, актер или объект, способный хранить в себе предметы) и сам предмет.
Можно задать количество удаляемых предметов.
Special – специальные операции.
Switch location – телепортирует героя к выбранному порталу (кнопка Add). Настройки
отвечают за сохранение позиции героя (это нужно, если мы, например, попадаем в замок
гремлинов, тогда для выхода нам нужно знать, откуда мы вошли) и появление панели
прогресса. Это действие необходимо использовать и для входа на арену, но без выбора
портала. В списке выбираемых порталов-выходов будут показаны только порталы открытых
в редакторе локаций.
Custom notification event – Запускает или прекращает пользовательское событие. По
сути, это значит только то, что событие за некоторым номером становится активным или
неактивным для выбранного вами объекта – вы отправляете приказ ему. Активность или
неактивность события можно отслеживать с помощью ловушки CUSTOM_EVENT.
Change shop assortment – меняет ассортимент указываемого магазина/NPC. Для
выбора нужно заранее прописать в магазине нескольких вариантов ассортимента, которые
потом можно будет удалять и добавлять с помощью этого оператора.
hidden – дополнительные операции. Эту группу можно увидеть, если включить галочку
Show rare conditions.
Run scenario – запускает один из заранее заскриптованных сложных сценариев. Список
доступных сценариев приведен здесь.
Timer – «подписывает» ЛО на таймер из списка. Каждый раз, когда таймер сработает
(истечет время), его срабатывание можно ловить ловушкой TIMER. Subscribe(once)
автоматически отменяет подписку на таймер после первого срабатывания, Unsubscribe
отменяет подписку.
Platform management – манипулирует платформами. Можно создавать платформу и
отправлять ее на станции. Подробнее об этом будет рассказано в разделе «Монорельсовая
система».
Teleport unit – перемещает ЛО к выбранному порталу.
Execute script – выполняет Lua-скрипт, передавая ему строку в виде параметра. Для
выбора редактором используются функции, у названия которых стоит комментарий “--
ftag:action”.
Modify variable – модификация внутренних переменных или значений счетчиков
выбранного в списке ЛО.
Spawn client – порождает атом с выбранным шаблоном ЛО в месте текущего ЛО.
Актуально для триггеров и виртуальных ЛО.
Spirit manipulator – функции работы с духами ярости. Для ПвД актуален только pet,
здесь можно его включить, дать ему опыт или уровни, можно принудительно включить ему
одну из способностей.
Send for hero – отправляет героя в позицию текущего ЛО.
Assign dialog to actor – позволяет склеивать диалоги. Если у героя есть основной
диалог с приоритетом 10, то, приклеив еще один с приоритетом 15, мы получим ситуацию,
когда конец второго диалога будет вести на начало первого, при этом разговор начнется со
второго. Равные приоритеты ведут к непредсказуемому поведению.
Change army – выставляет армию какому-то из взаимодействующих с текущим ЛО
внешних ЛО, либо ему самому. Можно как выставлять с нуля, так и добавлять по слотам, а
также перетаскивать армию целиком из другого эмбриона. Так сделан двойник героя –
сначала в него перетаскивается армия самого героя, потом удваивается. Галка Store army
отвечает за то, что предыдущая армия ЛО будет запомнена и восстановлена после
сражения.
Actor switch – меняет текущего актера ЛО.
3.2.5. Игровая логика. Сценарии и события.

Итак, как мы знаем, игра и объекты в ней могут генерировать различные события, а
объекты – ловить их. Существует два различных вида событий. Логические события
генерируются в коде игры в специфических ситуациях, любое из них имеет вполне
конкретный смысл. Пользовательские события (приказы) генерируются в логике,
настраиваемой дизайнером, и там же ловятся. Смысл они имеют именно тот, какой
дизайнер им присвоит. События отличаются друг от друга только номером, однако в
редакторе (не в игре) им присвоены удобные названия, которые в случае пользовательских
событиях нужны только для того, чтобы зарезервировать некоторые номера событий за
некоторыми типовыми реальными событиями. Никто не мешает вам сгенерировать при
нажатии на кнопку OK в диалоговом окне пользовательское событие Die, однако для этих
целей уже есть событие Special item commands/(ok), так что лучше использовать его. Точно
так же устроены и таймеры, названия им даны только для удобства, поэтому рассматривать
эти типы событий нет смысла – вы будете сами ими управлять. А вот список реальных
событий в игре, которые перехватываются ЛО, рассмотрим подробнее:

Spirit Click – игрок кликнул на одного из Духов Ярости в интерфейсе героя. В ЛоР на это
событие были завязаны диалоги с Духами Ярости, в ПвД не используется.
Reach boat – генерируется, когда объект подходит к лодке.
Begin chat – генерируется, когда с объектом начинается разговор.
End chat – генерируется, когда с объектом завершается разговор.
Box taken msg box ok – игрок кликнул на диалоговом окне данного ЛО контейнера.
Box digged out – объект выкопан из под земли.
-broadcast- (сообщения, которые приходят из игры, а не изнутри ЛО)
Building form closed – закрыто интерфейсное окно замка.
Chat form closed – закрыта интерфейсная форма диалога.
Loaded game – загружена игра.
End cutscene – закончился или прерван скриптовый ролик.

Теперь рассмотрим такую вещь, как сценарии. Условно сценарий – это некоторое
сложное действие, которое производит атом на карте, заданное заранее и доступное для
выбора из списка. Чаще всего использование таких сценариев – это исполнение какой-то
анимации атома, однако есть и ряд других. С другой стороны, можно сказать, что целый ряд
действий, которые можно использовать в Action editor, – наиболее востребованные
сценарии, а все остальное лежит в списке сценариев. Рассмотрим доступные сценарии:
Scripted
Execute scripted scenario – исполнить некоторый скриптовый сценарий. На деле
исполняется Lua-скрипт или закодированный сценарий. Соответствие названий сценариев и
Lua-скриптов можно найти в файле editor.txt в блоке scenarios. Галочка Freeze hero
заморозит управление героем и камерой, а сами скрипты можно найти в файле scenario.lua
в ses.kfs и в некоторых других. Можно и самому создавать и добавлять такие сценарии,
например последовательности анимаций и срежиссированных ракурсов камер. Обзор
скриптовых сценариев ниже.
Terminate scripted scenario – прервать исполнение верхнего в стеке скриптового
сценария.
Movement and interaction
Terminate current path processing – сбросить прохождение пути в данный момент.
Proceed path – привязать объект к выбранному пути. Можно выбрать путь либо из
переменных объекта, либо из списка путей локации.
Run to current hero position – объект побежит к текущей точке местоположения героя.
Исполняя раз в, скажем, 100 миллисекунд, получим преследование.
Re-test logic intersections – принудительно проверить пересечение шейпов объекта с
другими.
Go away – идти от героя.
Run away – бежать от героя.
Specials
Box taken – переместить содержимое контейнера в инвентарь игроку. При этом
указывается, показать отлетающий текст или окно с кнопкой. Для окна с кнопкой можно на
нажатие повесить custom event, который будет отслеживаться текущим ЛО (контейнером).
Load source to boat – загрузить этот объект в лодку.
Unload boat – разгрузить лодку (исполняется в ЛО лодки).
Set logic state – изменить логическое состояние атома. Очищает, выставляет
агрессивное состояние или сконфуженное (управляет иконками-знаками над отрядами)
Play sound – проиграть некоторый звук, который описан в sounds.csv как voice.
Hero
Drop slots – одетые предметы падают в инвентарь. С героя или жены (спутника) –
задается здесь же.
Replace wife – сменить жену/спутника на указанную/-ого.
Spawn child – родить ребенка в слоте жены. Не используется в ПвД.
Rename pet – вызвать диалог переименования питомца.
Global
Open location – открыть локацию на глобальной карте и для путешествий.
Location switch – позволяет на какое-то время или навсегда запретить переключение
локаций. Этим же сценарием можно вернуть все на круги своя.
Morning mania – восстанавливает ману и сбрасывает до нуля ярость. Используется
после быстрого путешествия.
End game – завершает игру победой или поражением.

Наконец, рассмотрим отдельно избранные скриптовые сценарии. Работу многих из них


можно подсмотреть вручную в Lua, так что не станем разбирать весь список. Наиболее
полезные и часто используемые при создании карт сценарии:
Hero – раздел run animation. Запускает анимации героя.
Transport – запускает анимации и привязанные к ним режиссерские ракурсы для
транспорта. Исчезновение и непосредственно перемещение между порталами и локациями
настраивается отдельно через Action editor.
Armies
Lost contact – отряд теряет героя из видимости. Но через 1 секунду он снова
«осмотрится» и может обнаружить героя.
Stop – здесь хранятся сценарии остановки блуждающего отряда. На заданные
интервалы времени и навсегда.
Custom – можно запустить любую прописанную анимацию, указав ее имя, и проигрывать
ее заданное количество секунд.
--run animation – однократно запускает одну из анимаций отряда (анимации хранятся в
атом-файлах объектов).
Platform – сценарии управления платформами. На деле эти сценарии в основном
касаются лифтов, более общие функции платформ настраиваются отдельно через действие
Platform management.
Quest object – сценарии управления НПЦ, multistate и квестовыми объектами.
Destroy – запускает анимацию dead и записывает в объект переменную death = 1.
Назначает idle анимацию death.
--run animation - однократно запускает одну из анимаций объекта. Выбранная анимация
обязана у объекта быть, иначе она не будет проиграна.
Recharge object – перезаряжает текущий алтарь или фонтан.

3.2.6. Игровая логика. Внутренний скриптовый язык игры.

Этот язык доступен через условие или действие Expression. В случае условия
оценивается истинность выражения, в случае действия – выражение исполняется. В
скриптовом языке недоступны прямые операции (читай, функции с побочным эффектом, то
есть язык по своей природе функциональный), однако, мы можем перезаписывать значения
глобальных переменных или переменных ЛО с помощью синтаксиса присваивания “:=”.
Сами переменные используются следующим образом: мы придумываем переменной
уникальное имя, например, a. Эту переменную в тексте выражения мы можем использовать
с синтаксисом “[a]”. Как только такая переменная появляется в тексте выражения, внизу
появляется поле, откуда ее можно брать.

Hero – какая-то переменная героя.


Logic unit variable – переменная некоторого логического объекта, который мы выбираем из
списка. В принципе, можно получать в распоряжение переменные и так.
Logic unit counter – счетчик некоторого логического объекта.
Logic unit chesspieces – количество боевых юнитов определенного типа у некоторого ЛО.
Logic unit scrolls – количество свитков определенного типа у некоторого ЛО.
Item custom param – внутренняя переменная предмета (Expression должен обрабатываться в
логике этого предмета).
Quest variable – внутренняя переменная некоторого квеста.
Global variable – глобальная переменная. Часть переменных сделаны не как глобальные, а
как переменные глобального ЛО all.
Random ID – не работает.
Internal – внутренняя переменная выражения. Обычно это просто какое-то число.

Доступен целый ряд разнообразных операторов. Ряд операторов поддерживает


несколько дополнительных аргументов через запятую, так что допустимы записи вроде a +
b, c, d. В случае, когда такая запись возможна, это будет оговорено отдельно, также такая
запись с очевидностью нереализуема для унарных операторов. Также всегда можно
заключать второй (если таковой имеется, в противном случае первый) операнд или список
операндов в скобки, например a + (b, c, d) или not(a).
Список операторов (символом “ó” обозначаются эквивалентные записи):

~x – побитовая инверсия. Унарный оператор, возвращает число. ~1001 =


0110 (двоичное представление чисел 9 и 6);
!x ó not x – логическое НЕ. Унарный оператор, возвращает булево значение;
a/b – деление. Поддерживает список операндов;
a%b – остаток от целочисленного деления a на b;
a*b – умножение. Поддерживает список операндов;
a+b – сумма. Поддерживает список операндов;
a–b – вычитание;
-x – унарный минус;
x << n – побитовый сдвиг влево;
x >> n – побитовый сдвиг вправо;
x<y – оператор сравнения. Возвращает булево значение;
x>y – аналогично;
x <= y – аналогично;
x >= y – аналогично;
x == y – оператор сравнения. Возвращает булево значение;
x != y ó x <> y – оператор «не равно». Возвращает булево значение;
a&b – побитовое И. 1101 & 0111 = 0101;
a^b – побитовое исключающее ИЛИ (XOR). 1101 ^ 0111 = 1010;
a|b – побитовое ИЛИ. 1101 | 0111 = 1111;
a && b ó a and b – логическое И, возвращает булево значение;
a || b ó a or b – логическое ИЛИ, возвращает булево значение;
a ? x, y – сложный оператор. Если a истинно, возвращает x, если ложно –
возвращает y;
a := b – в переменную a записывается значение b.
Истинными считаются все числа, не равные нулю, или непустые строки. Легко видеть,
что большая часть синтаксиса заимствована из С. Также в Expression допускается
использование ряда встроенных функций. Если у функции есть аргумент, то использование
скобок необязательно, можно записывать как abs(x), так и abs x. Однако для функций, у
которых нет аргументов, скобки писать обязательно.
Доступные функции:

day() – возвращает игровой день;


daytime() – возвращает время суток (0..3);
rnd(x) – псевдослучайное число [0..x) от таймера;
rnd(x, y) – псевдослучайное число [x..y] от таймера;
rnd(x, y, n – псевдослучайное число [x..y] от n;
hdist() – дистанция от текущего ЛО до героя в метрах, округленная;
abs(x) – модуль x;
abcd(x, a, b, c, d) – эта функция определяет положение x на отрезке a..b и возвращает
аналогичное число для отрезка с..d.

3.2.7. Разбор избранных логических объектов.

В этом параграфе мы рассмотрим два логических объекта для закрепления полученных


знаний – ЛО героя и шаблон ЛО замка. Начнем с героя. Для этого нужно открыть панель
логических объектов (Shift + U) и в ней папку [global] (Source:Session). Там хранится тот
самый ЛО героя для текущей сессии (в библиотеке есть и ЛО героя из ЛоР, но в аддоне у
него измененная логика). Он называется hero. Как видно, это тоже шаблонный ЛО
(выставлена галочка template), но реально он в игре используется всего единожды – в
единственном герое. Его шаблонность удобна тем, что, выставив героя на любую локацию,
мы сразу получим в свое распоряжение всю его логику.
В ЛО героя всего пять ловушек: как правило, своими действиями герой сам генерирует
сообщения, а уж другие объекты их ловят. Достаточно, например, посмотреть, сколько
ловушек и условий на взаимодействие у ЛО армий. Но, тем не менее, герою тоже присуща
определенная логика, ее мы сейчас и рассмотрим.
Рис. 3.4.
Ловушки героя.

INTERACTION_ACTIVE_ON
Эта ловушка срабатывает, когда герой входит в некоторый логический шейп другого
объекта. Как известно, для такой ловушки должно быть специфическое условие в ORC, там
стоит Complex – логическое И двух условий. Одно из них – Send for hero in progress, то есть
герой в данный момент бежит к ЛО-клиенту. Второе (как раз необходимое для работы Trap
specific условие) – задается класс объекта-клиента, в данном случае контейнер, и вид
шейпа, Layer #0 (buildings or boxes). Это условия получения сообщения, теперь рассмотрим
действия. Оно всего одно – рождается событие Taken в отправителе сообщения (то есть в
контейнере). Когда контейнер отловит это событие, он начнет совершать различные
действия, связанные с его подбиранием: запустит анимацию открытия (если это сундук),
модифицирует нужные счетчики героя, высветит диалоговое окно и самоуничтожится. Логика
внутри героя нужна только для того, чтобы отправить ему это сообщение и
синхронизировать все процессы.
START_GAME
Данная ловушка может работать без ORC, да и какое там может быть условие, в начале
игры? Действий всего три. Первое – Execute script. Запускается Lua-функция generation_hero
с параметром «test». Эта функция генерирует все начальные параметры героя в
зависимости от его класса, выставляет слоты для предметов, дает армию и делает массу
нужных вещей, связанных с начальной параметризацией героя. Ее можно найти в файле
logic_hero.lua в ses.kfs. Второе действие – выражение [a]:=0, где a – внутренняя переменная
ЛО героя (тут используется не self, а hero, но в данном случае они эквивалентны) canfly или,
в абсолютном обозначении: lu.hero.var.canfly. Иначе говоря, на старте игры, помимо
генерации параметров через скрипт, задается, что герой не может летать. Если выставить
эту переменную в 1, то герой получит возможность летать с самого начала игры. Третье
действие – запускается диалоговое окно с одной кнопкой. В качестве текста выбрана
некоторая глобальная строка из папки ДЛЯ КВЕСТОВ/Спасение Дариона, получателем
сообщения о закрытии выбран сам герой, но при этом ему не посылается никакого события,
так что это неважно. Говоря простым языком, данное действие ответственно за появление
диалогового окна с текстом про нелегкую судьбу Дариона в самом начале игры.
ACTIVATED
Ловушка срабатывает при активации ЛО. В данном случае есть два действия: подписка
на таймер и выполнение скрипта. Подписка на таймер означает только то, что каждые N
единиц времени (в данном случае 10 секунд реального времени) таймер будет генерировать
внутри ЛО сообщение, которое можно поймать ловушкой TIMER по названию таймера (в
данном случае Decrease rage). Такой механизм позволяет каждые 10 секунд что-то делать.
Плюс впервые запускается скрипт change_manarage из logic_hero.lua с параметром update.
С таким параметром, правда, он срабатывает вхолостую.
TIMER
В данной ловушке ловится таймер Decrease rage, который мы запустили из ловушки
ACTIVATED, то есть она срабатывает каждые 10 реальных секунд. Единственное, что
делается в этой ловушке, – запускается скрипт change_manarage, уже без параметров. Этот
скрипт ответственен за то, что со временем увеличивается мана героя и уменьшается
ярость. Есть одна тонкость: значение таймера записывается в сейв, так что сбросить его
перезагрузкой нельзя.
CUSTOM_EVENT
Для этой ловушки необходимо указать, какое именно событие ловить. В данном случае
ловится событие (можно посмотреть в ORC) NPC wait for hero, которое некоторые
персонажи, инициирующие диалог с героем сами, могут отправить. Исполняется сценарий
Stop, который отменяет все движения героя, в том числе и Send for hero.

Все остальные вкладки ЛО героя пусты, за исключением последней. Там нет ни актеров,
ни замка, ни портала, ни юнитов. Даже вкладка Skills не инициализирована – все стартовые
навыки героя задаются не здесь, а в скрипте generation_hero. Интерес представляет только
вкладка Variables, где хранятся переменные героя. Большая часть из них просто
инициализируется без начального значения для последующего использования, есть две
скриптовых переменных – companion_gold и rank, которые считаются из скриптов. Первая
определяет золото, которое дадут компаньону при увольнении, вторая – ранг героя, но она в
ПвД не используется. В аддоне, как известно, рангов и званий у Амели нет. Реально
инициализируются тут только две переменных – level и name, отвечающие за уровень и имя
героя соответственно. Есть и тип/имя дракончика, но, поскольку дракончик выключен до его
получения, то они, фактически, не используются.

Второй ЛО, который мы рассмотрим – это building_castle. Это шаблон ЛО, который
используют по умолчанию эмбрионы всех замков. Как уже было сказано, редактировать его
не стоит, потому что это вызовет изменения во всех замках, где не выставлен Custom Logic.
Зато мы можем залезть в него (найти его можно в корне Source:Library) и посмотреть, как же
он устроен.
Рис. 3.5.
Ловушки шаблона
замка.

CLICK_CAPTURE
Как обычно, левый клик по активному объекту на карте отправляет героя в путешествие
в их направлении, то есть выполняется Send for hero.
INTERACTION_PASSIVE_ON
Тут задается достаточно сложное условие: и ORC и PDC одновременно. В ORC в
обязательном порядке должен быть активен Send for hero, а также на выбор объект
взаимодействия должен быть героем или лодкой. Задержка на срабатывание ловушки
установлена в 300 миллисекунд, после нее проверяется PDC – опять на Send for hero (а
вдруг за эти 300 мс герой куда-то убежит?). Далее выполняются два действия, одно из
которых имеет дополнительное условие (учтите, в данном случае важно, что действия
отрабатывают по порядку! За то, что последующие действия не будут выполнены, отвечает
галочка Terminate processing if true). Условие состоит в следующем: у замка есть армия,
переменная nofight внутри текущего ЛО не равна 1 ( фактически, она и может запретить ЛО
драться) и ЛО агрессивно настроен по отношению к игроку. В этом случае вызывается
диалоговое окно с предложением подраться. Если игрок отвечает «да», генерируется
событие Go to arena внутри ЛО замка.
Если же эти условия не выполняются, то вызывается интерфейсная форма замка.
ARENA_WIN
Эта ловушка может сработать только в том случае, если герой с ЛО подрался и выиграл
бой. Тогда, во-первых, обнуляется армия ЛО, во-вторых, вызывается интерфейсная форма
замка.
CUSTOM_EVENT
В данном случае стоит ORC на событие Go to arena, то есть эта ловушка сработает
только при получении ЛО такого сообщения. Это сообщение генерируется в
INTERACTION_PASSIVE_ON, если игрок на вопрос о сражении отвечает утвердительно.
Почему же прямо там все и не сделать? Ну, во-первых, ответ на вопрос в диалоге не может
провоцировать действия, он может только сгенерировать событие. Во-вторых, такая схема
позволяет вызвать срабатывание этой ловушки и в других ситуациях, если событие Go to
arena приходит откуда-то извне ЛО. В любом случае, при этом происходят очень типичные
события: сначала делается Enter fight mode, который переводит нас в режим боя и
заготавливает арену, а потом Switch location без параметров, который и переносит нас на
арену.

Вообще нетрудно заметить, что для большинства замков часть этой логики не работает
вообще – там нет армии – или стоит nofight, то есть вся логика сражения не отрабатывает, а
работает урезанный вариант, который можно описать так:
CLICK_CAPTURE
Send for hero
INTERACTION_PASSIVE_ON (Send for hero + нужный шейп героя или лодки)
[Show form] form [Building]
Такое поведение типично для шаблонов ЛО: в них зашито множество различных
функций, а в конкретных реализациях, которые стоят на карте, используются только
некоторые из них. В принципе, вы можете модифицировать шаблоны, чтобы запихнуть в них
дополнительную логику, просто нужно удостовериться, что эта логика не просочится в те
объекты, которые уже используют этот шаблон на карте.

Практическая часть.

Пока не будем трогать логику, которая зашита в эмбрионы (нам вообще почти не нужно
будет ее трогать), а рассмотрим только те ЛО, которые существуют на карте «как есть». У
нас такой всего один – ЛО портала, который мы поставили. Нужно создать на Дебире
пещеру, портал в которой приведет на остров, и обратный портал. Используем для этого
тупик на Дебире, который находится рядом с заброшенным замком.
Рис. 3.6. Тупик.

Поставим там вход в пещеру из Decorations/cave. Редактирование текстур на Дебире нам


недоступно (нет соответствующих несжатых текстур в папке sourcemedia), поэтому выберем
такой вход в пещеру, который более-менее неплохо сливается с поверхностью сам по себе.
Пару деревьев придется убрать, ну и немного подвинуть лежащие рядом эмбрионы
контейнеров.
Рис. 3.7. Вход в пещеру.

Важно не забыть отредактировать карту проходимости под входом, иначе до него нельзя
будет добраться. Теперь нужно поставить там портал. Нам нужно два портала для связи
двух точек на локациях, не так ли? Нет, не так. Один портал переносит героя к другому, но
куда он при этом попадает? Правильно, точно в середину противоположного портала, то
есть в зону, где срабатывает логика перемещения. Два портала приведут к тому, что герой
будет просто бесконтрольно телепортироваться туда-сюда до скончания времен. Таким
образом, для связи между собой двух точек нам нужно четыре портала – два из них будут на
вход, они будут обладать логикой и красивым спецэффектом. А еще два портала – на выход,
просто точки с тегом портала, и больше ничего. Поставим портальную пару во вход в пещеру
на Дебире (необходимо, чтобы их логические шейпы не пересекались, подсветить их можно
сочетанием клавиш Ctrl-H). Для входа используем красный портал portal_twirl_red, а для
выхода – невидимый атом trigger_zone. Для точки выхода важна ориентация атома, который
для него используется. В случае trigger_zone у вспомогательного объекта (желтого
схематичного портала, их видно по нажатию Ctrl-T) есть стрелка, которая показывает
направление. Герой после выхода из портала будет смотреть в противоположную сторону.
Рис. 3.8. Порталы.

Аналогично добавим пару порталов на нашем острове. Теперь нужно настроить логику
для входов и тег портала/камеру для выходов. Выбираем trigger_zone на карте и нажимаем
L. Появляются настройки ЛО. Во вкладке Portal выставляем теги порталов (на Дебире –
exit_sunset_to_debir, на Острове Заходящего Солнца – exit_debir_to_sunset) и камеру. Кнопка
Test позволяет посмотреть «из глаз» самой камеры на выходе. Теперь нужно всего лишь
настроить входы так, чтобы они переносили нас к соответствующим точкам выхода. Логика
портала очень проста и уже настроена за нас: по ловушке CLICK_CAPTURE вызывается
привычный Send for hero, а INTERACTION_PASSIVE_ON включает саму логику – перенос в
другую локацию. Тут есть один подвох: в ORC для пассивного взаимодействия нет условия
на Send for hero. Попадание в логический шейп портала включит его логику вне зависимости
от того, кликали мы непосредственно на него или нет. Именно поэтому использование
одного и того же портала на вход и выход приведет к бесконечной телепортации. Действию
Switch location пока не хватает тега портала (можно выбирать из списка только те теги,
которые стоят на открытых в редакторе локациях). Нажимаем Add и добавляем
соответствующие точки выхода. Все, портал готов! Осталось только еще раз зайти в точки
входа (на этот раз в настройки атома, а не ЛО, то есть через пробел), открыть там вкладку
Text и задать всплывающую подсказку на карте, которая высветится при наведении курсора
на портал: «Вход в подводную пещеру».
Порталы надо проверить в игре. Лучше всего, конечно, проверять все в естественном
течении игры, но для ускорения можно использовать режим отладки (запустить kb.exe с
ключом –dev), в котором можно телепортироваться в любую точку в области видимости по
нажатию Ctrl-Q. Также будет быстрее посмотреть именно наш остров, если герой будет
начинать игру непосредственно на нем. Для этого на время тестов поставим на локацию
атом героя и пропишем в файле session.txt в нашей сессии в самом конце start=sunset_isle,
теперь игра начнется на этой локации. Там же можно выставить и параметр autoload,
который определяет автоматическую загрузку локации в редакторе.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >

3.3. Эмбрионы.

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

3.3.1. Общие свойства и смысл эмбриона.

Для эмбриона существует две различных области видимости: шаблон эмбриона для
объекта существует внутри типа объекта – отдельного атома. Такой эмбрион можно
просмотреть в таблице атомов, кликнув на иконку правой кнопкой мыши и выбрав Embryo
(однако здесь его редактировать не следует). Когда мы помещаем атом на карту, в нем
живет именно этот эмбрион-шаблон.
Рис. 3.9. Свойства атома.

Если выбрать Independently, объект будет использовать локальную копию этого


эмбриона, доступную для редактирования. Многие шаблоны эмбрионов изначально пусты
(эмбрионы зданий), так что для достижения необходимого эффекта всегда нужно нажимать
Independently и настраивать. Также всегда пусты эмбрионы армий. А вот эмбрионы
контейнеров, как правило, уже прописаны: поставив на карту волшебный пень, мы можем
быть уверены, что он без дополнительной настройки будет выдавать герою
золото/брильянты в зависимости от уровня сложности локации. Если же мы хотим, чтобы
бонус был каким-то специальным, нужно уже настраивать эмбрион вручную.
Все эмбрионы обладают свойством Chance – этот параметр определяет шанс
возникновения эмбриона на карте вообще. Если выставить его в 0, то объект на карте не
возникнет. Также для многих эмбрионов есть настройка Generate on demand. Когда эта
галочка выставлена, содержимое эмбриона генерируется не при старте игры, как обычно, а
в тот момент, когда игрок впервые взаимодействует с объектом. Это дает ряд
дополнительных опций генерации, но в общем случае использовать эту настройку не
рекомендуется: игрок будет сохраняться/загружаться перед объектом, чтобы получить
наиболее выгодную для себя генерацию.
Настройка Advanced mode, доступная у многих объектов, – расширенный режим
эмбрионов. В таком режиме в одном объекте будет уже жить не один независимый эмбрион,
а несколько, и при генерации случайным образом выберется один. Понятно, что для разных
вариантов ассортимента магазинов это делать не нужно, но таким способом реализуются
объекты типа логова разбойников в Моршанских топях: иногда там логово, а иногда – склеп.
То есть в данном случае генерация эмбриона определит не только наполнение, но и сам
генерируемый объект, включая всю его логику и содержимое.

Когда на карту выставлен объект с эмбрионом, у него есть еще одна крайне важная
опция. Выбрав во всплывающем меню Variations или нажав V, мы получим «висящую на
курсоре» полную копию объекта вместе с эмбрионом. Вообще, когда мы выставляем на
карту объект, ему присваивается определенный эмбрион за определенным номером.
Выставив объект снова, мы получим уже другой эмбрион. Через Variations мы можем
поставить на карту объект, в котором сидит тот же самый эмбрион, что и в оригинале.
Фактически, выставляя на карту вариации объекта, мы определяем возможные точки, где
этот объект может родиться при генерации. Так обеспечивается то, что на Дебире лежит
всегда только одна навигационная карта Боло, зато она может лежать в разных местах.
Выбрав в меню Show hidden, мы увидим над эмбрионами специальные значки в виде
гаечных ключей. Если над гаечным ключом висит плюс – у объекта есть вариации.

Наконец, мы можем редактировать и шаблон эмбриона. Отредактировав эмбрион в


объекте в режиме Independently, мы можем нажать Store – тогда текущие настройки
запишутся в шаблон эмбриона для этого атома. С существующими, конечно же, такого
делать не стоит, но можно создать новый атом, настроить ему эмбрион на месте и потом
запомнить настройки, чтобы они были у всех объектов с этим атом-тегом.

3.3.2. Эмбрион магазина/замка.

Откроем свойства эмбриона объекта класса castle. Этот эмбрион одинаков для замков и
обычных магазинов, а то, какой интерфейсный экран будет использован при входе в такой
объект, зависит от настроек логики. Рассмотрим параметры по отдельности.

Рис. 3.10.
Эмбрион замка.
Background – картинка задника для замков, выбирается из списка. Для того чтобы
пользовательская картинка отобразилась в списке, необходимо поместить ее в папку
\data\interface\textures\TownPics и прописать ее в файле editor.txt в категории zadniki. Rulers –
актеры, живущие в замке. Для обычного здания смысла указывать больше одного нет, для
замка можно указать несколько. По умолчанию актер включен, но можно его и выключить
(как, например, при старте игры в замке Фридриха выключена Эния), позже включив его
логикой, например через квест. Чуть ниже находится поле ассортимента. Разные варианты
ассортимента (и войск, и заклинаний, и предметов одновременно) могут быть переключены
через логику, но по умолчанию используется только base. Справа можно увидеть три поля:
настройку войск, свитков и предметов для продажи.
В ассортименте войск каждая строка (юнитсет) отвечает за наполнение одного из слотов
у торговца. По правому клику можно выбрать Add и добавить новый юнитсет, двойной клик
по сету открывает его для редактирования. В свою очередь, уже в юнитсете каждая строчка
отвечает за некоторый вариант генерации с определенным весом. Статистический вес здесь
– число, которое определяет шанс генерации. Если у двух вариантов вес равен 10 и 11, то
шансы их генерации соотносятся как 10:11. Ниже находится поле выбора юнитов. В каждой
строчке мы выбираем то, какие юниты могут быть сгенерированы в данном слоте, варианты
прописаны в строке через запятую и генерируются с равной вероятностью. Кликнув дважды
на расу, мы добавляем в список шанс генерации не определенного юнита, а случайного
юнита определенной расы, можно также добавить к этому и уровень, слева же можно
выбрать юнитов (над полем выбора юнитов есть кнопочка, которой для удобства можно
отфильтровать список) и их количество. Количество определяется следующим образом.
Просто число означает то, что именно столько юнитов и сгенерируется. Два числа,
разделенные двоеточием, означают, что сгенерируется случайное число в этих пределах.
Наконец, запись вида A:B:C означает генерацию в количестве от A до B с шагом C, то есть
сгенерироваться могут только числа в виде A+NB, не большие C, где N – целое число. Так,
запись 40:10:60 означает, что будут варианты только 40, 50 и 60. В одном сете можно задать
сколько угодно разных юнитов, и сгенерируется один из них. Например, у нас есть две
строчки:
10 Вампир:100:20:140, Древний Вампир:40:50
40 undead:3/150
Здесь у нас два юнитсета. Сначала игра выберет, какой именно из них использовать.
Соотношение веса вариантов – 20:80, то есть с вероятностью 80% в текущем слоте будет
сидеть случайный юнит нежити третьего уровня в количестве 150 штук. С вероятностью 20%
мы получим или вампиров в количестве 100, 120 или 140, или от 40 до 50 древних вампиров.
Если просчитать вероятности до конца, в результате с вероятностью 10% в слоте будут
древние вампиры (40-50), 10% – обычные вампиры в количестве 100, 120 или 140, 40% –
обычные вампиры в количестве 150 штук и последние 40% – привидения в количестве 150
штук. Количество юнитов, равное 9999 или больше, означает, что юниты будут продаваться
в бесконечном количестве, если же в качестве варианта оставить пустую строку (empty),
будет шанс (в зависимости от веса варианта), что данный слот останется пустым.
Ассортимент заклинаний настраивается похожим образом. Опять же, каждая строка в
ассортименте отвечает за генерацию в одном слоте. Каждая строка – некий набор
вариантов, который будет использован с определенным весов, в строке же варианты
равновероятны. Поле слева отвечает за генерацию случайного свитка (можно указать школу
и уровень заклинания, для того, чтобы узнать уровень заклинаний, рекомендуется
воспользоваться Руководством Искателя Приключений), количества прописываются по тому
же принципу (однако средний третий параметр не особо нужен – числа все-таки маленькие,
и красивые шаги, кратные 10 или 100, не нужны), справа же можно выбрать конкретный
свиток. В поле script можно задать специальный метод расчета веса варианта. Это должна
быть Lua-функция, не принимающая параметров, которая возвращает вес в виде числа. Так,
например, можно задавать разный вес вариантов в зависимости от класса героя или других
доступных через скрипты параметров. Единственное условие – должна быть выставлена
галочка Generate on demand: ассортимент должен генерироваться не при старте игры, а в
тот момент, когда игрок впервые зайдет в магазин. Рассмотрим для закрепления (все
эмбрионы ассортимента похожи друг на друга) еще и вариант со свитками. Так, у нас есть
такой набор для одного слота:
70 Random scroll: School[<<ANY>>], level[3], count[3:5]
10 spell_armageddon(1)
20 spell_trap(3:7), spell_animal_call(3)
Как и раньше, сначала выбирается одна из строк. Шансы их – 70%, 10% и 20%
соответственно. Потом в выбранной строке уже делается генерация по перечисленным
вариантам. С шансом 70% у нас будет некое случайное заклинание третьего уровня в
количестве от 3-х до 5-ти штук. С шансом 10% сгенерируется один-единственный, но очень
крутой свиток армагеддона, а с шансом 20% – или 3-7 свитков ловушки, или 3 свитка
призыва животных. То есть у последних двух по 10% вероятности генерации у каждого.
Единственная сложность здесь – имена заклинаний используются технические из spells.txt.
Мало чем отличается и настройка ассортимента предметов. Здесь мы, опять же,
настраиваем отдельно каждый слот. Разница в том, что предмет выбирается из списка в
отдельном окошке, а количество мы можем задать только для предметов-контейнеров (типа
семян терний), плюс есть галочка consider max count, которая запретит генерацию предмета,
если его уже сгенерировалось в игровом мире столько, сколько указано в его настройках в
поле maxcount. Все остальные настройки и логика генерации полностью идентичны
генерации свитков (впрочем, свиток с заклинанием, да и само заклинание, – это тоже
предмет).
Снизу в настройках эмбриона замка есть также поля, отвечающие за армию и арену.
Армия по умолчанию будет драться с героем, если выставлена галочка Aggressive, если
арену не выбрать, будет использована арена по умолчанию для данной области ландшафта.
Клик на армию перенесет нас в настройки эмбриона армии (об этом ниже), галочка All for
free нужна для того, чтобы все в замке было бесплатным (используется в Кронберге перед
битвой с Баалом).

3.3.3. Эмбрион армии.

Настройки эмбриона армии куда проще понять, если до этого разобраться в настройках
замков. Как и там, здесь слева находится поле, которое определяет различные варианты
генерации. Каждый из них – это отдельно настроенная армия, при генерации игры
выбирается лишь один (за исключением одного специального случая, оговоренного ниже), и
у каждого варианта есть свой вес, определяющий вероятность генерации. Эти заготовки
армий можно также выгружать для использования в дальнейшем в strg-файлы. Сверху
находятся настройки для всего эмбриона в целом: название войска (для удобства) и судьба
героя после поражения. Rebirth – возрождение героя после битвы у королевского замка, а
Total defeat – полное поражение. Место возрождения можно изменить, указав название
портала и локации в файле config.txt – параметр homeportal=имя_портала.имя_локации.
Рис. 3.11. Эмбрион армии.

Теперь о настройке конкретной заготовки армии. Сверху мы можем задать вес и имя,
ниже задаем либо диапазон лидерства, либо диапазон уровня врага. В файле config.txt
определена таблица соответствия уровня монстра и его лидерства (определяется так же, как
и лидерство героя, фактическое лидерство армии будет в пять раз больше), мы можем
задать либо диапазон уровней (и тогда возможное лидерство будет в диапазоне значений
лидерства для этих уровней), либо, если вводимого числа нет в таблице, оно и будет
считаться как лидерство, и тогда мы задаем диапазон вручную. Эти числа потом уже
автоматически множатся на коэффициент, зависящий от уровня сложности игры.
Далее мы настраиваем каждый слот в отдельности. Сперва выбираем тип юнита,
который будет генерироваться в слоте. Как и в случае с магазинами, можно выбрать
конкретного юнита, а можно – по расе и уровню. В одном слоте может сидеть несколько
типов юнитов, из них сгенерируется лишь один. Следующий пункт – заполнение слота.
Задаем либо percent (одно или два числа через двоеточие), если задать 10:30, тогда этот
тип юнитов сгенерируется в расчете на лидерство от 10 до 30 процентов от полного. В
противном случае через Amount можно жестко задать появление определенного количества
юнитов в армии, лидерство армии (а, следовательно, и уровень сложности) в данном случае
не учитывается. Filling type задает тип заполнения при генерации, подробнее об этом чуть
ниже, вес – относительная вероятность для генерации, а Excl tag позволяет настроить
условную генерацию. Выставив двум юнитам одинаковый Excl tag, мы помним, что при
генерации одного из них второй сгенерироваться уже не сможет.
Армия генерируется следующим образом: сначала берутся все юниты с типом
заполнения Required, из них случайно (с использованием веса) выбирается один и на
основании данных о том, какой ему дать процент, заполняется армия. Например, если
выбран юнит с 10:30, то в этот момент выберется случайное число от 10 до 30 (скажем 20), и
тогда армия на 20% заполнится этим типом юнита. На каждом следующем этапе армия
добирается следующими типами юнитов из группы Required, и так происходит, пока
укомплектованность армии не составит 100% или не закончатся Required-юниты. Далее
цикл проходит все оставшиеся юниты (Undefined и Addition) в случайном порядке, добавляя
их в армию. Если цикл завершился и еще осталось место для заполнения, проводится
новый цикл уже только с юнитами типа Addition, пока лидерство не станет равным
заданному. Таким образом, легче всего делать генерации, используя только типы Required и
Addition, в таком случае армия будет состоять из всех обязательных юнитов и всего, что
вместится из дополнительных.
Другие параметры армии:
Display – определяет тот тип юнита, который будет использован для отображения
армии на карте. Strongest – самый сильный по лидерству стек, First – первый юнит в списке.
Arrangement – расстановка юнитов на арене. Если выбран Automatic, то юниты
расставятся автоматически по гексам. Если же выбран By groups, то юнит в слоте за
номером N встанет в клетку за номером N на арене (клетки маркированы). Например, если
известно, что на арене гексы генерации идут по порядку, если выставить первый, третий и
пятый слоты для генерации, именно в них и встанут юниты на арене.
Behavior – поведение отряда на карте. Либо присоединяется, либо не обращает
внимания, либо нападает. Все эти три варианта поведения заданы как ЛО в библиотеке.
Выбрав Custom, можно использовать произвольный ЛО.
Hero – можно выбрать героя, который поведет в бой армию. Если герой выбран
и у него есть модель, то отображаться на карте тоже будет он.
Bonus – вызывает эмбрион контейнера для настройки награды за бой. Generate
on demand, как и раньше, означает генерацию непосредственно в момент получения, а не
при старте игры.

Все эти параметры в совокупности позволяют достаточно гибко настроить армию. Есть
еще один нюанс: если два раза щелкнуть на пункт в списке армий слева, то он станет
подсвечен зеленым, а эта армия станет основой для объединенной армии из двух. При
выбранной базе сама база генерируется всегда, а в дополнение к ней сгенерируется
дополнительная армия из оставшегося списка, и на поле боя против игрока выступят обе
армии одновременно. Если это – армия героя, то герой должен сидеть в основной армии,
чтобы все было корректно. Очень важно в этом случае удостовериться, что на поле боя
достаточно слотов для того, чтобы разместить больше 5 стеков. Это можно задать в
настройках арены для того участка земли, где предполагается сражаться с такой армией.

3.3.4. Эмбрион бокса/клада.

Настройка такого эмбриона очень похожа на настройку ассортимента в магазине. Важно


понять, что в каждой коробке всегда лежит что-то одно, это либо 1474 золота, либо 3 руны,
либо 5 свитков, но разные типы бонусов в одной коробке не встречаются. Есть несколько
общих параметров: Buried treasure делает сундук кладом, Can be digged отвечает за
свечение и возможность выкопать клад. Если эта галочка не стоит, клад временно будет
неактивен, пока его откуда-то через логику не включат. If in rucksack – настройка, которая
ответственна за копание клада. Если там выставить какой-то предмет, а галочка Can be
digged не выставлена, то копать можно будет только тогда, когда в инвентаре есть этот
предмет. Так сделано копание кладов по картам, при выкапывании предмет из инвентаря
исчезает. Update parameter script – зарезервированный для скриптов параметр. В игре не
используется.

Рис. 3.12. Эмбрион контейнера.

В списке, как обычно, находятся сеты с разным весом. В каждом из сетов можно либо
задать вес вручную, либо определить через скрипт (не забываем про галочку Generate on
demand) и выбрать уже равновероятные варианты генерации. Так, задав во второй вкладке
(Parameters2) Crystals:1 и Attack:1, мы получим, что при выборе этого сета для генерации в
сундуке будет с равной вероятностью либо один кристалл, либо перманентный бонус +1 к
атаке. Во вкладке Parameters1 находятся специально настроенные параметры, которые
имеют разную ценность в зависимости от этапа игры: лидерство, деньги и опыт. Можно
задать их вручную в текстовых полях, но можно (и предпочтительно) использовать галочки
над полями, которые сделают доступным вариант с заранее настроенным количеством.
Например, для лидерства Huge означает 34:2:40 лидерства в качестве бонуса. Это число
далее умножается на специальный коэффициент, зависящий от сложности локации, чтобы
получилась итоговая сумма. Если выставить две галочки сразу, то при генерации будут
учитываться уже оба отмеченных диапазона (на деле сгенерируется все равно один из
вариантов, но доступны для генерации оба). Во вкладке Parameters2 находятся бонусы с
инвариантной относительно этапа игры ценностью – параметры героя, руны и кристаллы.
Items позволяет выдать герою предмет, Scrolls – свиток, а Units – войска (тут необходимо
будет еще ввести сообщение, которое возникнет на экране, если игрок вдруг откажется).
Army – сундук будет настроен агрессивно по отношению к игроку и попытается на него
напасть, но сначала игроку об этом сообщат (мы можем ввести сообщение в поле снизу), во
вкладке же Text можно задать вообще сообщения, которые выдаются игроку в качестве
вопроса о том, взять ли сундук, и реакции на положительный или отрицательный ответ
игрока. Как правило, в таких полях (не во всплывающих подсказках на карте) нужно не
вбивать текст вручную, а вставлять имя текстовой переменной из списка глобальных строк
сессии.
В отличие от эмбрионов замка или армии, эмбрион контейнера редко приходится
настраивать: для заданных типов объектов эмбрионы, как правило, уже настроены. В списке
атомов есть и специальные объекты, которые представляют собой универсальные
эмбрионы (для них настроено очень много вариантов генерации). В редакторе у них нет
модели, и они отображаются как желтые или розовые шарики. Найти эти объекты можно
непосредственно в папке Resources в дереве атомов. Вообще, если вы будете настраивать
другие эмбрионы контейнеров, вы можете увидеть, что их вид несколько отличается от
описанного, но это потому, что описанный – наиболее общий, у других могут часто
отсутствовать те или иные функции.

Практическая часть.

Теперь пришло время всерьез взяться за магазины на нашем острове. Начнем с маяка.
Заходим в свойства атома и смело нажимаем Independently – теперь эмбрион мы
настраиваем вручную, потому что эмбрионы замков не содержат в себе никаких настроек по
умолчанию, в отличие от эмбрионов контейнеров. Но мы сначала проверим, какая у нас
используется логика для этого объекта. Нажимаем Custom Logic и получаем в свое
распоряжение локальную копию шаблона ЛО, который будет генерироваться в этом атоме.
Используется уже хорошо нам известный building_trader, который автоматически вызовет
форму торговли при отсутствии внутри ЛО армии. Так что настраивать тут ничего не нужно,
Custom Logic убираем. Переключаемся в настройки эмбриона (при нажатии кнопки
Independently появилась соответствующая кнопочка) и решаем поместить в маяк актера.
Идем в Session/Actors, выбираем в фильтре внизу All, находим локацию sunset_isle и просто
создаем правым кликом трех актеров: Маяк, Джо Грибник и Чудище Грибное. Пока что
вообще не будем редактировать этих актеров, они нам нужны для того, чтобы рассадить их
по зданиям и забыть на время. Возвращаемся к настройкам эмбриона маяка и вставляем
туда актера Маяк.
Теперь необходимо настроить сам ассортимент. Пусть у нас будет два слота юнитов с
малыми шансами на генерацию третьего. В первом слоте поселим с равной вероятностью
200-300 разбойников, 100-180 мародеров или 80-150 лучников. Во втором – пусть будут
100-200 гоблинов или 80-120 неистовых гоблинов. Третий пусть дает с вероятностью 30%
20-30 злобоглазов. Как мы помним, каждый слот нужно настроить по отдельности.
Рис. 3.13. Настройка первого слота.

Аналогично настроим второй слот, а вот с третьим немного сложнее – необходимо


создать несколько вариантов с разными весами. Фактически, нам нужны два варианта, из
которых один – пустой, с соотношениями весов 3:7 (так получается 30% вероятности).
Рис. 3.14. Настройка «плавающего» слота.

Осталось настроить свитки/предметы. Пусть здесь можно будет найти один слот с 3-5
случайных свитков 1-2 уровня и один слот со случайным предметом 1 уровня.
Получившийся полностью настроенный магазин можно увидеть на рис. 3.15. Не забудем
также добавить маяку в свойствах атома всплывающую подсказку на карте.
Рис. 3.15. Настроенный эмбрион маяка.

Теперь возьмемся за домик Джо. Тут уже одной настройкой чисел в эмбрионе не
обойдешься, нужно включить Custom Logic и отредактировать саму логику домика. Нам
необходимо, чтобы при взаимодействии с домиком появлялась не форма торговли, а диалог
с Джо. Для начала смело удаляем последние две ветки логики, которые связаны с ареной, –
драться мы с Джо не собираемся. Удаляем полностью все действия из
INTERACTION_PASSIVE_ON, однако саму ловушку оставляем. Теперь вместо действий,
которые мы в ней удалили, создаем другое – Begin dialog by current active actor. Форму
продажи уже в специальном порядке будем вызывать из диалога.
Рис. 3.16. Специальная логика для домика Джо.

Осталось настроить магазин грибника. Магазин призовой, поэтому населим его


сильными созданиями растительного происхождения. Пусть там живут 7-10 королевских
терний и один древний энт. Свитков в магазине не будет, зато будет несколько ростков энта и
грибная настойка – зелья маны. Не забудем выставить домику Джо подсказку на карте,
впрочем, сделаем то же самое еще и для нашего гигантского пня.
Теперь возьмемся за бонусы. Пусть на локации у нас будет штук шесть случайных
бонусов на основном острове и два – на маленьком. Местоположение бонусов, как мы
помним, можно задать вариациями. Также разместим на карте один случайный алтарь.
Начнем с него. Найдем в палитре (Resources/Altar) алтарь повышения атаки target (мишень).
Поставим его на карту, выберем Independently и теперь нажмем Advanced Mode. Так мы
можем создать в эмбрионе различные варианты атомов для генерации. Один у нас уже есть
в списке, это target. Кликаем на список и выбираем Add embryo, где в дереве по очереди
выбираем атомы training_dummy и absorbent_magic. Получится то, что изображено на рис.
3.17.
Рис. 3.17. Сложный эмбрион для
алтаря.

Вес вариантов у нас одинаковый, так что в игре с равной вероятностью сгенерируется
алтарь, повышающий интеллект, атаку или защиту. Вообще уже существуют такие сложные
эмбрионы для случайного алтаря, это – altar_bonus_all и altar_bonus_all_big, в них можно
залезть и посмотреть, как они устроены. Теперь расставим сами бонусы по локации. Будем
использовать как отдельные атомы класса box, так и «чистый эмбрион» – специальный атом
в папке Resources в виде желтого или красного шарика. Это – преднастроенный эмбрион с
очень большим числом вариантов генерации. Разместим таких на локации парочку. Также
закопаем под пнем клад, выставив эмбриону галочки Buried treasure и Can be digged.

Рис. 3.18. Локация с расставленными эмбрионами контейнеров.


Осталось расставить лишь армии. У нас их три. Одну настроим специально, с узкими
параметрами генерации, а две другие сделаем одинаковыми, но с большой свободой
генерации, так, чтобы в игре они были почти всегда разными. Пока у нас нет героя, который
мог бы вести в бой армию Чудища, но это не страшно: героя мы к ней прикрепим потом.
Поставим на карту армию (любую, здесь от вида атома почти ничего не зависит). Открываем
атом, нажимаем Independently и попадаем в настройку. Нам нужно создать несколько
вариантов генерации, скажем, четыре штуки. Мы рассмотрим отряд магов, вызвавших
демонов, разбойников, стаю лесных монстров и армию злобоглазы/дракончики. Создаем в
эмбрионе три дополнительных заготовки и даем им соответствующие названия.

Рис. 3.19. Эмбрион армии.

Теперь заполним эмбрион армиями. Рассмотрим для примера лишь звериную заготовку.
Сначала нужно задать полное лидерство заготовки. Определимся, какой уровень героя
соответствует такой армии. Локация у нас немного слабее, чем Алый Ветер, так что укажем
диапазон уровней 4-6, этому соответствует 216-462 лидерства. Теперь определимся с
типами юнитов. В лесу у нас могут жить волки, бурые и древние медведи, а также тернии-
охотники (как правило, нужно добавлять в армию хотя бы один стрелковый тип).
Обязательными выставим волков и медведей, обоих 20-40% от общего лидерства армии.
Оставшихся двух юнитов сделаем с типом заполнения Addition и процентами заполнения
10-30%.
Рис. 3.20. Лесная заготовка.

Аналогично настроим и другие заготовки, как именно – можно посмотреть на локации в


редакторе. Теперь, перед тем как закрывать настройку этого эмбриона, сделаем еще кое-
что: по очереди экспортируем все заготовки (выбрав Save Preset во всплывающем по
правому клику меню) в .strg-файлы. Поместим на карту вторую армию и просто по очереди
импортируем их туда. Все, у нас есть две похожих (но не одинаковых при генерации) армии.
При необходимости заготовки можно комбинировать, используя их снова и снова для
создания очень сложных в генерации армий.
Наконец, разместим на островке армию героя. Сделаем сдвоенную армию (мы уже
удостоверились, что арена позволяет ее разместить). Одну половину слепим из звероглазов
и всех видов змей, другую – из злобоглазов и всех видов пауков. Героя прилепим позже. Не
забудьте, что для слияния армии один из вариантов заготовки нужно выделить двойным
кликом мыши.
Рис. 3.21. Двойная армия.

На этом мы закончили настройку эмбрионов на локации.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >

4. Логика сессии.
В данной главе мы рассмотрим те аспекты логики, которые живут не на конкретной
локации, а в самой сессии. Такие данные в редакторе называются session internals и
сохраняются отдельно от локаций. Самый важный элемент этой логики – актер. Актер – это
игровой персонаж, контейнер для другой логики вроде диалогов и привязок к квестам.
Смысл такого контейнера в том, что мы с легкостью можем переселить актера с одной
локации на другую, и нам не придется почти ничего перенастраивать. Более того, такое
переселение мы можем делать не только статически в редакторе, но и динамически в игре.
Актеров, героев противника, диалоги, квесты и редактор предметов мы рассмотрим в
отдельных разделах главы. Здесь пока что ограничимся рассмотрением хранилища
глобальных строковых переменных.
Хранилище можно найти в главном меню по адресу Session/Texts. Там находятся
разнообразные тексты, которые можно использовать в диалоговых окнах. В отличие от
всплывающих подсказок на карте и текстов диалогов, диалоговые окна (те, что вызываются
через действие MessageBox) не поддерживают прямого ввода текста. Текст в них можно
вставлять по ссылке. А ссылка ведет как раз в хранилище строковых переменных. Когда мы
настраиваем, например, эмбрион контейнера, у нас есть возможность задать текст для
отображения в диалоговом окне, которое появляется, когда герой подбирает предмет. Для
того, чтобы сделать это правильно, нужно сначала создать в хранилище новую строковую
переменную, а потом выбрать ее в настройке эмбриона из списка. Это связано с
особенностью хранения строк в игре, да и часто одна и та же надпись используется в игре
неоднократно, и использование подобных ссылок упрощает задачу игровых текстов.

Практическая часть.

Подобно тому как мы это делали с логикой локации, сначала составим список того, что
нам нужно сделать для нашего острова:

– три актера – Джо Грибник, Чудище Грибное и Маяк;


– герой противника – Чудище Грибное;
– диалог с Джо Грибником. В диалоге должен выдаваться квест, проверяться его сдача, а
после сдачи квеста должен быть доступен магазин;
– квест на убийство Чудища Грибного. Должно быть два этапа: когда квест только
получен и когда чудище убито.

Все это будет сделано в пределах главы, однако мы еще немного доделаем квест, создав
для него движущуюся платформу.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >

4.1. Актеры и герои противника.


Для начала требуется понять, что такое актер. Актер – это описание игрового персонажа,
контейнер, в котором хранится имя, портрет персонажа, его диалоги и предметы. Все это
привязано к конкретному актеру и принадлежит ему даже при перемещении его между
различными зданиями и локациями. Один и тот же актер не может существовать в двух
разных местах, и если вы попытаетесь использовать одного актера дважды, то, во-первых,
игра выдаст предупреждение, а во-вторых – сгенерируется только один из них. Получается
что-то вроде вариаций, но в пределах всей игры, а не одной локации.
Итак, попробуем разобраться в настройках актера. Для того чтобы получить в свое
распоряжение список всех актеров в игре, необходимо выбрать пункт главного меню
Session/Actors.
Рис. 4.1. Актеры.

При этом вы увидите список локаций, к которым привязаны актеры. На самом деле эта
привязка весьма условна и нужна исключительно для вашего удобства. Режим All покажет
нам абсолютно все локации в сессии. Режим Actors покажет нам только те локации, которым
мы назначили актеров. Наконец, режим Dialogs покажет нам только те локации, на которых
есть актеры с диалогами. Выбрав в списке локацию, мы увидим список актеров в ней, а
выбрав конкретного актера – список привязанных к нему диалогов. Правым кликом на
локацию можно добавить туда нового актера, но пока рассмотрим существующего, открыв,
скажем, в локации bolo актера по имени Рейк Явик.
Рис. 4.2. Редактирование актера.

Во-первых, актеру надо дать имя. Описание нигде не используется в игре и выполняет
исключительно вспомогательную функцию. Галочка Multi instance actor очень важна – если
она включена, актеру разрешено появляться в нескольких местах в игровом мире
одновременно. Естественно, в большинстве случаев ее нужно держать отключенной. Ниже
находится список предметов актера (нужны для выдачи предметов с помощью действия
flush embryo), список его диалогов и условие, при котором над ним начинает висеть иконка
«начать квест», последнее задается через Condition editor. У Рейка Явика никаких предметов
нет, только один диалог, кликнув дважды на который, его можно отредактировать.
Портрет можно настроить кликом на поле: нужно либо ввести имя портрета самому, либо
выбрать из списка, но последнее возможно лишь в том случае, если у вас правильно
организованы папки ресурсов игры. Для того чтобы выбрать свой портрет с альфа-
прозрачностью (не квадратный), основной, необходимо поместить его в папку
\data\interface\textures\CFaces, если же необходимо, чтобы актер имел еще и квадратный
портрет с задником (для интерфейса в замке или для героя на поле боя), необходимо
дополнительно поместить таковой в папку \data\interface\textures\Faces.
С актером пока все. Нетрудно догадаться, что герои противника сделаны на основе
актеров и используют их портреты и имена. Героев противника мы можем найти, выбрав
пункт меню Session/Heros. Откроем все того же Рейка Явика. Первое поле отвечает за
актера-основу, оно обязательно. Если у нас нет никакого актера, с которым мы
разговариваем или торгуем, то придется его создать. Актеры героев лежат в локации
bolo_dungeon_1, и они все имеют минимум настроек, диалога у них нет. Поле Hint
определяет описание героя, которое выводится при наведении на его портрет в бою.
Поле Atom отвечает за атом героя на карте, определяющий его внешний вид, анимацию
и скорость перемещения. Таковой, с очевидностью, должен быть только у тех героев,
которые по карте ходят сами (а не сидят в замках), так что обязательным является лишь
условно. Дальнейшие настройки очевидны: Attack, Defense, Mana, Intellect, Level и список
доступных заклинаний не нуждаются в пояснении, в то время как ниже находится одно
интересное поле – настройка дополнительных бонусов, которые будет давать герой своим
войскам. Настройка этих свойств абсолютно идентична настройке обычных предметов, так
что в этом разделе мы ее пропустим, а более подробно она будет описана в конце главы 4.4.

Практическая часть.

Начнем с маяка. Это самый простой актер, потому что для него нужны только имя и
портрет. Хотя у нас в сессии нет портретов в открытом виде, мы сделаем небольшой трюк:
найдем среди существующих актеров маяк и будем использовать его портрет. Находим в
списке актера Большой Маяк. Название его портрета: face_house_lighthouse_02.png,
копируем его и вставляем в наш маяк. Все, у нашего актера есть лицо. Аналогичным
образом поступим с Джо и Чудищем, взяв портрет для первого у Грога Риппера с Умкаса, а
для второго – у Монстра из Бездны с Дебира.
В актере Джо нам еще нужно будет создать диалог, но мы сделаем это позже. А сейчас
создадим вражеского героя из Чудища. Открываем панель героев, выбираем Add во
всплывающем меню и попадаем в окно настройки нового героя. Сначала нужно выбрать
актера-прототип, это будет Чудище Грибное. Теперь нужно создать описание и выбрать атом
на карте (пусть это будет ah_beholder_vulgaris, так же, как и у Монстра из Бездны). Выставим
ему параметры: 6 уровень (это просто цифра, ни на что не влияет), по 3 атаки и защиты, 8
интеллекта и 70 маны. В книгу ему запишем Молнию, Меч-Призрак и Ускорение
(spell_lightning, spell_ghost_sword и spell_haste).
Теперь самое интересное – назначим ему уникальные модификаторы для войск.
Добавим всем войскам героя +15% урона магией. Для этого кликнем на поле Fight mods и
выберем Add. Появится окошко бонусов. Справа можно настроить фильтр: чтобы бонус
выдавался только союзным войскам, выбираем Check Belligerent, а в поле чуть ниже – Ally,
после чего нажимаем на Add, чтобы добавить фильтр. В поле бонусов жмем на Damage, тип
урона magical, а сам бонус – 15 в поле % of base. Теперь все юниты героя получат +15% к
урону магией. Следует отметить, что бонус этот получается умножением на 1.15 базового
магического урона. Поэтому если юнит не наносит магического урона, то и никакого бонуса
он не получит.
Рис. 4.3. Настройка героя противника.

Осталось лишь поставить монстра на карту. Открываем армию, которую мы уже для него
настроили, заходим в базовую заготовку (он выделен зеленым) и кликаем на Hero, где
выбираем Чудище Грибное. Готово.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


4.2. Диалоги.
4.2.1. Создание диалога для актера.

Диалоги можно найти в главном меню в Sessions/Dialogs.

Однако создавать диалоги


через это окошко не
рекомендуется, потому что там
они создаются без привязки к
какому-либо актеру, а это нам
нужно крайне редко (да и
неудобно при дальнейшем
редактировании). Поэтому
рекомендуем создавать диалоги
через список актеров, выбрав
актера, щелкнув на него правой
кнопкой мыши, и нажав Add. Там
же можно задать диалог актера
по умолчанию. Главный диалог
(по умолчанию) – тот, что
вызывается напрямую, например
через Action – begin dialog by
current active actor. Другие
диалоги нужно либо указывать в
action, либо предварительно
назначать их актеру, делая
базовыми. Диалогам также нужно
давать внятное «говорящее» имя,
обычно таким образом маркируют
диалоги, связанные с какими-
либо квестами.

Рис. 4.4. Диалоги сессии.

4.2.2. Редактирование диалога, двухмерное


представление.

Структура диалога в окне редактирования представляет собой блок-схему. На этой схеме


может быть три типа элементов: snap, switch и соединения. Правый клик на схеме дает
возможность создать элемент или, если клавишу мыши зажать, передвинуть всю схему.
Клавиша Home вернет окно в исходное положение или отцентрирует по стартовому
элементу.
Рис. 4.5. Двухмерное представление диалога.

Snap – основная составная часть диалога, каждый snap – это один «экран» диалога, где
есть текст, который говорит нам актер, и варианты наших ответов. Каждый вариант ответа по
умолчанию заканчивает диалог, нажав на него и проведя стрелку к другому элементу, мы
создаем связь. Самый первый элемент (это может быть как snap, так и switch), который мы
добавляем в диалог, становится стартовым, и с него диалог запускается по умолчанию, если
мы не укажем в явном виде другое.
Switch – это элемент технического характера. Он отличается тем, что, во-первых, к нему
можно привязать какое-либо действие, а во-вторых, switch может иметь несколько выходов,
из которых логикой будет выбираться лишь один. Общие свойства диалога можно
редактировать сверху: Description позволяет задать техническое описание диалога для
ясности в списке, Priority определяет приоритет диалога при использовании метода Assign
dialog to actor (см. раздел 3.2.4), галочка Important выключает «крестик» в окошке диалога,
через который его можно закрыть. Можно также выбрать актера-хозяина диалога, но мы
изначально создаем диалог уже в актере, так что трогать это не следует. Кнопки Store и
Restore отвечают, как обычно, за импорт и экспорт диалога в .strg-файл.
4.2.3. Основная логика диалога.

Итак, стартовый switch/snap помечается зеленым цветовым градиентом. Для начала


рассмотрим, что именно можно настроить в переключателе. Для этого откроем какой-нибудь
несложный диалог и попытаемся разобраться, как он устроен. Возьмем для этих целей
паломника на Дебире, который дает герою руны. Выбираем в списке актеров Паломник, у
которого есть диалог main. Кликаем дважды, чтобы перейти в редактирование диалога.
Диалог начинается с переключателя BEGIN. Кликаем на него дважды и смотрим, что здесь
можно настроить. Вверху появляется поле Techname, это техническое имя элемента. Удобно
для того чтобы маркировать стартовые элементы или те, что потом нужно будет вызывать из
других мест (например если после сражения с NPC нужно начать диалог не со стартового, а
с какого-то другого места). Чуть ниже находится поле условия самого switch/snap. Эта
настройка дублирует опции switch, который находится перед ней и не используется. Условие
определяем либо через Condition editor, либо галочками Ones per game или Ones per talk.
Первая сделает элемент активным лишь в самом первом диалоге и выключит его потом,
вторая означает, что элемент будет доступен раз за диалог. Опция Autosave сохраняет игру в
слот Autosave по завершении диалога. При использовании непосредственно перед запуском
сражения или перед сменой локации приводит к ошибкам при загрузке. Не рекомендуется
использовать.
Ниже находятся поля вариантов. Каждый вариант switch отвечает за переход на какой-то
другой элемент (можно здесь прописать вручную или связать выход switch с каким-то из
элементов, протянув мышкой стрелочку на диаграмме), а также имеет условия
существования и действия при переходе. У паломника в стартовом switch два варианта –
либо идет перенос на ветку диалога snap_5 при выполнении некоторого условия (а именно
того, что переменная piligrim_done внутри ЛО all не равна нулю. Примечание: ЛО all – это
глобальный ЛО в игре, не имеющий местоположения на карте, в котором хранится много
глобальных переменных), либо уже безусловно идет перенос на основную ветку snap_3.
Варианты перебираются по порядку: сначала проверяется нулевой «выход» switch, если
условие выполняется, то идет перенос на соответствующую ветку, если же нет, проверяется
условие следующего варианта, и так далее. Справа находятся поля, которые специфичны
уже для каждого варианта.
Поле Header override позволяет задать текст диалога, который возникнет в целевом
элементе при переходе из текущего. Например, есть snap, в котором нам говорят «Привет»,
и варианты ответа «Как дела?» и «Я пошел». «Я пошел» выводит нас из диалога, а «Как
дела?» переносит нас на тот же самый snap. Однако если на вариант «Как дела?» настроить
Header override «Отлично!», то при выборе этого варианта уже в этом же snap текст будет
«Отлично!», при этом варианты ответа останутся те же самые. Иначе говоря, Header override
перегружает заголовок (текст, который нам говорит собеседник) того snap, на который мы
перейдем.
Поле Conditions позволяет вызвать Condition editor и выбрать условие существования
варианта ответа snap/выхода switch. Ниже находятся Options, которые дают дополнительное
условие: существовать единожды за игру или единожды за диалог. В поле Actions можно
добавить любые действия, доступные в Action editor, и дополнительно пункт перехода: либо
начало/конец диалога, либо любой из локальных для диалога snap/switch, либо стартовый
элемент любого диалога в игре.
Настройки snap во многом дублируют настройки switch, разница в том, что здесь
задается текст, который нам показывают, и вариант ответа в игре мы выбираем сами, в то
время как в switch выбирается первый, для которого выполнится его условие.
Дополнительное поле слева позволяет нам ввести текст заголовка, варианты создаются
аналогично. Однако здесь Condition уже определяет то, высветится ли вариант ответа как
доступный для выбора (если условие не выполняется, то его просто не будет). Точно так же
можно завязать на вариант ответа какое-то действие и перегрузить заголовок следующего
snap. Сверху есть поле Voice, которое позволит проиграть звуковой файл при переходе
диалога в данный snap, то есть озвучить диалог. Но в игре это нигде не используется.

Рис. 4.6. Настройки snap.

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


переменной нулю приведет нас в snap_5. Там мы можем только прочитать о том, что
паломник медитирует, и покинуть диалог. Намного интереснее вариант, который перемещает
нас в snap_3: там паломник спросит нас о нелегкой судьбе. Вариант ответа номер один
закончит диалог, а второй приведет нас в snap_0, где мы выбираем то, что нам нужно. Далее
диалог ветвится снова: последний вариант ответа опять приводит к «слепому» (в том
смысле, что там не выполняется никаких действий и можно только уйти) snap_1, а вот три
других варианта дают нам по две руны. Каждый вариант выполняет некоторое выражение в
скриптовом языке (h.rune.might := h.rune.might + 2 – прибавляем 2 руны к счетчику напрямую)
и вызывает диалоговое окно, которое оповестит нас о получении бонуса, а потом переносит
нас в snap_4. На первый взгляд он настроен странно: заголовок представляет собой просто
восклицательный знак, но это потому, что каждый из трех вариантов, которые ведут в этот
snap, имеет заполненное поле Header override, содержимое которого и отобразится вместо
восклицательного знака в заголовке. Теперь идет прямой переход в финальный snap_2, где
паломник говорит, что нам пора идти, выбор единственного варианта ответа переводит в
switch_1, единственная роль которого – установка переменной piligrim_done в ЛО all
значения «1». Легко заметить, что теперь при старте диалога в BEGIN switch уже включен на
переход на snap_5, и паломник уже никогда с нами не поговорит и не даст рун, если только
эту переменную как-то не изменить.
Нужно также обратить внимание, что между теми действиями, которые дают нам руны, и
выставлением переменной в 1 есть два snap. Теоретически, если в этих snap игрок закроет
диалог крестиком (уже получив руны), то он сможет опять инициировать призовую ветку
диалога и опять получить руны. Чтобы этого избежать, для диалога выставлена галочка
Important, которая крестик запрещает. Такие ситуации необходимо отслеживать.

Немного по цветовым кодам диалогов. Стартовый элемент выделяется зеленой


градиентной окраской. Жирная стрелка означает, что по ней в целевой элемент потечет
Header override (который, кстати, может насквозь течь через switch, то есть протекать по
стрелке дальше вплоть до первого snap).
Варианты ответов на snap/switch помечаются следующим образом:
• темно-синий – конец диалога.
• зеленый – обычный вариант ответа.
• желтый – к варианту ответа привязано дополнительное условие или действие.
• оранжевый (может быть смешан с другими цветами) – один раз за диалог.
• красный – один раз за игру.

4.2.4. Изменения игрового мира через диалог и приемы


использования диалогов.

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

Стартовая фраза. Часто необходимо, чтобы при старте диалога вызывался некоторый
snap с большим количеством вариантов ответа, который бы при повторном переходе на него
из другого snap имел некоторую стандартную фразу, но при первом появлении – приветствие
от персонажа. В этом случае имеет смысл начать диалог со switch, у которого два выхода.
Оба связать с интересующим snap, но первому выставить галочку Once per talk и настроить
поле Header override, вбив туда стартовую фразу. Так приветствие появится только
единожды.

Switch-коллектор. Такие switch частенько используются, когда при переходе на snap из


разных мест нужно выполнить некоторое действие (например, записать в переменную
признак того, что мы к этой ключевой фразе пришли). У такого switch будет всего один выход
– на интересующий snap, а втекать в него диалог будет из разных мест. На выходе switch
будет настроено то самое действие, что спасет нас от необходимости настраивать его на
каждом варианте ответа, который ведет к интересующему нас snap, и уменьшит вероятность
ошибки.
Центральный snap. Это snap, в котором много вариантов ответа (просьб поговорить с
NPC на определенные темы), каждый из которых ведет обратно в этот же snap через switch-
коллектор, но с перегрузкой заголовка. Таким образом, мы фактически сидим все время в
одном snap с одними и теми же вариантами ответа, но текст заголовка постоянно меняется в
зависимости от того, какие варианты ответа мы выбираем. Также частенько варианты ответа
доступны раз за диалог, так что по мере их перебора их становится все меньше и меньше.

Action editor. Позволяет вносить какие угодно изменения в игровой мир, в частности
работать с текущим ЛО (актер, как мы помним, сидит на карте в каком-то объекте), героем
или глобальными ЛО. Можно давать герою предметы, можно заставить его драться
(необходимо сначала выставить текущему ЛО армию), можно перейти в другой диалог
текущего или другого актера, можно выполнять этапы квестов. Чаще всего используется
банальный expression, который позволяет модифицировать счетчики героя (таким образом
герою дается опыт или руны) или переменные текущего или глобального ЛО. Грамотное
использование глобальных переменных позволяет через диалоги включить/выключить
практически что угодно. Например, выставим в диалоге некоторую глобальную переменную
ЛО all по имени shop_active в положение 1. В магазине на карте в ловушку
INTERACTION_PASSIVE_ON добавим условие lu.all.var.shop_active==1. Теперь, пока мы не
доберемся до этой фразы в диалоге, магазин не будет работать. Более того, поскольку ЛО
all – глобальный, магазин вообще может находиться в другой локации. Таким же образом
через диалоги можно включать/выключать или изменять свойства практически чего угодно.

Практическая часть.

Теперь самое время сделать для Джо диалог. Идем в Session/Actors, выбираем Джо,
кликаем на него правой кнопкой мыши и выбираем Add. Диалог будет связан с квестом, так
что сразу же выставим там галочку Important, чтобы потом не иметь неприятных ситуаций с
крестиком. Теперь набросаем примерную схему диалога. Сначала поставим switch, который
либо переведет нас к приветствию (раз за игру), либо уже сразу в центральный snap. От
центрального snap в switch-коллекторе создадим пару тем для разговора, там же завяжем
его на квест. На рис. 3.14. роль стартового switch играет START, snap приветствия – greetings,
центрального snap – maintalk, а switch-коллектора – transparent (он прозрачен в том смысле,
что на нем нет никакой логики, он нужен только для удобства и читаемости).
Рис. 4.7. Начальная структура диалога.

Теперь распишем структуру подробнее. Начальных ситуаций, влияющих на варианты


заголовка основного snap, у нас будет не две, а четыре. Сохраним приветствие и
стандартную ситуацию, но добавим еще вариант, когда мы получили квест, но еще не
выполнили, и вариант после выполнения квеста. Поскольку условия проверяются по
порядку, необходимо, чтобы безусловный вариант (стандартная ситуация) был в списке
последним. Теперь сделаем в центральном snap ряд вариантов ответа с флагом Once per
talk. Пусть герой расспрашивает Джо про остров, про грибы и про грибной отвар, последним
же вариантом добавим выход из диалога. Варианты ответа будем реализовывать через
Header override. Добавим еще один вариант ответа – про успешное выполнение задания – и
вариант ответа, который переносит нас в торговую форму (Action Show form: buy_from_s), и
наконец, вариант ответа, который переносит нас в ветку получения квеста. С текстами
получится что-то вроде того, что изображено на рис. 4.8.
Рис. 4.8. Полная структура диалога.

Не забываем в ветках, связанных с квестом, использовать тег [reward], который


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

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


4.3. Квесты.
Квесты можно найти в главном меню в Session/Quests. В окне вы увидите список всех
локаций, на которых есть квесты (или, если выбрать All, вообще всех локаций).

Рис. 4.9. Список квестов сессии.

Как и актеры, квесты привязываются к локации. Также по правой кнопке мышки можно
перенести квест в другую локацию или добавить в него диалог. Последнее не
рекомендуется, потому что диалог будет создан без актера и его нужно будет затем
привязывать к актеру. Правильнее будет действовать таким образом: создать в актере
новый диалог, потом зайти в Session/Dialogs, выбрать диалог и во всплывающем меню
выбрать Assign Quest, чтобы прикрепить диалог вместе с актером к квесту. Прикрепление
диалога к квесту не обязательно, но благодаря этому мы можем:
– использовать тег [reward] в тексте диалога, который отобразит награду за квест;
– можно будет работать с диалогом из квеста, что намного удобнее при работе
непосредственно над квестом: все его диалоги собраны в одном месте и открываются для
редактирования одним кликом.
4.3.1. Редактирование квеста, двухмерное представление.

Выберем какой-нибудь квест для редактирования, например квест со сбежавшей Эрикой


на Боло. Он достаточно сложно устроен, чтобы проиллюстрировать основные возможности,
доступные при создании квестов, и в то же время, в нем несложно разобраться. Итак, логика
квеста. На двухмерном поле, как и в случае с диалогами, есть ряд элементов: лунки (chip
place), фишки (chip), переходы и клапаны (transition). По правому клику на них вызывается
меню управления текущим элементом.
Есть у квеста и ряд общих свойств, рассмотрим их. Галочка Primary Quest означает
сюжетный квест, ничего особенного, в принципе, не дает, кроме иконки с короной и
отображения первым в журнале квестов. Dialogs позволяет просмотреть список
подключенных к квесту диалогов и создать новый, привязанный к текущему квесту. Rewards
позволяет настроить награду за квест. Можно создавать несколько наград, по умолчанию
есть только золото и опыт, рассчитываемые из сложности квеста, которая задается в поле
Difficulty значением от 1 до 100 аналогично сложности локаций. Так что в самом простом
случае награда задается автоматически. Если выставлен Auto ticks в миллисекундах, то
проверка условий выполнения логических этапов квеста происходит, помимо реальных
изменений в самом квесте, еще и автоматически в начале каждого указанного периода.
Logic unit вызовет настройку логического объекта квеста, ловушки там делать нельзя (ибо
его нет на карте), зато можно создавать и хранить там переменные, такие переменные в
тексте квеста можно использовать в простой форме [varname], наподобие [reward]. Наконец,
галочка Journal отвечает за то, будет ли запись о квесте в журнале. Если она выставлена,
можно нажать кнопку Journal и попасть в текстовую часть квеста.

Рис. 4.10.
Двухмерное
представление
квеста.
В верхних полях мы задаем название и общее описание квеста, в процессе его
выполнения они не меняются (конечно, если мы не будем использовать теги вроде <gen=…
>), в поле описания рекомендуется использовать тег [reward], который выведет в описание и
награду за квест (она генерируется при старте игры, так что в момент выдачи уже будет
фиксирована), но, если по тем или иным причинам мы хотим скрыть от игрока наличие или
величину награды, можно его и не использовать. Ниже находится поле To kill, для
контрактов. Если мы выберем для него вражеского героя, то появится дополнительное поле
Done, в котором нужно ввести текст, выводимый по выполнении контракта. Контракты имеют
общую и достаточно простую структуру, пользователь вполне может изучить ее
самостоятельно. Ниже находится поле с промежуточными этапами выполнения квеста,
которые будут заноситься в журнал. В каждой строке можно ввести текст этапа и актера, по
умолчанию вам предлагается список актеров, связанных с квестом, но выбрать можно
любого. Выбранный актер (или его жилище) на карте будет помечен квестовым значком,
чтобы вы знали, кто является вашей целью на данном этапе.

Рис. 4.11.
Свойства журнала.

Теперь вернемся к общей структуре квестов. Правило очень простое: квест всегда
инициализируется из логики через действие Begin quest. Квест завершается, когда в лунке,
отмеченной ореолом, появляется фишка. Ореол может быть зеленым (квест выполнен),
красным (квест провален) или синим (игрок отказывается от квеста, и он просто удаляется из
журнала), это настраивается в поле Chip event в настройках лунки. Как фишка может
появиться в лунке? При активации квеста, при любом изменении в его логике (обычно это
удаление или размещение фишки в лунке) или при тике (если таймер активен) все фишки
пытаются продвинуться из своих лунок дальше по переходам, в направлении стрелок. Лунки
можно соединять только с клапанами, но не друг с другом, хотя если вы сделаете это, то
автоматически будет создан пустой клапан и два перехода. Соединяются переходами
элементы квеста с зажатым Shift. Пытаясь проскочить из своей лунки к следующей по
переходу, фишка натыкается на клапан. Если она может его проскочить – то она двигается
дальше, в следующую лунку, а оттуда пытается продвинуться еще дальше. Но у нас есть
клапаны, которые могут мешать передвижению фишек. Посмотрим, как это происходит.
В квесте с Эрикой в самом начале реализуется такая схема: на клапан ведут дорожки с
лунки Start и Pogovoril_s_erikoi, а из клапана – в лунку Znayu_o_probleme. В стартовой лунке,
как правило, всегда есть фишка, поэтому рассмотрим настройки клапана, из которых станет
ясно, почему же она сразу не проваливается дальше при инициализации квеста. Основная
настройка коллектора – Input Condition. Оно определяет, как клапан будет пропускать фишки
при их попадании на этот клапан. В данном случае это условие – логическое И, то есть для
открытия клапана необходимо, чтобы во всех лунках, которые в него ведут, были фишки.
Если в клапан попадает только одна фишка, то она так и останется в лунке перед клапаном
до тех пор, пока клапан не откроется – то есть в него должна попасть и вторая фишка. Мы
можем точно так же настраивать режим выхода, если из клапана ведет несколько стрелок
(при логическом И фишка падает в каждый выход, логическое ИЛИ не используется) и
дополнительное условие (вкладка Additional Condition) уже через знакомый нам Condition
editor. Кроме этого, в клапанах мы можем задать ряд действий (вкладка Actions), которые
будут выполняться каждый раз, когда клапан открывается – т.о., выполняются все условия
прохождения фишек, и они проходят через клапан.
Теперь перейдем к лункам. По сути лунка – это логический этап квеста, который игроку
не виден, и он может находиться в двух состояниях: активном (внутри лунки есть фишка) и
неактивном (лунка пуста). Попадание фишки в лунку активирует ее и выполняет следующие
действия (неважно, задержалась фишка, или проскользнула дальше):
1) завершение квеста. Через Chip event;
2) выдача награды за этот логический этап квеста. Либо добавляется к глобальной
награде за квест, либо, если выставлено Give immediately, сразу дается игроку;
3) обновление записей в журнале. Здесь нужно остановиться подробнее. Изначально все
этапы квеста находятся в состоянии Invisible и в журнале не отображаются. У них есть еще
три состояния: Completed (добавляется в журнал серым цветом, с пометкой «завершен»),
Enabled (добавлен в журнал обычным цветом) и Failed (добавлен серым цветом с пометкой
«провален»). Эти этапы нужны исключительно для пометок в журнале, чтобы помочь игроку,
и в самой игре влияют только на квестовые иконки над головами персонажей: если этап
находится в состоянии Enabled, то иконка появится над персонажем. В стартовой лунке
логично перевести в состояние Enabled хотя бы один этап квеста, иначе в журнале не будет
ни одной записи для этого задания. А уже затем на различных логических этапах задания
мы манипулируем журналом, добавляя в него записи или помечая их как выполненные (или
проваленные) этапы.
Наконец, мы можем использовать Condition editor для того, чтобы настроить пропускную
способность каждого перехода, выходящего из клапана. Для этого необходимо дважды
кликнуть по исходящему переходу левой кнопкой мыши.
Разберем наш квест более детально: лунка Znayu_o_probleme никуда не ведет, и попав в
нее фишка здесь застрянет – не забывайте, что в различных Conditions мы можем
отслеживать состояние лунок на предмет нахождения в них фишек. Дальнейшее же
продвижение квеста осуществляется через диалоги. Прочие лунки квеста тоже настроены
довольно просто: в них только идет учет текстовых этапов квеста, но не выдаются награды.
Условий пропускания на переходах нет, все клапаны настроены по умолчанию на логическое
И без дополнительного условия или действий. Для того чтобы продвинуться дальше в
понимании работы этого квеста, откроем диалог Рольфа.
4.3.2. Работа с этапами квеста в диалогах и другой
логике.

В самом начале диалога Рольфа присутствует switch, в котором есть три выхода.
Каждый срабатывает при определенном условии, но один безусловен (он проверяется
последним), а два других отслеживают состояние квеста. Они используют условие Is quest
online в Condition editor, теперь мы можем рассмотреть его внимательнее. Состояние online
означает, что квест сейчас активен и выполняется. Состояние offline означает, что квест
вообще не был взят. Следующие три условия будут отлавливать завершенные квесты по
типу завершения, а последнее – просто завершенный, неважно каким образом. Нам
интересно то, что произойдет в самом начале, поэтому выберем последний вариант
QUEST_OFF. После долгого путешествия по стрелкам квеста (многие варианты, кстати,
проверяют состояние квеста, например торговать Рольф будет только при состоянии квеста
«Завершен») попадаем в snap_4, где при действии Begin quest стартует наш квест. В этот
момент все инициализируется, и стартовая фишка зависает над первым клапаном.
Запомним это место. Теперь идем в диалог Эрики.
У Эрики тоже есть немало проверок на состояние квеста, учитывая, что сейчас он взят,
мы проходим до switch_1. Там впервые видим другой тип условия – Quest chip place. Это
условие позволяет нам проверять наличие фишки в конкретной лунке, в данном случае в
лунке prouchili_eriku. Фишки там пока нет, так что идем в другую сторону – в сторону snap_9.
Там на вариант ответа «Я говорила с твоим мужем» повешено новое действие Quest. Оно
может создать или уничтожить фишку в выбранной лунке. В данном случае оно ставит
фишку в лунку pogovorili_s_erikoi, и теперь ничто не мешает клапану под стартовой фишкой
открыться и пропустить фишку в лунку znayu_o_probleme. Это произойдет уже
автоматически. Как вариант, мы могли сразу поставить фишку в лунку znayu_o_probleme,
результат был бы совершенно одинаков для игры. Попробуем посмотреть, что будет
дальше, если мы продолжим разговор с Эрикой и вынудим ее сражаться. Очевидно, ничего.
Нас выкидывают в бой и меняют локации, никаких действий по изменению квеста не
происходит. Где же их искать? Правильно, нужно войти в ЛО дома Эрики и найти ловушку
ARENA_WIN.
Находим. Там фишка ставится в лунку prouchili_eriku и вновь открывается диалог с
актером – Эрикой. Смотрим структуру диалога, теперь по совокупности условий мы
приходим в snap_11. Там у нас есть только один вариант ответа, который рождает фишку в
«слепой» лунке palatka_zarkita (фактически, она используется как флаг, хранящий факт
нашей победы над Эрикой) и обнуляет армию внутри ЛО шатра. Нетрудно догадаться, на
что повлияет заполненная только что лунка – вновь открываем ЛО шатра и смотрим в
ловушку INTERACTION_PASSIVE_ON. Первое условие, которое раньше никогда не
выполнялось внутри действий этой ловушки, гласит, что, если квест выполнен или если
заполнена лунка palatka_zakrita (с дополнительным условием на то, что квест сейчас
выполняется), то просто вызывается диалоговое окошко с сообщением о том, что в доме
никого нет.
Наконец, заходим вновь в диалог Рольфа и смотрим, куда же мы придем при текущем
составе заполненных фишками лунок. А придем мы через switch в snap_9, где единственный
вариант ответа рождает фишку в лунке Olaf_nakazal_jenu, и теперь уже нижний клапан
открывается и фишка проваливается в лунку win_olaf, которая завершает квест. Другой
вариант развития событий, когда побеждает Эрика, остается читателю на самостоятельное
изучение. Стоит только заметить, что в тексте заголовка snap_9 используется тег [reward],
который непосредственно перед получением показывает нам награду. Похожим образом
устроены и многие другие квесты в игре.
Многие линейные квесты, однако, устроены по-другому. Для простоты в них есть только
лунки, которые заполняются фишками по ходу выполнения квеста через действия в Action
editor. Например, квест по убийству паука на Дерсу. Так делать проще, когда у квеста совсем
нет ветвления, но сделать сложный квест таким образом нельзя.

Практическая часть.

Теперь создадим квест на убийство монстра и модифицируем диалог Джо, учитывая


квестовые условия. Идем в Session/Quests, выбираем там нашу локацию и добавляем в нее
новый квест. Нам понадобятся два этапа квеста: между получением квеста и убийством
монстра и между убийством монстра и сдачей квеста. Будем использовать самую простую
схему: три лунки, стартовая, промежуточная (убийство монстра) и финальная. Создав лунки,
дадим в Journal квесту имя «Грибные дела», чтобы легче находить его в списке. Теперь
идем в Dialogs и находим там диалог Джо, который мы создали раньше. Кликаем на него и
выбираем Assign quest, где находим наш только что созданный квест. Теперь диалог
привязан к квесту.

Рис. 4.12. Структура квеста.


Займемся дополнительной настройкой квеста. Добавим награду – Experience (average) и
Money (average). В квест запишем описание и два текстовых этапа. Наконец настроим этапы
квеста по выполнению. В первой лунке будет включен лишь первый этап, во второй первый
будет выполнен, а второй включен, в третьей – оба выполнены, как и сам квест.
Как обеспечить выполнение первого этапа по убийству чудовища? Есть несколько
способов. Можно модифицировать логику эмбриона армии, в которой сидит Чудище,
добавив туда ловушку ARENA_WIN и прописав в ней действие по выполнению этапа квеста.
Мы пойдем по более простому пути: добавим на диаграмму квеста клапан и завяжем
выполнение первого этапа квеста на него (соединим с ним первую и вторую лунки). В
клапане зайдем на вкладку Additional condition, где выберем условие Army death, а источник
армии – актера Чудище Грибное. Теперь этот этап выполнится автоматически при убийстве
монстра.
Но и это еще не все. Нам осталось добавить логику в диалог. Итак, как мы помним, у нас
там есть два варианта ветвления стартовой фразы в зависимости от этапа квеста. Для
варианта ответа, завязанного на выполненный квест, выставляем условие Is quest online, где
выбираем состояние succeeded и наш квест. Для варианта ответа, завязанного на начатый,
но невыполненный квест, ставим то же самое условие, только состояние квеста уже online.
Если условия будут проверяться именно в таком порядке, все будет хорошо.
Теперь первый вариант ответа в основном snap, в котором мы сообщаем Джо об успехе.
Там необходимо добавить условие Quest chip place (full) для лунки, которая отвечает за
убийство монстра, и вместе с тем нужно, чтобы этот вариант ответа не появлялся, когда
квест уже сдан, то есть условие Quest chip place (empty) для финальной лунки. На этот
вариант ответа завяжем и действие – Quest, где выбираем наш квест, его финальную лунку
и set. Таким образом, теперь этот вариант ответа завершает квест. Вешаем условие
завершенности квеста и на вариант ответа, который приводит нас в магазин.
Осталось разобраться только с веткой диалога, которая ведет к получению квеста.
Добавляем там условие Is quest online с состоянием offline, теперь эта ветка будет доступна
только тогда, когда квест не получен. Далее эта ветка делится на две: принятие квеста и
отказ от него. К принятию прикрепляем действие Quest:Begin quest. Теперь взаимодействие
квеста и диалога полностью настроено.

СЛЕДУЮЩАЯ ПРАКТИЧЕСКАЯ ЧАСТЬ >


4.4. Редактор предметов.
В редактор предметов можно попасть, выбрав Session/Items в главном меню. Нашему
взору предстанет список всех предметов в сессии и большое количество параметров
фильтрации списка. В этом списке можно выбрать некоторый предмет и попытаться его
отредактировать или создать новый. С фильтрацией нетрудно разобраться самостоятельно,
поэтому посмотрим сейчас на редактирование самого предмета. Откроем для этого новый
или существующий предмет (лучше всего для этого подходит класс Equipment: для него
доступно больше всего настроек), в новом окне появится несколько вкладок.
Первая вкладка – General. Здесь нужно задать иконку предмета (как и для актера, на нее
нужно просто кликнуть мышью), техническое имя предмета или тег (важнейшая
характеристика, без нее предмет не существует) и ряд других показателей: раса (влияет на
генерацию), уровень (влияет на генерацию и количество кристаллов/рун при разрушении),
слот героя и принадлежность к комплекту. Можно настроить цену и максимальное
количество, которое, однако, не запретит герою поднять больше предметов, чем требуется,
– просто в случайной генерации этих предметов больше, чем указано, не будет создано.
Ничто не мешает нам, однако, сгенерировать его через On demand-эмбрион или с
игнорированием числа maxcount. Ноль означает, что таких предметов в игре может быть
неограниченное количество. Здесь же настраиваются флаги предмета: Quest запрещает его
выбросить и разрушить, Usable и Dialog включают пункты всплывающего меню
«Использовать» и «Поговорить», Moral включает счетчик морали, а Rare запрещает
случайную генерацию в магазинах, Upgrade to – новая ступень предмета при улучшении,
Army и Arena – армия и арена для улучшения или усмирения.
На вкладке 3D находятся настройки трехмерного отображения предмета. В текущей
версии игры трехмерные модели имеют только контейнеры существ, которые можно
подобрать на карте, однако это можно изменить. У атома на карте может быть
прикрепленный шаблон ЛО, если у предмета есть атом, то эта настройка, равно как и
всплывающая подсказка на карте, становится доступной.
Вкладка Labels отвечает за строковые данные. Name – имя предмета, Hint –
всплывающая подсказка (именно здесь нужно писать информацию о бонусах, автоматически
она не формируется), Information – текст, который отображается, если выбрать «Инфо» во
всплывающем меню по предмету. Три других поля нужны только для атомов с трехмерным
отображением, они отвечают за его свойства на игровой карте.
Вкладка Use Condition появляется только у тех предметов, у которых выставлена галочка
Usable. Дает возможность использовать Condition editor, чтобы создать условие
использования предмета.
Вкладка Pacify Condition появляется только у тех предметов, у которых выставлена
галочка Moral. Дает возможность создать дополнительное условие на усмирение предмета.
На вкладке Mods стоит остановиться подробнее. Эта вкладка отвечает за
модификаторы, которые предмет дает герою или войскам. Здесь есть два поля:
модификаторы героя и модификаторы войск. Модификаторы героя – его основные
параметры или счетчики, задаются в верхнем поле. Правый клик по нему вызовет форму с
двумя строчками: имя параметра и модификатор значения. Счетчики (counters) – это
лидерство, атака, защита, мана и прочие основные параметры героя, у которых всегда есть
текущее значение и предел. Выбрать параметр для модификации можно внизу (count и limit).
В поле модификатора можно выбрать значение либо в абсолютных единицах, либо в
процентах (при этом бонусы от надетых предметов учтены не будут!). Также, кроме
счетчиков, там доступны специальные параметры (Specials) – они задаются в файлах
конфигурации. Как правило, с их помощью проводится модификация лидерства существ или
параметров заклинаний. Например, с их помощью реализован бонус на лидерство темным
рыцарям или Сапоги Паломника в ЛоР.
В нижнем поле мы можем создавать простейшие фильтры, при выполнении условий
которых на войска будут накладываться бонусы, именно такое поле доступно при настройке
специальных предметов у героев противника. Правым кликом мы можем создать новый
бонус: сверху задаем один или несколько фильтров для бонуса (не забывайте для своих
юнитов выставлять belligerent=ally, иначе бонус будет распространяться на все войска на
арене). Все фильтры продублированы инвертированными – теми, которые дадут бонус всем
юнитам, кроме тех, что пройдут фильтрацию. Также многие фильтры оперируют числами, в
данном случае число может начинаться с символов < или >, что означает сравнение.
Задание нескольких значений через запятую означает логическое ИЛИ.
Виды фильтров:
Check param – параметр юнита больше, меньше или равен заданному. Доступные
параметры: race (раса, строка), leadership (лидерство юнита, число), count (количество
юнитов в стеке, число), level (уровень юнита, число);
Check unit – тэг юнита, выбираем один или несколько из списка;
Check belligerent – определяет, на чьей стороне сражается юнит. Player – игрок, вне
зависимости от того, на чьей он стороне, Ally – союзник, Enemy – враг;
Check daytime – проверка времени суток.

Также можно настроить до трех типов бонусов по видам. Первый тип – параметр юнита,
например скорость, инициатива или наличие ответного удара. Второй тип – модификация
урона, здесь выбираем тип сопротивления. Наконец, третий тип – модификация
сопротивления. На одном фильтре нельзя настроить два модификатора одного типа.
Параметры модификаторов:
Mod tag – уникальный тег модификатора. Зная тег, мы можем динамически снять его через
Lua-скрипт в бою;
Absolute – абсолютный бонус (или пенальти, если значение отрицательное);
% of base – процент от базового значения;
% of cur – процент от текущего значения;
Duration – длительность действия модификатора в раундах. Как правило, 0 (бесконечно), но
можно выставить и конечную;
DoD – снимать ли модификатор при получении юнитом урона;
Priority – приоритет модификатора, который определяет его порядок в расчетах значения.
Актуально только для тех модификаторов, которые имеют бонус к текущему значению. Чем
выше, тем позже модификатор считается, модификаторы с разным приоритетом имеют
неопределенный порядок расчетов. Этим параметром достаточно сложно управлять, так как
другой модификатор может прийти откуда угодно, и его приоритет будет неизвестен.

В бою мы можем накладывать (и снимать, если известен тег) модификаторы через


скрипты функцией Attack.act_attach_modificator(). Модификаторы урона, однако, доступны
только через предметы: функций, которые бы их накладывали, не существует.
Вкладка Events отвечает за события, которые происходят с предметом. С каждым
событием можно ассоциировать одно или несколько действий через Action editor. Можно
исполнять действия при улучшении предмета, при нажатии на пункт меню «Поговорить» и
ряде других событий.
Custom params – вкладка внутренних переменных предмета. Их можно использовать в
выражениях или скриптах, можно хранить в них разнообразные свойства предмета, которые
так или иначе изменяются со временем. Записываются в текстовом формате в виде
<parname>=<parvalue>, с разделителем – новой строкой.
Здесь рассмотрены не все свойства предметов, а только большая часть из них. У разных
классов могут отсутствовать многие из перечисленных свойств и присутствовать другие.
Например, у навигационных карт есть параметр Open map, который отвечает за то, какую
именно локацию открывает карта, у медалей – вкладка Medal condition, которая определяет
условие получения (как правило, это некоторое выражение, скомпонованное из глобальных
переменных), у компаньонов – вкладка Wife, где задается набор дополнительных слотов.
Для полного понимания картины нужно представлять себе, что такое предмет. Все предметы
сессии хранятся в файле items.txt, и у него множество подключаемых файлов настроек.
Спутники, медали, навигационные карты, специальные параметры героя, бонусы от
некоторых навыков и даже заклинания – это все предметы. Со всеми предметами в игре
можно работать с помощью Lua-библиотеки Obj и функции Logic.obj_par.

5. Дополнительные аспекты редактирования локации.

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

5.1. Монорельсовая система, платформы.

Инструмент для работы с монорельсовой системой находится во вкладке Monorail


System в панели инструментов. Для начала разберемся, что представляет собой
монорельсовая система. Как правило, мы не можем работать с реальными координатами
объекта в игровом мире. Мы можем выставить его в некоторую заданную точку, но работа с
координатами в процессе игры практически невозможна. Мы не можем узнать текущую
координату объекта в игровом мире, равно как мы и не можем дать ему задание
переместиться в какую-то другую точку с известной координатой. Да, есть инструмент,
который позволяет нам работать с путями (он описан ниже), но там задаются только
конечные или промежуточные точки маршрутов, но никак не пути – дорогу между точками
объект будет искать самостоятельно. Монорельсовая система, с другой стороны, позволяет
создавать жесткие «рельсовые» маршруты в пространстве. По сути, монорельсовая система
включает в себя три составляющих: станцию, монорельс и платформу. Станция – это точка в
пространстве, обладающая также набором вращательных степеней свободы. То есть у нее
есть три координаты и три угла поворота. Сама точка, конечно, не вращается, но эти углы
будут определять поворот платформы при нахождении на станции. Монорельс создается
соединением двух или нескольких станций в маршрут. Маршрут всегда имеет начало и
конец, хотя одна и та же станция может использоваться в нем неоднократно. Сама кривая
монорельса строится автоматически аппроксимацией – это будет наиболее гладкая кривая,
которая строго проходит через все станции. Достаточным количеством станций можно, в
теории, аппроксимировать маршрут любой сложности. И, наконец, платформа – то, что
будет двигаться по маршруту. У платформы есть два шейпа – физический шейп аналогичен
шейпу моста, в этой области платформа, как и мост, создает деформацию карты высот, но в
отличие от моста он создает проходимую область, даже если платформа стоит на
непроходимой. И логический шейп или радиус, с которым работает логика платформы и
внутри которого герой «приклеивается» к платформе во время ее движения.
Типичный сценарий действия платформы: при вхождении героя внутрь логического
шейпа платформы генерируется пользовательское событие, которое запускает движение
платформы от текущей станции к противоположной ей конечной. На время путешествия
герой намертво приклеивается к платформе (это происходит автоматически и не требует
настройки), а по прибытии на конечную станцию вновь получает свободу.
Новые станции можно добавлять клавишей Insert. Их можно двигать и вращать
аналогично атомам, а можно открыть окно свойств клавишей пробел, чтобы настроить
положение/поворот платформы вручную. Станции изначально просто висят в воздухе и
ничему не принадлежат. Для того чтобы создать новый маршрут, нужно кликнуть на панели
Routes правой клавишей мыши и выбрать Add. В этой панели будет отображен список всех
маршрутов на локации, а чуть ниже можно выбрать тип платформы на этом маршруте. В
поле ниже отобразится поле станций, входящих в маршрут. Добавить туда станцию можно,
кликнув на ней правой клавишей мыши; кривая отрисуется автоматически. Одна и та же
станция может быть частью нескольких разных маршрутов, более того, – может даже
фигурировать в одном и том же маршруте дважды. Через панель станций можно поменять
порядок станций в маршруте или удалить ненужные.
Нам, однако, необходимо, чтобы угол поворота и положение платформы на конечных
станциях маршрута были приведены в строгую стыковку с рельефом. Для этого клавишами
Home и End мы можем отобразить в редакторе платформу на начальной или конечной
станциях маршрута соответственно, чтобы посмотреть, насколько хорошо она состыкована.
Повторное нажатие на эти клавиши запустит платформу в путешествие по маршруту, что
позволит получить представление о ее поведении в игре непосредственно в редакторе.
Теперь, когда мы создали один или несколько маршрутов, необходимо привязать к ним
логику. Для этого в панели ЛО создадим новый объект (не забываем указать Scope =
Location, платформы плохо работают с глобальными ЛО). Во-первых, в какой-то момент
игры (обычно на ее старте) необходимо создать платформу на маршруте, а во-вторых,
обеспечить какие-то условия, при которых она начнет двигаться. Для всех этих целей служит
действие Platform management.
Внутри этого действия доступно шесть разных вариантов:

Spawn platform – создает на выбранной станции платформу (тип выбирается по типу,


данному станции или маршруту) с уникальным именем. Spawn uniq отвечает за то, что
вторую платформу с таким же именем создать нельзя. В начале игры на монорельсе
платформ нет, поэтому их обязательно нужно создавать этим действием;
Kill platform – убивает платформу с определенным именем или на определенной
станции, или, если выбраны оба условия, платформу с определенным именем только в том
случае, если в момент срабатывания ловушки платформа находится на заданной станции;
Kick platform to station – запускает платформу с заданным именем на заданную
станцию. Если станцию не указать, то платформа поедет на противоположную конечную
станцию маршрута. По желанию можно указать состояние, которое будет у платформы при
движении (обычно onmyway), Speed отвечает за скорость движения платформы. При
принадлежности одной станции нескольким монорельсам она будет выбирать путь сама, так
что необходимо точно задавать станцию, если конечных станций несколько;
Change state – меняет состояние платформы;
Subscribe for event – в выбранном ЛО будет возникать пользовательское событие,
которое можно будет отловить ловушкой CUSTOM_EVENT. Событие будет возникать при
выполнении некоторых условий на определенной платформе и/или станции, которые
задаются галочками ниже: отправка платформы, прибытие, вход или выход кого-нибудь в
физический или логический радиусы. Галочка Automatic unsubscribe отвечает за то, что при
однократной генерации события оно больше не будет возникать, по крайней мере через эту
конкретную подписку. Чуть ниже мы задаем тип события, для платформ в подавляющем
большинстве случаев используется Special Command #1, а событие генерируется в том же
ЛО, в котором запускается действие Platform management, но теоретически возможно
создавать и иные схемы;
Unsubscribe – все подписки выбранного ЛО на события, связанные с выбранной
платформой, будут отменены.

Помимо того, что платформа – это особенный мост, она еще обладает свойствами
multistate-атома, то есть имеет состояния. Состояния отвечают только за анимацию, и на
конечных станциях маршрутов можно настраивать состояние по умолчанию.

5.2. Пути патрулирования армий.

Пути настраиваются через инструмент Paths в панели инструментов. Логика проста: мы


создаем путь независимо от того, кто будет его использовать, а потом привязываем его к
одному или нескольким активным объектам, как правило армиям или NPC. Кнопка Show all
paths покажет все пути на карте, иначе будет отображаться только выбранный путь. Список
путей находится в верхнем поле, там же можно создать новый, кликнув правой кнопкой
мыши и выбрав New path, а в поле внизу отображаются уже точки текущего пути. Создадим
новый путь. Добавлять на карту новые точки мы можем кнопкой Insert. Нажав Insert снова,
мы создадим новую точку, связанную стрелкой с предыдущей, и так далее. Повторное
нажатие J на точке, которая уже связана с выбранной, изменит тип стрелки на
одностороннюю, кнопкой U стрелку можно удалить. Таким образом мы создадим сеть
маршрутов одного пути патрулирования. При попадании в точку персонаж выберет
случайным образом следующее направление движения из доступных, если только ему не
приказать поступать иначе (например, с помощью односторонних стрелок мы можем
заставить его ходить по кругу). Также по прибытии юнита на точку ему с некоторой
вероятностью может быть выдано указание исполнить сценарий.
Настроить конкретную точку и исполнение сценариев на ней можно, выбрав ее и нажав
на пробел. Реально используется только одна настройка – scenario, хотя в потенциале
можно использовать и notifications. Самый часто используемый сценарий – ожидание. Когда
юнит приходит на такую точку, он не идет дальше, а встает и начинает оглядываться по
сторонам – проигрывается анимация idle. Например, выбираем сценарий Armies/Stop/Time 5.
В этом случае юнит подождет на точке пять секунд. Можно выставить вероятность
выполнения сценария и поворот юнита, тогда на точке появится фиолетовая стрелочка. Это
будет означать, что, перед тем как подождать, персонаж повернется в выбранном
направлении. Сценарии можно использовать и другие, например запускать анимации
персонажа или что-нибудь еще.
Теперь об управлении. Мы уже выяснили, что создавать и удалять связь между точками
можно кнопками J и U. Зажатой левой клавишей мыши можно перемещать точку, если же
зажать Shift, то будет меняться радиус преследования для армии (работает, только если для
пути выставлена галочка Сustom chase radius). Клик на точке с зажатым Ctrl изменит
вероятность исполнения на ней сценария, с Alt – тип сценария (используются только
сценарии ожидания с разным временем). Наконец, движение мыши с зажатыми Shift, Ctrl и
левой кнопкой будет вращать фиолетовую стрелку, отвечающую за направление поворота
армии в точке.
Теперь, когда путь создан и полностью настроен, осталось привязать его к объекту. У
всех объектов, имеющих способность к передвижению, в ЛО есть переменная path. Там мы
можем ввести вручную или выбрать из списка путь для использования. Можно использовать
один и тот же путь для нескольких армий.

5.3. Поверхность для полета.

Перейти в режим редактирования поверхности для полета можно, выбрав инструмент


Flight surface в панели инструментов. Кнопка Enable включает режим, поле Factor позволяет
выбрать количество вершин поверхности на единицу площади, а Grid – режим отображения
сетки для удобства. Каждую из вершин поверхности можно поднимать или опускать мышкой
таким образом, чтобы при полете герой не врезался в деревья или элементы ландшафта.
Необходимо следить только за тем, чтобы поверхность была достаточно гладкой и не было
резких перепадов высот. Кнопки чуть ниже ответственны за то, чтобы
передвинуть/деформировать всю поверхность целиком.

Практическая часть.
Начнем с плота–платформы. Создадим две-три станции прямо над водой в районе
пролива, так, чтобы две из них были у берегов. Создадим новый маршрут Route_0 и
добавим эти станции в него по порядку. Теперь нужно выбрать тип платформы на маршруте,
выбираем raft_platform (плот). Теперь нужно выставить точкам высоту и ориентацию таким
образом, чтобы плот оказался в воде наполовину, а весло его не погружалось в землю на
конечных станциях. Для этого нам очень пригодятся кнопки Home и End, которыми мы можем
создавать плот на конечных станциях, и двигать его по маршруту. В завершение
формирования маршрута необходимо еще раз проверить карту проходимости. Хотя
платформа создает под собой область проходимости, нужно проверить, что с нее нельзя
никуда свалиться, пока она не запущена, и то, что на нее достаточно просто пройти.
Рис. 5.1. Настройка монорельса.

Мы создали монорельс, но еще не присвоили ему никакой логики. При начале игры на
нем даже не будет платформы. Это можно и нужно исправить, для этих целей мы идем в
инструмент Logic Units и создаем там новый ЛО. Назовем его lu_raft и обязательно выставим
Scope = Location. В этом ЛО мы будем хранить логику поведения платформы и переменную,
которая будет отвечать за то, что эта логика включена. Создадим переменную в списке,
назовем ее power и инициализируем со значением 0.
Теперь необходимо настроить ловушки в созданном ЛО. Для начала нужно создать
платформу на монорельсе, это можно сделать на старте игры через ловушку START_GAME.
Выберем в качестве действия Platform management и внутри него выберем Spawn platform. В
нашем случае нужно создать одну платформу (назовем ее raft) на конечной станции, которая
находится у берега основного острова. Spawn uniq не имеет значения, мы не собираемся
создавать другие платформы. Теперь нужно подписать ЛО платформы на событие. Выберем
опять Platform management, но уже Subscribe for event. Введем в качестве имени платформы
raft, а в качестве условия – Anyone in adhesion radius, ЛО оставим self, а событие – Special
Command #1. Теперь при попадании кого-либо в радиус адгезии платформа сгенерирует
внутри ЛО событие Special Command #1, которое мы и отловим ловушкой.
Создадим теперь ловушку CUSTOM_EVENT, в ORC которой выберем тип события –
Special Command #1. Выбираем опять Platform management, имя платформы – raft, а само
действие – Kick platform to station. Больше ничего вводить не надо, платформа отправится
на противоположную станцию. Теперь логика плота почти полностью готова, однако
осталась маленькая загвоздка: нам нужно, чтобы платформа не работала до того, как герой
не получит квест. Добавим в ORC CUSTOM_EVENT дополнительное условие (сначала
кликнув на основное условие ORC и выбрав Complicate) – Expression. Запишем там
выражение [a]==1, а внизу расшифруем, что a – это lu.self.var.power (то есть переменная
power самого ЛО). Теперь движение платформы начнется только в том случае, если
переменная power равна 1. Где мы ее изменяем? Откроем снова диалог Джо и находим тот
вариант ответа, на котором мы получаем квест. Там же создаем второе действие –
Expression. Пишем в нем [a]:=1, в качестве a выбираем Logic unit variable -> Specific -> lu_raft
(так называется ЛО, который мы создавали для платформы). В списке должна появиться
переменная power, ее и выбираем. Теперь при получении квеста она становится равной
единице, что нам и надо: это создает достаточное условие для того, чтобы до получения
квеста она не работала.

Рис. 5.2. Полная логика платформы.

Осталось сделать пути для армий. Нам нужно всего два пути, для каждого из которых
хватит двух точек. Нужно создать пути, в их рамках создать по две точки и на каждой
выставить 100% исполнение сценария Stop 5 с поворотом армии. Угол поворота задать к
центру острова. Тогда в каждой финальной точке монстр будет смотреть на игрока и будет
выжидать по пять секунд, прежде чем двигаться дальше.
Рис. 5.3. Настройка пути.

Осталось лишь привязать эти пути к нашим армиям. Заходим в настройки атома –
Variables. Там есть переменная path (у всех армий). Кликаем на нее дважды и получаем
возможность выбрать путь из списка. Вот, в общем-то, и все.

Теперь осталось только снять мини-карту, убрать тестовый атом героя и не забыть снова
прописать в session.txt параметр start=darion_1, который вернет нормальное течение игры.
Наша локация полностью готова, теперь на ней можно смело играть!

6. Редактирование арен.
Итак, во-первых, арена – это почти обыкновенная локация в терминах игры.
Обыкновенная потому, что для нее действуют те же самые правила создания, что и для
обычной – на ней нужно создать рельеф, раскрасить ее текстурой и расставить объекты,
сделать освещение, воду (если в ней есть необходимость), настроить небо и задать список
треков (playlist). Однако у такой локации несколько иная логика: например, в ней нет ЛО и
нет логических карт ландшафта, нет карт для полета. Вместе с тем у нее появляется ряд
дополнительных свойств, которые мы и рассмотрим. Одно из различий: у арены нет карты
высот для логических объектов и бойцов. Есть уровень сетки, и на этом уровне стоят
абсолютно все боевые единицы и pawn, боевая поверхность арены всегда будет плоской.
Лишь на внешней части поля боя, за пределами сетки, можно манипулировать рельефом.
расставлять как угодно статичные и динамические объекты и прочее. Еще одно замечание:
непосредственно на поле боя, как правило, не используются обычные статичные объекты.
Вместо них используются атомы другой группы, те, у которых в свойствах align стоит
chessboard. Они специально предназначены для размещения в заданном количестве гексов,
и ориентированы для поворотов на арене – по сторонам гексов. На арене отсутствует и
проходимость в ее обычном понимании. Проходимость ландшафта или объектов на арене
не действует, есть только проходимость клеток.

6.1. Дополнительные свойства арены как локации.

Сначала рассмотрим те свойства арены, которые появляются в Location/Properties в


главном меню. В самом верху есть поля, ответственные за Lua-скрипты, которые
рассчитывают повреждения на арене и бонус после боя, который получает герой.
Изначально в этих полях стоят apply_damage и calc_bonus соответственно, оба эти скрипта
можно найти в arena.lua. При желании можно вместо них для данной арены использовать
другие. Следом идут поля, которые исполняют заклинания на арене. Так, Start spell –
заклинание, которое выполнится в самом начале сражения (после скрипта on_round_start), а
Each turn spell будет выполняться после каждого хода каждого существа, аналогично скрипту
subturn_modificators. Нужно заметить, что это – именно заклинания, то есть они должны быть
прописаны в items.txt или в подключаемых к нему через include файлах, а реальный
исполняемый скрипт будет задаваться в поле script_attack этих заклинаний.
Random objects – настройки появляющихся на арене активных объектов. В зависимости
от случайного фактора на арене может возникнуть один или несколько алтарей, сундуков
или просто непроходимых гексов с каким-нибудь камнем или пнем. Мы можем настроить
группу объектов, которые могут появиться на арене (так, очевидно, что в группу
pawn_human, ответственную за рождение алтарей на аренах человечких земель, не входит
вулкан), максимальное количество объектов данного типа и вероятность появления каждого
объекта на поле боя. Следует заметить, что такие объекты рождаются только в специально
маркированных клетках, так что, если таких клеток на поле нет, можно выставить хоть сто
сундуков для генерации, все равно ни один не появится. Это, однако, можно настроить в
редакторе сетки, и об этом ниже.
В поле Logic bits мы можем выбрать характеристики арены. От этих характеристик
зависит, будут ли юниты считать арену, например, подземной, и получать соответствующие
бонусы. Поле Cell highlight preset определяет цвет окантовки гексов, поле Arena type –
используемая по умолчанию основная камера. В поле Sickness camera можно настроить
качку для арен на кораблях (работает только первый вариант из всплывающего списка,
второй – тестовый). В поле Return location мы можем настроить телепорт, из которого выйдет
герой по окончании боя. По умолчанию герой оказывается там же, где бой и начался, но
можно принудительно перебросить его в другое место. Доступны телепорты только открытых
в данный момент в редакторе локаций. Наконец, галочка Disable rage spirits выключает
дракончика/духов ярости в сражениях с, например, боссами, а Total defeat запрещает герою
после поражения возрождаться – поражение приведет к проигрышу.
6.2. Настройка гексагональной сетки.

При редактировании арены в панели инструментов появляется пункт Arena, недоступный


для других локаций. Там можно включить нестандартную камеру, двигать или вращать сетку
(при включенном режиме Move arena) по локации и вызвать редактор гексагональной сетки,
рассмотрением которого мы сейчас и займемся. Также этот редактор можно вызвать и из
Location/Board в главном меню.

Рис. 6.1. Настройка сетки.

Слева находится список заготовок. В этом списке можно выбрать заготовку арены из
библиотеки или из других арен и скопировать в текущую арену (Move to current). Справа
находится собственно поле редактирования арены, а снизу задается режим редактирования.
Во всех режимах левый клик добавляет или убирает клетку, правый – вызывает
всплывающее меню. Двигать поле можно при зажатой средней кнопке мыши, а
масштабирование происходит автоматически.
Entity – наиболее важный режим. Здесь показывается проходимость каждого гекса
(внутри него есть серый шестиугольник), которую можно менять клавишей U. Есть четыре
типа проходимости – полный, только для летающих, для летающих/парящих и полностью
непроходимый. Зачем гексу нужна полная непроходимость, ведь мы можем просто не
создавать этот гекс вообще? Ну, во-первых, на таких гексах стоят духи ярости и дракончик.
Во-вторых, при существовании гекса мы уже через скрипт можем менять его проходимость в
процессе боя. Так что в начале боя один гекс будет непроходимым, а потом станет
проходимым, нужно только знать его (об этом ниже). Далее, на гексе мы можем выставить
место под рождение отряда героя или противника. У героя может быть до пяти таких мест, у
противника – целых десять. Направление такого гекса (при появлении юнит будет смотреть в
эту сторону) задается клавишами [ и ]. Также нажатием клавиши B мы можем сделать клетку
кандидатом на рождение сундука, P – улья или алтаря, а O – препятствия. Для таких клеток
тоже можно задать направление. Наконец, во всплывающем меню есть еще два пункта,
которые не продублированы горячими клавишами: Empty очистит клетку от всякой логики, а
Spirit сделает ее точкой рождения духов ярости/дракончика. Следует заметить, что для
дракончика есть некоторый стандарт разметки (три непроходимых гекса сверху арены, в
самом верхнем сидит питомец), который необходимо подсмотреть в других аренах и
использовать в своих. Обусловлено это размерами самого дракончика и необходимым для
его маневров пространством.
Camera – настройки «кинематографической» камеры (не будет работать, если игрок ее
отключил или поставил ускоренные анимации). На поле боя таковых четыре штуки, здесь мы
размечаем то, какая из них будет использоваться для отображения эффектных событий в
этом гексе. Обычно сторона игрока использует первую камеру, сторона противника – вторую.
Духи ярости и верхняя часть поля боя используют третью, а все остальное – нулевую.
Boss – позволяет придать клетке дополнительное свойство, которое потом можно из нее
выбрать Lua-функцией Attack.bosscellid(cellunit). По правому клику клетке можно выставить
тип идентификатора босса. В клетку запишется число, и функция возвращает именно его.
Можно использовать эти идентификаторы и не в сражениях с боссами, просто для того,
чтобы как-то маркировать клетки на арене для использования в скриптах. Естественно,
можно одинаково маркировать несколько клеток.
Uids – режим изменения уникальных идентификаторов клеток. Каждая клетка на арене
имеет свой уникальный номер, от нуля до количества клеток за вычетом единицы. Эти
идентификаторы нужны только для того, чтобы по номеру клетки узнать ее местоположение.
Чаще всего просто используется итерация по клеткам вроде:
for i=0,Attack.cell_count()-1 do – возвращает число клеток на арене и перебирает их по
очереди
local cell = Attack.cell_get(i) – возвращает cellunit по ID клетки
<какие-то действия>
end
Однако можно теоретически использовать номера клеток и в других целях, расставляя их
самостоятельно и группируя каким-нибудь образом. Кнопкой Z можно выставить нулевую
клетку (с ID=0, она выделена желтым цветом), единственный ее реальный смысл – на нее
смотрит камера.

6.3. Настройка камеры.

Мы можем настроить специальную камеру для арены, выбрав Custom Camera в режиме
Arena в панели инструментов. Store запоминает текущее положение камеры, а Restore
camera загружает ранее сохраненное положение. Кнопкой Edit camera можно настроить
положение и параметры управления камерой вручную. Откроем этой кнопкой окно настройки
камеры. Load и Save, как и во многих других окнах редактора, отвечают за
импорт/экспорт .strg-файлов, Load default загрузит камеру по умолчанию. Можно
редактировать камеру, глядя на нее «со стороны», а можно и глядя из нее, как будто вы
находитесь в игре, для этого нужно нажать кнопку Define camera. В этом режиме
игнорируются настройки камеры редактора и все горячие клавиши для управления ей
действуют, как будто вы находитесь в игре. Look at bounds определяют максимальное
возможное смещение камеры по горизонтальным осям. Movement speed ответственна за
скорость движения камеры по осям.
Камера «висит» над ареной и по умолчанию направлена на нулевой гекс. Мы управляем
положением камеры (x, y, z) и углами ее поворота (pitch – наклон камеры относительно
плоскости арены, yaw – поворот камеры влево-вправо относительно своей виртуальной
оси). Также мы задаем дистанцию от плоскости камеры до плоскости арены.
Группа параметров Camera preset отвечает за текущее положение камеры в режиме
Define camera – в тестовом режиме. Кнопку Apply необходимо нажимать при редактировании
любых параметров камеры, выключив режим Define camera. В группе параметров Initials
задаются начальные параметры камеры: FOV (Field of view) определяет угол обзора камеры.
Увеличение этого параметра, во-первых, чисто визуально отдалит камеру от арены, во-
вторых, усилит эффект перспективы. Pitch и Yaw – углы, на которые будет повернута камера
в начале боя. Dist to center – стартовая дистанция камеры от плоскости арены. В группе
параметров Limits мы, соответственно, настраиваем пределы изменения вышеуказанных
параметров во время игры. Все углы настраиваются в градусах, однако в поле Camera
preset они отображаются в радианах. Расстояния – в условных метрах. Рост рыцаря на
арене – примерно два условных игровых метра, размер маленького тайла ландшафта –
один условный метр.

6.4. Специфичные для арен группы атомов.

На аренах существует ряд атомов, которые сделаны специально для них. В папке Arena/
Decorations можно найти статичные атомы для арен, у которых удобные для размещения на
гексах размеры и прописана привязка align=chessboard, которая автоматически выставляет
атом в центр гекса на арене и выдает ему угол поворота, кратный 60 градусам. Такие же
атомы входят в группы декораций, которые могут автоматически появиться на арене в
гексах, помеченных как Obstacle (Препятствия). На аренах допускается использовать и
динамические атомы, и любые другие, которые не обладают логикой, например, bridge или
land. Объекты с логикой, в принципе, можно выставлять на арену, но логический объект
внутри них нельзя настраивать. Для надежности лучше всего для таких объектов делать
копии и менять им класс на dynamic. Взаимодействовать с ними все равно нельзя, но так мы
избежим возможных ошибок. Например, таким образом сделаны «зрители» на арене Генома
на Рехау.
Следующий класс объектов – chesspiece. Это – войска. Войска (да и любые другие
недекоративные объекты) не стоит выставлять на арену вручную: они в бою появятся сами.
В крайнем случае, их всегда можно дополнительно создать функцией Attack.act_spawn.
Общие свойства chesspiece как бойцов и доступные свойства атак можно найти в
приложениях.
Наконец, последний тип атомов, который необходимо рассмотреть, – pawn. В отличие от
chesspiece, у них может не быть почти никаких свойств и они всегда ставятся на арене в
единственном числе, а не как отряды. Поведение таких объектов полностью настраивается
через скрипты, и такие атомы можно, а порой и нужно выставлять на арену прямо в
редакторе, – в частности, так выставлены боссы. В библиотеке есть все игровые pawns,
которые уже настроены, кроме, разве что, боссов – для них просто нужно назначить гексам
boss-id.
7. Взаимодействие с игрой.
Теперь, когда мы уже обсудили все возможности самого редактора, необходимо
выяснить, как же использовать созданный нами контент в самой игре.

7.1. Структура папок сессии. Методы распространения.

Как уже было сказано в самом начале руководства, сессия – это, по сути, папка-
хранилище. Там находится важный файл session.txt, в котором хранится, в частности,
структура локаций сессии и все необходимые для работы новые и измененные данные.
Данные разделены по папкам и файлам:

Actors – там хранятся актеры по номерам. Номер актера уникален, но из него, к


сожалению, нельзя изъять имя;
Chats – специфичные для сессии файлы диалогов. Редактор сохраняет сюда
измененные файлы диалогов и те, что мы создаем сами. Ситуация аналогична ситуации с
актерами, так что восстановить диалог из его номера весьма проблематично;
Config – в этой папке содержатся конфигурационные файлы, хранящие всевозможные
параметры, настройки объектов и так далее. Также здесь лежит файл lulib.strg (библиотека
шаблонов ЛО) и файл embryos.txt, отвечающий за эмбрионы сессии;
Heros – папка с героями противника;
Images – всякие картинки. Можно класть сюда иконки предметов, заклинаний, задники
для замков, мини-карты и даже элементы интерфейса;
Localization – папка с файлами, в которых хранятся игровые тексты: диалоги и квесты,
описания атомов на карте, всплывающие подсказки и прочее;
Locations – здесь в отдельных папках хранятся все локации. Каждая локация состоит из
ряда элементов, которые не поддаются редактированию, но лежат отдельно. В файлах
типа .loc хранятся данные об объектах и других элементах локации, вычисляются по
названию. Особняком стоит файл tex_<locationname>.stream – это сжатая текстура
поверхности ландшафта на всей локации. Она очень хорошо оптимизирована и сжата,
поэтому восстановлению текстура из нее не подлежит, для редактирования необходимо
иметь исходник из sourcemedia;
Lus – все логические объекты в сессии, которые не были созданы автоматически при
постановке на карту атомов. ЛО, которые жестко связаны с атомами, лежат в локациях в
<locname>.lus.loc;
Quests – все квесты в сессии;
Lutree.strg – данные о дереве логических объектов сессии;
Properties.txt – данные о «внешних» свойствах сессии, ее название и т.п.;
Session.txt – данные о внутренней структуре сессии.

В принципе, любой из этих файлов можно двигать в пределах папки сессии как угодно, и
он все равно будет использоваться, так же можно создавать и свои вложенные папки –
данные будут считываться по-прежнему. Сессия также допускает упаковку в .kfs (необходимо
сделать .zip или .rar архив и поменять расширение вручную) и будет читаться из архива.
Распространение дополнения в этом виде, наверное, наиболее логично.

7.2. Редактирование session.txt, properties.txt и других


важных для сессии текстовых файлов.

Начнем с properties.txt. В этом файле содержатся название и описание сессии, а также


список исключений (помечает данные, которые имеют отношение к сессии). Это название и
описание сессии будет высвечиваться в главном меню при выборе дополнительной
кампании для игры. Также там будет высвечиваться картинка сессии, которая так и
называется: <sessionname>.png. В качестве нее вы можете использовать любую картинку.
Второй важный для сессии файл – собственно, session.txt. В этом файле сначала идет
список категорий локаций внутри сессии (cats). Можно свободно добавлять новые категории,
главное – не менять старые. Следующий список в файле – maps. Это – самый важный
список, он определяет набор локаций в сессии. Фактически, для того, чтобы добавить
локацию в сессию (чтобы ее можно было использовать в логике), нужно внести ее в этот
список в виде «<location_name>=». При создании локации это случится автоматически,
однако если необходимо подключить локацию из другой сессии, действовать нужно именно
так. После знака равенства можно написать еще и номер категории, чтобы она сразу
записалась туда. Это позволит организовать список локаций в редакторе. Записать локацию
в категорию через редактор уже нельзя, только через этот файл (естественно, редактор в
этот момент должен быть выключен или хотя бы должен работать с другой сессией).
Аналогично прописываются арены и их категории (точнее, арены используют общий список
категорий, но список самих арен задается отдельно – arenas). Далее можно настроить
список пещер: локации такого типа (если они имеют номер в списке) будут отображаться в
редакторе как имеющие пещеру, с плюсом. Ну и, наконец, autoload отвечает за то, что
указанная здесь локация при открытии сессии в редакторе загрузится автоматически, а start
– стартовая локация сессии (не забудьте поставить на эту локацию атом героя).
В нашей сессии могут быть и другие файлы, которые не создаются редактором
автоматически. Формат их, в общем-то, похож, так что мы рассмотрим их вскользь.
playlists.txt (переносим из data.kfs) – файл, отвечающий за плейлисты музыки, формат
файла описан внутри. sound_tables.txt (sounds.kfs) – это таблица звуков, внутри которой
лежат ссылки на .csv(comma separated values)-файлы с таблицами всех звуковых файлов в
игре. Для того чтобы использовать звуки/музыку в игре (например, как аттачменты), звуки
должны быть там прописаны. config.txt (ses.kfs) – набор разнообразных констант, которые
читаются как из кода, так и из Lua через функцию Game.Config. Его включениями являются
также arena.txt, logic.txt и несколько других файлов. Все текстовые файлы в игре
поддерживают синтаксис включения, например “==this.txt” означает “вставить в это место
содержимое файла this.txt”. Ну и напоследок важным файлом является items.txt: там
хранятся все-все предметы сессии, включая и заклинания. Очень многие вещи в игре
реализованы как предмет или заклинание (например, свойства специальных арен), так что
ручное редактирование этого файла почти обязательно.

7.3. Интеграция в глобальную карту.

Перед нами стоит две задачи. Первая: как сделать так, чтобы у локации вообще была
карта и чтобы ее можно было вызвать через глобальную карту. Вторая: как сделать так,
чтобы можно было найти навигационные карты локации и реализовать быстрое
путешествие. Остановимся на второй задаче. Каждая навигационная карта, как атом, имеет
тип map и простейшую логику при подборе, аналогичную логике контейнера. Собственно,
карта – это и есть контейнер, она выдает через эмбрион игроку специальный предмет типа
map, который в редакторе предметов имеет дополнительную настройку – открываемую
карту. Таким образом, самое важное – именно открываемая карта. Для того, чтобы на
локацию можно было быстро переместиться на лодке, на ней должен быть портал с тегом
travel_<locname>. Например, для путешествия в локацию Элона нужно найти атом
map_elona, в эмбрионе которого выдается предмет om_elona, в свойствах которого задан
один-единственный параметр – Open map = elona. На самой локации есть портал в море с
тегом travel_elona, который позволяет путешествовать в локацию. Логика, которая вместо
существующей карты выдает нам свиток магии странствий, зашита в коде для этого класса
атома/предмета, и ничего настраивать не нужно.
Это была та часть работы, которую можно сделать в редакторе. Вторую часть можно
сделать, только редактируя файлы сессии вручную. За облака на карте отвечает файл
clouds_editor.txt, туда нужно записать свою локацию. Нужно создать и отредактировать по
образу и подобию существующих ui-файлы интерфейсов. Например, для Элоны это будут
map_elona.ui и map_elona_clouds.ui. Осталось сделать иконку для глобальной карты и
интегрировать ее. За это отвечает раздел bigmaps в файле config.txt.

7.4. Загрузка сессии в игре.

Если у вас в папке sessions находится хотя бы одна пользовательская сессия, то в


главном меню игры появится дополнительное меню, через которое можно подключить
любую из имеющихся сессий, называемых в игре кампаниями. Одновременно может быть
активна только одна из них, и файлы сохранений индивидуальны для каждой из сессий и не
будут видны из других кампаний. Через это же меню кампаний можно вернуться в
оригинальную Принцессу в Доспехах. Можно загрузить выбранную сессию через все тот же
app.ini – с ключом session прописывается основная сессия, с ключом sessionadd –
дополнительная. Нас интересует именно дополнительная. Все, выбрав сессию таким
образом и сделав ее активной, мы уже готовы к игре!
8. Приложения.

8.1. Редактор аттачментов.

Каждый атом в игре может иметь прикрепленные к нему объекты: другие атомы,
спецэффекты, источники света или звуки. Например, пламя, которое горит в глазах импа,
или его хихикание на поле боя – это прикрепленные объекты, или аттачменты. В редакторе
есть средство добавления и настройки этих самых аттачментов. Доступен этот инструмент
через пункт Attachments во всплывающем меню по правому клику на атоме в списке
(необходимо, чтобы опция atoms_editable в editor.ini была включена). Рассмотрим вкратце
возможности редактора, открыв редактор аттачментов для армии – мечника.

Рис. 8.1. Редактор аттачментов.

Слева показана модель, а внизу – опции отображения. Мы можем проиграть конкретную


анимацию, выбрав ее из списка. Для того, чтобы запустить анимацию и эффекты, нужно
нажать кнопку Play. Здесь же можно отключить отображение сетки и координатных осей.
Кнопкой Make Thumb мы можем сохранить текущее изображение из окна предпросмотра в
иконку выбранного атома, а с помощью Write AVI – записать видео с анимацией. Наконец,
целый ряд аттачментов отображается только в определенных условиях: на определенной
поверхности или в логическом состоянии атома, кнопками Logic State и Surface Type можно
выставить конкретные условия и посмотреть, как поведут себя наши аттачменты.
Краеугольным камнем аттачментов является понятие Attach Point – точки привязки.
Кликнув на поле Attach Points, мы можем создать новую точку. Почти все модели персонажей
в King’s Bounty используют скелетную анимацию. Соответственно, мы можем прикреплять
объекты не только в системе координат атома, но и к самому скелету – тогда аттачменты
будут двигаться вместе с моделью при анимации. Не у всех моделей, однако, заданы такие
точки прикрепления, но именно так сделаны горящие руки и глаза импа: пламя всегда
остается у руки, где бы сама рука относительно нуля координат не находилась. У скелетных
точек прикрепления вообще нет никаких настроек, у обычных – настройки положения и
ориентации в координатах атома.
Выбрав точку прикрепления, мы уже можем настроить сам аттачмент. При его выборе
помимо вкладки Main появляются еще несколько. Вкладка Common – условия отображения.
Можно выбрать время суток, специфическую анимацию, логическое состояние (например,
над мечником в разных состояниях может висеть целый ряд иконок) или тип поверхности, на
котором будет отображаться аттачмент. Кнопка Spec позволяет дополнительно настроить
положение конкретного аттачмента уже относительно точки прикрепления. Следующая
вкладка – настройки, присущие разным типам прикрепляемых объектов.
Список доступных объектов:

particle – частицы. Типичный пример – анимация портала между локациями или


обычное пламя;
omni – omni-источник света. Настройки абсолютно идентичны настройкам обычного
omni-источника (см. 2.5.4);
mesh – любая модель в формате .bms или .bma, однако она не будет анимироваться;
sound – звук, прописанный в таблице звуковых файлов sounds.csv;
aspawn – при переходе атома в состояние, для которого определен такой аттачмент, в
игровом мире рождается выбранный атом;
uispawn – при переходе атома в состояние, для которого определен такой аттачмент,
вызывается выбранная интерфейсная форма;
camera shaker – вызывает сотрясение камеры. Такой аттачмент есть у гиганта на
анимации землетрясения;
light_alterator – изменение глобального рассеянного и диффузного освещения;
dummy – пустой аттачмент для замены на что-то другое с помощью скриптов.

8.2. Конфигурационные файлы игры и редактора.

Многие настройки игры и редактора хранятся в ini-файлах. Свойствами редактора на


конкретной машине заведует файл editor.ini в папке editor.
Рассмотрим параметры, заданные в нем:
atomseditable – 1 или 0, определяет, можно ли внутри редактора изменять атом-файлы
объектов. Для редактирования ресурсы игры должны быть распакованы. Также это включит
редактор аттачментов;
undosize – размер буфера Undo. Чем больше, тем лучше, однако может вызвать
замедление работы компьютера. Значения меньше 10000 не рекомендуются;
sourcemediafolder – папка для хранения текстур локаций и исходных материалов. Если
при инициализации редактора адрес был задан неправильно, здесь можно его поменять;
font – шрифт, используемый в редакторе. Можно выбрать любой, который установлен в
компьютере;
editor_use_adapter – использовать ли второй монитор в редакторе;
execcount – количество запусков редактора в системе. Если в файле этого ключа нет
или значение равно нулю, будет проведена инициализация редактора, предложено выбрать
папку sourcemedia и так далее.

Параметры игры хранятся в файлах app.ini, game.ini и default.ini в папке data. Чуть ниже
рассмотрим значимые для редактора настройки.

app.ini:

sets ~language – языковой код текущей версии игры. Игра будет работать только с теми
файлами локализации (.lng), которые начинаются с этого кода;
sets ~session – базовая сессия игры. Всегда «addon», потому что это – вся игра. Можно
поставить и свою, но тогда там должно быть все, что необходимо для полноценной игры от
начала до конца;
sets ~sessionadd – дополнительная сессия. Их мы создаем в редакторе и подключаем к
игре.

8.3. Lua-скрипты.

Игра использует скриптовый язык Lua, который давно уже активно используется во
множестве игр. Отличительной особенностью данного языка является то, что его исходные
коды, как правило, компилируются непосредственно в момент исполнения, то есть до
запуска игры (а иногда и во время нее) их можно редактировать, как текстовые файлы. Все
скрипты хранятся в файле ses.kfs в папке sessions, в файлах с расширением .lua. Lua –
очень простой в изучении и использовании язык, его довольно легко освоить, обладая
небольшими познаниями в программировании. Официальный учебник по Lua от его
создателя можно найти в сети Интернет по адресу http://www.lua.org/pil/ (на английском
языке).
Само взаимодействие игры и Lua организовано по следующему принципу: в
специфических условиях игра вызывает Lua-функцию и передает ей параметры. После этого
она ждет, пока функция не исполнится, и считывает возвращенные значения для того, чтобы
на их основании провести изменения в игровом мире. Также игра предоставляет достаточно
обширную библиотеку функций, доступную для использования. Функции эти облагают
огромными возможностями манипуляции игровыми переменными и объектами. Список
функций игровых библиотек с описаниями можно найти в Интернете по адресу
http://kingsbounty.ru/docs/scripting/.
Для использования Lua-скриптов непосредственно в редакторе нужно, чтобы у названия
функции рядом стоял комментарий --ftag:<type>, где <type> - тип функции. Неполный список
типов функций:

--ftag:frame – фрейм-скрипт (на кадре анимации);


--ftag:idle – для chesspiec функция idle;
--ftag:vv – Var's value;
--ftag:watch – скрипт-ловушка изменения значения переменной;
--ftag:itmw – скрипт-ловушка изменения значения предмета;
--ftag:if – проверка условий;
--ftag:damage – функция расчета наносимого урона;
--ftag:bonus – функция расчета бонуса после битвы;
--ftag:action – вызывается из action;
--ftag:mascn – map actor scenario;
--ftag:escn – editor's scenario;
--ftag:posthit – скрипт постобработчика урона после удара;
--ftag:objuse – функция для использования предмета;
--ftag:armygen – функция-генератор армии.

8.4. Обзор структуры ресурсов игры.

Как было сказано в самом начале руководства, ресурсы игры делятся на две части:
данные как таковые, атомы, текстуры и прочие глобальные для игры вещи, своеобразные
детали конструктора, и сессию как логику сборки конкретной реализации игры из этого
конструктора. Настало время разобраться, как разбиты ресурсы на части. В папке sessions
два архива: ses.kfs – хранилище логики сессии. Здесь хранятся все скрипты, логические
объекты, конфигурационные файлы (config.txt и его инклюды), предметы, локации и прочие
вещи, которые отвечают за логику. Текстуры локаций хранятся отдельно вне архива. В
файле loc_ses.kfs хранятся все данные, имеющие отношение к локализации игры: .lng-
файлы. Название этих файлов должно начинаться с трехбуквенного языкового кода версии
игры (для русской версии это «rus»), а в них лежат заголовки по названиям. Строковые
данные в игре допускают достаточно сложное форматирование, для которого используются
специальные теги, очень похожие на html.
В папке data находятся ресурсы игры, для удобства распределенные по архивам. В
архиве models.kfs хранятся трехмерные модели различных игровых объектов в
формате .bma. Это – внутренний формат движка theEngine, который используется игрой. В
файле animations.kfs хранятся анимации для этих моделей. Архив textures.kfs содержит в
себе большую часть текстур, используемых в игре, в формате Direct Draw Surface (.dds). В
архиве interface_textures.kfs хранятся текстуры, используемые для интерфейса игры,
портреты героев, задники для замков, интерфейсные формы для меню и многое другое. В
архиве loc_data.kfs хранятся те графические данные (например, текстура названия островов
на глобальной карте), которые требуют локализации.
Наконец, важнейшим архивом является data.kfs. В нем очень много разных данных, мы
рассмотрим лишь несколько типов файлов, которые нам важны. Во-первых, там хранятся
абсолютно все атомы объектов (.atom). Во-вторых, там находится графическая библиотека
игры. Это те картинки, которые слишком малы, чтобы хранить их отдельно, например иконки
талантов или предметов. Они все вместе хранятся в больших файлах типа tex2.dds, а
местоположение конкретного виртуального «файла» в огромной плоской текстуре в виде
таблицы задано в файле itextures.dat. Графическая библиотека – альтернативное место
поиска графических файлов, если они не найдены в обыкновенной форме в ресурсах;
принципиальной необходимости ее использования нет. Также в data.kfs хранятся файлы
интерфейса. Все интерфейсы в игре настраиваются, файлы их настройки хранятся в
текстовом виде с расширением .ui.

Краткий список основных видов файлов игры:


.txt – такие файлы могут иметь очень разные форматы, в них, как правило, задается
конфигурация игры или объектов;
.atom – атом-файл. Специальный текстовый файл, в котором описывается объект игрового
мира и все его свойства;
.ui – файл конфигурации интерфейса;
.dds – текстуры объектов;
.png – интерфейсные картинки;
.ani – анимированный курсор;
.bma – трехмерная модель с анимацией;
.bms – трехмерная статичная модель;
.bsa – файл анимации для скелетной модели;
.csh – файл collision shape, задающий плоский контур пересечения объектов;
.cms – файл collision mesh. Упрощенная модель, задающая пересечение объекта с курсором
или лучом камеры;
.track – маршрут режиссерской камеры;
.stream – сжатая текстура локации;
.lu – логический объект в бинарном виде;
.strg – некоторое хранилище данных, универсальный формат;
.kfs – переименованный .rar или .zip-архив;
.ptb – файл частиц. В нем настраивается генерация и характер этих самых частиц;
.loc – файл локации;
.csv – простейшая таблица данных;
.act – внутренний формат файла актера;
.chat – внутренний формат файла диалога;
.hero – внутренний формат файла героя;
.qst – внутренний формат файла квеста;
.lua – Lua-скрипт. Текстовый файл;
.ogg – звуковой формат, используемый для музыки.
8.5. Дополнительная настройка редактора.

Все, что касается редактора, хранится в папке editor или sourcemedia. В корне папки
editor лежат текстовые файлы с внутренними настройками редактора. Редактировать их
нужно только в самых крайних случаях, но там можно посмотреть много полезных вещей. В
файле editor.txt находятся доступные в редакторе настройки величины области отрисовки,
типы камер, курсоры и начальные установки камер. Также там хранятся названия для
логических и пользовательских событий, для таймеров, соответствия сценариев и Lua-
скриптов, названия различных картинок и иконок. Именно там, как правило, и нужно искать
списки меню редактора и соответствие пунктов меню реальным значениям. Также там
можно создавать новые пользовательские события или таймеры и добавлять их в меню
редактора.
Теперь перейдем к sourcemedia. По сути, почти во всех папках лежат .strg-файлы,
которые соответствуют названию папки, это экспортированные настройки воды, эмбрионов,
камеры и еще почти чего угодно.
Здесь же находится очень важная папка terrain, в которой лежат текстуры ландшафта. В
папке materials хранятся текстуры материалов, обычно 1024х1024 пиксела в формате .PNG,
материалы дополнительно разбиты по папкам для группировки. В папке brushes хранятся
текстурные кисти, levels – текстуры уровней, а decal_thumbs – иконки декалей для
отображения в редакторе (сами декали хранятся непосредственно в архивах игры).
Особый интерес представляет собой папка in_progress, там находятся файлы текстур
локаций. Если папка для локации пуста, редактировать текстуру нельзя. Для часто
редактируемых локаций рекомендуется делать резервные копии этой папки, чтобы быть
спокойным за возможность редактирования.
8.6. Горячие клавиши в редакторе.

Общие:

Home – ставит камеру в положение по умолчанию;


Ctrl + R – отключить отображение вспомогательных объектов;

Ctrl + "Gray+/Gray-" – увеличить/уменьшить скорость хода времени;


Ctrl + Gray1 – показать/скрыть все, кроме ландшафта;
Ctrl + Gray1 – показать/скрыть ландшафт;

Ctrl + F1 – показать/скрыть FPS;


Ctrl + F2 – показать/скрыть распределение ресурсов процессора;
Ctrl + F3 – показать/скрыть загрузку памяти;
Ctrl + F4 – показать/скрыть загрузку видеопамяти;
Ctrl + F5 – показать/скрыть статистику отрисовки примитивов;

Ctrl + H – показать/скрыть проходимость и логические/физические


шейпы;
Ctrl + G – показать/скрыть сетку текстурных тайлов ландшафта;

Shift + F2 – показать/скрыть bound boxes;


Shift + F3 – показать/скрыть collision meshes;
Shift + F8 (Ctrl + Gray1) – показать/скрыть не ландшафтные модели;

Ctrl + Shift + Alt + H – показать/скрыть тени;


Ctrl + Shift + Alt + O – включить/выключить omni-освещение;
Ctrl + Shift + Alt + B – включить/выключить bloom;
Ctrl + Shift + Alt + S – включить/выключить звуки;

Ctrl + W – включение/выключение воды в редакторе.

Контроль камеры:
ЛКМ – левая кнопка мыши, ПКМ – правая кнопка мыши, СКМ – средняя кнопка мыши;
Default engine camera:

ПКМ – вращение;
A, D – движение влево/вправо;
W, S – вперед/назад вдоль оси камеры;
Up, Down – вперед/назад без изменений высоты;
Left, Right – поворот влево/вправо;
Pgup, Pgdn – поворот вверх/вниз;
E, Q – движение вверх/вниз;

+ Shift – быстрое перемещение;


+ Ctrl – медленное перемещение;
+ Alt – медленное вращение;

3DMAX-like camera:

СКМ – панорамное движение;


СКМ + Alt – движение по орбите;
СКМ + Alt + Ctrl – плавное движение вперед/назад;
СКМ + Ctrl – вращение;
СКМ + Shift – движение вверх/вниз;
Колесико мыши – приблизить/отдалить камеру;
Left, Right, Up, Down – движение в плоскости XY (+Shift – быстрое, +Ctrl – медленное);
Pgup, Pgdn + СКМ – движение вверх/вниз (+Shift – быстрое, +Ctrl – медленное).

Панель инструментов:

Shift + L – инструмент ландшафта;


Shift + A – инструмент атомов;
Shift + U – инструмент логических объектов.

Инструмент рельефа:

ЛКМ – поднять рельеф;


ЛКМ + Shift – опустить рельеф;
ЛКМ + Ctrl – сделать рельеф плоским;
ЛКМ + Alt – уровень моря;
[ – уменьшить кисть;
] – увеличить кисть;
[ + Shift – уменьшить внутренний радиус кисти;
] + Shift – увеличить внутренний радиус кисти;
1...0 – сила кисти;
' " – квадратная/круглая кисть.

Инструмент уровней:

[ – уменьшить кисть;
] – увеличить кисть;
' " – квадратная/круглая кисть;
Pgup – на уровень вверх;
Pgdn – на уровень вниз;
+Shift – стереть.

Объекты на карте:

P – просмотреть свойства атома;


L – просмотреть логический объект/шаблон логического объекта;
A – выбрать этот атом в палитре;
N – следующий атом такого же типа;
Space (на атоме) – свойства объекта на карте;
Shift + мышь – выделение рамочкой группы объектов;
M – двигать объект;
M + Alt – двигать по вертикальной оси;
S – масштабировать объект;
R – вращать объект вокруг вертикальной оси;
R + Alt – вращать объект вокруг горизонтальных осей;
V – создать «под курсором» вариацию объекта.

Логика:

Ctrl + Q – квесты;
Ctrl + A – актеры;
Ctrl + D – диалоги.
Пути:

Insert – новая точка;


J – добавить/изменить тип связи;
U – удалить связь;
Space – свойства точки;
Ctrl + Shift + Alt + Click – поставить/убрать поворот;
Ctrl + Shift + ЛКМ + движение мыши вокруг объекта – поворачивать стрелку, отвечающую за
направление взгляда персонажа;
Ctrl + Click – вероятность выполнения сценария/остановки;
Alt + Click – время остановки.

Монорельсы:

Insert – новая станция;


ПКМ – добавить станцию в выбранный маршрут;
Space – свойства станции;
Home – создать/запустить платформу с начальной станции маршрута;
End – создать/запустить платформу с конечной станции маршрута.

Задать вопросы по игровому редактору, поделиться своими кампаниями с другими


игроками или ознакомиться с чужим творчеством вы можете на официальном форуме
игры: http://www.kingsbounty.ru/forum/