Системный подход к дизайну уровней

Страница 1 из 2

Игорь Пасичный
Закончил Национальный технический университет Украины "Киевский политехнический институт" по специальности "Компьютерные системы, автоматика и управление". В данный момент работает в компании UDC над проектом "Сердце Вечности" в качестве ведущего левел-дизайнера.

Часто приходится сталкиваться с тем, что разработка игрового проекта на просторах СНГ ведется без использования каких-либо методов объектно-ориентированного проектирования, анализа и систематизации. Это приводит к непредсказуемым последствиям, хотя такие методы очень успешно используются компаниями, которые занимаются разработкой обычного программного продукта. Опыт и практические навыки, полученные мною при работе над проектом со значительным размером контента и игровых сцен с закрытыми и открытыми пространствами, я решил изложить в приведенном ниже алгоритме по проектированию игровых сцен.

Само понятие "дизайн" можно трактовать по-разному, например, как творческий метод и процесс художественно-технического проектирования объекта или их комплекса и системы. Метод должен быть ориентирован на достижение наиболее полного соответствия создаваемых объектов и среды поставленной цели. Уровень в компьютерной игре представляет собой систему, которая есть совокупностью разнообразных взаимосвязанных элементов, объединенных единой целью - погрузить игрока в мир виртуальной реальности и раскрыть все особенности геймплея конкретного игрового продукта. Поэтому использование этапов проектирования позволит значительно упростить разработку уровней на основных стадиях разработки игры.

Основные этапы проектирования уровня:

  1. Анализ функциональных и технических требований:
    • составление глоссария;
    • структуризация и классификация основных элементов, которые будут использованы в сцене;
    • разработка и анализ поставленных требований, возможности их реализации в проектируемой сцене.
  2. Концептуальная модель сцены:
    • текстовое описание;
    • структурная схема;
    • план в проекциях;
    • сценарии и варианты их реализации;
  3. Сборка эскизного проекта:
    • построение прототипа сцены;
    • моделирование "пустышек";
    • сборка всей локации, которая является упрощенным представлением для физического движка.
  4. Тестирование эскизного проекта, проверка реализации поставленных задач:
    • игровая механика;
    • физика;
    • основные элементы скриптовых задач.
  5. Принятие решения по эскизному проекту сцены:
    • задачи выполнены и цели достигнуты, переход на 6 пункт;
    • задачи не выполнены переход к 3 пункту(модификация существующего прототипа, или построение полностью нового).
  6. Разработка художественного оформления:
    • выбор общего стиля представления архитектуры;
    • предварительные скетчи основных архитектурных композиций;
    • обсуждение реализации геометрии сцены;
      • создание скетчей или фотоподборка основных архитектурных масс;
      • разработка технических требований к моделям элементам архитектуры на основе требований поставленных в техническом задании;
    • Выбор стафа для сцены:
      • создание скетчей или фотоподборка;
      • разработка технических требований к моделям стафа на основе требований поставленных в техническом задании;
    • Разработка технического задания на основе предыдущих пунктов для:
      • текстуровщиков - тайлы, текстуры стафа, элементов архитектурных масс;
      • моделлеры, левелдизайнеры - модели геометрии и стафа.
  7. Создание геометрии уровня:
    • создание сетки уровня, мапинг, текстурирование;
    • создание сетки объектов, мапинг, текстурирование;
    • контроль качества полученных моделей и текстур.
    • создание библиотеки объектов используемых в игровой сцене, и в всех уровнях.
  8. Первая сборка полной геометрии сцены:
    • построение композиции основных архитектурных масс;
    • заполнение геометрии уровня элементами стафа с учетом общей композиции;
    • единичные объекты;
    • совокупность объектов (малая композиция);
    • совокупность объектов (большая композиция);
    • модульная система
    • настройка элементов геометрии и материалов с помощью скриптов;
    • тестирование геометрии сцены в движке.
  9. Пост процесс:
    • освещение;
    • система частиц (particles) партиклы;
    • другие спецэффекты.
  10. Финальная сборка всей сцены
    • полное тестирование сцены:
      • игровая механика;
      • физика;
      • геометрия уровня;
      • текстуры, освещение, партиклы и т.д.
      • выполнение требований ТЗ;
    • документирование результатов;
    • если присутствуют ошибки, то провести их исправление по установленным приоритетам.
  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 треугольников, или же смоделировать "пустышку" с минимальным количеством полигонов. В дальнейшем такие же "пустышки" должны быть назначены всем объектам, с которыми будут происходить взаимодействие. На данном этапе основными "пустышками" в сцене будут прототипы.

     
      стр. 1 из 2  

    Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

    Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

    Замечания и предложения отправляйте через форму обратной связи.

    Пользовательское соглашение