Существует гораздо больше зависимостей подобного типа, чем записано в стеке. Например, я разместил стек «стены» над стеком «строительство». Но возможно, что в процессе разработки дизайнеры могут обнаружить, что им нужно изменить интерфейс строительства, чтобы упростить строительство стен. Таким образом, стек «стены» зависит от стека «строительство», а стек «строительство» зависит от стека «стены» – циклическая зависимость. Эти нити зависимостей пронизывают Fantasy Castle насквозь. Возможно, придется изменить стек «стен», чтобы их можно было легче размещать вокруг ферм. На систему изобретений может повлиять стек «дружеские взаимоотношения», если друзья могут настраивать друг друга на создание изобретений. В каком-то смысле любой элемент может повлиять на все остальное, поэтому все взаимозависимо.
Но некоторые из этих зависимостей сильнее, чем другие. Значительные изменения в стеке «стены» могут в некоторых случаях повлиять на стек «строительство». Но изменения в стеке «строительство» почти наверняка затронут стек «стены». Стек зависимостей намеренно игнорирует самые слабые зависимости, чтобы мы могли сосредоточиться на наиболее важных и потенциально опасных из них. Нахождение этого фокуса является целью стека.
Стек зависимостей является редуктивным. Он не включает в себя важные части реальности разработки. Но если вы просто человек, столкнувшийся с такой сложной проблемой, как сотня взаимозависимых элементов дизайна, включающих сто тысяч взаимосвязей, рациональная редукция – единственный способ добиться прогресса. Мы должны игнорировать некоторые зависимости, иначе погрузимся в аналитический паралич. Стек зависимостей – это не теоретический вопрос, это инструмент для принятия решений. И эти решения лучше принимать, концентрируясь на наиболее значимых взаимозависимостях. Существует несколько способов построения стека зависимостей с учетом деталей дизайна. Можно представить себе игру по строительству замков, в которой существует строительство, но нет персонажей. Или такую, в которой есть нападение гоблинов, но нет стен. Я создал этот стек на основании придуманных мной деталей для Fantasy Castle, но мне не хватит этой книги для того, чтобы я мог их описать. Если бы дизайн-документы были написаны по-разному, стеки бы тоже были разными, даже если бы названия были одинаковыми.
Каскадная неопределенность
Мы уже видели, что проекты могут не работать так, как мы ожидаем. Дизайнеры могут написать документ о том, как будут работать нападения гоблинов, но они не могут быть уверены, что это будет работать именно так, как предполагалось. Дизайнеры смогут убедиться, будет ли это работать, только когда проведут компилирование и плейтест.
Неопределенность усиливается в результате зависимостей.
Именно из-за этой неопределенности мы должны обращать внимание на зависимости. Если бы мы не принимали во внимание любую неопределенность, было бы неважно, в каком порядке выполнять работу. Мы бы генерировали идеи, записывали их, выстраивали их в любом порядке, и в последний день разработки дизайн бы идеально складывался, как мозаика. И в случаях производных дизайнов, основанных на проверенных идеях, это может сработать практически полностью, потому что каждый элемент дизайна определен.
Но в играх с некоторой новизной написанный дизайн часто не соответствует действительности. Существует вероятность того, что в процессе разработки элемент дизайна необходимо будет изменить. И именно эта неопределенность делает зависимости важными.
Например, система набегов гоблинов описана на двух страницах где-то в документации проекта. В ней указано, как и когда появляются гоблины, какую тактику они используют, какие у них есть возможности и стратегии для победы.
Как и у каждого плана, у этого дизайна некоторый уровень неопределенности. Он отражает вероятность, с которой дизайн будет работать не так, как ожидалось. Предположим, что это шаблонный дизайн, поэтому определенность составляет 80 %. По оценкам разработчиков, в этой ситуации восемь из десяти раз система будет работать так, как написано, без существенных изменений. Это весьма неплохо.
Но значит ли это, что с самого начала разработки мы можем быть на 80 % уверены, что нападения гоблинов окажутся в игре и будут работать так же, как написано?
К сожалению, нет; эта цифра в 80 % охватывает только неопределенность дизайна, касающегося нападения гоблинов. Но нападения гоблинов могут пострадать не только в результате изменений, вызванных несовершенством дизайна. Они также уязвимы к изменениям, вызванным несовершенством дизайна, от которых зависят.
