Чтобы стек «набеги гоблинов» работал, как и было запланировано, мы сначала должны реализовать персонажей, строительство, строительство стен и боевые системы. Если в какой-либо из этих систем произойдет значительный сдвиг, изменения будут проходить каскадом через стек зависимостей и приводить к изменениям в стеке «набеги гоблинов». Даже если каждый из этих основополагающих элементов имеет чрезвычайно благоприятную определенность в 80 %, то вероятность того, что стек «набеги гоблинов» сработает так, как и ожидалось, умножится на 0,8 в пятой степени, или на 0,33 (33 %), поскольку ошибка в любом из пяти основополагающих элементов приведет к изменению в стеке «набеги гоблинов».
Каскадная неопределенность означает, что верхние элементы стека зависимостей почти всегда нуждаются в серьезном изменении дизайна.
В большинстве дизайнов нет даже 80 % определенности. При разработке рискованных, теоретически прорывных игр большинство проектов терпят неудачу. Определенность в системе часто составляет менее 30 %. При таких условиях дизайн пяти слоев вверх по стеку зависимости останется неизменным в 0,2 % случаев. Так что, в принципе, никогда.
Это значит, что большая часть написанного дизайна для Fantasy Castle – ерунда. Фундаментальные системы почти наверняка изменятся при реализации или тестировании, и эти изменения будут проходить каскадом через дизайн, приводя к изменениям везде. Концепции могут остаться, но все особенности будут меняться снова и снова. К концу разработки большая часть верхней части стека будет в несколько раз урезана или изменена.
Казалось бы, это простая истина, но в ней скрыт глубокий смысл. Каждый разработчик видел, как игры меняются в процессе разработки, особенно если они нестандартные.
Но часто трудно четко сформулировать, почему это происходит. Простой неопределенности в отношении отдельных частей дизайна недостаточно, чтобы объяснить это. Настоящая проблема заключается в том, что каждое изменение создает ударную волну последующих изменений, которые пронизывают весь дизайн через зависимости. Это настоящий виновник массового хаоса многих дизайнов. Это ключевая причина, по которой нужны итерации.
Но подойдет не любая итерация. Мы должны выполнять итерацию особым образом, исходя из зависимостей, которые мы определили с помощью стека. Общая стратегия проста.
Начните с нижней части стека зависимостей и идите вверх через каждый цикл итерации.
Мы начинаем с нижней части, с дизайна, который ни от чего не зависит. После нескольких итераций и плейтестов эта основа становится более определенной. На бумаге определенность могла составлять 40 %, но как только мы провели несколько плейтестов, она может достичь 90 %. Затем мы можем создать элементы, которые зависят от этой основы, и быть уверенными в том, что они не будут разбиты на части дальнейшими изменениями, идущими снизу вверх. И мы просто продвигаемся вверх по стеку, компилируя снизу вверх. Тем не менее все равно будут появляться неожиданные результаты дизайна и сотрясать всю структуру, но мы уменьшаем их частоту и влияние, выполняя работу в правильном порядке.
Например, в игре Fantasy Castle мы могли бы начать разработку игры только с основными персонажами, конструкцией и стенами. Во-первых, это просто игра о людях, строящих стены. Спустя несколько итераций и хорошего плейтеста мы можем добавлять фермерство. После нескольких итераций мы добавляем торговлю и времена года. Мы продвигаемся вверх, строим башню зависимостей снизу вверх. И дизайн, скорее всего, изменится наполовину – после плейтестинга фермерства мы можем почувствовать, что не нужно добавлять времена года, а вот новый элемент в виде болезней сельскохозяйственных культур привнесет больше интереса. Таким образом, вершина стека меняется по мере укрепления фундамента.
Бэклог дизайна
Тот факт, что дизайны в верхней части стека очень неопределенные, не означает, что они бесполезны. У нас все время есть мысли, идеи и наблюдения, и их следует записывать, потому что они могут быть весьма ценными. Но для того, чтобы объединить их во взаимосвязанный подробный проект, требуется проделать большую работу, которая, вероятно, будет аннулирована из-за каскадной неопределенности.
Решение состоит в том, чтобы сохранить идеи в текучей, не заблокированной форме, записав их в бэклог дизайна.
БЭКЛОГ ДИЗАЙНА – это резервуар идей, концепций и впечатлений, над которыми вы не работаете и над которыми не будете работать в ближайшее время. Большинство идей должно идти в бэклог дизайна.
