Тайнан Сильвестр - Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше

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

Не было такого дня, когда самолет был бы готов. В течение многих итераций его производительность постепенно улучшалась. В 1899 году они запустили воздушного змея шириной полтора метра. В 1900 году они запустили достаточно большой планер, который мог поднять человека. Планер 1902 года имел новые рули и систему управления, позволяющую пилоту совершать управляемые повороты влево и вправо. В 1903 году они добавили двигатель и полетели с подачей энергии и возможностью управления, но всего на несколько секунд в нескольких метрах над землей. Райты продолжали работать, улучшая слабые стороны проекта, учась на ошибках и достигая больших успехов. К 1905 году Уилбур совершал 40-минутные полеты на расстояние 32 км. Они работали в течение шести лет.

Задача геймдизайнера имеет много общего с задачей Райтов. Как и самолет, игра – это система. Она служит другой цели, но процесс изобретения принципиально тот же. Геймдизайнеры – это изобретатели машин для генерирования опыта.

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

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

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

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

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

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

Популяция лосей значительно выросла. Вскоре огромные стада лосей начали съедать осины и ивы. Это привело к исчезновению бобров, так как у них не осталось достаточно древесины для плотин. Без плотин парк начал пересыхать каждое лето. Для рыбы не осталось водоемов, и вскоре озера опустели. С исчезновением рыбы упала популяция гризли, так как они выживали благодаря пойманной из рек рыбе. С исчезновением гризли и появлением такого количества лосей, на которых можно охотиться, выросла популяция волков. Рост популяции оленей вскоре прекратился из-за волков и выпаса лосей.

И изменения продолжались, распространяясь на всю экосистему…

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

Ключ к ответу на этот вопрос заключается в понимании зависимостей.

ЗАВИСИМОСТЬ – это такое отношение между двумя частями проекта, когда изменения в одной части вызывают изменения в другой.

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

В геймдизайне все не так. Различные части дизайна часто взаимозависимы. Внешний вид уровня зависит от оформления этого уровня. Оформление зависит от инструментов игрока. Инструменты игрока зависят от базового интерфейса. Если какой-либо элемент изменяется, то изменяется и каждый зависимый от него элемент.

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

Анимация зависит от дизайна системы движений персонажа; изменение в системе движений повлияет на анимацию и испортит хорошую работу. Если бы мы лучше понимали зависимости, мы могли бы сначала укрепить механику движения (в «сером ящике»), а потом делать анимацию.

Стек зависимостей

Чтобы понять зависимости в дизайне, дизайнеры могут построить стек зависимостей.

СТЕК ЗАВИСИМОСТЕЙ – это простой метод анализа, который определяет ключевые зависимости между элементами проекта. Так мы можем понять, над чем нужно работать сейчас, а что можно оставить на потом.

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