Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Я убежден, что вы не можете по-настоящему оценить цифровую игру или интерактивные медиа без реализации всех ее деталей, потому что именно они во многом определяют, будет игра работать или нет. Вспомните изречение дизайнеров Рэя и Чарльза Имз: «Детали – это не мелочь. Они создают дизайн»[80]. Подумайте обо всех мельчайших составляющих, влияющих на хорошее ощущение игры и ее сочность. Очевидно, что в гейм-дизайне, как и во всем дизайне, важна каждая деталь, воздействующая на понимание, восприятие и оценку аудитории. Даже одна незначительная деталь, оказывающая негативное влияние, может испортить все впечатление. В пример – яркий, но грубый – приведу одно высказывание: «Сколько мух вы готовы положить в свой суп?»
Преимущества модульного подхода хорошо демонстрирует притча о часовщиках в начале этой главы. Работая модульно, мы создаем стабильные промежуточные формы нашего проекта, которые позволят нам, к примеру, тестировать (а затем итерировать) небольшую часть игры на ранней стадии, вместо того чтобы ждать окончательной версии игры, чтобы проверить, работает она или нет.
В своей книге Advanced Game Design: A Systems Approach гейм-дизайнер и профессор Майкл Селлерс дает нам дополнительный контекст для понимания важности модульности в гейм-дизайне. Он вводит понятие метастабильности, что означает «стабильный, но постоянно меняющийся». Он пишет: «Метастабильность – это состояние, когда нечто длительное время пребывает в стабильной форме во времени (как правило), тем не менее постоянно меняется на более низком уровне организации»[81]. Затем Майк продолжает:
Слово «синергия» означает «совместная работа». В употребление этот термин ввел Бакминстер Фуллер, который описывал синергию как «поведение всей системы, которое не может быть предсказано через наблюдения за поведением составных частей и подразделов этой системы» (Фуллер, 1975). Это еще один способ описания метастабильности, когда в результате сочетания деталей на более низком уровне организации возникает что-то новое, что часто приводит к свойствам, не присущим самим деталям…
Идея того, что системы являются метастабильными объектами с собственными свойствами и что они содержат другие метастабильные элементы более низкого уровня, – одно из ключевых понятий как системного мышления, так и гейм-дизайна[82].
Одна из ключевых мыслей – это замечание Бакминстера Фуллера о том, что «поведение не может быть предсказано через наблюдения за поведением составных частей». По мере того как мы соединяем модули нашей игры, в дизайне появляется что-то новое, чего мы не могли предвидеть. Это может вызвать проблемы – мы не знали, что если мы соединим то и это вместе, то получится такое! Обычно мы называем такие неожиданности багами, проблемами дизайна и эксплойтами, и в дальнейшем мы будем говорить обо всех трех.
Однако такие неожиданности могут стать источником творческих возможностей. Даже если кажется, что гейм-дизайн не работает, изменение одной маленькой детали на самом низком уровне может все исправить. Иногда то, что поначалу выглядит как баг, может стать фичей игры. Лучшие варианты проявляются в «эмерджентном геймплее», когда забавные и интересные ситуации, не предполагаемые дизайнером, обнаруживают игроки по мере того, как они исследуют пространство возможностей игры.
Итерация, оценка и стабильность
Итерация важна, но часто бывает сложной. Легко заблудиться в итеративных циклах, если вы не будете двигаться медленно и осторожно. Джордж Кокорис считает, что «самое важное, что нужно сделать при тестировании и итерации, – это уменьшить количество движущихся частей в каждом исследуемом случае, чтобы лучше определить причинно-следственные связи»[83].
Когда мы разрабатываем модульным способом, следует регулярно отдыхать или делать перерывы на протяжении всего проекта, чтобы оценить, где именно находится проект. Кроме того, как напомнил мне гейм-дизайнер Марк Вильгельм, мы должны учитывать, что «в средних и особенно крупных командах… модульный подход также позволяет “функциональным командам” разделять обязанности и работать более целенаправленно и с менее пугающими результатами. Это может усилить чувство сопричастности и, следовательно, чувство приверженности и гордости за работу и вклад в проект».
Для того чтобы работать наиболее эффективно, необходимо, чтобы все в нашей игре было готово пройти оценку на каждом этапе проекта, будь то ежедневный тест в студии, формальный тест с аудиторией или презентация проекта заинтересованным сторонам и спонсорам. Чтобы мы могли оценить любой модуль нашей игры, каждый подмодуль должен быть стабильным и работать исправно. Это очень соответствует принципам Agile-разработки. Разработчик и продюсер Алан Данг сказал: «Имея возможность оценивать игру на каждом ее этапе, вы можете вносить необходимые изменения или менять приоритеты, чтобы сделать игру лучше и привести ее в соответствие с видением каждого»[84].
Концентрическая разработка помогает с менеджментом времени
Разработка концентрическим, модульным способом поможет лучше контролировать сроки нашего проекта. Подходя к этапам альфа- и бета-тестирования, гейм-дизайнеры часто сталкиваются с проблемой объединения модулей игры в единое целое, проанализировав проект на этапе продакшена. Пересмотр содержания неизбежен для большинства проектов – у всех нас в конечном счете заканчивается время, и приходится что-то убирать из игры.
Умный разработчик задаст себе такой вопрос: когда я пойму, что у меня заканчивается время? Останется ли у меня время, чтобы реализовать задуманное? Концентрическая разработка поможет вам быстрее осознать, когда что-то не складывается и что время уходит. В то время как часовщик, вероятно, не сможет отказаться от подмодуля своих часов, игры удивительно пластичны (в том смысле, что их легко перестроить). Если мы обнаружим, что разработка основ нашей игры неожиданно съела половину общего срока проекта, у нас будет время продумать, какие части игры можно включить или исключить и как мы могли бы сместить фокус нашего дизайна, чтобы в конце собрать все воедино.
Когда мы создаем игру концентрическим, модульным способом, мы можем раньше и яснее увидеть, когда конкретный модуль нашей игры не работает, тем самым поддерживая кредо быстрого прототипирования, о котором я упоминал в главе 11: «Ошибайтесь рано, ошибайтесь
