Глава 13. Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте разберем пример. Представьте, что мы делаем Fantasy Castle, легкую игру о строительстве замка в фэнтези-мире. Разработка Fantasy Castle только началась, поэтому команда дизайнеров переполнена идеями, но им не хватает протестированных и проверенных проектных решений. Они написали длинный дизайн-документ. Каждая из 22 подсистем подробно описана на бумаге. Далее следует их краткое изложение в произвольном порядке:

• Персонажи. Могут существовать и перемещаться в окружающей среде.

• Семьи. Персонажи могут вступать в семейные отношения.

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

• Межвидовое скрещивание. Различные виды могут скрещиваться, чтобы создать гибриды с общими характеристиками своих родителей.

• Нападения гоблинов. Гоблины могут устраивать периодические облавы, чтобы проверять оборону замка.

• Сельское хозяйство. Сельское хозяйство и продовольственная система дают населению пропитание.

• Торговля. Персонажи могут торговать с соседними замками особыми или редкими товарами.

• Образование. Персонажи могут получить образование.

• Изобретения. Образованные персонажи могут изобретать новые машины для замка.

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

• Гнев богов. Другие божества разозлятся на вас, если вы будете неуважительно относиться к ним или поклоняться их врагам.

• Друзья. Персонажи могут иметь платонические отношения.

• Романтика. Персонажи могут иметь романтические отношения.

• Строительство. Персонажи могут что-то строить.

• Стены. Персонажи могут строить стены, чтобы остановить врагов.

• Укрепления. Стены можно укреплять и утолщать, чтобы сдерживать гоблинов.

• Ловушки. Персонажи могут устанавливать ловушки или автоматические защиты.

• Сражения. Персонажи могут бороться, чтобы защитить замок.

• Захватчики. Можно организовывать группы захвата, чтобы исследовать близлежащие подземелья и получать добычу.

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

• Времена года. Полный сезонный цикл влияет на сельское хозяйство, строительство и другие виды деятельности.

• Мыльная опера. Среди жителей замка разыгрываются адюльтер и прочие романтические драмы.

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

Ниже представлен мой стек зависимостей для игры Fantasy Castle:

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

Прежде чем мы продолжим, позвольте мне прояснить понятие зависимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ядро геймплея

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

ЯДРО ГЕЙМПЛЕЯ – это то, что вытекает из минимальной механики игры, которая лежит в основе ее стека зависимости. Уберите все, что можно убрать, эмоционально не обедняя игру, и то, что останется, и будет ядром игры.

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

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

Некоторые примеры ядра геймплея:

• Civilization V. Карта, города, поселенцы, воины.

• Unreal Tournament. Карта, игроки с управлением от первого лица, оружие.

• Starcraft II. Карта, центр командования, работники, пехотинцы.

В основе каждой из этих сложных игр лежит простой цикл итераций, который сам по себе создает полезный опыт. Даже при наличии только рабочих и морпехов игра StarCraft II генерирует интересные решения и стратегии. Одним из самых популярных способов играть в Unreal Tournament был режим InstaGib, который убирал все, кроме одного очень простого оружия – мгновенного уничтожения. Ядро – это и есть игра, хорошая или плохая. Все остальное – просто вариации и шлифовка.

Во многих случаях ядро игры определяет жанр. Например:

• Tower defense. Карта, объект для броска, башни, приближающиеся враги.

• Dungeon crawler. Персонаж, подземелье, герой, монстры, прокачка.

• Fighting game. Движение, удар, блок, бросок.

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

Если вы не можете найти ядро или работаете над его созданием и у вас получается ужасно, попробуйте начать заново с чем-то другим. Должна появиться очень веская причина, чтобы оставить игру без надежного ядра. И иногда она действительно существует. Например, в приключенческих играх в жанре «указать и щелкнуть» нет реального ядра. Указывание и щелканье не является само по себе рабочей игрой. Эти игры являются исключениями; они работают, потому что их опыт определяется содержанием, а не механикой. В некоторых играх есть несколько возможных ядер. Рассмотрим RPG с открытым миром Fallout 3.

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

Небольшой стек зависимостей

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

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

• Скорость. Кэпп бегает чрезвычайно быстро, фактически на виражах.

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

• Падение. У Кэппа есть слабое место. В случае повреждения во время атаки он падает на землю.

• Прыжок от стены. Кэпп прыгает и отскакивает от стен, чтобы попасть в специальные зоны или обойти противников.

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

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

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

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

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

В каждой части дизайна существует некоторая неопределенность:

• Удар ногой с разворота. В нем существует небольшая неопределенность, поскольку он является производной атак, которые мы видели в других играх. Основная неопределенность заключается в выборе радиуса и времени. Если окажется, что удар ногой с разворотом работает лучше, когда он длится полсекунды, а не три секунды, как предполагали разработчики, изменения могут сместиться вверх к другим способностям.

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

• Скорость. Здесь существуют неопределенности, связанные с технологиями. Нестандартное движение на основе физики всегда сложно реализовать хорошо. У ИИ могут быть проблемы с ожиданием или навигацией, а у игроков могут быть проблемы с его управлением. Может потребоваться изменение дизайна или отказ от приема.

• Прыжок от стены. В нем существуют аналогичные риски, что и в скорости, с дополнительными проблемами, с которыми сталкивается ИИ при навигации по путям, которые обычно недоступны. Систему управления прыжков от стены тоже, вероятно, потребуется переделывать несколько раз.

• Переворот с опорой на руки. Сам по себе он не так уж не определен, но он уязвим к множеству каскадных неопределенностей систем более низкого уровня.

• Подсечка. Сама по себе она простая, но уязвима к каскадным неопределенностям нижних уровней.

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

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

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

Зависимости и потребности внешнего дизайна

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

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

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