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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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