Системный подход к дизайну уровней
Игорь Пасичный
Закончил Национальный технический университет Украины "Киевский политехнический институт" по специальности "Компьютерные системы, автоматика и управление". В данный момент работает в компании UDC над проектом "Сердце Вечности" в качестве ведущего левел-дизайнера.
Часто приходится сталкиваться с тем, что разработка игрового проекта на просторах СНГ ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. Это приводит к непредсказуемым последствиям, хотя такие методы очень успешно используются компаниями, которые занимаются разработкой обычного программного продукта. Опыт и практические навыки, полученные мною при работе над проектом со значительным размером контента и игровых сцен с закрытыми и открытыми пространствами, я решил изложить в приведенном ниже алгоритме по проектированию игровых сцен.
Само понятие "дизайн" можно трактовать по-разному, например, как творческий метод и процесс художественно-технического проектирования объекта или их комплекса и системы. Метод должен быть ориентирован на достижение наиболее полного соответствия создаваемых объектов и среды поставленной цели. Уровень в компьютерной игре представляет собой систему, которая есть совокупностью разнообразных взаимосвязанных элементов, объединенных единой целью - погрузить игрока в мир виртуальной реальности и раскрыть все особенности геймплея конкретного игрового продукта. Поэтому использование этапов проектирования позволит значительно упростить разработку уровней на основных стадиях разработки игры.
Основные этапы проектирования уровня:
1. Анализ функциональных и технических требований:
* составление глоссария;
* структуризация и классификация основных элементов, которые будут использованы в сцене;
* разработка и анализ поставленных требований, возможности их реализации в проектируемой сцене.
2. Концептуальная модель сцены:
* текстовое описание;
* структурная схема;
* план в проекциях;
* сценарии и варианты их реализации;
3. Сборка эскизного проекта:
* построение прототипа сцены;
* моделирование "пустышек";
* сборка всей локации, которая является упрощенным представлением для физического движка.
4. Тестирование эскизного проекта, проверка реализации поставленных задач:
* игровая механика;
* физика;
* основные элементы скриптовых задач.
5. Принятие решения по эскизному проекту сцены:
* задачи выполнены и цели достигнуты, переход на 6 пункт;
* задачи не выполнены переход к 3 пункту(модификация существующего прототипа, или построение полностью нового).
6. Разработка художественного оформления:
* выбор общего стиля представления архитектуры;
* предварительные скетчи основных архитектурных композиций;
* обсуждение реализации геометрии сцены;
o создание скетчей или фотоподборка основных архитектурных масс;
o разработка технических требований к моделям элементам архитектуры на основе требований поставленных в техническом задании;
* Выбор стафа для сцены:
o создание скетчей или фотоподборка;
o разработка технических требований к моделям стафа на основе требований поставленных в техническом задании;
* Разработка технического задания на основе предыдущих пунктов для:
o текстуровщиков - тайлы, текстуры стафа, элементов архитектурных масс;
o моделлеры, левелдизайнеры - модели геометрии и стафа.
7. Создание геометрии уровня:
* создание сетки уровня, мапинг, текстурирование;
* создание сетки объектов, мапинг, текстурирование;
* контроль качества полученных моделей и текстур.
* создание библиотеки объектов используемых в игровой сцене, и в всех уровнях.
8. Первая сборка полной геометрии сцены:
* построение композиции основных архитектурных масс;
* заполнение геометрии уровня элементами стафа с учетом общей композиции;
* единичные объекты;
* совокупность объектов (малая композиция);
* совокупность объектов (большая композиция);
* модульная система
* настройка элементов геометрии и материалов с помощью скриптов;
* тестирование геометрии сцены в движке.
9. Пост процесс:
* освещение;
* система частиц (particles) партиклы;
* другие спецэффекты.
10. Финальная сборка всей сцены
* полное тестирование сцены:
o игровая механика;
o физика;
o геометрия уровня;
o текстуры, освещение, партиклы и т.д.
o выполнение требований ТЗ;
* документирование результатов;
* если присутствуют ошибки, то провести их исправление по установленным приоритетам.
11. Обсуждение полученных результатов, переход к следующей сцене:
* Ошибки;
* "что-то новое";
* предложения.
Теперь по пунктам.
1. Анализ функциональных и технических требований
Правильно составленное техническое задание позволяет исключить множество часто возникающих ошибок, а также избежать затрат времени на разработку неиспользуемого контента. Каждая команда разработчиков, работая над игровым проектом того или иного жанра сталкивается со следующими ситуациями: используемый в данный момент движок готов для техно-демо, а функциональность реализована на 30-40% или меньше; в проекте используется чужой лицензирований движок, при этом приходится самим встраивать необходимые функции; свой движок - следующий проект.
Каждый из вариантов накладывает свои ограничения и имеет недостатки, связанные с рисками. Независимо от этого должен существовать дизайн-документ или другое функциональное и техническое описание проекта, из которого возможно получить информациию об основных действиях, которые может выполнять игрок при управлении персонажем, группой персонажей либо каким-то объектом:
* набор действий главного персонажа (например: бегать, ползать, прыгать, подтягиваться, выполнять сложные действия с объектами окружающей среды.);
* действия, выполняемые отдельными игровыми персонажами или их группами, взаимодействия с окружающей средой;
* действия, связанные с конкретной спецификой данного жанра игры и т.д.
На основании функциональных описаний из диздока геймдизайнер должен составить список тех действий, которые будут использованы в данной сцене и направлены на максимальное использование игровой механики, доступной на данной стадии реализации движка. Также необходимо обсудить возможность их корректной реализации с программной точки зрения с ведущим программистом, при возникновении больших рисков провести фичкат. После утверждения основных функций необходимо составить базу родительских прототипов и внести их в глоссарий. Прототипы обладают некоторыми атрибутами и представляют собой набор элементов, с которыми будут происходить взаимодействия.
Например:
перекладина - цилиндрический предмет, закрепленный перпендикулярно стене одним или двумя концами; функциональные взаимодействия:
* подпрыгнуть и ухватится;
* раскачивание и прыжок;
* подтянутся и сесть сверху;
* свесится на ногах;
* и так далее.
Когда все прототипы описаны, необходимо составить подробную структуру того, к каким элементам в сцене будут присвоены их атрибуты и функции. По возможности необходимо провести классификацию моделей по группам.
Например:
Прототип канат - объекты, которые наследуют его атрибуты: свисающая веревка, цепь, лиана, торчащие корни и т.д.
Далее прототипы будут использованы при построении тестовой сцены.
Независимо от того, какие ограничения будут возникать в проектируемой сцене в связи с используемыми прототипами, существуют технические ограничения, которые будут влиять на оптимальную производительность игры. Конечно, в данный момент рынок железа предоставляет большое количество мощных аппаратных средств, но это не значит, что ими обладают среднестатистические пользователи. Поэтому при составлении требований к сцене желательно использовать среднюю конфигурацию компьютера и поставить жестокое ограничение на количество полигонов в сцене, размер текстур, источников освещения и т.д. Эти данные также нужно использовать при составлении требований к моделям контента.
2. Концептуальная модель сцены
Концептуальная модель сцены представляет собой ее предметное описание. Если игра делается по книгам, то в качестве такого описания могут служить фрагменты художественного произведения, которые раскрывают основную атмосферу сцены, или же следует разработать собственное текстовое описание, которое может быть дополнено сходными по атмосфере артами и (или) фотоподборкой.
Структурная схема сцены (уровня) представляет собой дерево с разветвлениями, где отдельный блок является фрагментом уровня, см. рисунок 2.1. Структурная схема фрагмента уровня - блоки, с которыми должен выполнять действия персонаж, например, сейф, дверь, сундук, компьютер и т.д.
Рисунок 2.1 - Структурная схема уровня
При необходимости точного воспроизведения фрагмента уровня или всей локации исходя из развития сценария используют план в нужных для этого проекциях, например, см. рисунок 2.2
Рисунок 2.2 - Схематический план комнаты охраны
Сценарий - это специальная последовательность действий или взаимодействий между игровым персонажем и элементами сцены, например, сценарий успешного прохождения коридора с ловушками. Сценарий является экземпляром прецедента - это набор взаимосвязанных успешных и неудачных сценариев, описывающих использование пользователем (игроком) данной сцены в процессе игры для решения одной из задач.
Пример.
Прецедент 1. Сцена - ангар, взлетная площадка.
Основной исполнитель. Пользователь.
Участвующие лица и их требования:
Игровая программа:
# выполняет скриптовые сцены по заложенному алгоритму. В зависимости от действий пользователя выполняет соответствующий алгоритм разворачивания событий. Пользователь:
# отыгрывает роль персонажа. Хочет пройти этап игры в данной сцене, выполнив поставленную перед ним задачу на этом этапе развития сюжета.
Основной успешный сценарий
1. Пользователь: Персонаж заходит в сцену "Ангар" и подход к пульту на балконе.
2. Игровая программа: Скриптовый ролик - антипод главного героя активирует бомбу и покидает сцену через вентиляционную шахту.
3. Игровая программа: скритп - последовательное разрушение сцены.
4. Пользователь:
* Персонаж перепрыгивает с шатающейся балконной платформы№1 на обломок торчащей из стены балки№1. (10 секунд на выполнение).
* Персонаж срывается вниз - переход на основной неуспешный сценарий.
5. Игровая программа: скрипт - отламывается и падает вниз балконная платформа №1, если персонаж находится на платформе, то переход к выполнению неуспешного сценария вариант 1.
6. Пользователь:
* Персонаж отталкивается от балки и прыгает на болтающийся кусок кабеля. (8 секунд на выполнение).
* Персонаж срывается вниз - переход на основной неуспешный сценарий.
7. Игровая программа: скритп разрушение стены, балку№1 взрывом выкидает в сторону, если персонаж на ней то переход к выполнению неуспешного сценария вариант 2.
8. Пользователь:
* Персонаж раскачивается на кабеле и прыгает в сторону вентиляционного проема, хватается за выступ (5 секунд на выполнение).
* Персонаж срывается вниз - переход на основной неуспешный сценарий.
9. Игровая программа: скрипт - взрыв купола, обломки и кабель падают вниз, если персонаж находится на кабеле то переход к выполнению неуспешного сценария вариант 3.
10. Пользователь: Персонаж залазит в вентиляционное отверстие и двигается по нему.
11. Игровая программа: новый сюжетный скриптовый ролик.
И так далее.
На основании данного сценария в техническом задании указываются, какие прототипы объектов в сцене должны быть использованы, какие объекты будут использованы в скриптовой анимации.
3. Сборка эскизного проекта
Для того, чтобы удостоверится в правильности работы игровой механики, кинематики, срабатывания скриптовых сцен и игровых фич, которые необходимо предоставить пользователю на данном этапе игры, нужно построить первый прототип сцены - эскизный проект. Прототип сцены представляет собой ее упрощенное представление с использованием несложных геометрических элементов и базовых родительских прототипов элементов сцены с нужными атрибутами.
Что такое "пустышка"? Все очень просто, существую так называемое понятие колижина, алгоритмы его расчета для взаимодействия объектов разные, но чем сложнее геометрия объекта, тем больше программных расчетов необходимо провести, и все это влияет на оптимальную производительность. Исходя из этого, сложный геометрический объект сцены лучше заменить простой - геометрической "пустышкой", параметры которой будут использованы в программных расчетах. Например, в сцене есть контейнер на 400-500 треугольников, к нему можно привязать самый обычный бокс на 12 треугольников, или же смоделировать "пустышку" с минимальным количеством полигонов. В дальнейшем такие же "пустышки" должны быть назначены всем объектам, с которыми будут происходить взаимодействие. На данном этапе основными "пустышками" в сцене будут прототипы.
4. Тестирование эскизного проекта, проверка реализации поставленных задач
Итак, свершилось, первый прототип сцены собран. Необходимо провести тестирование эскизного проекта и получить ответы на некоторые вопросы. А действительно ли все так, как мы хотели? Насколько удачной будет такая сцена, отрабатываются ли здесь те элементы, которые хотели "засветить" геймдизайнеры? Получается ли реализация нужных фич, есть ли нужная динамика? И вообще, как ведет себя физика? Перечень вопросов довольно велик.
5. Принятие решения по эскизному проекту сцены
Отчет по тестированию эскизного проекта составлен, есть "за и против". Теперь необходимо принять решение: станет ли прототип готовой игровой сценой, нужна ли вообще такая сцена? Это очень важный шаг, так как если решение будет принято неправильно, сцену смоделируют, наполнят контентом, но потом не будут использовать в готовом проекте, то это потраченные впустую время и деньги. Чего, зачастую, обычно и не хватает разработчикам. На модификацию прототипа или разработку нового уйдет гораздо меньше времени, чем на готовую собранную сцену.
6. Разработка художественного оформления
Для того, чтобы прототип сцены превратится в полноценную игровую сцену, необходимо проделать еще очень большой объем работы, связанный с художественным оформлением. Фактически, графическое оформление определяет настрой игры, придает целостность ее идее, и очень часто художественный стиль становится той самой изюминкой, которая привлекает к проекту значительную часть потребительской аудитории. На оформление влияет множество различных факторов - жанр игры, возможности движка, креатив и квалификация концепт-художников, моделеров, левел дизайнеров и текстуровщиков.
При разработке графического оформления необходимо определится со стилем всего игрового содержания, например, общим стилем архитектуры. Для этого нужно составить подборку соответствующих фотографий, артов, сделать предварительные скетчи архитектурных композиций. На основе, например, "мозгового штурма" провести выборку стафа с соответствующим составлением групп по игровым сценам.
В связи с этим очень часто возникает вопрос: насколько детально нужно прорабатывать сцену? По большей части, настолько, чтобы быстрый взгляд со стороны заставил поверить в живость происходящего в ней. Иногда некоторые мелкие детали существенно изменяют все восприятие в поставленной сцене. Так, например, для большого заброшенного ангарного помещения или какой-то промышленной зоны со станками и поломанным оборудованием следует добавить мелкие композиционные детали: разбросанные кучи ржавого металлолома, элементов оборудования, тары и так далее.
Следующим шагом является разработка четких технических требований в техническом задании по геометрии моделей, которые будут содержаться в игровой сцене. Исходя из требований оптимальной производительности, необходимо провести расчет количества полигонов и максимальных размеров текстур.
7. Создание геометрии уровня
Подходов при построении сеток объектов и создании текстур много, каждый может основываться на личном опыте сотрудника и зависеть от геометрии нужного объекта. Необходимо учесть, что кроме основных моделей на данном этапе также нужно сделать геометрию "пустышек" и LOD'ов, если таковые не рассчитываются автоматически в движке.
Геометрия основных элементов сцены связана с жанром игры и должна быть соответственно оптимизирована, что четко оговорено в техническом задании. Например, определенное позиционирование и поведение камеры позволяет значительно упростить геометрию архитектуры, но изменения этих атрибутов повлечет за собой новые доработки геометрии.
Очень важен на данном этапе контроль качества моделей и текстур, так как пропущенные ошибки будут блистать в финальной сцене и могут требовать значительных затрат времени на их устранение. Зачастую это плохие карты текстур объектов, двойные фейсы и ребра, не сшитые вершины, т-соединения, направленные не в ту сторону нормали, лишние полигоны внутри модели и тому подобное. Все это лучше отсекать сразу - если ваши персонал работает, например, в 3ds max, пусть использует STL Check, инструмент обнаруживает и отображает ошибки в геометрии объектов. Нормали можно проверить, включив их в соответствующих опциях, а карты текстур с использованием шахматки в материалах - Checker.
В программировании существуют некоторые формальные правила хорошего тона при написании кода - к ним относятся, в частности, использование комментариев и специальных имен для переменных, атрибутов, функций и т.д. Что также необходимо применять при моделировании: составьте базу данных моделей, текстур, материалов, которые используются в проекте, все это упростит процесс разработки и в будущем сэкономит время.
Наиболее актуально в дизайне уровней использовать модульную систему. Зачастую все движки имеют свои редакторы карт с определенными модулями и библиотеками. Вся геометрия моделируется в 3ds max или Maya, исходя из этого сцена в редакторах может строиться по следующим принципам:
* основная архитектурная композиция собирается в 3D-редакторе, там же рассчитываются теневые карты, затем происходит экспорт в редактор карт, где строятся локальные композиции при помощи библиотечных объектов и наборов скриптов;
* сцена полностью собирается из библиотечных модулей и объектов.
Эти варианты предусматривают использование библиотеки объектов окружения, источников освещения, партикловых эффектов и т.д. Объект в библиотеке может представлять собой:
* основную сетку;
* экспорт;
* LOD;
* "пустышку" - сетку для физики;
* прототип;
* набор текстур;
* набор звуков;
* набор партикловых эффектов;
* скрипты - настройки атрибутов физики, материалов, эффектов и т.д;
* другие атрибуты.
Редактор карт должен обладать необходимой функциональностью и позволять постановщику свободно манипулировать объектами в сцене, поэтому желательно, чтобы дизайнеры чаще консультировали программистов по этому поводу. Непосредственное построение сцены в редакторе карт позволяет увидеть игровую сцену глазами игрока, тем самым лучше акцентировать внимание на необходимом сюжетном моменте, построив необходимую для этого композицию.
8. Первая сборка полной геометрии сцены
Композиция - это система правил и приемов взаимного расположения частей и объектов сцены в единое гармоническое целое. Умение составлять композицию игрового уровня - искусство, которое дает возможность точно и выразительно размещать изображение в пределах поведения формата камеры. Глазу присуще видеть и воспринимать окружающий нас мир в пропорциях и соразмерностях, то есть сама природа положила в основу нашего зрения качества, позволяющие определить прекрасные пропорции. Выразительная композиция в игровой сцене подразумевает наличие гармоничности, при которой глаз играющего не ощущает несоответствия размеров частей и целого, а сочетания не раздражают его восприятие. Не стоит подходить к этому этапу по принципу "а чего там, сейчас в редакторе предметы растыкаем!"
Нужно научится композиционному видению, которое дизайнер уровней может развивать различными способами. Лучше всего использовать подход от простого к сложному, начать с одного объекта, а потом включать в компоновку два и более.
При работе над композицией в рабочей сцене необходимо:
* определить смысловое содержание постановки;
* построить черновую постановку и определить основные точки зрения, которые могут возникать у игрока;
* установить необходимые масштабы предметов и разместить их;
* определить центр композиции;
* выявить целостность сцены посредством использования источников освещения и получения игры светотеней;
* при возможности использовать пост эффекты, тем самым обобщить и завершить работу над композицией.
При разработке игр с большим количеством контента в сценах целесообразно в редакторе использовать библиотечные объекты, которые представляют собой совокупность объектов малой или большой композиции, или заранее построенные модули игровых сцен, примером чего может быть, скажем, комната с уже расположенными в ней объектами. При этом используется максимальный набор предметов в модуле, а легкая манипуляция над ними в редакторе карт позволяет быстро получать разнообразные блоки в игровой сцене. Модульный дизайн требует качественного проектирования, ответственности и контроля качества.
Ложкой дегтя при построении композиции игровой сцены порой становится то, что поставленный не в нужном месте предмет может приводить к критическим программным ошибками, например, персонажи будут застревать или вести себя не так как предписывают скрипты.
Завершающим шагом данного этапа является настройка сцены при помощи скриптов - от дальности рендера объектов до анимации объектов. После чего можно тестировать собранную сцену в движке на наличие ошибок геометрии, которые различными способами могут повлиять на игровой процесс.
9. Пост-процесс
Игровая сцена это не только геометрия - пустые, блеклые "картонные" коробки нужно оживить, преподнести к взору игрока и заставить его поверить в правдивость происходящего... Порхающие бабочки, светлячки, колышущиеся деревья и трава, водная рябь и брызги, отражения, пыль... это есть пост-процесс. А еще - свет! Что, как не свет и игра теней передает нужную атмосферу? Конечно, систему частиц, систему освещения и шейдерные эффекты с бампом и паралаксом программисты осилят с точки зрения технической реализации, только все это еще нужно эффективно использовать. Так, неправильно поставленный свет ведет к разрушению архитектурных форм. Поэтому вопрос должен решатся с привлечением специалистов из данной области, что и определит влияние полученных статические и динамические теней на завершенность композиции в сцене.
Останавливаться более подробно на системе частиц и других спецэффектах в данной статье нет смысла, так она несет чисто обзорный характер. В сущности, система частиц подлежит отдельному проектированию, с постановкой целей и подробным описанием задач и методов их решения.
10. Финальная сборка всей сцены
На данном этапе игровая сцена представляет собой полностью композиционно завершенную систему:
* геометрия;
* освещение и теневые карты, материалы;
* сетка АI;
* партикловые эффекты;
* скриптовая анимация объектов;
* другие эффекты пост-процесса.
То есть, практически, является той сценой, которую используют в бета-версии. Такой вариант подлежит внутреннему тестированию с фиксированием и документированием всех ошибок, которые не только присутствуют в сцене и нарушают целостность ее художественного и композиционного оформления, но и влияют на возникновение ошибок в работе игровой механики, физики и во всем игровом процессе в целом. Результаты полного тестирования заносятся в отчеты: баг- или фикс-листы. Найденные ошибки необходимо отсортировать в группы по приоритетам их исправления, и использовать составленные отчеты для выдачи коррекции.
11.Обсуждение полученных результатов, переход к следующей сцене
Выводы и анализ полученных результатов, часто возникающие ошибки и методы их устранения. Небольшая критика и похвала персонала. Обсуждение рисков при реализации следующей сцены, есть ли необходимость введения других методов решения поставленных задач. А также предложения, именно предложения, личный профессиональный опыт сотрудников и возникающие у них идеи при разработке, могут внезапно принести очень хорошие решения. Кто, например, как не левел-дизайнеры, расскажут об основных проблемах при работе с редактором сцен, и чего им не хватает для комфортной работы с точки зрения программной реализации? Пользуйтесь "мозговым штурмом", а затем проводите четкий анализ полученных идей. И если это необходимо, корректируйте алгоритм действий при построении следующей сцены.
Заключение
Каким бы ни был жанр вашего проекта, дизайн уровней представляет собой очень сложный процесс, которому требуется предварительное проектирование. Потраченное время на составление технической документации и технического задания ускорит разработку и значительно упростит вам жизнь. Лучше выявить подводные камни заранее и спокойно миновать их, чем потом тратить время на коррекцию критических ошибок, которых можно было бы избежать. Если методы объектно-ориентированного проектирования давно и повсеместно используются при разработке различных систем, в том числе и программного обеспечения, так что мешает нам воспользоваться этими инженерными наработками в разработке компьютерных игр?
http://dtf.ru/articles/read.php?id=43163&page=2
Социальные закладки