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

Каскадная неопределенность

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

Неопределенность усиливается в результате зависимостей.

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

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

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

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

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

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

Чтобы стек «набеги гоблинов» работал, как и было запланировано, мы сначала должны реализовать персонажей, строительство, строительство стен и боевые системы. Если в какой-либо из этих систем произойдет значительный сдвиг, изменения будут проходить каскадом через стек зависимостей и приводить к изменениям в стеке «набеги гоблинов». Даже если каждый из этих основополагающих элементов имеет чрезвычайно благоприятную определенность в 80 %, то вероятность того, что стек «набеги гоблинов» сработает так, как и ожидалось, умножится на 0,8 в пятой степени, или на 0,33 (33 %), поскольку ошибка в любом из пяти основополагающих элементов приведет к изменению в стеке «набеги гоблинов».

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

В большинстве дизайнов нет даже 80 % определенности. При разработке рискованных, теоретически прорывных игр большинство проектов терпят неудачу. Определенность в системе часто составляет менее 30 %. При таких условиях дизайн пяти слоев вверх по стеку зависимости останется неизменным в 0,2 % случаев. Так что, в принципе, никогда.

Это значит, что большая часть написанного дизайна для Fantasy Castle – ерунда. Фундаментальные системы почти наверняка изменятся при реализации или тестировании, и эти изменения будут проходить каскадом через дизайн, приводя к изменениям везде. Концепции могут остаться, но все особенности будут меняться снова и снова. К концу разработки большая часть верхней части стека будет в несколько раз урезана или изменена.

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

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

Но подойдет не любая итерация. Мы должны выполнять итерацию особым образом, исходя из зависимостей, которые мы определили с помощью стека. Общая стратегия проста.

Начните с нижней части стека зависимостей и идите вверх через каждый цикл итерации.

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