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

Задачи о размещении объектов

Электронные таблицы для этой части можно скачать здесь: (SuperTank) (телепорты, часть 1) (телепорты, часть 2)

SuperTank: задача решена!

В первой статье серии мы рассказали о примере задачи для игры под названием SuperTank. Во второй её части, мы познакомились с основными концепциями моделирования решений и я рассказал о решении простого примера с помощью инструмента «Поиск решений» в Excel.

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

Аннотация

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

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

Для записи трёхмерных поворотов программисты графики используют кватернионы. Однако в кватернионах сложно разобраться, потому что изучают их поверхностно. Мы просто принимаем на веру странные таблицы умножения и другие загадочные определения, и используем их как «чёрные ящики», поворачивающие векторы так, как нам нужно. Почему $$ и $$? Почему мы берём вектор и превращаем его в «мнимый» вектор, чтобы преобразовать его, например $$? Да кому это интересно, если всё работает, правда?

Существует способ описания поворотов под названием ротор, который относится к области и комплексных чисел (в 2D), и кватернионов (в 3D), и даже обобщается до любого количества измерений.

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

Кроме того, для визуализации и понимания трёхмерных роторов не нужно использовать четвёртое пространственное измерение.

Было бы здорово, если бы начали вытеснять использование и изучение кватернионов, заменяя их роторами. Заменить их очень просто, а код останется почти таким же. Всё, что можно делать с кватернионами, например, интерполяцию и устранение блокировки осей (Gimbal lock), можно сделать и с роторами. Но понимать мы начинаем гораздо больше.

Проблема сложности в играх обсуждаются уже давно. Были предложены, проанализированы и реализованы различные альтернативы традиционному выбору уровней сложности в начале игры. И несмотря на то, что они исправляют ошибки традиционного подхода, внутри них возникает множество других неотъемлемых проблем и сложностей. Поэтому я хотел бы предложить ещё одну альтернативу — это скорее не механическое решение, требующее реализации, а другой подход к созданию дизайна сложности.

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

Но сначала я попробую вкратце перечислить наиболее распространённые претензии к традиционной схеме с уровнями сложности и к её альтернативам.

Мы занимаемся поиском, а не итерациями

В основном геймдизайн — это процесс поиска. Занимаясь дизайном, мы исследуем множество возможных конфигураций дизайна для решения конкретной дизайнерской задачи. Например, это может быть способ соединения комнат в подземелье, набор функций и навыков, которыми владеют различные игровые агенты, «магические числа», определяющие эффективность юнитов в боевой системе, или само сочетание возможностей, которые будут присутствовать в нашей игре.

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

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

Такие «итерации» совсем непохожи на линейные изменения, которые обычно происходят в «итерациях» компьютерного кода; гораздо больше они напоминают поиск в лабиринте со множеством резких поворотов и вынужденных возвратов назад. Часто они приближают нас к цели, но часто оказывается непонятно, улучшилась ли от них игра. Иногда обнаруживается, что изменения дизайна, которые, по нашему мнению, должны были улучшить игру, имеют непредвиденные изъяны и нам нужно откатить них или попробовать заново.

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 20: туман войны

• Сохраняем данные ячеек в текстуре.
• Изменяем типы рельефа без триангуляции.
• Отслеживаем видимость.
• Затемняем всё невидимое.

В этой части мы добавим на карту эффект тумана войны.

Теперь серия будет создаваться на Unity 2017.1.0.


Теперь мы видим, что можем и не можем видеть.

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 8: вода

• Добавляем в ячейки воду.
• Триангулируем поверхность воды.
• Создаём прибой с пеной.
• Объединяем воду и реки.

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


Вода прибывает.

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 12: сохранение и загрузка

• Отслеживаем тип рельефа вместо цвета.
• Создаём файл.
• Записываем данные в файл, а затем считываем его.
• Сериализуем данные ячеек.
• Уменьшаем размер файла.

Мы уже умеем создавать достаточно интересные карты. Теперь нужно научиться их сохранять.

От переводчика: эта статья — первая из подробной (27 частей) серии туториалов о создании карт из шестиугольников. Вот, что должно получиться в самом конце туториалов.

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 1: создание сетки из шестиугольников

Оглавление

• Преобразуем квадраты в шестиугольники.
• Триангулируем сетку из шестиугольников.
• Работаем с кубическими координатами.
• Взаимодействуем с ячейками сетки.
• Создаём внутриигровой редактор.

Этот туториал является началом серии о картах из шестиугольников. Сетки из шестиугольников используются во многих играх, особенно в стратегиях, в том числе в Age of Wonders 3, Civilization 5 и Endless Legend. Мы начнём с основ, будем постепенно добавлять новые возможности и в результате создадим сложный рельеф на основе шестиугольников.

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 4: Неровности

Оглавление

• Сэмплируем текстуру шума.
• Перемещаем вершины.
• Сохраняем плоскостность ячеек.
• Подразделяем рёбра ячеек.

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