Как-то раз барон Мюнхгаузен зашел в гости к разработчикам компьютерных игр. Ходил, смотрел и удивлялся их мастерству. Игры у них выходили ладные и искусные. Уже уходя, барон попросил дать ему чертеж или схемку, по которой он смог бы у себя в Германии сделать такие же. Он бы даже рад был заморозить неуловимое искусство, как замораживал звук рожка в одном из своих прошлых путешествий. Но на дворе было жаркое лето.

Разработчики сконфузились. Ведь делали они игры по старинке — на глазок да на зубок. Но не скажешь же такого немцу, немец — он порядок любит. Надо спасать престиж, решили разработчики и крепко задумались.

Филькины грамоты

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

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

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

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

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

Также это дает шанс для существования прослойки дизайнеров, которые не ассоциированы с постоянным местом работы и могут производить за время полномасштабного цикла разработки не одну игру, а несколько готовых дизайнов. Которые потом реализуются студиями независимо от дизайнеров. Так, собственно, происходит с киносценаристами, которые могут продавать готовые сценарии. До сих пор у дизайнеров такого инструмента нет. Почему? Я полагаю, это всего лишь вопрос времени и юности индустрии. Разработка таких средств велась на заре игровой индустрии, но теперь не успевает за ростом индустрии. Вероятно, в будущем, когда будут достигнуты пределы роста в индустрии и преимущество разработчиков будет заключаться не в способность экспансивного роста, а в способности более рационально использовать имеющиеся ресурсы, такие приемы работы станут востребованы.

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

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

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

Человекообразный автомат

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

На заре развития кибернетики ученые-бихевиористы задались целью найти язык для описания действий человека — программ, которым он следует в повседневной жизни. Ученые отметили, что для каждого действия человека можно выделить цель, которую он хочет достичь. Для достижения каждой цели человек использует набор действий. Чтобы выбрать то или иное действие, человек проверяет, совпадает ли текущее состояние с конечным. Если да, то он завершает действие, если нет — предпринимает новые попытки. Цель, действия, проверка-завершение, сокращенно — ЦДПЗ. В английской литературе используется сокращение TOTE.

Эта модель поведения очень проста. Например, нам надо взять в руки чашку. Мы представляем себе, как чашка находится у нас в руках. Мы смотрим на чашку и отмечаем, что она находится от нас на отдалении. Мы начинаем движение к чашке, постоянно проверяя, приближаемся мы к ней или, наоборот, удаляемся. Для такого простого действия все проверки происходят за границами сознания, но на замедленной съемке было бы видно, что мы не идем к чашке самым прямым путем, а постепенно «заходим на цель», постоянно промахиваясь и корректируя курс. Наши действия — разные движения рук и тела — постепенно приближают нас к цели. Когда чашка наконец оказывается в наших руках, мы переключаемся на следующую цель. Разумеется, цель взять чашку может быть составной частью другой, более сложной цели. Скажем, попить чаю. Цели могут организовываться в иерархии, но как бы сложны они ни были, мы всегда можем описать их иерархической моделью ЦДПЗ.

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

Ведь ничто не мешает описать в терминах ЦДПЗ поведение человека в течение игровой сессии и даже в течение всего прохождения. То есть вместо того чтобы гадать, как поступит игрок в той или иной ситуации, дизайнер может занять активную позицию и сформулировать то, как он хочет, чтобы пользователь вел себя от начала игры до конца. Дизайнер сразу оказывается за рулем. Он может ставить конкретные цели и впоследствии их достигать. Это уже более наука, чем искусство.

Конечно, скептически настроенный читатель скажет, что дизайнер волен ставить какие угодно цели, но это бесполезно, если их невозможно достичь. Разумно. Но модель ЦДПЗ поможет и в этом. Ведь точно так же дизайнер может описать желаемое поведение компьютерного игрока. Для этого ему нужно будет ответить на следующий вопрос — если я хочу, чтобы человек вел себя в соответствии с тем, как я для него задумал, то что должен делать компьютер, чтобы помочь в этом игроку?

Две половинки лошади

Игра — занятие социальное, и обе стороны одновременно учитывают действия друг друга. Они образуют саморегулирующуюся систему.

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

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

Одна из сторон совершает какое-то действие. Другая начинает немедленно оценивать ситуацию и свое действие выбирает исходя из того, что делает противник. Чем, в свою очередь, дает пищу для размышлений. Обе стороны становятся друг для друга источником обратной связи. В игровом пространстве — единственным источником.

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

Входит и выходит

Вообще говоря, все сводится к такому скучному понятию, как устройства ввода-вывода. Ввод сводится к нажатию клавиш и их комбинаций, а также к перемещению аналоговых манипуляторов (на ПК обычно мышь, на приставках — аналоговые джойстики). Вот, собственно, и все. В последние пару лет Nintendo подарила нам новые способы ввода — аналоговые перемещения манипулятора на Wii и сенсорный экран/микрофон на Nintendo DS. Тем не менее описать последовательность ввода игрока — задача тривиальная. Обратная связь от компьютера немного более разнообразна и заслуживает более подробного рассмотрения.

Наиболее очевидным способом предоставления обратной связи от компьютера к игроку является демонстрация образов на мониторе. Другим необязательным, но все равно часто используемым приемом становится звуковой канал. Для человека в западной культуре важным является еще один канал восприятия — кинестетический, то есть канал телесных ощущений. Но современные компьютеры напрямую с этим каналом работают с трудом. Если на приставках вибрирующие элементы геймпадов уже стандарт, то на PC технология force feedback пока еще не особо прижилась. К счастью, особенности восприятия до определенной степени позволяют обойти это ограничение, но об этом ниже.

Итак, чтобы узнать, что сделал компьютер, игрок должен что-то увидеть, услышать или почувствовать. (в нашей культуре люди поразительно ловко оперируют образами, поэтому я буду в основном упоминать визуальную составляющую, но подразумевать также звуки и в меньшей степени ощущения). Что же видит игрок в процессе взаимодействия с программой? Глупый вопрос — картинку на экране, окно в игровой мир, игровой интерфейс.

Описать традиционные элементы интерфейса — кнопки, полоски, индикаторы и тому подобное — не составляет никаких проблем. Это делается на уровне технического задания для программиста интерфейса. Чтобы представить ту же информацию в модели ЦДПЗ, ее нужно лишь по-другому структурировать.

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

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

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

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

Что вижу, то пишу

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

Рассмотрим их по порядку — характеристику и способ ее объективного измерения. Ну, во-первых, само наличие или отсутствие элемента на экране. Другим параметром являются линейные размеры элементов. Ширина, высота описанного вокруг элемента или вписанного в элемент прямоугольника.

1) Цвет. Понятная характеристика распадается на три основных составляющих, которые могут быть известны тем, кто более или менее часто работал с «Фотошопом».

2) Насыщенность — насколько насыщен цвет элемента. Это параметр Saturation в цветовой модели HSV.

3) Цветовой тон — то, что в простонародье именуется цветом. Hue в той же модели HSV.

4) Светлота или яркость — Value в той же модели.

5) Резкость образа — насколько он резок или размыт. До недавнего времени все элементы на компьютерных образах были до безобразия четкие и имели характерный компьютерный вид. Как максимум симулировались эффекты размытия движения отдельных элементов. Сейчас эффект размытости становится доступен дизайнерам благодаря развитию графических карт и движков. Очень эффектное применение этому приему было найдено в игре Myst 4: Revelation, где разная степень размытости частей картинки призвана подчеркивать текущий фокус внимания игрока. Степень размытости может быть количественно задана как набор параметров алгоритма размытия (например, для фильтра Gaussian Blur количество пикселей, на которое размывается изображение и центр эффекта).

6) Форма элемента определяется во многом его силуэтом. К примеру, из анимации известно, что читаемость какого-то действия в большей степени определяется тестом на силуэт, если по черному силуэту персонажа на белом фоне непонятно что происходит, то прорисовка деталей не сильно улучшит положение вещей. Уникальность мультипликационных персонажей во многом определяется их силуэтом. Если вы хотите сделать ставку на персонажа, неплохо было бы сравнить его силуэт с силуэтами уже существующих. И в данном случае копирование — это неэффективный путь.

Для измерения и сравнения силуэтов между собой можно использовать характеристики линий — такие, как кривизна (минимальная и максимальная), распределение отрезков разной кривизны по периметру. Можно измерять симметричность контура относительно какой-либо оси, минимальный и максимальный радиус от геометрического центра, распределение различных радиусов по периметру. Или можно использовать разработанный в принстонском университете дескриптор геометрических моделей. Он предназначен для экспериментального поисковика моделей, но можно позаимствовать его и для наших целей.

7) Детальность — наличие или отсутствие на элементе большого количества различимых деталей. Ранние образы компьютерных игр были бедны деталями и абстрактны, в современных играх присутствует тенденция к постоянному увеличению деталей, что делает игровые образы предположительно более реалистичными, а скорее более конкретными — игроку меньше остается додумывать в образе элемента, меньше достраивать. С одной стороны, это делает картинку более зрелищной, с другой — усложняет отождествление игрока с происходящим, если образ угадан неверно (когда игрок по-другому представляет себе изображаемый предмет или явление). Детальность можно измерить как размер минимальной различимой детали в пикселях или процентах площади элемента и распределение деталей разного размера в составе одного элемента. Иногда деталь одного элемента может вполне считаться отдельным элементом. Тогда для нее можно определить свой набор характеристик.

8) Пропорции — в простейшем случае отношения линейных размеров различных частей элемента между собой. Тут все как обычно: длина к высоте, длина одной части к другой.

9) Положение — где именно в пределах экрана находится элемент. Думаю, координат геометрического центра или угла описывающего прямоугольника хватит.

10) Наличие или отсутствие у элемента контура. Не путать с силуэтом. Силуэт присущ любой замкнутой форме. А контур — это выделение силуэта дополнительной линией. Обычный пример — контур при выделении персонажа по границе его модели.

Для 3D-игр доступны манипуляции с виртуальной камерой, и для всего кадра можно определить ряд характеристик, связанных с ней.

1) Угол зрения (Field of View). В оптике различают вертикальный и горизонтальный угол зрения, которые для системы линз (в том числе и человеческого глаза) тесно связаны с глубиной резкости и перспективными искажениями. Как говорилось выше, изображение глубины резкости только начинает широко применяться в реальном масштабе времени, но перспективные искажения являются неизбежными спутниками трехмерной сцены. Угол зрения измеряется в градусах.

2) Точка зрения — но более компактно будет просто указать координаты виртуальной камеры в сцене и углы поворотов.

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

Долгая дорога в душу

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

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

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

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

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

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

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

А способ объективной записи позволит однозначно для всей команды описать, как все должно быть.

За волосы из болота

Нельзя сказать, что современная игровая документация не стремится к этому. Но обычно информация содержится сразу в нескольких документах и бывает нелегко проследить связь между ними. А с использованием модели ЦДПЗ можно все связать воедино.

Можно написать «партитуру» игры. Выглядела бы она как два длинных нотных стана с несколькими линиями. Один стан (желаемая партитура игрока) — его эмоциональное состояние и его действия. Эмоции изобразить несложно — словами или обычными смайликами. Другой стан — «партитура» компьютера. На нем будут отмечаться его действия в ответ на сигналы игрока.

Для достижения каждой цели человек использует набор действий. Чтобы выбрать то или иное действие, человек проверяет, совпадает ли текущее состояние с конечным. Если да, то он завершает действие, если нет — предпринимает новые попытки. Цель, действия, проверка-завершение, сокращенно — ЦДПЗ.

Между двумя станами слева направо расположена временная ось игры. Переходы хода показываются стрелками от одного стана к другому. По внешним краям каждого стана находится самая крупная программа в модели ЦДПЗ: «сыграть в игру». Чем ближе к центру, тем больше дробятся блоки: Отдельные меню и игровые уровни, затем взаимодействие между игроками внутри уровня, и так далее, постепенно разукрупняя до конкретных действий. А в самом центре будут управляющие действия игрока, с одной стороны, и изменения индикаторов программы — с другой. Такая запись заметно облегчит жизнь разработчикам.

Для каждого игрового элемента можно будет проследить его родословную и понять, для реализации какой части игрового процесса он нужен. Для каждого момента игры можно посмотреть состояния всех элементов. Отследить их одновременное появление, насколько равномерно игроку предъявляются новые элементы. При этом все параметры описаны численно, что позволит с большой точностью определять, достигнута ли поставленная цель разработки, и если нет, то что именно нужно изменить, чтобы она была достигнута. На более высоких уровнях иерархии программисты команды найдут описание того, как именно связаны элементы между собой. Это позволит с большей уверенностью на ранних стадиях разработки создавать технический дизайн игры. Структуры модели ЦДПЗ достаточно просто описываются с использованием UML или других средств прототипирования кода.

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

Кроме того, можно будет в объективной форме фиксировать удачные решения и тиражировать их. Можно будет делать copy/paste отдельных блоков дизайна из проекта в проект.

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

Я не претендую на истину в последней инстанции. Вдумчивый читатель найдет в моих идеях проблемные места, над которыми еще предстоит работать. Но я убежден в одном. Каждый, кто интересуется разработкой игр, должен задуматься и искать для себя ответ на вопрос: каким мог бы быть универсальный язык описания геймплея. Рано или поздно ответ будет найден, и мы все получим радость от тех удивительных игр, которые будут созданы после этого.

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