Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше Сильвестр Тайнан
«СЕРЫЙ ЯЩИК» – это черновой прототип игровой механики, системы или уровня.
Я тестировал методом «серого ящика» в процессе проектирования боя, но этот метод подходит не только для тестирования уровней, его можно применять практически везде. Внутриигровое видео можно заменить неподвижными изображениями или всплывающими окнами со статическим текстом. Сложные интерфейсы можно заменить помеченными командными кнопками. Звуки можно воспроизвести с помощью дешевых синтезированных гудков и жужжания. Диалог может читать программа преобразования текста в речь или он может отображаться на экране в виде текста.
Когда компания-разработчик BioWare создала Mass Effect 3, дизайнеры тестировали существ методом «серого ящика». На раннем этапе разработки гигантский боевой робот представлялся в виде большого куба с двумя длинными прямоугольниками внизу и двумя кубами, прикрепленными к бокам для оружия. Другой враг – высокий желтый блок – хватал героя с длинными желтыми блоками, прикрепленными к бокам. Это выглядит странно, но именно так и происходит. Эти «серые ящики» позволили дизайнерам BioWare тестировать и итерировать свои работы, не вкладывая средства в графику непроверенных проектов.
Тестирование методом «серого ящика» ускоряет итерацию. A «серый ящик» можно тестировать как готовую игру и скомпилировать его в разы проще. Поскольку большинство идей не работают, нет смысла реализовать их все с самого начала, используя все возможности графики. Но если мы сначала компилируем все в «сером ящике», мы можем позволить себе несколько ошибок, прежде чем наконец получим правильную работу механики. Только после того, как дизайн проверен, мы можем вкладывать ресурсы для его реализации, включая добавление аудиовизуальных эффектов.
Некоторые люди беспокоятся о том, что тестирование методом «серого ящика» влияет на художников, звукорежиссеров и других создателей контента. На первый взгляд кажется, что они могут разочароваться, если их попросят просто «нарисовать» серые фигуры. В действительности художники обычно ценят такое тестирование, потому что в этом случае проделанную ими работу отбрасывают гораздо реже. Без тестирования «серым ящиком» художники вынуждены работать над непроверенными проектами, поэтому большая часть их работы неизбежно урезается по причинам, не связанным с самой графикой. Но работая над хорошо протестированным «серым ящиком», у художника больше гарантий, он верит в то, что его труд не напрасен. Еще лучше, если художники будут общаться с разработчиками на этапе такого тестирования, чтобы дать представление о том, во что этот «серый ящик» превратится. Таким образом, они уже внесли свой вклад в «серый ящик», который их просят украсить, поэтому они уже понимают и верят в него.
Что не нужно тестировать методом «серого ящика»
«Серые ящики» дают нам возможность тестировать большую часть игрового опыта, включая механику и задумку. Но они не представляют собой весь опыт. Очевидно, что «серые ящики» не могут генерировать эмоции, как это делают музыка и графика.
Поэтому чем более аудиовизуально насыщенным является игровой опыт, тем менее полезным становится тестирование методом «серого ящика». Такие игры, как LIMBO и Flower, сильно пострадают в «сером ящике», поскольку в основном они основаны на аудиовизуальных эмоциональных триггерах. Однако этот метод весьма хорошо подходит для Counter-Strike и StarCraft II, так как эти игры всегда были основаны на механике.
Преждевременный продакшн
Всегда остается соблазн «сломать серый ящик» и начать использовать лучшие возможности слишком рано. Я называю это «преждевременный продакшн».
ПРЕЖДЕВРЕМЕННЫЙ ПРОДАКШН – преждевременное добавление дизайнером графики и звука к дизайну «серого ящика» для того, чтобы получить следующий набор контрольных данных.
В краткосрочной перспективе добавление аудиовизуальных материалов в незавершенный дизайн выглядит круто. Графика и звук заставляют сердца трепетать и вызывают улыбки на совещаниях по проекту. Проблема в том, что эта эмоциональная выгода недолговечна, а за ее получение приходится платить снова и снова на протяжении всего процесса. С этого момента любое изменение графики, которое должно соответствовать изменяющейся механике, тормозит любой итерационный цикл. В конечном счете преждевременное добавление графики приведет к затратам значительно большим, чем те усилия, которые потребовались для ее создания. И платить за это придется еще долго после того, как первичный эмоциональный подъем угаснет.
Хуже того, преждевременный продакшн ограничивает конечное качество игры. Нам всегда не хватает места для аудиовизуальных материалов, в результате чего механика накладывает ограничения на качество игры. Но если мы спрятали слабое ядро механики за графикой, то мы не сможем исправить это, не отказавшись от графики. В конечном итоге все закончится несовершенной механикой, которую мы не можем изменить из-за созданной вокруг нее графики.
Чтобы оставаться в «сером ящике», нужна дисциплина. После неудачного плейтеста идея быстро скрыть недостатки дизайна графикой кажется весьма заманчивой. Но если графика не даст нужных результатов в следующем плейтесте, это будет означать ошибку. Чтобы получить полезные тестовые данные, графику следует добавлять как можно позже.
Навык оценки «серого ящика»
Играть в хороший «серый ящик» – совсем не то же самое, что играть в хорошую игру. Это означает, что оценка «серых ящиков» – это навык, которому нужно учиться на практике. Надо было оценить много «серых ящиков», чтобы научиться понимать, что такое хороший и плохой «серый ящик». Без этого навыка мы, скорее всего, не примем даже идеальный «серый ящик» просто потому, что в нем нет графики.
В связи с этим возникают споры в процессе принятия групповых решений, когда некоторые люди не имеют способности оценивать «серые ящики». Они смотрят на дизайн, и он им не нравится только потому, что он выглядит ужасно. Это гало-эффект в действии – плохое качество визуальных эффектов создает эмоциональное впечатление, которое становится чьим-то мнением обо всем дизайне. Поэтому дизайн не принимают, даже если он хорош.
В реальной жизни это обычно самая большая проблема «серых ящиков». Поэтому будьте внимательны с тем, кто принимает решения о дизайне «серого ящика». Этим должен заниматься только опытный специалист, поскольку неопытные тестировщики склонны принимать плохие решения в результате гало-эффекта. Если они должны принять такие решения, возможно, придется включиться в преждевременный продакшн, несмотря на стоимость.
Миф о сценарии
Многие считают, что игра должна начинаться с большого дизайн-документа, потому что именно так создаются фильмы. Но эта метафора неверна.
Ближайшим эквивалентом сценария в геймдизайне является не дизайн-документ, а рабочий прототип «серого ящика».
Сценарий включает все события фильма. Каждое слово диалога, каждое изображение, каждый поворот сюжета – все это прописано в сценарии. Когда мы читаем его, наш мозг должен восполнить недостающие аудиовизуальные детали, это легко сделать с помощью активного визуального воображения. Так что просто читая сценарий и представляя изображения, мы можем приблизиться к опыту киноманов.
Нельзя сделать то же самое в геймдизайне, так как дизайн-документ не определяет игровые события – он определяет игровую механику. Прочитать дизайн-документ и понять окончательный опыт – это не просто представить визуальные эффекты, а мысленно смоделировать всю игровую механику и выбор игроков, чтобы создать события, которые управляют этим опытом. С таким моделированием справится далеко не каждый.
Но в «сером ящике» игра производит механическое моделирование. Разум игрока должен только заполнить недостающий аудиовизуальный ряд, как при чтении сценария. Таким образом, наиболее близким к сценарию является рабочий «серый ящик». Он предоставляет столько же информации о конечном продукте, сколько и сценарий, в то время как дизайн-документ предоставляет гораздо меньше.
Парадокс качества
В геймдизайне временное принятие некачественной работы в конечном итоге приводит к более качественной работе. Это ПАРАДОКС КАЧЕСТВА.
Мудрость гласит: «Семь раз отмерь, один раз отрежь». Когда вы строите палубу или дамбу, в этом есть смысл. Так как ошибки исправить в такой работе стоит очень дорого, лучше всего избегать их. Но в геймдизайне крайняя степень неприятия ошибок приводит к ухудшению качества продукта.
Классический совет гласит, что если вы будете работать медленно, с любовью, уделяя внимание каждой детали, то вы получите качественный продукт. Если вы быстро сляпаете разные куски воедино, то получите мусор. С этой точки зрения завершение качественного продукта означает выполнение качественной работы на каждом этапе процесса.
Игры отличаются тем, что наиболее важным фактором, определяющим их качество, является количество итерационных циклов, через которые они проходят. Одержимость качеством на каждом этапе замедляет итерацию, что в конечном итоге ведет к ухудшению игры.
Вот почему не следует отказываться от несовершенной работы на ранних этапах итерации. Дизайнера, который так делает, можно сравнить с писателем, который не может сказать ни слова, потому что ему нужно, чтобы сказанное было идеальным. Таким образом, каждый цикл итерации растягивается в результате избыточного анализа, так как дизайнер пытается дважды отмерить и получить идеальный результат. В конце концов, страх ошибиться приводит его к плохому результату, потому что он провел только несколько циклов итерации.
В геймдизайне, прежде чем игра достигает своего окончательного вида, все пересматривается и меняется множество раз. Работа, которую мы делаем на самых ранних циклах итерации, не создает финальную игру. Это только платформа.
Ошибочность видения
Молодой инженер авиационной и космической промышленности в свой первый рабочий день заходит в кабинет начальника с блеском в глазах и заявляет: «У меня есть гениальная идея для нового типа самолета».
Босс заинтригован.
«Говори», – отвечает он.
Молодой инженер задумчиво смотрит вдаль.
«Пассажиры спокойно заходят на борт за пять минут. Затем самолет тихо взлетает, пока пассажиры наслаждаются мартини в частных кабинках. Когда они летят над Атлантикой, молодая пара любуется видом, находясь в одном из множества фонарей самолета, а милый ребенок осматривает кабину. Капитан смеется, когда ребенок спрашивает, почему они не могут полететь на Луну. К тому времени, когда они приземляются, любовь уже найдена, уроки пройдены, и все готовы ко всему, что их ожидает в пункте назначения».
Босс откидывается на спинку стула и затягивается сигарой.
«Уволен», – говорит он.
У молодого инженера было видение. Но это было видение процесса полета, а не самого самолета. Он описал замечательный опыт, но ничего не сказал о механических системах, которые создали этот опыт. Это называется ошибочностью видения.
ОШИБОЧНОСТЬ ВИДЕНИЯ заключается в приравнивании воображаемого образа опыта к дизайну системы, которая создает этот опыт.
Люди склонны принимать решения, используя мыслительные образы. Мы воображаем историю, оцениваем, как образ заставляет нас чувствовать себя, и принимаем решение на основании этой эмоциональной реакции. Психолог Дэниел Гилберт называет эту технику предвидением.
Во многих случаях предвидение имеет смысл. Оно использует способность эмоционального бессознательного быстро генерировать детальное мнение о сложной идее. Хотите пойти в кино? Предвидьте. Хотите съесть вон то блюдо? Предвидьте. Это простой, быстрый и зачастую эффективный способ принятия решений о будущем.
Мы делаем то же самое в геймдизайне, когда оцениваем потенциальную игру, воображая, что играем в нее. Особенно сильный ментальный образ часто называют видением. Оно может быть источником вдохновения, мотивируя так, как могут мотивировать только истории.
Видение может быть обманчивым и определять опыт. Но игра – это не опыт, это система создания опыта. Точно так же, как не стоит путать идеальный полет с идеальным самолетом, также не стоит путать видение отличного игрового опыта для создания великолепной игры.
Видение ничего не говорит о плюсах и минусах, а также издержках системы, которая стоит за опытом. Оно также ничего не говорит нам обо всех других опытах, которые будет генерировать игра. Это важно, потому что игроки не просто получают в игре лучший опыт – они получают весь опыт. Кроме того, видение всегда скрывает недостатки дизайна, потому что для нас естественно представлять только лучшее в игре, которую мы создаем. Мы представляем захватывающую битву, а не пятиминутную прогулку от базы. Мы представляем, что предохранитель сработал, а не сломался. Мы видим только хорошую сторону, а наш мозг убирает плохую. Эта модель порождает чрезмерную уверенность в планах разработки и приводит к избыточному планированию. Таким образом, хотя дизайнеры и должны искать мотивацию в видении, необходимо ставить под вопрос ее надежность.
Попробуйте такой антидот против ошибочности видения: вместо того чтобы пытаться представить лучший опыт, который может создать игра, попытайтесь представить худший. Старайтесь в деталях представлять каждую неудачу, скучный гринд и непонятное взаимодействие. Здесь вам придется приложить когнитивные усилия, а не представлять в уме замечательные образы. Но так вы получите намного больше информации, потому что увидите сбалансированную картину игры, вместо того чтобы выбирать лучшие результаты.
Серендипность
Есть известные известные – вещи, о которых мы знаем, что знаем их. Есть также известные неизвестные – вещи, о которых мы знаем, что не знаем. Но еще есть неизвестные неизвестные – это вещи, о которых мы не знаем, что не знаем их.
Дональд Рамсфелд
В геймдизайне мы сталкиваемся со многими неизвестными явлениями. Поймет ли игрок этот инструмент? Не слишком ли это задание сложное? Сколько времени понадобится, чтобы построить этот уровень? Возможно, на эти вопросы трудно ответить, но это не самое важное незнание, с которым нужно что-то делать.
Мы совершаем ошибки, даже не замечая этого. Мы проходим мимо возможностей, которых даже не видели. Мы основываем целый дизайн на предположениях, которые мы фактически не делаем, даже не догадываясь об этом.
Большинство действительно важных вещей в разработке игр возникают из неизвестных неизвестных.
Некоторые неизвестные неизвестные приводят к катастрофе. Тестировщик находит вырожденную стратегию, которую сложно исправить и которая нарушает всю игровую систему. Очевидный на первый взгляд интерфейс оказывается непонятным для новичков. Мы получаем дикое новое указание от издателя или ведущий программист уходит на больничный. В отличие от запланированных методов, итерационные процессы устойчивы к таким вещам.
В случае итерации мы не делаем предположений о далеком будущем. Иначе говоря, мы можем быстро изменить направление в ответ на меняющиеся обстоятельства. Более того, постоянные проверки итераций в реальных условиях означают, что катастрофические открытия обычно обнаруживаются рано. Это само по себе является основной причиной для итераций.
Но есть еще один, часто более важный вид неизвестного: серендипность, или прозорливость. Игроки влюбляются во второстепенного персонажа. Изобретают новую интересную тактику. Находят эмоции в, казалось бы, неважной части игры. Это положительные результаты, которые дизайнеры так и не увидели. И часто эти случайные открытия являются наиболее ценными из того, что происходит в процессе разработки. Такая проницательность необходима для создания революционных проектов, потому что большинство революционных геймдизайнов не создают намеренно, а открывают случайно.
Например, прародителем видеоигр в жанре RPG является Dungeons & Dragons. D&D генерировала большую часть своего наполнения из своих ролевых элементов, так как позволяла игрокам вербально разыгрывать любую фэнтезийную историю, какую они только могли представить. Как только компьютеры стали способны генерировать аналогичный опыт, D&D преобразовали в видеоигру Rogue. Rogue отображает карту подземелья в текстовой графике. Игрок управляет героем, который исследует просторы сгенерированного случайным образом подземелья, убивая монстро, набираясь опыта и собирая древние сокровища. На первый взгляд Rogue может показаться довольно близкой компьютеризированной версией D&D. Но она создает опыт совсем другим способом. D&D работает в основном через ролевое взаимодействие и социализацию, а Rogue – через эмергентную историю и получение награды по графику. В свое время это были революционные достижения в геймдизайне. Но дизайнеры Rogue этого не планировали. Пытаясь скопировать опыт D&D, они наткнулись на силу режимов подкрепления и эмергентный нарратив, стимулируемый апофенией. Игра работала фантастически по причинам, которые ее создатели никогда не смогли бы предсказать.
Серендипность не является чем-то необычным. Знаменитый персонаж Большой папочка в BioShock изначально был мутантом в водолазном костюме; добавление слабых Маленьких сестричек привело к созданию очаровательных взаимоотношений между огромным големом-отцом и маленькой девочкой-дочерью. Голос GLaDOS в игре Portal, одного из самых популярных игровых персонажей, стал роботизированным только когда Эрик Волпо заметил, что людям больше понравился «серый ящик» в исполнении синтезатора голоса. Безупречный финальный уровень Braid разработчики обнаружили, когда игра была практически закончена, Джон Блоу понял, как он мог использовать механику, сдвигающую время, чтобы обратить вспять не только время, но и персонажа. Игра Tetris появилась из компьютерной версии традиционной русской игры-головоломки «Пентамино»[13].
The Sims были разработаны на основе симуляции архитектуры, когда Уилл Райт заметил, что игрокам нравится играть с персонажами больше, чем строить дома. Даже изначальный хит Райта SimCity был разработан, когда он заметил, что ему нравится создавать карты для вертолетных боев больше, чем взрывать их.
Серендипность – одно из самых больших преимуществ итерации. Для тех, кто любит глубокое и тщательное планирование, серендипность означала бы отказ от любимого и дорогостоящего плана. Часто вместо этого они отказываются случайным образом. Когда мы итерируем, нам не нужно этого делать, потому что будущее открыто и мы можем заполнить его новыми открытиями по мере их появления.
Серендипные открытия в дизайне появляются не только благодаря удаче. Чтобы поймать их, мы должны наблюдать и адаптироваться.
Серендипность не происходит просто так. Мы должны быть готовы к ней. Ключом на пути к этому являются наблюдательность и желание открывать новое. Она проявляется как странное поведение или бессмысленные результаты в хорошо понятых системах. Нам остается заметить эти намеки и копнуть глубже.
Закрытый человек не может этого сделать, так как его ментальная модель недостаточно гибкая, чтобы воспринимать новые идеи. Он увидит подсказку, но проигнорирует или прикроет ее, чтобы укрепить свою собственную точку зрения.
Чтобы использовать серендипность, дизайнер должен уметь пересматривать свои мысли на основании своих наблюдений, а не подстраивать свои наблюдения в соответствии со своим мировоззрением.
Геймдизайн – это не просто процесс авторства. Это также процесс наблюдения и открытия.
Как творческие люди, мы хотим проецировать наше видение на мир. Но чтобы контролировать серендипность, требуется ослабить авторский контроль. У отличных геймдизайнеров нет идеального видения игры, а затем они просто воплощают ее в реальность. Они копают глубже в поисках возможностей, следят за драгоценными подсказками и тут же хватают их.
Вера в итерацию
Трудно избавиться от привычки планирования. Я пытаюсь представить, что бы подумал, прочитав эту главу несколько лет назад. Я мог бы кивнуть в знак согласия и подумать, что понял. Но сомневаюсь, что это на самом деле было бы так. Интеллектуальное понимание – это не то же самое, что эмоциональная вера.
Большинство знакомых мне дизайнеров, которые понимают итерацию, поверили в нее только спустя многие годы неудачных попыток, вызванных глубоким планированием. Они работали в цейтноте, срывали сроки, снова и снова наблюдали за крушением планов. Я делал то же самое. Возможно, единственный способ поверить в проблемы с планированием – это сначала пережить их самому.
Это не тот опыт, который можно получить легко. Это означает, что нужно пройти всю игру до конца – прототипов недостаточно. Масштаб игры должен быть значительным; тривиальные игры для школьников слишком просты, чтобы можно было противостоять планированию на их примере. В игру должны играть настоящие игроки, у которых нет причин жалеть дизайнера. Свою истинную ценность игра может проявить только в реальных условиях. И только тогда дизайнер получает неоспоримую, болезненную обратную связь, которая меняет эмоциональные убеждения.
Глава 12. Создание знаний
Игра – это не объект, который мы производим. Это система знаний. Это не комплект шахматных фигур. Это сам процесс игры в шахматы.
Сложная часть геймдизайна – это не физическая реализация игры. Это изобретение и совершенствование знаний о дизайне.
Возьмем, к примеру, процесс написания романа. Писателю не сложно набирать слова, ему сложно выполнять умственную работу по созданию взаимосвязанных персонажей, окружающей обстановки, тем и сюжетных поворотов. Главная проблема, с которой сталкиваются геймдизайнеры, – это не реализация игры, а изобретение механики, сюжета, графики и технологий, которые объединяются в мощный двигатель опыта. Это процесс создания знаний о дизайне, который мы собираемся реализовать. Это гораздо больше, чем просто придумывать идеи. Это значит изобретать эти идеи, совершенствовать их, тестировать, обсуждать и связывать воедино, чтобы они работали вместе. Делать это означает отвечать на многие вопросы и устранять многие неопределенности. Это означает, что мы должны создавать знания.
Методы создания знаний
Чтобы создать эти знания, мы применяем различные методы создания знаний. Плейтестинг, мозговой штурм, дискуссии, дебаты и фантазирование – все это методы создания знаний.
Думайте о каждом методе как о карте, которую мы можем разыграть. У разных карт разные возможности и разные ресурсы. Например, в методе мозгового штурма несколько разработчиков быстро придумывают множество неопробованных идей, в то время как для высококвалифицированного плейтестинга привлекаются тестировщики баланса, которые тщательно исследуют нюансы существующего дизайна.
Освоение процесса разработки означает знание того, какую карту разыграть и когда. Цикл итерации показывает нам хороший базовый подход, но само по себе это недостаточно. В действительности не существует простого алгоритма создания знаний. Чтобы получилось хорошо, мы должны постоянно реагировать на меняющиеся условия проекта. Для этого нужно очень хорошо знать все свои карты. Итак, давайте пройдемся по колоде.
Руминация
Руминация – это постоянное обдумывание проблемы в течение длительного времени. «Пережевывайте» идею часами, днями или годами, и в конечном итоге она сможет раскрыть свои секреты.
Разум автоматически размышляет при выполнении простых задач, таких как принятие душа, ходьба или вождение. Иногда размышления могут быть даже невольными. Все испытывали то чувство, когда поток мыслей не дает уснуть. Но даже такие размышления, какими бы неприятными они ни были, могут быть продуктивным (многие мысли, описанные в этой книге, родились и были записаны в 2 часа ночи).
Размышление также происходит неосознанно. Наше сознание может забыть о проблеме, а бессознательное – нет. Оно еще долго работает после того, как мы сдаемся. Если вы когда-нибудь внезапно поняли решение трудной задачи на следующий день после того, как не смогли решить ее, это значит, что вы собрали урожай бессознательного размышления.
Невозможно предсказать, когда бессознательное размышление даст результаты. Вот почему некоторые мыслители носят с собой блокноты, в которых записывают свои мысли и идеи. Они хотят успеть сорвать плод своего бессознательного размышления.
Одна из стратегий использования бессознательного размышления – чередовать работу над разными задачами. Работая над одной задачей, наше бессознательное размышляет над другой. Вот почему Эдисон, Дарвин, Леонардо да Винчи, Микеланджело и Ван Гог работали над несколькими проектами одновременно.
Для хороших размышлений нужны два ключевых ингредиента.
Во-первых, знания. Размышление работает, формируя новые связи между старыми мыслями. Чем больше у вас старых мыслей, тем больше возможных связей. Геймдизайнерам необходимы знания, связанные с игрой, поэтому дизайнеры должны много играть. Но даже те знания, которые напрямую не связаны с этой проблемой, могут подпитывать размышления. Знание экономики, истории, непальской культуры или техники ловли рыбы на мушку – все это может стать частью творческого решения сложных задач дизайна.
Люди думают аналогиями, поэтому наши мысли пополняются информацией, когда появляется больше знаний для сравнения.
Во-вторых, расслабление. Именно поэтому озарение приходит к людям, когда они принимают душ, сидят в яблоневом саду или едут в автобусе. Такие эмоции, как гнев, страх и сосредоточенность, препятствуют творчеству на неврологическом уровне. Исследования на МРТ показали, что незадолго до внезапного озарения кровь устремляется к части правого полушария мозга, которая называется передней верхней височной извилиной, или aSTG. Страх, гнев и интенсивная сосредоточенность на задаче на самом деле подавляют приток крови к aSTG, что, в свою очередь, подавляет свободные ассоциации и творческие способности. В этом есть смысл, если вы пещерный человек и пытаетесь сбежать от льва. Вы бы вряд ли захотели тратить время на то, чтобы представить львов, в то время как один из них уже практически вцепился вам в горло. Но это также означает, что сосредоточение – убийца творчества. Итак, если вы хотите размышлять, вы должны сначала расслабиться.
Исследование
Иногда мы проводим исследования, чтобы ответить на конкретные вопросы. Дизайнер уровней может изучать средневековую архитектуру для создания части игры про Крестовые походы. Разработчик систем, работающий над стратегической игрой, может поиграть в другую стратегию, чтобы выяснить, какая механика работает и как. Это то исследование, которому всех нас учили в школе.
Второй вид исследований гораздо менее целенаправленный. Это наполовину произвольное исследование, в котором мы учимся, не обязательно понимая, как полученные знания будут применяться к проекту. Цель здесь не в том, чтобы отвечать на вопросы, а в том, чтобы расширить наш запас знаний и питать мозг.
Мы все проводим наполовину произвольное исследование ежедневно, черпая информацию из телевидения, кино, игр, интернета и нашей повседневной жизни. Мы собираем идеи, мемы и культурные стандарты повсюду. Но без какого-либо направления мы получаем те же знания, что и другие геймдизайнеры. Все в каждой игровой команде, с которыми я работал, знали о «Звездных войнах» и «Терминаторе-2». Эта культурная однородность является одной из причин, по которой многие игры очень похожи друг на друга. Мы заперты в мире героев, побеждающих драконов и мрачных космических морпехов, потому что поглощаем только идеи друг друга.
Чтобы избежать культурной эхо-камеры, дизайнер должен развивать нестандартные интересы. Геймдизайнер стратегий может сыграть в The Sims и получить новую идею для экономической системы. Он может прочитать книгу по микробиологии и подумать о новой системе производства биологических войск. Такие наполовину зарегистрированные исследования являются долгосрочной инвестицией. Они нужны даже не для конкретного проекта – это действительно предполагает богатую интеллектуальную жизнь, включающую множество уникальных идей, источников и опыта. Это то, что нужно развивать как по личным, так и по профессиональным причинам.
В геймдизайне богатая интеллектуальная жизнь окупается уникальной работой, которую она позволяет нам создавать. Например, разработчики BioShock смогли придумать уникальный мир Восторга только потому, что они ранее исследовали ар-деко и объективизм. Без глубоких произвольных исследований BioShock никогда бы не появился.
Художественные методы
Вспомните, когда вы в последний раз рисовали на бумаге. Может быть, вы были на уроке рисования в школе или рисовали закорючки на деловой встрече. В любом случае, у вас почти наверняка был такой опыт: вы рисуете фигуру, а затем замечаете, что определенная ее часть напоминает вам о чем-то совершенно ином. Развивая свою мысль, вы совершаете ошибку. Чтобы скрыть ее, вы придумываете новый объект, который хотите нарисовать сверху, чтобы перекрыть старый. Этот новый объект заставляет вас менять окружающие формы. Процесс так продолжается, одно изменение вдохновляет другое. Когда вы закончили, вы видите, что нарисовали что-то совершенно не то, что планировалось изначально. В процессе создания художественной работы вы придумали новую идею.
Сила искусства заключается в том, что вы работаете руками, одновременно записывая свои идеи. Погружаясь в поток, мы чувствуем меньше запретов. На бумагу мы можем записывать мысли, которые невозможно передать словами. Делая ошибки и сталкиваясь с физическими ограничениями, мы идем к новым идеям.
Различные виды художественных процессов обеспечивают доступ к этим возможностям по-разному. Благодаря концептуальному искусству можно исследовать образы персонажей, настроение или пространство. Раскадровки устраняют неоднозначность во фрейминге, цвете и последовательности изображений. Благодаря предварительной визуализации можно исследовать различные способы передачи идеи. Когда Pixar работал над The Incredibles, он создавал бесформенные цветовые свотчи для каждой сцены, чтобы понять визуальную и эмоциональную прогрессию фильма только по цветам. Некоторые художники даже создают скульптуры существ или персонажей.
Орсон Скотт Кард, автор Ender’s Game, описал свой процесс изобретения фэнтезийных вселенных. Он достает гигантский чистый лист и начинает рисовать карту. Он набрасывает на ней города, достопримечательности и особенности местности, придумывая им названия. Он ничего не планирует; он изобретает мир, рисуя его. Давая название каждому из городов, он задумывается об его истории, обществе, которое его создало, и о причине его существования.
Каждые ошибка и исправление приводят к появлению нового подхода и идеи. Получившаяся карта представляет собой подробное описание нового фантастического мира.
Этот метод распространяется на неизобразительные искусства. Иногда, находясь в поиске сюжетных идей, я задействовал короткие рассказы, чтобы мое творческое мышление заработало. Истории получались ужасными, но процесс следования истории персонажа, живущего в вымышленном мире, всегда создает идеи для глобальной истории. Люди, ориентированные на результат, могут импровизировать, чтобы экспериментировать с персонажем. Профессионал в аудио может создать звуковую среду. Возможности безграничны.
Мозговой штурм
Мозговой штурм – это полуформальный процесс, предназначенный для быстрого генерирования большого количества разнообразных идей. У разных людей и организаций свои особенности проведения мозговых штурмов. Некоторые из них почти не структурированы, в то время как другие назначают лидеров, которые будут контролировать поток обсуждений и записывать идеи. Мозговой штурм – хорошо известный метод, поэтому я не буду описывать его подробно.
Мозговой штурм хорошо подходит для генерирования идей в большом количестве. Он не подходит для улучшения идей, а идеи, которые появляются в результате мозгового штурма, будут сильно различаться по качеству.
Письменный анализ
Письменный анализ – это форма структурированного мышления. В этой книге я мало писал о документах геймдизайна, но они важны и у них есть свое место. При написании документа мы думаем иначе, как если только прокручиваем мысли в голове. Документ может включать диаграммы, ссылки и хорошо продуманные логические цепочки. Благодаря письменному анализу мы размышляем о деталях так, как не стали бы размышлять спонтанно или если бы обсуждали идею с коллегами.
Глубокий анализ сложного проекта с широкими исследованиями и использованием формальных статистических или математических методов может занять несколько недель. Иногда оно того стоит, потому что в результате можно получить информацию, которая не появится просто так.
Дебаты
Дебаты ведутся с определенной целью: они помогают находить недостатки в идеях. Они занимают огромное место в формальных системах принятия решений, таких как суды, демократия и наука, так как с их помощью можно выявить скрытые предположения и логические ошибки. Но вести дебаты нелегко. Продуктивные дебаты требуют специфического сочетания навыков и социальных условий.
Оба участника дебатов должны быть опытными. Они должны знать, как быстро и эффективно оспаривать и защищать аргументы. Плохой участник дебатов будет тратить время на оспаривание сильных аргументов или пропускать логические ошибки, допущенные противником, делая весь процесс менее продуктивным и медленным.
Участники дебатов должны иметь разностороннее мышление. Это означает, что они обладают разными знаниями, мнениями, опытом и предположениями. Так они могут находить слабости в чужих идеях. К сожалению, разностороннее мышление редко встречается в организациях, потому что там, как правило, нанимают других людей, которые думают так же, как сотрудники организации. Чтобы развить разностороннее мышление, требуются определенные усилия.
Оба участника дебатов должны уважительно относиться друг к другу. Они должны быть в состоянии отделить свои личные чувства от логического процесса дебатов. В противном случае процесс может разрушить их взаимоотношения и перестать быть продуктивным.
Наконец, участники дебатов не должны бояться друг друга. Дискуссия легко может уйти не в то русло в случае дисбаланса власти. Человек, у которого меньше полномочий, не будет честно спорить из-за страха возмездия. Вот почему дебаты лучше всего проводить среди людей, которые вообще не имеют власти друг над другом. Чтобы начальник мог вступать в дебаты со своими подчиненными, он должен сначала доказать свою беспристрастность. Некоторые начальники этого не делают. Они наказывают людей за несогласие, иногда делая это невольно, злобно вздыхая или закатывая глаза. Такое поведение заставляет людей мягче относиться к плохим идеям начальника, что делает дебаты менее полезными.
Тестирование
Мы уже рассматривали плейтестинг. Это самый важный, но не единственный вид тестирования игр. Существуют различные виды тестирования, каждый из которых дает различные виды информации.
Тестирование юзабилити — это метод, заимствованный из дизайна программного обеспечения, который сосредоточен на интерфейсах и элементах управления. Он похож на плейтестинг тем, что предполагает участие реального пользователя, которого сажают перед интерфейсом и смотрят, как он будет его использовать.
QA-тестирование выполняется специализированными тестировщиками и направлено на поиск технических ошибок. Оно важно в любом процессе разработки видеоигры.
Термин фокус-тестирование часто ошибочно используется как синоним плейтестинга. Это неверно. Фокус-тестирование – это форма исследования рынка, в которой участники совместно обсуждают различные идеи касательно продукта. Он не требует работающей игры.
Метрики
В геймдизайне термин «метрики» относится к данным, которые автоматически собираются из игровых сессий. Игра может записывать информацию о разграбленных объектах, проваленных заданиях, времени завершения, побежденных врагах, исследуемых областях или сотне других событий. Метрики можно получить на основании результатов сотен внутренних тестировщиков или миллионов игроков, играющих в общедоступную бета-версию. Затем компьютеры обрабатывают все эти числа в статистических отчетах и графиках, а дизайнеры используют их для принятия проектных решений.
Метрики помогают дизайнерам увидеть паттерны и дисбалансы, которые можно пропустить в плейтестах. Например, в файтинге метрики покажут, что один персонаж выигрывает у другого в 55 % случаев, потому что он может выбирать тысячи матчей. Подобные точные данные нельзя получить на основании плейтестинга, поскольку размер выборки слишком мал. Вот почему метрики неоценимы при тонкой настройке. Не умея видеть маленькие достижения, вы будете замечать только большие изменения в результатах, и прогресс становится прерывистым и неритмичным. Показывая даже небольшие изменения в сложности или ритме, метрики позволяют нам подниматься вверх размеренными шагами и достигать успеха.
Кен Бердвелл пишет о своем опыте использования метрик для тонкой настройки Half-Life:
«К середине проекта, когда основные элементы были созданы и можно было пройти большую часть игры, дело в основном оставалось за тонкой настройкой. Для этого мы добавили в игру базовые инструменты, автоматически записывая положение игрока, его здоровье, оружие, время и любые другие важные действия, такие как сохранение игры, смерть, травмы, прохождение квеста, бой с монстром и так далее. Затем мы взяли результаты нескольких сессий и собрали их воедино, чтобы найти проблемные места. Они включали области, где игрок пробыл слишком долго без каких-либо стычек (скучно), слишком долго со слишком большим количеством здоровья (слишком легко), слишком долго со слишком небольшим количеством здоровья (слишком сложно), и все это дало нам хорошее представление о том, где персонажи игроков, скорее всего, умрут и какие позиции наиболее выгодны для добавления функциональных возможностей».
Когда в 1998 году был разработан Half-Life, занимаясь балансом, другие студии полагались на предположения и самостоятельное тестирование. Эти методы полезны на ранних стадиях разработки, но они не позволяют детализировать более подробные данные, необходимые для идеального баланса степени сложности. Благодаря метрикам качество дизайнерских решений принесло огромное преимущество разработчикам Valve. И им не нужно было быть умнее всех, чтобы создать лучшую игру, потому что они работали на свету, а все остальные работали в темноте.
В дополнение к корректировке метрики также позволяют дизайнерам находить редкие пиковые ситуации. Возможно, 20 привлеченных вами тестировщиков не найдут эту вырожденную стратегию, но если ее обнаружит один из миллиона игроков в общедоступной бета-версии, то это будет отображаться как пик данных.
Иногда мы можем использовать продуманные метрики для сбора данных, которые на первый взгляд получить невозможно. Например, работая над игрой Halo: Reach, разработчики компании Bungie хотели получить больше информации о влиянии медленной игры в сети на опыт. Игра уже могла записывать файл кинофрагмента, включая каждую игровую переменную в любой момент, включая лаги. Но этого было недостаточно – дизайнеры хотели знать, как игроки воспринимают лаги, которые сложно увидеть в данных. Решить эту проблему с помощью плейтестинга было невозможно, поскольку многие проблемы с лагами встречаются настолько редко, что дизайнерам потребовалось бы огромное количество времени на просмотр достаточного количества плейтестов. Более того, для реального сетевого тестирования требуется, чтобы игроки были рассредоточены, что делает практически невозможным следование традиционным протоколам плейтеста.
Разработчики решили проблему, добавив специальную кнопку: «Я только что увидел лаг». Они регистрировали количество нажатий, а также остальную игру. Как только данные поступали, дизайнеры просматривали изображение и переходили в те точки, где игроки нашли лаг, чтобы точно увидеть то же, что и на экране игрока. Благодаря данному нестандартному методу дизайнеры получили огромное количество достоверной информации о восприятии лагов при относительно небольших затраченных усилиях разработчиков. Таким образом, они решили многие проблемы с восприятием лагов, и Halo: Reach стала отличной сетевой игрой. Разработчики получили прекрасный чистый код, и вовсе не потому, что они были светилами программирования. Как и сотрудники Valve, они работали с большим количеством информации.
Изобретенные методы
На некоторые вопросы невозможно ответить установленными методами. В этих случаях мы должны вернуться к началу и придумать новый способ получения необходимой информации.
Создавая игру для людей в возрасте, разработчику, возможно, придется придумать специальный протокол плейтеста. Игра с необычной внутриигровой экономикой может потребовать новых способов анализа и интерпретации данных. Команде разработчиков, работающей на разных континентах, возможно, придется вступать в дебаты и проводить мозговые штурмы не так, как это делают разработчики, находящиеся рядом. Изобретение и улучшение инструментов создания знаний являются неотъемлемой частью геймдизайна.
Органический процесс
Давайте рассмотрим классический пример процесса создания знаний. Этот пример не из геймдизайна, а из изобретательства.
С наступлением XX века не одна команда пыталась изобрести летательные аппараты тяжелее воздуха.
Некоторых на это толкало скорее хвастовство, чем способности. Они привязывали плавники или крылья к телу и пытались взлететь, многие погибли, испытывая свои безумные изобретения, прыгая с мостов или холмов.
Другие были более серьезными. У этих благородных европейских изобретателей и известных американских ученых, казалось, были все преимущества. Одним из самых богатых был Сэмюэл Лэнгли, секретарь Смитсоновского института, который использовал свои связи, чтобы получить 70 тысяч долларов из государственного финансирования США.
Но устройства Лэнгли так и не заработали, ничего не получилось и у его богатых коллег. Зато все получилось у Орвила и Уилбура Райтов, ремонтников велосипедов из Огайо, и они добились того, что человек сумел полететь. Они потратили менее тысячи долларов.
Как? Как два человека без особых связей обошли крупнейшие государственные проекты в мире, имея менее чем 2 % бюджета?
Благодаря умению создавать знания. Райты не просто нарисовали свой проект на бумаге, построили его и полетели. Они применяли головокружительное множество методов создания знаний в течение нескольких лет. Они провели сотни испытаний, многие из которых требовали изобретения новых методов и устройств для испытаний. Они спроектировали и построили планеры, сечения аэродинамических поверхностей и руль управления полетом, и каждое из этих устройств было разработано для решения конкретной задачи. Они использовали математические расчеты, полевые и лабораторные испытания, руминацию, аргументацию и дебаты, а также исследования и разработки. На каждом этапе они выбирали наиболее подходящий метод для решения следующего неизвестного. С каждым последующим полетом планера, изменением его дизайна и новыми расчетами они узнавали все больше нового о том, как летать.
Они были очень упорными. На своем планере 1902 года братья провели 1000 испытательных полетов, снова и снова модифицировали его и каждый раз узнавали что-то новое. Отдельные полеты мало чему научили их, но по мере накопления знаний Райты начали осваивать небо.
Полученные знания, а также источники их получения были очень разнообразны. При тестировании разных вариантов сечений аэродинамических поверхностей в аэродинамической трубе они узнали, что традиционное уравнение подъемной силы было неверным. Во время полевых испытаний планера они узнали, что установленный спереди горизонтальный стабилизатор позволяет самолету осуществлять мягкую посадку «на живот». И у них были моменты озарений, порожденные бессознательным размышлением: думая над управлением креном самолета, Уилбур безучастно крутил в своей мастерской длинную коробку и вдруг понял, что для того, чтобы контролировать крен самолета, можно изменить форму крыла. В результате это привело к появлению системы управления круткой крыла.
В то же время Лэнгли и другие также использовали свои ресурсы, но делали это неправильно. Большинство из них были сосредоточены на создании более мощных двигателей. В то время проектирование двигателей было традиционной деятельностью, поэтому деньги можно было легко вложить в создание более совершенных двигателей. Однако Райты понимали, что дело было не в двигателях. В то время как о двигателях было известно многое, об аэродинамике не было известно почти ничего. Платить за лучшие аэродинамические системы управления было попросту некому; практически никто не был готов заниматься исследованиями. Так что Райты сделали это сами, используя свои собственные методы создания знаний.
И Райты стали мастерами по экспериментальному проектированию и конструированию. Они построили самую точную в мире аэродинамическую трубу и использовали ее для испытания 200 различных форм крыльев. Когда выяснилось, что испытания методом проб и ошибок с использованием полноразмерного планера стоят слишком дорого, они создали устройство, похожее на велосипед, к которому можно было прикреплять аэродинамические части. Езда на велосипеде толкала часть крыла в воздух и позволяла измерить его показатели, давая тот же результат, что и планер, при гораздо меньших затратах. Они не просто изобрели самолет; они изобретали все инструменты, необходимые для изобретения самолета.
Братья столкнулись со множеством неудачных попыток. Планеры не могли подняться, не могли повернуть, повернули не в ту сторону или упали на землю. Значения коэффициента подъемной силы и результаты испытаний формы крыла, полученные предыдущими исследователями, оказались неверными и требовали пересмотра. Конструкции винтов, которые они надеялись позаимствовать из судостроения, не работали, поэтому пришлось изобретать свои собственные. Ни у одного производителя двигателей не было достаточно легкого источника энергии, поэтому они построили его в своей мастерской. Компоненты часто ломались, откладывая испытания и требуя дорогостоящих замен. Несмотря на все это, у них не было никакой гарантии, что самолет когда-нибудь будет работать. Но они твердо стояли на своем.
Не было такого дня, когда самолет был бы готов. В течение многих итераций его производительность постепенно улучшалась. В 1899 году они запустили воздушного змея шириной полтора метра. В 1900 году они запустили достаточно большой планер, который мог поднять человека. Планер 1902 года имел новые рули и систему управления, позволяющую пилоту совершать управляемые повороты влево и вправо. В 1903 году они добавили двигатель и полетели с подачей энергии и возможностью управления, но всего на несколько секунд в нескольких метрах над землей. Райты продолжали работать, улучшая слабые стороны проекта, учась на ошибках и достигая больших успехов. К 1905 году Уилбур совершал 40-минутные полеты на расстояние 32 км. Они работали в течение шести лет.
Задача геймдизайнера имеет много общего с задачей Райтов. Как и самолет, игра – это система. Она служит другой цели, но процесс изобретения принципиально тот же. Геймдизайнеры – это изобретатели машин для генерирования опыта.
Работа Райтов похожа на итерацию. Но очевидно, что итеративный цикл из трех частей является преступным упрощением той работы, которую они проделали.
Райты тестировали, но не по фиксированному графику. Их процесс был органичным, включал множество различных взаимодействий. Их подход менялся каждый день в соответствии с их потребностями. То же относится и к геймдизайнерам. Иногда мы должны планировать. Иногда должны размышлять, рассчитывать, рисовать или изобретать новый метод создания знаний. Изобретение – это не повторяющийся конвейерный процесс. Это постоянно меняющаяся интеллектуальная граница.
Так что схема итерации, которую я показывал ранее, неверна. Настоящий геймдизайн более органичен.
И этот процесс усложняется в тысячу раз, когда команда становится гораздо больше, чем всего несколько людей. Создание знаний – очень изменчивый и тщательный процесс. Он бурлит в каждом разработчике, ежесекундно, ежедневно. Каждая мысль дизайнера создает знание. Каждый раз, когда художник откидывается назад и смотрит на картину, чтобы увидеть ее под другим углом, он создает знания. Каждый раз, когда программист запускает игру на пять секунд, чтобы проверить виджет интерфейса, он создает знания. Итерационный цикл не может управлять этим, и никто не может сделать так, чтобы процесс выполнялся по заданному расписанию. Это невозможно.
Вот почему как дизайнеры мы должны помнить, что можем управлять только основными процессами, которые мы запускаем. Реальность всегда более органична и сложна, чем наше представление о ней.
Глава 13. Зависимости
После создания заповедника недавно обученные смотрители парка сразу решили внести некоторые изменения. Они думали, что лосей было недостаточно, поэтому запустили программу по их вскармливанию.
Популяция лосей значительно выросла. Вскоре огромные стада лосей начали съедать осины и ивы. Это привело к исчезновению бобров, так как у них не осталось достаточно древесины для плотин. Без плотин парк начал пересыхать каждое лето. Для рыбы не осталось водоемов, и вскоре озера опустели. С исчезновением рыбы упала популяция гризли, так как они выживали благодаря пойманной из рек рыбе. С исчезновением гризли и появлением такого количества лосей, на которых можно охотиться, выросла популяция волков. Рост популяции оленей вскоре прекратился из-за волков и выпаса лосей.
И изменения продолжались, распространяясь на всю экосистему…
Геймдизайн может иметь сотни механик, вымышленных элементов и подсистем. Даже в течение нескольких минут после создания идеи игры у дизайнера может быть 20 различных идей для задач, систем и интерфейсов, которые можно добавить. Имея такое количество идей, как мы узнаем, над чем работать в первую очередь? Начнем ли мы с самого уникального? Самого основного? Самого легкого? Самого технологичного? Самого рискованного?
Ключ к ответу на этот вопрос заключается в понимании зависимостей.
ЗАВИСИМОСТЬ – это такое отношение между двумя частями проекта, когда изменения в одной части вызывают изменения в другой.
Представьте, что кто-то просит вас покрасить 10 домов. В этой задаче нет зависимости. Неважно, в каком порядке вы будете их красить, потому что это не влияет на то, как вы будете красить другие дома.
В геймдизайне все не так. Различные части дизайна часто взаимозависимы. Внешний вид уровня зависит от оформления этого уровня. Оформление зависит от инструментов игрока. Инструменты игрока зависят от базового интерфейса. Если какой-либо элемент изменяется, то изменяется и каждый зависимый от него элемент.
Понимание зависимостей помогает нам снизить риск того, что придется переделывать законченную работу из-за изменений в каком-то месте, от которого она зависела. Например, представьте, что мы потратили время на анимацию персонажа, который бегает со скоростью 5 километров в час во всех направлениях. Если позже мы решим, что он должен двигаться со скоростью 7 километров в час, всю эту анимацию придется переделывать.
Анимация зависит от дизайна системы движений персонажа; изменение в системе движений повлияет на анимацию и испортит хорошую работу. Если бы мы лучше понимали зависимости, мы могли бы сначала укрепить механику движения (в «сером ящике»), а потом делать анимацию.
Стек зависимостей
Чтобы понять зависимости в дизайне, дизайнеры могут построить стек зависимостей.
СТЕК ЗАВИСИМОСТЕЙ – это простой метод анализа, который определяет ключевые зависимости между элементами проекта. Так мы можем понять, над чем нужно работать сейчас, а что можно оставить на потом.
Чтобы создать стек зависимостей, мы начинаем с геймдизайна. Проект может быть представлен в виде плана на бумаге в начале разработки или он может быть частично реализован и протестирован. Мы разбиваем игру на отдельные элементы – механику, элементы управления, интерфейсы и подсистемы. Затем определяем ключевые зависимости между этими элементами. Наконец, мы рисуем график, иллюстрирующий все взаимозависимости. Это и есть стек зависимостей.
Давайте разберем пример. Представьте, что мы делаем Fantasy Castle, легкую игру о строительстве замка в фэнтези-мире. Разработка Fantasy Castle только началась, поэтому команда дизайнеров переполнена идеями, но им не хватает протестированных и проверенных проектных решений. Они написали длинный дизайн-документ. Каждая из 22 подсистем подробно описана на бумаге. Далее следует их краткое изложение в произвольном порядке:
• Персонажи. Могут существовать и перемещаться в окружающей среде.
• Семьи. Персонажи могут вступать в семейные отношения.
• Расы. Замок может быть заполнен большой группой людей, эльфов, гномов и других фэнтезийных рас.
• Межвидовое скрещивание. Различные виды могут скрещиваться, чтобы создать гибриды с общими характеристиками своих родителей.
• Нападения гоблинов. Гоблины могут устраивать периодические облавы, чтобы проверять оборону замка.
• Сельское хозяйство. Сельское хозяйство и продовольственная система дают населению пропитание.
• Торговля. Персонажи могут торговать с соседними замками особыми или редкими товарами.
• Образование. Персонажи могут получить образование.
• Изобретения. Образованные персонажи могут изобретать новые машины для замка.
• Религия. Персонажи могут строить храмы и проводить там религиозные обряды, развивать отношения с конкретными божествами и получать дары от них.
• Гнев богов. Другие божества разозлятся на вас, если вы будете неуважительно относиться к ним или поклоняться их врагам.
• Друзья. Персонажи могут иметь платонические отношения.
• Романтика. Персонажи могут иметь романтические отношения.
• Строительство. Персонажи могут что-то строить.
• Стены. Персонажи могут строить стены, чтобы остановить врагов.
• Укрепления. Стены можно укреплять и утолщать, чтобы сдерживать гоблинов.
• Ловушки. Персонажи могут устанавливать ловушки или автоматические защиты.
• Сражения. Персонажи могут бороться, чтобы защитить замок.
• Захватчики. Можно организовывать группы захвата, чтобы исследовать близлежащие подземелья и получать добычу.
• Приключения. Можно обслуживать путешествующих искателей приключений, обеспечивая трактиры и лавочников в обмен на трофеи из древних склепов.
• Времена года. Полный сезонный цикл влияет на сельское хозяйство, строительство и другие виды деятельности.
• Мыльная опера. Среди жителей замка разыгрываются адюльтер и прочие романтические драмы.
Игра может включать в себя все эти элементы, но как выбрать, на чем сосредоточиться в первую очередь? Начинать ли с основ мира и создавать времена года? Начинать с персонажей, друзей и семьи? Возможно, следует начать с войны, выстроив боевую систему для сражений между жителями замка и гоблинами? Начать с уникальных элементов игры, таких как искатели приключений, или построить базу, используя элементы, которые были сделаны ранее в других играх, такие как стены и бои? Стек зависимостей помогает нам принять решение.
Ниже представлен мой стек зависимостей для игры Fantasy Castle:
Нет смысла в ловушках и оборонительных системах, если нет набегов гоблинов. Набеги гоблинов не нужны, если нет боя. Бой не имеет особого значения при отсутствии стен и не может работать без персонажей. Для стен нужны системы строительства, которые требуют, чтобы персонажи работали. Каждый элемент зависит от нижестоящих элементов.
Прежде чем мы продолжим, позвольте мне прояснить понятие зависимости.
ЗАВИСИМОСТЬ не означает, что основополагающий элемент не должен влиять на зависимый элемент. Она предполагает, что изменения в дизайне базового элемента приведут к изменениям в зависимом элементе.
Помните, что блоки стека – это не просто слова, которые вы видите, – каждое слово представляет собой подробный дизайн нескольких страниц. Части этих дизайнов взаимосвязаны. Например, дизайн строительства описывает каждую кнопку, выделение и опцию интерфейса, который игроки используют для конструирования. Аналогичным образом дизайн фермерства подробно описывает размещение, управление и удаление ферм. При этом дизайн фермерства предполагает, что дизайн строительства будет правильным. Что произойдет, если изменятся детали в интерфейсе строительства, если кнопки поменяются местами или будут заменены на управление мышью? Строительство все еще остается в игре, но оно изменилось, и теперь все детали фермерства необходимо изменить соответствующим образом. Вот почему фермерство зависит от строительства.
Существует гораздо больше зависимостей подобного типа, чем записано в стеке. Например, я разместил стек «стены» над стеком «строительство». Но возможно, что в процессе разработки дизайнеры могут обнаружить, что им нужно изменить интерфейс строительства, чтобы упростить строительство стен. Таким образом, стек «стены» зависит от стека «строительство», а стек «строительство» зависит от стека «стены» – циклическая зависимость. Эти нити зависимостей пронизывают Fantasy Castle насквозь. Возможно, придется изменить стек «стен», чтобы их можно было легче размещать вокруг ферм. На систему изобретений может повлиять стек «дружеские взаимоотношения», если друзья могут настраивать друг друга на создание изобретений. В каком-то смысле любой элемент может повлиять на все остальное, поэтому все взаимозависимо.
Но некоторые из этих зависимостей сильнее, чем другие. Значительные изменения в стеке «стены» могут в некоторых случаях повлиять на стек «строительство». Но изменения в стеке «строительство» почти наверняка затронут стек «стены». Стек зависимостей намеренно игнорирует самые слабые зависимости, чтобы мы могли сосредоточиться на наиболее важных и потенциально опасных из них. Нахождение этого фокуса является целью стека.
Стек зависимостей является редуктивным. Он не включает в себя важные части реальности разработки. Но если вы просто человек, столкнувшийся с такой сложной проблемой, как сотня взаимозависимых элементов дизайна, включающих сто тысяч взаимосвязей, рациональная редукция – единственный способ добиться прогресса. Мы должны игнорировать некоторые зависимости, иначе погрузимся в аналитический паралич. Стек зависимостей – это не теоретический вопрос, это инструмент для принятия решений. И эти решения лучше принимать, концентрируясь на наиболее значимых взаимозависимостях. Существует несколько способов построения стека зависимостей с учетом деталей дизайна. Можно представить себе игру по строительству замков, в которой существует строительство, но нет персонажей. Или такую, в которой есть нападение гоблинов, но нет стен. Я создал этот стек на основании придуманных мной деталей для Fantasy Castle, но мне не хватит этой книги для того, чтобы я мог их описать. Если бы дизайн-документы были написаны по-разному, стеки бы тоже были разными, даже если бы названия были одинаковыми.
Каскадная неопределенность
Мы уже видели, что проекты могут не работать так, как мы ожидаем. Дизайнеры могут написать документ о том, как будут работать нападения гоблинов, но они не могут быть уверены, что это будет работать именно так, как предполагалось. Дизайнеры смогут убедиться, будет ли это работать, только когда проведут компилирование и плейтест.
Неопределенность усиливается в результате зависимостей.
Читать бесплатно другие книги:
