Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение

Идея того, что системы являются метастабильными объектами с собственными свойствами и что они содержат другие метастабильные элементы более низкого уровня, – одно из ключевых понятий как системного мышления, так и гейм-дизайна[82].

Одна из ключевых мыслей – это замечание Бакминстера Фуллера о том, что «поведение не может быть предсказано через наблюдения за поведением составных частей». По мере того как мы соединяем модули нашей игры, в дизайне появляется что-то новое, чего мы не могли предвидеть. Это может вызвать проблемы – мы не знали, что если мы соединим то и это вместе, то получится такое! Обычно мы называем такие неожиданности багами, проблемами дизайна и эксплойтами, и в дальнейшем мы будем говорить обо всех трех.

Однако такие неожиданности могут стать источником творческих возможностей. Даже если кажется, что гейм-дизайн не работает, изменение одной маленькой детали на самом низком уровне может все исправить. Иногда то, что поначалу выглядит как баг, может стать фичей игры. Лучшие варианты проявляются в «эмерджентном геймплее», когда забавные и интересные ситуации, не предполагаемые дизайнером, обнаруживают игроки по мере того, как они исследуют пространство возможностей игры.

Итерация, оценка и стабильность

Итерация важна, но часто бывает сложной. Легко заблудиться в итеративных циклах, если вы не будете двигаться медленно и осторожно. Джордж Кокорис считает, что «самое важное, что нужно сделать при тестировании и итерации, – это уменьшить количество движущихся частей в каждом исследуемом случае, чтобы лучше определить причинно-следственные связи»[83].

Когда мы разрабатываем модульным способом, следует регулярно отдыхать или делать перерывы на протяжении всего проекта, чтобы оценить, где именно находится проект. Кроме того, как напомнил мне гейм-дизайнер Марк Вильгельм, мы должны учитывать, что «в средних и особенно крупных командах… модульный подход также позволяет “функциональным командам” разделять обязанности и работать более целенаправленно и с менее пугающими результатами. Это может усилить чувство сопричастности и, следовательно, чувство приверженности и гордости за работу и вклад в проект».

Для того чтобы работать наиболее эффективно, необходимо, чтобы все в нашей игре было готово пройти оценку на каждом этапе проекта, будь то ежедневный тест в студии, формальный тест с аудиторией или презентация проекта заинтересованным сторонам и спонсорам. Чтобы мы могли оценить любой модуль нашей игры, каждый подмодуль должен быть стабильным и работать исправно. Это очень соответствует принципам Agile-разработки. Разработчик и продюсер Алан Данг сказал: «Имея возможность оценивать игру на каждом ее этапе, вы можете вносить необходимые изменения или менять приоритеты, чтобы сделать игру лучше и привести ее в соответствие с видением каждого»[84].

Концентрическая разработка помогает с менеджментом времени

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

Умный разработчик задаст себе такой вопрос: когда я пойму, что у меня заканчивается время? Останется ли у меня время, чтобы реализовать задуманное? Концентрическая разработка поможет вам быстрее осознать, когда что-то не складывается и что время уходит. В то время как часовщик, вероятно, не сможет отказаться от подмодуля своих часов, игры удивительно пластичны (в том смысле, что их легко перестроить). Если мы обнаружим, что разработка основ нашей игры неожиданно съела половину общего срока проекта, у нас будет время продумать, какие части игры можно включить или исключить и как мы могли бы сместить фокус нашего дизайна, чтобы в конце собрать все воедино.

Когда мы создаем игру концентрическим, модульным способом, мы можем раньше и яснее увидеть, когда конкретный модуль нашей игры не работает, тем самым поддерживая кредо быстрого прототипирования, о котором я упоминал в главе 11: «Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто». Если мы будем мыслить понятиями модулей, а не только взаимосвязанного целого, то с наибольшей вероятностью мы сможем вовремя отказаться от идей, что раз за разом терпят неудачу или кажутся уже не такими важными. Это согласуется с мыслью режиссера Pixar Эндрю Стэнтона («История игрушек», «Приключения Флика», «В поисках Немо»), которую Эд Кэтмелл и Эми Уоллес приводят в книге «Корпорация гениев».