Академический Документы
Профессиональный Документы
Культура Документы
ПО РЕДАКТОРУ ИГРЫ
«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. Редактор предметов.
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: Принцесса в Доспехах». Необходимо представлять себе основы
игровой механики и структуру игровых локаций. С точки зрения разработчика модификаций
никаких специальных знаний не потребуется – они либо не нужны, либо будут описаны в
процессе. Во вторую очередь, крайне желателен опыт работы с какими-либо игровыми
редакторами уровней либо с редакторами трехмерной графики. Отдельные разделы будет
сложно усвоить без знания основ трехмерной графики и работы с изображениями, но ничего
невозможного в этом тоже нет.
Тем, кто хочет реализовать максимум своих фантазий, придется работать не только с
редактором, но и с текстовыми конфигурационными файлами игры. В этом нет ничего
сложного, и в руководстве будет описана структура некоторых таких файлов.
В этой главе будут описаны именно основы работы с редактором: как, что и зачем
редактируется, какой инструментарий включает в себя игровой редактор и как им
пользоваться. Центральным понятием этой главы является игровая сессия. Также именно в
этой главе мы создадим демонстрационную сессию, на примере которой будем осваивать
работу с редактором на практике.
При первом запуске редактор предложит вам сделать несколько операций. Во-первых,
выбрать папку sourcemedia, это папка, в которой хранятся текстуры ландшафта. Из-за
своего большого размера она устанавливается отдельно от редактора. Чтобы установить ее,
нужно распаковать находящийся на диске с игрой архив setup_media.exe в удобное для вас
место. И потом, при запуске редактора, нужно будет указать путь к этой папке.
В этом архиве помимо кистей и шаблонов, находятся текстуры всех локаций
"Принцессы", за исключением боевых арен. В распакованном виде sourcemedia займет 14
гигабайт – учитывайте это! Несжатые текстуры локаций находятся в папке
sourcemedia\terrain\in_progress\ и вы можете просто удалить те локации, текстуры которых
править не собираетесь.
Во-вторых, будет предложено создать новую сессию. Что такое игровая сессия?
Фактически, это сама игра, и она включает в себя практически все, кроме контента игры
(контент – неизменяемые графические, звуковые и прочие ресурсы). Игровые локации со
всей логикой и структурой, тексты, LUA скрипы, конфигурационные файлы – все это
относится непосредственно к игровой сессии. В техническом плане новая сессия,
создаваемая в редакторе, – дополнительная. В ней используется все, что есть в основной
игровой сессии (для ЛоР это base, для ПвД – addon) плюс дополнительные данные вашей
сессии. Если вы изменяете или дублируете данные оригинальной сессии, то все эти
изменения сохраняются в вашу, пользовательскую, сессию, и измененные данные будут
загружаться именно из нее. Сама сессия – это просто папка, в которой хранятся все
создаваемые и редактируемые файлы данных. Попробуем создать тестовую сессию с
именем «tutor» (она нужна нам для обучения работе с редактором). Это имя одновременно
и будет названием папки. В этой папке также можно хранить любые модифицированные или
дополнительные игровые файлы, в том числе и те, оригинал которых находится в папке
data. Игра будет загружать файлы только той дополнительной сессии, которая в данный
момент подключена в игре. Таким образом, сессия – это еще и хранилище любых файлов,
которые нужны для ее нормальной работы.
В идеологическом плане сессия
– это дополнение к игре. Основная
мощь возможностей редактора
направлена на то, чтобы создавать
распространяемые дополнения с
новыми локациями, квестами,
предметами и диалогами к игре
«King’s Bounty: Принцесса в
Доспехах». Для того, чтобы сделать
что-то более масштабное
(например, полноценную новую
игру или существенно изменить
игровую механику и контент),
только редактора будет
недостаточно.
Одновременно редактор может работать только с одной сессией; для того, чтобы
работать с другой, его необходимо перезапустить. Редактирование оригинальной сессии
addon не допускается, однако, вы можете открывать любые локации из нее и делать любые
изменения – дубликаты измененных данных запишутся в вашу сессию. При создании новой
сессии можно задать ее имя и описание, которые будут использоваться в игре. Отметив
галочкой пункт Stand alone в этом окне, вы отключите все локации и все данные сессии
addon (включая предметы, персонажей и их диалоги, героев и так далее…). Таким образом
можно создать отдельное приключение принцессы Амели в каком-нибудь другом мире, но
мы сейчас не будем этого делать. Дадим сессии имя «Остров Заходящего Солнца», а в
описании напишем «Обучающая сессия». Далее нам предложат выбрать локацию для
редактирования. Локации бывают двух типов – обычные и боевые арены. Мы не будем
ничего выбирать, а сразу создадим новую – нажмем кнопку New Map. Новой локации нужно
дать техническое имя на латинице. Мы будем делать дополнительный остров для
«Принцессы в Доспехах» – Остров Заходящего Солнца. Соответственно, его техническое
имя будет sunset_isle.
1.2. Интерфейс редактора.
Закладка 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). Типы объектов, которые
визуализируются на радаре:
Для нормальной работы радара в игре его картинка должна быть сохранена либо в
папке \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:
Эта штука проверяет все и вся, ищет всевозможные ошибки, как то: пустые здания,
актеры без портретов и диалогов, пути без армий и прочее.
Сначала остановимся на внешнем виде локации. В следующей главе будет описано, как
с помощью инструментов вкладки Landscape создать локацию и придать ей уникальный вид.
Практическая часть.
Инструмент Levels tool позволяет создавать уровни ландшафта: резкие перепады высот
с высокой детализацией текстуры и рельефа «стен». Сами «стены» уровней – это набор
разнообразных заранее заготовленных объектов, которые маскируют резкие перепады
высот. Без уровней невозможно создавать, в частности, подземелья и темницы, для которых
существуют свои наборы «стен».
Сначала необходимо выбрать набор, который определяет внешний вид уровня и его
высоту (глубину). Затем нужно выбрать порядок вашего уровня в настройке Level.
Изначально уровень локации – 0. Все типы стен делятся на два класса – обычные и
инвертированные. Обычные делают зону локации выше, инвертированные – ниже. Для
обычных Level должен быть установлен в «+1», для инвертированных – в «-1». Для создания
«ступенек» с помощью уровней, каждая следующая ступенька будет рисоваться с
параметром Level больше (или меньше) на единицу.
Размер кисти, как и всегда, регулируется клавишами [ и ], или напрямую в поле Brush
size. Но удобнее для этого использовать сочетание Shift-Click. Режим Ramp создает на уже
нарисованном фрагменте уровня спуск – область, где герой может подняться на ступеньку
уровня или спуститься с него. Не для всех типов стен существуют такие подъемы-спуски, и
их наличие устанавливается экспериментальным путем.
Уровни можно стирать, либо просто водя кистью со включенной галочкой Erase, либо
зажав клавишу Shift. Первый режим автоматически стирает и рампы, второй – стирает
только при включенном режиме Ramp. Учтите, что стирается только тот тип стен, который
выбран в палитре. Так что, если вы нарисовали уровень со стеной cave2, то стереть его
можно будет только в том случае, если в палитре тоже выбран cave2.
Режим Customize позволяет вручную выбирать из списка один из элементов набора. Это
удобно при создании в конкретных местах специальных объектов, например дверей,
лестниц или входов в пещеру. Также можно изменить внешний вид участка стены просто
повторным кликом по нему, тогда фрагмент выбирается случайным образом. Некоторые
наборы уровней отличаются только текстурами (например, стены королевского замка и
стены тюрьмы), тогда при выборе такого набора под кнопками Ramp и Customize появляется
список доступных наборов текстур, в котором можно выбрать нужный.
При работе с уровнями рекомендуется заранее сохраниться и в дальнейшем делать это
как можно чаще, если вы создаете сложные структуры. Использовать уровни лучше только
тогда, когда в них есть необходимость; в других случаях решить проблему возвышенностей
можно простым изменением рельефа и текстуры или добавлением объектов-гор на карту.
Практическая часть.
Как уже было упомянуто выше, каждому большому тайлу поверхности соответствует
текстура максимального разрешения 1024 на 1024 пиксела (для экономии памяти
разрешение текстур на тайлах можно уменьшать в редакторе). Для того, чтобы создавать
уникальные и разнообразные ландшафты, в редакторе доступны сотни различных текстур,
для удобства сгруппированных по категориям. Кроме того, существует несколько методов
наложения и форм кистей, которые позволят создать именно тот вид ландшафта, который
задумал автор.
Инструмент текстурирования.
Режим работы с текстурой доступен через инструмент Texture Tool во вкладке Landscape
панели инструментов. Всего существует три метода раскрашивания поверхности (группа
кнопок 1 на рис. 2.3): кисть (кнопка brush), заливка текстурой региона (кнопка region) и
наложение декали (кнопка decal). Также в режиме работы с текстурой появляется
дополнительное окно (2) – окно выбора материалов. Для того, чтобы добавить сюда
палитры текстур, нужно либо импортировать вручную материалы из заранее нарисованных
текстур, либо скачать с сайта игры пакет sourcemedia, содержащий все текстуры,
используемые в игре. Также необходимо учесть, что текстуры ландшафта редактор хранит в
несжатом виде и они занимают немало места на жестком диске. Так, текстура ландшафта
Дебира в исходном виде занимает почти 400 мегабайт. Несжатая текстура хранится в папке
sourcemedia/terrain/in_progress/<имя локации>, и если такой папки нет или она пуста, то
редактировать текстуры ландшафта невозможно.
Сверху находятся кнопки Save и Save Packet. Сейчас мы их не используем, текстура
сохраняется в sourcemedia автоматически, но первую кнопку можно использовать для того,
чтобы взглянуть на текстуру ландшафта «с высоты птичьего полета». Это может позволить
получить представление об общей цветовой гамме локации, однако в этом окне не
используется ни рельеф, ни освещение, так что это представление будет как минимум
приблизительным.
Этот режим включается кнопкой region. Он удобен для заливки какой-то области
определенной текстурой. При этом контур области может быть очень сложным,
составленным из коротких отрезков. Сначала нужно создать регион последовательными
кликами мышки – каждый следующий создаст новую точку многоугольника. Если подвести
курсор к существующей вершине, линия станет зеленого цвета и кликом мышки регион
можно замкнуть. Shift-клик на замкнутом регионе зальет его текстурой выбранного
материала, Ctrl-клик удалит регион (но не текстуру, которой он залит!). Следует отметить,
однако, что покраска региона ничем принципиально не отличается от покраски кистью, так
что для него будут работать те же правила, что и для обычной кисти, – слои материалов и
привязка текстуры к тайлам. Вообще, если вы пытаетесь рисовать текстурой на области
ландшафта, но почему-то ничего не происходит, это значит, что этот материал уже
применялся к тайлу и лежит в каком-нибудь нижнем слое, где его не видно под другими.
Ситуация разрешается либо поднятием слоя, либо при помощи операции merge map.
2.2.4. Декали.
При рисовании локации нужно всегда держать в голове один факт – необходимо
заботиться о нервах пользователей со слабыми компьютерами. Каждый пенек, каждое
дерево на локации – это дополнительная нагрузка на видеосистему. То же самое относится
и к источникам света, и к просто большим локациям. А потому текстурирование является
самым «дешевым» и одновременно очень выразительным средством при создании локации.
При работе с редактором карт в «King’s Bounty» необходимо избавиться от стереотипов,
закрепившихся при работе с редакторами для игр вроде «Warcraft 3» или «Heroes of Might
and Magic”. Там есть трава, есть песок и есть снег с небольшими автоматическими
вариациями, а уникальность ландшафтов создается исключительно объектами. Здесь же
возможности работы с текстурами практически не ограничены, и все зависит от
воображения и таланта дизайнера. Палитра редактора содержит несколько сотен
разнообразных текстур и их вариаций на любой вкус. Помимо обычных сплошных текстур,
представлены также декоративные прозрачные, которые можно и нужно накладывать поверх
основных – опавшая листва, камни, ракушки, цветы и т.д.
С помощью текстур даже можно создавать иллюзии объема: мелкие камушки, корни,
выступающие из земли плиты, овраги или лужи. Для того, чтобы освоить искусство
украшения локаций и понять, какие наборы и текстуры можно органично сочетать друг с
другом, рекомендуется изучить уже созданные для игры локации и посмотреть, как они
устроены, как сделаны те или иные переходы и каким образом достигается ощущение
уникальности каждого места.
Практическая часть.
Как уже было сказано выше, текстура – одно из основных выразительных средств,
которым владеет дизайнер локаций. Грамотное сочетание текстур и объектов даст нам
полную власть над ощущениями, которые вызывает локация у игрока.
Нам необходимо подключить пакеты текстур, которые лучше всего отражают настроение
локации – места, где царит вечный закат. Нам нужны закатные, оранжевые тона, поэтому
будем использовать пакеты текстур humenlands и autumn. Для начала наложим базовую
текстуру на локацию – это будет наша основа.
Теперь финальный штрих – выделим верхушки гор более светлой вариацией текстуры
камня – humen_stone_10a. Не то чтобы это было катастрофически важно, но использование
вариаций текстуры немного другого тона – основной способ имитации освещенности наряду
с lumi-слоем.
Рис. 2.6. Подсветка вершин гор более светлой вариацией текстуры.
Аналогично поступим и с южным мысом: точно так же сначала наложим текстуру камня,
потом создадим переход к песчаной текстуре мелкими камушками и, наконец, подсветим
выступающие части гор более светлой вариацией текстуры.
Мы разобрались с горами и тем, как их рисовать с помощью текстур. А еще с тем, как
можно обеспечивать переходы разных текстур друг в друга с помощью дополнительной
детализации. Конечно, можно делать переходы за счет полупрозрачной кисти, но это ведет к
смешению двух текстур, что не всегда выглядит красиво и логично. Теперь займемся
островком, примыкающим к основной локации.
Рис. 2.8. Берег островка.
Поскольку на нем у нас будет жить чудовище, имеет смысл сделать его темным и
страшным, поэтому для него мы будем использовать группу текстур темного леса (она
находится в уже подключенном наборе humenlands). Для начала возьмем материал
humen_darkstone_1 и сделаем с его помощью скалистый берег на юго-востоке островка (на
северо-западе у нас будет вход через мост). Сетка включена для того, чтобы видеть, где
начинается спад уровня высоты, – там уместнее рисовать скалу. На следующем рисунке
изображен уже полностью покрашенный островок.
Рис. 2.9. Базовая текстура островка.
В этом разделе пойдет речь, прежде всего, о статичных объектах ландшафта. Любой
объект в игре в общем случае состоит из двух частей – атома и логического объекта. Атом –
это то, что определяет базовые свойства объекта в мире: его внешний вид, размер, то, как
он влияет на проходимость локации. Логический объект определяет уже характер его
взаимодействия с игроком, его реакцию на клики мышкой и так далее. Прототип объекта –
его атом-файл. В строгом смысле атом и атом-файл – это не одно и то же, так как атом-файл
также содержит базовую информацию о логике, но мы будем пользоваться термином «атом»
для обозначения и того, и другого.
Атомы обладают целым рядом свойств, но, прежде всего, каждый атом принадлежит
определенному классу. В этом разделе мы рассмотрим классы атомов 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, которые не попали ни в какую категорию.
Практическая часть.
У нас готова основа локации, наполненной объектами. Теперь нужно будет все это
детализировать, но пока сделаем то же самое и с северо-востоком основного острова и
заодно поставим там домик, в котором будет жить наш NPC. Домик возьмем из папки
Buildings/Pirate_robber/building_pirate_house03, он вполне соответствует внешнему виду
«обычного жилища». Небольшой участок на северном мысе пока оставим нетронутым.
Рис. 2.18. Объекты на севере острова.
Теперь займемся пещерой. Нам нужен красивый вход в нее, его можно либо слепить из
отдельных камней самостоятельно, либо взять готовый, уже сделанный за нас художниками
Katauri. Мы пойдем по второму пути и «вклеим» в уже нарисованную гору вход в пещеру из
папки Decorations/cave/cave_cyclop. Но вот беда, он немного отличается по цвету от горы под
ним. Прежде чем искать другой вход подходящего цвета (такого на самом деле нет) или
переделывать гору целиком, зададимся вопросом: а настолько ли велика разница в цветах?
Возьмем текстуру мелких камушков зеленоватого оттенка (здесь и далее читателю
предлагается найти ее в палитре самостоятельно) и подкрасим гору вокруг входа в пещеру,
создавая плавный переход от объекта к текстуре.
Рис. 2.19. Вход в пещеру.
Получилось неплохо. Необходимо только покрасить и сам вход: для этого в палитре есть
текстура черного цвета, ею закрасим стену горы, которая находится внутри входа в пещеру.
Доработаем это место, добавив на самый верх горы атомы из группы
Decorations/human/stone/mountain. Не нужно стесняться погружать их в ландшафт и
масштабировать в широких пределах: поскольку область априори непроходима, нас
интересует только внешний вид. Если все сделать правильно, поверхность горы станет
несколько более неоднородной и с резкими перепадами высот без потери качества
текстуры.
Рис. 2.20. Сочетание текстуры горы и атомов.
Тут уже все определяется полетом фантазии дизайнера, но можно описать то, что было
сделано на рисунке. Во-первых, пространство за маяком было заполнено ананасовыми
кустами из 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. Тропинка в лесу.
Остался лишь один вопрос: как связать маленький остров с основной локацией?
Попробуем поставить между ними мост, однако расстояние оказывается слишком большим,
чтобы поместился какой-либо деревянный мост, а каменный не вписывается в тему локации.
Что же делать? Мы поступим просто: сделаем плот. Подробно этот процесс будет описан
ниже, в 5.1, уже после рассмотрения логических объектов и принципов работы
монорельсовой системы. Сейчас же мы займемся настройкой воды.
Вода – еще одна сильная сторона движка «King’s Bounty». Доступно достаточно много
параметров ее настройки, но необходимо учитывать, что это почти прямой интерфейс к
настройке воды SkyFallen, так что не все функции адекватно работают в игре, а некоторые
не работают вообще. Настройки воды доступны в игре из трех мест: инструмент Water в
панели инструментов, там доступен шаблон default, который отвечает за основную воду на
локации; кнопка Deep Water Settings в Landscape (на самом деле редактируется тот же
самый шаблон default) и дополнительные настройки воды в Location/Light в главном меню. О
последнем речь пойдет позже, а сейчас немного теории о первых двух.
Вода делится на два типа – основная и дополнительная. Основная вода определяется
шаблоном default и по умолчанию «заливает» всю локацию, дополнительная определяется
другими шаблонами и может существовать на локации в отрыве от основной. Можно
заливать локацию дополнительной водой кликами мышкой с выбранным шаблоном – можно
заливать целиком каждый текстурный тайл локации. Основная вода и дополнительная
значительно отличаются в настройке.
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) – не используется.
Foam width – определяет ширину текстуры волн от берега. Если поставить параметр на
максимум, увеличится расстояние от начала волны до берега и скорость волны;
Foam jitter – определяет то, насколько отдельные участки текстуры волны
синхронизированы друг с другом. Если этот параметр близок к нулю, то все волны будут как
бы слиты в одну большую. Высокие значения параметра увеличат разброс;
Foam speed – скорость анимации текстуры волн.
Для всех трех слоев также есть общие настройки:
Таким образом, глубокую воду можно настроить достаточно гибко, однако в первую
очередь нужно ориентироваться на итоговый внешний вид: чем привлекательнее и
естественнее, тем лучше. Один из важнейших ее параметров – цвет толщи воды –
недоступен через настройки самой воды, его нужно настраивать через свойства освещения
(Location/Light/Water Settings/Deep Color). Следует также заметить, что глубокую воду можно
использовать и творчески: например, можно убрать ее поверхность и выставить цвет толщи
черным – тогда ее можно использовать как бездонную пропасть.
Данная совокупность настроек позволяет сделать воду достаточно красивой. Учтите, что
текстура неба не движется с передвижением камеры, так что некоторые текстуры заранее
рассчитаны на использование в специфических условиях, например, humen_underwater.
Побольше экспериментируйте, порой с помощью настроек воды можно достигнуть
удивительных результатов.
Практическая часть.
Первым делом выберем текстуру неба. Можно оставить текущую, а можно выбрать и
другую, это не столь важно. Хотя следует предварительно условиться, что, раз уж мы
используем закатную гамму, то и вода должна быть соответствующая, поэтому будем
использовать более мягкую текстуру water_cube_sky_2.dds. Также сделаем цвет
поверхности более мягким, поставив все слайдеры примерно на 0.15, слегка выдвинув
красный. Чтобы увеличить прозрачность поверхности, Fresnel bias поставим приблизительно
0.25.
Рис. 2.33. Регулировка цвета воды.
Несколько увеличим количество волн на воде слайдерами Fresnel depth alpha и Bump
scale. Также нужно запустить движение ряби параметром Water speed. Получится что-то
вроде того, что изображено на рис. 2.34.
На этом пока настройку воды закончим. Далее нам нужно будет выставить цветовой
градиент глубины воды, но это уже в следующей главе.
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-файлы. При создании локаций, на которых свет не зависит от времени
суток, удобно сделать только освещение для одного времени суток, потом экспортировать
его и импортировать во все остальные времена суток.
Для начала нужно отметить, что туман в игре необходим. Туман не только создает
атмосферу на локации, но и позволяет скрыть границу отрисовки объектов, за пределами
которой объекты перестают отображаться. Настраивается туман в двух местах: во вкладке
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. Тогда придется настраивать свойства тумана не по
всем направлениям сразу, а по каждому в отдельности.
Как уже было описано выше, данный вид освещения ответственен за точечные
источники света. Важным замечанием тут является то, что этот свет не заставляет объекты
отбрасывать тени.
Перейти в режим редактирования 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-источниками света для придания атмосферы. Особенно
красиво выглядят фонари, зажигающиеся с приходом ночи, или освещенные мистическим
светом волшебные полянки.
Практическая часть.
Для упрощения задачи настройки света наложим на него дополнительное условие: на
локации всегда будет закат, и время суток меняться не будет. Настроим это. Заходим в
Location/Light в главном меню. Нас интересует параметр Sun dir scale – именно он отвечает
за количество оборотов солнца вокруг локации за день. По умолчанию он равен 1, а мы
сейчас выставим его в 0 – тогда солнце перестанет вращаться. Само направление
недвижимого солнца выставим параметром Sun time – поставим его так, чтобы вход в маяк
был не в тени – в 3.30. Наконец, нам нужно мягкое освещение и длинные тени, поэтому
параметры Min pitch и Max pitch поставим оба в 1.
Слегка сгладим цвет теней, добавив в него серого. К цвету диффузного и рассеянного
освещения добавим немного оранжевого для более реалистичного освещения. Наконец,
таким же оранжевым выставим цвет линии горизонта (пока смотрится диковато, но это
ненадолго) и цвет тумана. Приблизим ближнюю и дальнюю плоскости тумана так, чтобы он
слегка проявился на локации. Ну и напоследок выставим более темный, чем стоит по
умолчанию, цвет глубокой воды. Вечером вода почти непрозрачна, это создаст хороший
эффект присутствия. Теперь экспортируем все это в файл (Save panel settings) и загрузим
для всех других времен суток.
Самое время заняться локальным освещением. Расставим несколько omni-источников
на локации. Необязательно делать их в реалистичных местах (хотя и логично, что маяк
освещает окрестности вокруг себя). Наша задача в том, чтобы заставить локацию выглядеть
интересно и подсветить те места и объекты, которые в силу их расположения оказались в
тени своей лицевой стороной, например наш волшебный пень и домик NPC. На основном
острове будем пользоваться преимущественно бледно-желтыми тонами, а на близлежащем
островке – красными и синими, там у нас живет чудовище, а потому освещение может быть
более причудливым.
На этом пока настройки света закончим. Поскольку на локации у нас пока нет неба,
выглядит все достаточно странно и немного неестественно, но мы это вскоре исправим.
Мы уже столкнулись с 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. Общие свойства локации.
В этом режиме настраиваются общие свойства локации, такие как музыка, тени,
сложность и типы арен для локации. Есть несколько вкладок, по которым сгруппированы
настройки.
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.1. Атомы.
Мир состоит из атомов. Точно так же трехмерный мир King’s Bounty состоит из атомов.
Атомы – это кирпичики, элементарные частицы конструктора, из которого слеплена игра. По
сути своей атом – это некоторый объект, который обладает следующими свойствами:
1) он рендерится (визуализируется) движком игры, как целое.
2) он обладает физическими параметрами: размером, трехмерной моделью, звуком или
спецэффектом.
3) в нем может храниться логический объект.
Существует несколько разных классов атомов, и, как мы уже говорили, прототип атома
определяется его атом-файлом. От класса атома и ряда параметров его атом-файла
зависит то, какие возможности для него будут доступны в редакторе и в игре. Для начала
рассмотрим те классы атомов, которые есть в игре.
Их достаточно много, и они определяют прежде всего доступность для атома той или
иной настройки, а также то, какая логика будет настроена в атоме по умолчанию при
помещении его на карту. Список классов:
Данный список стоит воспринимать как ознакомительный. Это прежде всего необходимо,
если вы хотите изменять свойства объектов, например, сделать из обычного камня
говорящий или что-то еще в том же роде. Класс атома static не даст вам приделать к камню
никакую логику, в том числе и диалог, так что придется делать дубликат атома с другими
свойствами, например, классом npc.
Итак, в меню выбора атома можно на любом из них кликнуть правой кнопкой мыши.
Всплывет некоторое меню, в котором вы сможете посмотреть/изменить настройки атомов.
Edit thumbnail, Explore thumbnail, Reread thumbnail и Replace thumbnail with отвечают за
иконку атома в списке, Move to позволяет переместить атом в другое место в папках, Clone
создает дубликат атома, Attachments вызывает редактор аттачментов (см. приложение 8.1).
В любой момент можно посмотреть атом в текстовом виде через Edit atom file или Explore
atom file, но для этого ресурсы игры должны быть распакованы. Нас интересует сейчас Atom
properties и соотношение настроек, представленных там, с тем, что есть в атом-файле.
Внутри каждого атома есть блок main. Рассмотрим параметры, которые могут быть в
этом блоке атома (не все, но большинство):
В атомах есть и другие блоки. Блок 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 – аналогично предыдущему.
Эти настройки помогут, если непонятно, как сделать «очень большое дерево» или «очень
маленькую гору». Существует масса других параметров в атомах (их всего несколько сотен),
но перед нами не стоит задача разобраться во всех них.
Итак, чуть выше было впервые упомянуто понятие «эмбрион», сейчас попробуем
разобраться, что же это такое. Когда мы имеем конечную, итоговую генерацию игры, на
локациях у нас есть атомы и логические объекты внутри них (есть и объекты, которые не
принадлежат никаким атомам, но это – редкость). Как уже было сказано выше, атом – это
модель и самые базовые свойства объекта в игровом мире, а логический объект – его
поведение. В логическом объекте может быть настроено то, как атом реагирует на клик
мышкой, какие переменные внутри него хранятся, например, армия, предметы, персонаж, а
сама логика определяет то, как эти переменные используются для взаимодействия с
игровым миром. То есть логический объект – это набор некоторых значений переменных и
набор некоторых функций, которые срабатывают при определенных событиях в игровом
мире. Однако тут сразу же очевидны некоторые проблемы:
1) у нас есть дом, который настроен на то, что клик мышкой вызовет форму торговли, где
есть 10 импов и 20 церберов. Ставим соседний дом и настраиваем все то же самое заново.
Это долго и очень трудоемко;
2) мы настраиваем на карте объект, в котором как переменные содержатся 20
архидемонов и 100 злобоглазов. При левом клике вызывается сражение, в котором из этих
переменных берется армия врага. В каждой генерации игры это будет одинаковый объект, а
мы хотим разнообразия. Как быть?
Для решения этих двух проблем есть специальная сущность, которая называется
«эмбрион». Эмбрион существует только в редакторе. Поставив на карту эмбрион, мы можем
настроить то, чем он в игре станет, и при генерации игры эмбрион превратится в атом с
логическим объектом внутри. Существует несколько стандартных видов эмбрионов со
стандартными формами настройки, нам нужно только вбить числа, логика уже задана за
нас, притом эмбрион содержит в себе не только логику будущего логического объекта, но и
логику генерации. Настроив эмбрион армии, в игре мы получим результат – армию, состав
которой может очень сильно варьироваться, зависит от уровня сложности и так далее, в
общем, именно то, что нам нужно. По умолчанию многие классы атомов имеют
прикрепленный тип эмбриона – есть эмбрион замка, эмбрион армии и эмбрион контейнера.
Настраивая логику такого объекта на карте, мы на самом деле настраиваем его эмбрион. В
редакторе объект может иметь либо эмбрион, либо логический объект, и никогда – оба
одновременно. Поскольку эмбрион – прообраз логического объекта, одновременное
существование их в объекте бессмысленно. Настроить эмбрион выбранного объекта мы
можем, нажав клавишу E, логического объекта – L.
Строение эмбриона таково: есть атом, который мы ставим на карту. В простом режиме
этот же атом будет сгенерирован в игре. Есть прототип логического объекта, который
берется из библиотеки и задается параметром lutemplate в атом-файле. Есть механизм
генерации эмбриона из его параметров, который жестко задан, и менять его нельзя. И,
наконец, есть набор этих самых параметров, которые мы и задаем. Ниже будет разобрана
параметризация различных видов эмбрионов, пока что ограничимся пониманием структуры.
Нажатие на вкладку Logic в настройках атома на локации выдаст нам три больших
кнопки. По умолчанию не нажата ни одна, это значит, что будут использованы настройки
эмбриона по умолчанию. Это не такая хорошая идея, потому как большинство эмбрионов по
умолчанию пусты, у них нет ни магазинного ассортимента, ни состава армии, ничего.
Исключение здесь представляют собой контейнеры, настройки которых зависят от
сложности локации, а потому мы будем получать из них золото/бриллианты даже в том
случае, если вообще ничего не настроим. Нажатие кнопки Independently значит, что для
данного объекта мы используем локальную копию эмбриона и можем ее настроить.
Advanced Mode – режим, когда мы в эмбрионе задаем не только параметры, но и сам атом,
таким образом создаются магазины, в разных генерациях имеющие разный внешний вид. В
этом режиме в одном месте на локации находится несколько пар атом-эмбрион и при
генерации будет использована одна из них. Третий режим, Custom Logic, означает, что,
вдобавок к настройке эмбриона (который генерирует параметры логического объекта) мы
используем еще и самостоятельный локальный логический объект, правила поведения
которого в игровом мире и реакция на действия игрока будут отличаться от того, что для
данного атома используется в качестве шаблона. Здесь много непонятных слов, но на деле
эмбрионы достаточно просты в настройке.
Учтите, что нажатие L на атоме с эмбрионом все-таки вызовет логический объект для
настройки, но это будет не локальный логический объект, который хранится в атоме
(помним, что при наличии эмбриона логический объект возникает только в момент
генерации), а шаблон логического объекта, который использует эмбрион. Редактировать его
крайне не рекомендуется, потому что это повлияет на все эмбрионы в игре, где используется
этот же шаблон. Если мы изменим шаблон магазина, сломаются абсолютно все магазины на
всех локациях, так что лучше залезать в шаблоны только с целью ознакомления, но никак не
редактирования. Есть у эмбрионов еще одно важное свойство – уникальность. Если
несколько объектов используют один эмбрион (не одинаковый, а именно один и тот же),
сгенерируется только один из них. У каждого эмбриона есть номер, можно посмотреть его в
статусной панели, наведя на содержащий его атом курсор. Если у двух атомов одинаковый
номер эмбриона, случайным образом сгенерируется лишь один из них. Так сделаны
навигационные карты – на локации карта может лежать в нескольких разных местах, но
всегда в единственном экземпляре. Этот механизм в редакторе называется вариациями
(Variations).
Есть и еще один механизм, исключительно для удобства. Мы можем создавать в палитре
мета-атом (по правому клику выбрать пункт Meta atom) и добавлять в него обычные. Это
функция, которая существует только в редакторе. При установке на карту такого атома будет
выбран случайный реальный атом, содержащийся в нем. Например, так можно сделать
«кисть», которая рисует случайные деревья из списка. Здесь выбор производится именно на
стадии установки объекта на карту в редакторе, нельзя путать этот механизм с эмбрионами,
генерация содержимого которых происходит в начале игры.
В качестве первой ловушки выбран все тот же 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 и только в
случае прохождения обеих проверок запустит какие-то действия.
Совет: для понимания вышеизложенного материала изучите работу как можно большего
количества уже настроенных ЛО – их достаточно много, и многие из ловушек так или иначе
реализованы в них.
3.2.3. Игровая логика. Condition editor.
Рис. 3.2.
Редактор условий.
Итак, как мы знаем, игра и объекты в ней могут генерировать различные события, а
объекты – ловить их. Существует два различных вида событий. Логические события
генерируются в коде игры в специфических ситуациях, любое из них имеет вполне
конкретный смысл. Пользовательские события (приказы) генерируются в логике,
настраиваемой дизайнером, и там же ловятся. Смысл они имеют именно тот, какой
дизайнер им присвоит. События отличаются друг от друга только номером, однако в
редакторе (не в игре) им присвоены удобные названия, которые в случае пользовательских
событиях нужны только для того, чтобы зарезервировать некоторые номера событий за
некоторыми типовыми реальными событиями. Никто не мешает вам сгенерировать при
нажатии на кнопку 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 – завершает игру победой или поражением.
Этот язык доступен через условие или действие Expression. В случае условия
оценивается истинность выражения, в случае действия – выражение исполняется. В
скриптовом языке недоступны прямые операции (читай, функции с побочным эффектом, то
есть язык по своей природе функциональный), однако, мы можем перезаписывать значения
глобальных переменных или переменных ЛО с помощью синтаксиса присваивания “:=”.
Сами переменные используются следующим образом: мы придумываем переменной
уникальное имя, например, a. Эту переменную в тексте выражения мы можем использовать
с синтаксисом “[a]”. Как только такая переменная появляется в тексте выражения, внизу
появляется поле, откуда ее можно брать.
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. Тупик.
Важно не забыть отредактировать карту проходимости под входом, иначе до него нельзя
будет добраться. Теперь нужно поставить там портал. Нам нужно два портала для связи
двух точек на локациях, не так ли? Нет, не так. Один портал переносит героя к другому, но
куда он при этом попадает? Правильно, точно в середину противоположного портала, то
есть в зону, где срабатывает логика перемещения. Два портала приведут к тому, что герой
будет просто бесконтрольно телепортироваться туда-сюда до скончания времен. Таким
образом, для связи между собой двух точек нам нужно четыре портала – два из них будут на
вход, они будут обладать логикой и красивым спецэффектом. А еще два портала – на выход,
просто точки с тегом портала, и больше ничего. Поставим портальную пару во вход в пещеру
на Дебире (необходимо, чтобы их логические шейпы не пересекались, подсветить их можно
сочетанием клавиш 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. Эмбрионы.
Выше было упомянуто, что эмбрион – это, по своей сути, прототип некоторого объекта на
карте. В понятие объекта здесь включается атом и логический объект. При генерации игры (в
специальных случаях, может быть, и в другой момент) эмбрион превращается в реальный
объект на карте. Настройка эмбриона, таким образом, представляет собой выбор того, что
вообще может сгенерироваться, и вероятностей генерации разных вариантов.
Для эмбриона существует две различных области видимости: шаблон эмбриона для
объекта существует внутри типа объекта – отдельного атома. Такой эмбрион можно
просмотреть в таблице атомов, кликнув на иконку правой кнопкой мыши и выбрав Embryo
(однако здесь его редактировать не следует). Когда мы помещаем атом на карту, в нем
живет именно этот эмбрион-шаблон.
Рис. 3.9. Свойства атома.
Когда на карту выставлен объект с эмбрионом, у него есть еще одна крайне важная
опция. Выбрав во всплывающем меню Variations или нажав V, мы получим «висящую на
курсоре» полную копию объекта вместе с эмбрионом. Вообще, когда мы выставляем на
карту объект, ему присваивается определенный эмбрион за определенным номером.
Выставив объект снова, мы получим уже другой эмбрион. Через Variations мы можем
поставить на карту объект, в котором сидит тот же самый эмбрион, что и в оригинале.
Фактически, выставляя на карту вариации объекта, мы определяем возможные точки, где
этот объект может родиться при генерации. Так обеспечивается то, что на Дебире лежит
всегда только одна навигационная карта Боло, зато она может лежать в разных местах.
Выбрав в меню Show hidden, мы увидим над эмбрионами специальные значки в виде
гаечных ключей. Если над гаечным ключом висит плюс – у объекта есть вариации.
Откроем свойства эмбриона объекта класса 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 нужна для того, чтобы все в замке было бесплатным (используется в Кронберге перед
битвой с Баалом).
Настройки эмбриона армии куда проще понять, если до этого разобраться в настройках
замков. Как и там, здесь слева находится поле, которое определяет различные варианты
генерации. Каждый из них – это отдельно настроенная армия, при генерации игры
выбирается лишь один (за исключением одного специального случая, оговоренного ниже), и
у каждого варианта есть свой вес, определяющий вероятность генерации. Эти заготовки
армий можно также выгружать для использования в дальнейшем в 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 стеков. Это можно задать в
настройках арены для того участка земли, где предполагается сражаться с такой армией.
В списке, как обычно, находятся сеты с разным весом. В каждом из сетов можно либо
задать вес вручную, либо определить через скрипт (не забываем про галочку 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-5
случайных свитков 1-2 уровня и один слот со случайным предметом 1 уровня.
Получившийся полностью настроенный магазин можно увидеть на рис. 3.15. Не забудем
также добавить маяку в свойствах атома всплывающую подсказку на карте.
Рис. 3.15. Настроенный эмбрион маяка.
Теперь возьмемся за домик Джо. Тут уже одной настройкой чисел в эмбрионе не
обойдешься, нужно включить Custom Logic и отредактировать саму логику домика. Нам
необходимо, чтобы при взаимодействии с домиком появлялась не форма торговли, а диалог
с Джо. Для начала смело удаляем последние две ветки логики, которые связаны с ареной, –
драться мы с Джо не собираемся. Удаляем полностью все действия из
INTERACTION_PASSIVE_ON, однако саму ловушку оставляем. Теперь вместо действий,
которые мы в ней удалили, создаем другое – Begin dialog by current active actor. Форму
продажи уже в специальном порядке будем вызывать из диалога.
Рис. 3.16. Специальная логика для домика Джо.
Вес вариантов у нас одинаковый, так что в игре с равной вероятностью сгенерируется
алтарь, повышающий интеллект, атаку или защиту. Вообще уже существуют такие сложные
эмбрионы для случайного алтаря, это – altar_bonus_all и altar_bonus_all_big, в них можно
залезть и посмотреть, как они устроены. Теперь расставим сами бонусы по локации. Будем
использовать как отдельные атомы класса box, так и «чистый эмбрион» – специальный атом
в папке Resources в виде желтого или красного шарика. Это – преднастроенный эмбрион с
очень большим числом вариантов генерации. Разместим таких на локации парочку. Также
закопаем под пнем клад, выставив эмбриону галочки Buried treasure и Can be digged.
Теперь заполним эмбрион армиями. Рассмотрим для примера лишь звериную заготовку.
Сначала нужно задать полное лидерство заготовки. Определимся, какой уровень героя
соответствует такой армии. Локация у нас немного слабее, чем Алый Ветер, так что укажем
диапазон уровней 4-6, этому соответствует 216-462 лидерства. Теперь определимся с
типами юнитов. В лесу у нас могут жить волки, бурые и древние медведи, а также тернии-
охотники (как правило, нужно добавлять в армию хотя бы один стрелковый тип).
Обязательными выставим волков и медведей, обоих 20-40% от общего лидерства армии.
Оставшихся двух юнитов сделаем с типом заполнения Addition и процентами заполнения
10-30%.
Рис. 3.20. Лесная заготовка.
4. Логика сессии.
В данной главе мы рассмотрим те аспекты логики, которые живут не на конкретной
локации, а в самой сессии. Такие данные в редакторе называются session internals и
сохраняются отдельно от локаций. Самый важный элемент этой логики – актер. Актер – это
игровой персонаж, контейнер для другой логики вроде диалогов и привязок к квестам.
Смысл такого контейнера в том, что мы с легкостью можем переселить актера с одной
локации на другую, и нам не придется почти ничего перенастраивать. Более того, такое
переселение мы можем делать не только статически в редакторе, но и динамически в игре.
Актеров, героев противника, диалоги, квесты и редактор предметов мы рассмотрим в
отдельных разделах главы. Здесь пока что ограничимся рассмотрением хранилища
глобальных строковых переменных.
Хранилище можно найти в главном меню по адресу Session/Texts. Там находятся
разнообразные тексты, которые можно использовать в диалоговых окнах. В отличие от
всплывающих подсказок на карте и текстов диалогов, диалоговые окна (те, что вызываются
через действие MessageBox) не поддерживают прямого ввода текста. Текст в них можно
вставлять по ссылке. А ссылка ведет как раз в хранилище строковых переменных. Когда мы
настраиваем, например, эмбрион контейнера, у нас есть возможность задать текст для
отображения в диалоговом окне, которое появляется, когда герой подбирает предмет. Для
того, чтобы сделать это правильно, нужно сначала создать в хранилище новую строковую
переменную, а потом выбрать ее в настройке эмбриона из списка. Это связано с
особенностью хранения строк в игре, да и часто одна и та же надпись используется в игре
неоднократно, и использование подобных ссылок упрощает задачу игровых текстов.
Практическая часть.
Подобно тому как мы это делали с логикой локации, сначала составим список того, что
нам нужно сделать для нашего острова:
Все это будет сделано в пределах главы, однако мы еще немного доделаем квест, создав
для него движущуюся платформу.
При этом вы увидите список локаций, к которым привязаны актеры. На самом деле эта
привязка весьма условна и нужна исключительно для вашего удобства. Режим 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, где
выбираем Чудище Грибное. Готово.
Snap – основная составная часть диалога, каждый snap – это один «экран» диалога, где
есть текст, который говорит нам актер, и варианты наших ответов. Каждый вариант ответа по
умолчанию заканчивает диалог, нажав на него и проведя стрелку к другому элементу, мы
создаем связь. Самый первый элемент (это может быть как snap, так и switch), который мы
добавляем в диалог, становится стартовым, и с него диалог запускается по умолчанию, если
мы не укажем в явном виде другое.
Switch – это элемент технического характера. Он отличается тем, что, во-первых, к нему
можно привязать какое-либо действие, а во-вторых, switch может иметь несколько выходов,
из которых логикой будет выбираться лишь один. Общие свойства диалога можно
редактировать сверху: Description позволяет задать техническое описание диалога для
ясности в списке, Priority определяет приоритет диалога при использовании метода Assign
dialog to actor (см. раздел 3.2.4), галочка Important выключает «крестик» в окошке диалога,
через который его можно закрыть. Можно также выбрать актера-хозяина диалога, но мы
изначально создаем диалог уже в актере, так что трогать это не следует. Кнопки Store и
Restore отвечают, как обычно, за импорт и экспорт диалога в .strg-файл.
4.2.3. Основная логика диалога.
Диалоги имеют достаточно гибкую систему настройки, поэтому часто можно достичь
одного и того же результата разными путями. Это вносит некоторую сложность, а потому
имеет смысл рассмотреть ряд стандартных приемов использования диалогов для
достижения тех или иных целей.
Стартовая фраза. Часто необходимо, чтобы при старте диалога вызывался некоторый
snap с большим количеством вариантов ответа, который бы при повторном переходе на него
из другого snap имел некоторую стандартную фразу, но при первом появлении – приветствие
от персонажа. В этом случае имеет смысл начать диалог со switch, у которого два выхода.
Оба связать с интересующим snap, но первому выставить галочку Once per talk и настроить
поле Header override, вбив туда стартовую фразу. Так приветствие появится только
единожды.
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. Начальная структура диалога.
Как и актеры, квесты привязываются к локации. Также по правой кнопке мышки можно
перенести квест в другую локацию или добавить в него диалог. Последнее не
рекомендуется, потому что диалог будет создан без актера и его нужно будет затем
привязывать к актеру. Правильнее будет действовать таким образом: создать в актере
новый диалог, потом зайти в Session/Dialogs, выбрать диалог и во всплывающем меню
выбрать Assign Quest, чтобы прикрепить диалог вместе с актером к квесту. Прикрепление
диалога к квесту не обязательно, но благодаря этому мы можем:
– использовать тег [reward] в тексте диалога, который отобразит награду за квест;
– можно будет работать с диалогом из квеста, что намного удобнее при работе
непосредственно над квестом: все его диалоги собраны в одном месте и открываются для
редактирования одним кликом.
4.3.1. Редактирование квеста, двухмерное представление.
Рис. 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. Например, квест по убийству паука на Дерсу. Так делать проще, когда у квеста совсем
нет ветвления, но сделать сложный квест таким образом нельзя.
Практическая часть.
Также можно настроить до трех типов бонусов по видам. Первый тип – параметр юнита,
например скорость, инициатива или наличие ответного удара. Второй тип – модификация
урона, здесь выбираем тип сопротивления. Наконец, третий тип – модификация
сопротивления. На одном фильтре нельзя настроить два модификатора одного типа.
Параметры модификаторов:
Mod tag – уникальный тег модификатора. Зная тег, мы можем динамически снять его через
Lua-скрипт в бою;
Absolute – абсолютный бонус (или пенальти, если значение отрицательное);
% of base – процент от базового значения;
% of cur – процент от текущего значения;
Duration – длительность действия модификатора в раундах. Как правило, 0 (бесконечно), но
можно выставить и конечную;
DoD – снимать ли модификатор при получении юнитом урона;
Priority – приоритет модификатора, который определяет его порядок в расчетах значения.
Актуально только для тех модификаторов, которые имеют бонус к текущему значению. Чем
выше, тем позже модификатор считается, модификаторы с разным приоритетом имеют
неопределенный порядок расчетов. Этим параметром достаточно сложно управлять, так как
другой модификатор может прийти откуда угодно, и его приоритет будет неизвестен.
В этой короткой главе мы вновь вернемся к редактированию локации. Есть еще три
инструмента, которые не были рассмотрены. Все они достаточно просты в использовании, и
проделывать нижеописанные процедуры необходимо уже в самом конце, когда все
остальное готово. Это – настройка летающих платформ, настройка путей патрулирования
для армий и настройка поверхности полета.
Помимо того, что платформа – это особенный мост, она еще обладает свойствами
multistate-атома, то есть имеет состояния. Состояния отвечают только за анимацию, и на
конечных станциях маршрутов можно настраивать состояние по умолчанию.
Практическая часть.
Начнем с плота–платформы. Создадим две-три станции прямо над водой в районе
пролива, так, чтобы две из них были у берегов. Создадим новый маршрут 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, ее и выбираем. Теперь при получении квеста она становится равной
единице, что нам и надо: это создает достаточное условие для того, чтобы до получения
квеста она не работала.
Осталось сделать пути для армий. Нам нужно всего два пути, для каждого из которых
хватит двух точек. Нужно создать пути, в их рамках создать по две точки и на каждой
выставить 100% исполнение сценария Stop 5 с поворотом армии. Угол поворота задать к
центру острова. Тогда в каждой финальной точке монстр будет смотреть на игрока и будет
выжидать по пять секунд, прежде чем двигаться дальше.
Рис. 5.3. Настройка пути.
Осталось лишь привязать эти пути к нашим армиям. Заходим в настройки атома –
Variables. Там есть переменная path (у всех армий). Кликаем на нее дважды и получаем
возможность выбрать путь из списка. Вот, в общем-то, и все.
Теперь осталось только снять мини-карту, убрать тестовый атом героя и не забыть снова
прописать в session.txt параметр start=darion_1, который вернет нормальное течение игры.
Наша локация полностью готова, теперь на ней можно смело играть!
6. Редактирование арен.
Итак, во-первых, арена – это почти обыкновенная локация в терминах игры.
Обыкновенная потому, что для нее действуют те же самые правила создания, что и для
обычной – на ней нужно создать рельеф, раскрасить ее текстурой и расставить объекты,
сделать освещение, воду (если в ней есть необходимость), настроить небо и задать список
треков (playlist). Однако у такой локации несколько иная логика: например, в ней нет ЛО и
нет логических карт ландшафта, нет карт для полета. Вместе с тем у нее появляется ряд
дополнительных свойств, которые мы и рассмотрим. Одно из различий: у арены нет карты
высот для логических объектов и бойцов. Есть уровень сетки, и на этом уровне стоят
абсолютно все боевые единицы и pawn, боевая поверхность арены всегда будет плоской.
Лишь на внешней части поля боя, за пределами сетки, можно манипулировать рельефом.
расставлять как угодно статичные и динамические объекты и прочее. Еще одно замечание:
непосредственно на поле боя, как правило, не используются обычные статичные объекты.
Вместо них используются атомы другой группы, те, у которых в свойствах align стоит
chessboard. Они специально предназначены для размещения в заданном количестве гексов,
и ориентированы для поворотов на арене – по сторонам гексов. На арене отсутствует и
проходимость в ее обычном понимании. Проходимость ландшафта или объектов на арене
не действует, есть только проходимость клеток.
Слева находится список заготовок. В этом списке можно выбрать заготовку арены из
библиотеки или из других арен и скопировать в текущую арену (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, она выделена желтым цветом), единственный ее реальный смысл – на нее
смотрит камера.
Мы можем настроить специальную камеру для арены, выбрав 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 они отображаются в радианах. Расстояния – в условных метрах. Рост рыцаря на
арене – примерно два условных игровых метра, размер маленького тайла ландшафта –
один условный метр.
На аренах существует ряд атомов, которые сделаны специально для них. В папке Arena/
Decorations можно найти статичные атомы для арен, у которых удобные для размещения на
гексах размеры и прописана привязка align=chessboard, которая автоматически выставляет
атом в центр гекса на арене и выдает ему угол поворота, кратный 60 градусам. Такие же
атомы входят в группы декораций, которые могут автоматически появиться на арене в
гексах, помеченных как Obstacle (Препятствия). На аренах допускается использовать и
динамические атомы, и любые другие, которые не обладают логикой, например, bridge или
land. Объекты с логикой, в принципе, можно выставлять на арену, но логический объект
внутри них нельзя настраивать. Для надежности лучше всего для таких объектов делать
копии и менять им класс на dynamic. Взаимодействовать с ними все равно нельзя, но так мы
избежим возможных ошибок. Например, таким образом сделаны «зрители» на арене Генома
на Рехау.
Следующий класс объектов – chesspiece. Это – войска. Войска (да и любые другие
недекоративные объекты) не стоит выставлять на арену вручную: они в бою появятся сами.
В крайнем случае, их всегда можно дополнительно создать функцией Attack.act_spawn.
Общие свойства chesspiece как бойцов и доступные свойства атак можно найти в
приложениях.
Наконец, последний тип атомов, который необходимо рассмотреть, – pawn. В отличие от
chesspiece, у них может не быть почти никаких свойств и они всегда ставятся на арене в
единственном числе, а не как отряды. Поведение таких объектов полностью настраивается
через скрипты, и такие атомы можно, а порой и нужно выставлять на арену прямо в
редакторе, – в частности, так выставлены боссы. В библиотеке есть все игровые pawns,
которые уже настроены, кроме, разве что, боссов – для них просто нужно назначить гексам
boss-id.
7. Взаимодействие с игрой.
Теперь, когда мы уже обсудили все возможности самого редактора, необходимо
выяснить, как же использовать созданный нами контент в самой игре.
Как уже было сказано в самом начале руководства, сессия – это, по сути, папка-
хранилище. Там находится важный файл session.txt, в котором хранится, в частности,
структура локаций сессии и все необходимые для работы новые и измененные данные.
Данные разделены по папкам и файлам:
В принципе, любой из этих файлов можно двигать в пределах папки сессии как угодно, и
он все равно будет использоваться, так же можно создавать и свои вложенные папки –
данные будут считываться по-прежнему. Сессия также допускает упаковку в .kfs (необходимо
сделать .zip или .rar архив и поменять расширение вручную) и будет читаться из архива.
Распространение дополнения в этом виде, наверное, наиболее логично.
Перед нами стоит две задачи. Первая: как сделать так, чтобы у локации вообще была
карта и чтобы ее можно было вызвать через глобальную карту. Вторая: как сделать так,
чтобы можно было найти навигационные карты локации и реализовать быстрое
путешествие. Остановимся на второй задаче. Каждая навигационная карта, как атом, имеет
тип 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.
Каждый атом в игре может иметь прикрепленные к нему объекты: другие атомы,
спецэффекты, источники света или звуки. Например, пламя, которое горит в глазах импа,
или его хихикание на поле боя – это прикрепленные объекты, или аттачменты. В редакторе
есть средство добавления и настройки этих самых аттачментов. Доступен этот инструмент
через пункт Attachments во всплывающем меню по правому клику на атоме в списке
(необходимо, чтобы опция atoms_editable в editor.ini была включена). Рассмотрим вкратце
возможности редактора, открыв редактор аттачментов для армии – мечника.
Параметры игры хранятся в файлах 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> - тип функции. Неполный список
типов функций:
Как было сказано в самом начале руководства, ресурсы игры делятся на две части:
данные как таковые, атомы, текстуры и прочие глобальные для игры вещи, своеобразные
детали конструктора, и сессию как логику сборки конкретной реализации игры из этого
конструктора. Настало время разобраться, как разбиты ресурсы на части. В папке 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.
Все, что касается редактора, хранится в папке editor или sourcemedia. В корне папки
editor лежат текстовые файлы с внутренними настройками редактора. Редактировать их
нужно только в самых крайних случаях, но там можно посмотреть много полезных вещей. В
файле editor.txt находятся доступные в редакторе настройки величины области отрисовки,
типы камер, курсоры и начальные установки камер. Также там хранятся названия для
логических и пользовательских событий, для таймеров, соответствия сценариев и Lua-
скриптов, названия различных картинок и иконок. Именно там, как правило, и нужно искать
списки меню редактора и соответствие пунктов меню реальным значениям. Также там
можно создавать новые пользовательские события или таймеры и добавлять их в меню
редактора.
Теперь перейдем к sourcemedia. По сути, почти во всех папках лежат .strg-файлы,
которые соответствуют названию папки, это экспортированные настройки воды, эмбрионов,
камеры и еще почти чего угодно.
Здесь же находится очень важная папка terrain, в которой лежат текстуры ландшафта. В
папке materials хранятся текстуры материалов, обычно 1024х1024 пиксела в формате .PNG,
материалы дополнительно разбиты по папкам для группировки. В папке brushes хранятся
текстурные кисти, levels – текстуры уровней, а decal_thumbs – иконки декалей для
отображения в редакторе (сами декали хранятся непосредственно в архивах игры).
Особый интерес представляет собой папка in_progress, там находятся файлы текстур
локаций. Если папка для локации пуста, редактировать текстуру нельзя. Для часто
редактируемых локаций рекомендуется делать резервные копии этой папки, чтобы быть
спокойным за возможность редактирования.
8.6. Горячие клавиши в редакторе.
Общие:
Контроль камеры:
ЛКМ – левая кнопка мыши, ПКМ – правая кнопка мыши, СКМ – средняя кнопка мыши;
Default engine camera:
ПКМ – вращение;
A, D – движение влево/вправо;
W, S – вперед/назад вдоль оси камеры;
Up, Down – вперед/назад без изменений высоты;
Left, Right – поворот влево/вправо;
Pgup, Pgdn – поворот вверх/вниз;
E, Q – движение вверх/вниз;
3DMAX-like camera:
Панель инструментов:
Инструмент рельефа:
Инструмент уровней:
[ – уменьшить кисть;
] – увеличить кисть;
' " – квадратная/круглая кисть;
Pgup – на уровень вверх;
Pgdn – на уровень вниз;
+Shift – стереть.
Объекты на карте:
Логика:
Ctrl + Q – квесты;
Ctrl + A – актеры;
Ctrl + D – диалоги.
Пути:
Монорельсы: