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

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

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

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

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

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

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

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

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

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

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

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

Бэклог дизайна

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

Решение состоит в том, чтобы сохранить идеи в текучей, не заблокированной форме, записав их в бэклог дизайна.

БЭКЛОГ ДИЗАЙНА – это резервуар идей, концепций и впечатлений, над которыми вы не работаете и над которыми не будете работать в ближайшее время. Большинство идей должно идти в бэклог дизайна.

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

Только потому, что большая часть дизайна игры Fantasy Castle является ерундой из-за каскадной неопределенности, это не значит, что он бесполезен. Скорее, он требует реорганизации. Большую часть следует рассматривать как не более чем гипотетические идеи на будущее. Эти элементы не нужно объединять в строгий план, поскольку это подразумевает определенность, которой у нас нет. Следует сжижать и помещать в неупорядоченный массив, чтобы в будущем их можно было оттуда извлечь.

Теперь Fantasy Castle выглядит примерно так:

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

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

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