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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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