Войти в систему
Войти с помощью соц. сетей:
В этой главе
• Балансировка в ходе разработки.
• Ранние этапы разработки.
• Первая пригодная для игры версия.
• До альфа-версии.
• Альфа-версия.
• Бета-версия.
• Пострелизный этап.
• Игровое тестирование с целью балансировки.
На первые 90 % кода приходятся первые 90 % времени разработки. На остальные 10 % кода приходятся остальные 90 % времени разработки.
Правило 90–90, Том Каргилл (Tom Cargill), компания Bell Labs
Начинающие дизайнеры часто задают следующий вопрос о балансе: на каком этапе цикла разработки следует приступать к балансировке игры? Это хороший вопрос. С одной стороны, нельзя начинать слишком рано, поскольку любое изменение основной механики игры полностью разбалансирует ее и почти вся работа по балансировке, выполненная до этого, окажется напрасной. С другой стороны, нельзя начинать и слишком поздно, поскольку, если вы протянете до самого конца цикла разработки, у вас не останется времени на то, чтобы сбалансировать компоненты должным образом.
Кроме того, применение различных методов балансировки может оказаться более или менее сложным на разных этапах разработки. В самом ее начале, когда игра представляет собой лишь грубый прототип, наблюдение за ходом игрового тестирования с участием нескольких человек может оказать неоценимую помощь. Но позднее, когда дело уже подходит к выпуску игры, привлечение большого количества игроков, желающих торчать в комнатах наблюдения, становится нецелесообразным, особенно если ваша компания проводит широкое бета-тестирование. С аналитикой картина обратная: в начале разработки у вас просто нет статистически значимого количества аналитических данных, но, когда уже есть данные от нескольких сотен тысяч участников тестирования предварительной бета-версии, использование этой аналитики приносит гораздо больше пользы, чем простое наблюдение за тем, как несколько человек играют в вашу игру, сидя перед вами.
В этой главе мы пройдемся по всем этапам создания игры — от формирования общего замысла до этапа, следующего за ее выпуском, — и поговорим о том, какие связанные с балансом задачи должен решать разработчик на каждой из этих стадий.
На самых ранних этапах работы над игровым проектом, когда у вас еще даже нет пригодного для игры прототипа, в механику игры постоянно вносятся значительные изменения. Главной задачей здесь является получение не сбалансированной, а для начала достаточно увлекательной игры либо каким-то иным образом удовлетворяющей цели дизайна. Вам нужно получить надежное ядро игры — базовый игровой процесс, повторяемый на всем ее протяжении. Поскольку на этом этапе игра еще подвергается значительным изменениям, проводить ее балансировку пока не имеет смысла. Прежде чем волноваться о балансе, сделайте игру увлекательной.
Единственным исключением здесь является тот случай, когда игра настолько далека от сбалансированного состояния, что это не дает вам получить содержательные результаты игрового тестирования. Если я не могу играть в вашу стратегическую игру изначально предполагавшимся образом, потому что обнаружил эксплойт вырожденной стратегии, позволяющий мне прийти к победе в обход большей части механизмов, с которыми я должен взаимодействовать, вы должны исправить это, потому что дисбаланс не дает вам получить содержательные результаты тестирования и продолжить доработку игры. В таком случае, безусловно, нужно потратить определенное время на балансировку и устранить наиболее очевидные проблемы. Хорошей новостью является то, что сделать это, как правило, довольно просто: в сильно разбалансированной игре источники проблем вполне очевидны, и вы можете, используя какой-либо грубый метод, «занерфить» эксплойты лишь настолько, чтобы игра снова стала тестируемой (на этом этапе не нужно добиваться идеального баланса — главное, чтобы баланс перестал быть препятствием при реализации разработки).
Однако для получения первой версии игры вам еще нужно будет присвоить числовые значения различным ее элементам, не имея пока ни математических моделей, ни результатов игрового тестирования, ни аналитических данных. Откуда вы возьмете эти цифры, если пока не на что опереться, кроме своей интуиции?
Одним из первых и самых важных решений в работе над игрой является ответ на вопрос о том, должно ли в ней все быть слишком мощным (игра все равно может быть сбалансированной, если все будет слишком мощным в одинаковой степени) или в ней ничто не должно быть слишком мощным. В зависимости от того, какую именно игру вы создаете, уместными могут быть оба подхода. Однако с точки зрения общего впечатления от игры ваш выбор в этом вопросе определяет и подход при определении числовых значений. Если вы решили, что игра должна представлять собой эпическое сражение между мощными существами, то почти все числа должны быть очень большими. Например, доспехи должны выдерживать урон в несколько миллионов очков здоровья, кумулятивные бонусы урона должны обеспечивать нанесение одним ударом урона, измеряемого числами со степенями, а перемещение должно осуществляться практически мгновенно. В таком случае следует обеспечить большой контраст между различными элементами, используя экстремально большие числа и сдерживая себя лишь там, где это абсолютно необходимо. В более реалистичной игре следует применять более скромные цифры, стараясь не выходить за границы узкого диапазона средних значений, при этом большие отклонения от этого диапазона будут заметными исключениями, немедленно привлекающими к себе внимание игрока и требующими особого внимания при последующей балансировке игры. В большинстве случаев следует не допускать того, чтобы в вашей игре почти все выглядело заурядно и лишь некоторые вещи были сверхмощными, — это может привести к тому, что игроки будут учитывать только эти несколько вещей, игнорируя или отбрасывая как ненужный мусор все остальное.
Определившись с тем, насколько большим должен быть разброс числовых значений, следует подумать о назначении или роли каждого элемента игры. Какими свойствами определяется каждый из них? Если вы создаете класс персонажей, то какая у них роль — они должны наносить большой урон, защищать остальных членов партии, увеличивать количество получаемой добычи или выполнять другую функцию? Если создаете некоторый вид оружия в шутере, то для чего оно больше подходит — для стрельбы с дальней дистанции на открытой местности или для уничтожения больших, но медленно движущихся транспортных средств в условиях ближнего боя в тесных туннелях? Если вы создаете определенный элемент доспехов в ролевой игре, то он защищает от физических или магических атак? Или, возможно, обеспечивает меньшую защиту при более высокой способности к уклонению, что позволяет вообще не подвергаться ударам? А может, он лишь предоставляет бонусы статистики, увеличивающие наносимый урон, не обеспечивая при этом какой-либо защиты? Если вы разрабатываете тип башни в игре жанра «защита башни», то для чего он больше подходит — для борьбы с группами врагов, отдельными мощными врагами наподобие боссов, врагами в доспехах, быстро движущимися врагами или должен выполнять иную функцию, например усиливать ближайшие башни или ослаблять ближайших врагов, делая их более уязвимыми для других типов башни? Если вы создаете вражеского персонажа, то должен ли он вызывать у игрока ощущение собственной силы или сообразительности, производить на него грозное впечатление или играть какую-то иную роль? В общем, подумайте обо всех преимуществах и особенностях того, что вы создаете.
Определившись с тем, что должен делать компонент игры, подумайте о том, какие числовые значения позволят этого добиться. Если вам нужен класс персонажей, представляющий собой «стеклянную пушку» (способный наносить большой ущерб противникам, но разваливающийся на части при получении небольшого урона), то, максимизировав параметры, которые определяют количество наносимого урона, и минимизировав параметры, определяющие способность переносить получаемый урон, вы получите первоначальную основу для этого класса. Конечно, эти цифры будут далеко не окончательными, но, повторим, на ранних этапах разработки ваша задача не в том, чтобы добиться баланса, а в том, чтобы задать общую атмосферу игры.
Поскольку вам нужно как можно быстрее получить играбельную версию (чтобы можно было приступить к игровому тестированию и оценить, насколько увлекательной она является), можно пока не создавать для игры весь контент. Если вы создаете MOBA-игру, в окончательной версии которой должно быть свыше 100 активных персонажей, не стоит создавать их всех уже на первых этапах разработки. Вместо этого отберите несколько персонажей, представляющих все стратегии, которые должна поддерживать игра. Если, например, предполагается, что большинство персонажей вашей игры будут выполнять три традиционные роли: «урон в секунду», «танк», и «поддержка», то пока достаточно создать трех персонажей, позволяющих в целом понять, как будет выглядеть игровой процесс. Если можете создать одного «ванильного» персонажа, представляющего всех персонажей игры, то сделайте только его в качестве базового варианта, дающего общее представление о том, персонажей с каким уровнем мощности и набором навыков вам нужно будет сбалансировать. Фактически нужно создать абсолютный минимум контента, позволяющий получить игру, которую можно будет подвергнуть игровому тестированию и которая продемонстрирует основные механизмы, стратегии и стили игры, которые вы собираетесь поддерживать.
Наконец, при создании каждого игрового объекта на данном этапе будет полезно документировать его назначение. Опишите в одном или нескольких предложениях назначение или роль создаваемого компонента, а также «ручки настройки» его дизайна: какие цифры можно менять, какие — нельзя и какие еще ограничения следует соблюдать, чтобы не терялся исходный смысл использования этого объекта в игре. Сохраните документацию так, чтобы ее можно было легко найти впоследствии. Когда придет время всерьез заняться балансом, вы наверняка обнаружите значительный дисбаланс, и эти заметки позволят вносить изменения таким образом, чтобы их не приходилось впоследствии отменять.
Не стоит сильно переживать, если на данном этапе вам еще не удастся добиться идеального баланса. Задача здесь состоит в том, чтобы получить играбельную версию, сделать ее увлекательной и получить первое представление о том, к чему следует стремиться и как сказываются на игровом процессе те или иные числа. Хотя вы можете сильно ошибаться в исходных предположениях, чем больше таких предположений вы делаете, тем быстрее удастся развить чутье и интуицию разработчика. Даже подбирая неправильные наборы чисел, вы будете расти как разработчик систем.
На каком-то этапе разработки (надо надеяться, довольно раннем) вам удастся получить первую версию игры, способную обеспечить определенную форму игрового процесса. Эта версия может работать не так, как надо, содержать множество ошибок (если речь идет о компьютерной игре), в ней могут отсутствовать большая часть контента и ряд ключевых систем, но она уже будет позволять вам сыграть и получить определенный опыт. В игровой индустрии такую версию, что вполне логично, принято называть первой играбельной версией игры. Именно здесь начинают проводить игровое тестирование.
На этом этапе, как правило, тестирование будет выполняться с участием небольшого круга людей. В случае коммерческой видеоигры вы, вероятно, еще не успеете анонсировать проект и поэтому ограничитесь игровым тестированием с участием членов команды разработчиков или, возможно, очень надежных друзей, подписавших соглашение о неразглашении информации. Если это настольная игра, разработчик может сыграть несколько партий с членами своей семьи, друзьями или с небольшой локальной группой игрового тестирования (если ему посчастливится обзавестись таковой).
Это тестирование еще не будет ориентированным на баланс. Пока нужно будет главным образом проверить, удалось ли вам получить увлекательную игру, работает ли основная ее механика и соответствует ли реальный игровой процесс исходному замыслу. (Ответ на все эти вопросы часто оказывается отрицательным — именно поэтому мы и проводим игровое тестирование. В этом нет ничего страшного — просто вносите изменения для устранения проблем и повторяйте тестирование до тех пор, пока игра не начнет нормально работать на базовом уровне.)
Единственно, на что здесь нужно будет обратить внимание в части баланса, так это на макроуровневый баланс между общими стратегиями, сборками персонажей или стилями игры — в зависимости от того, что из этого актуально для вашей игры. Если вы используете пять «ванильных» ролей персонажа, представляющих различные стили игры, то сбалансированы ли эти роли в целом по отношению друг к другу, или одна из них неизбежно оказывается более сильной или более слабой по сравнению с остальными — в силу не столько применяемых чисел, сколько того, что основная механика ставит в более или менее выгодное положение игроков, использующих определенный стиль игры? Если, например, вы обнаружите, что в вашей игре дальние атаки слишком мощны по сравнению с атаками ближнего боя, это не значит, что вы должны тут же устранить данную проблему как первоочередную. Вы должны лишь взять это себе на заметку и, возможно, немного скорректировать механику, чтобы проблема не выходила из-под контроля.
Получая обратную связь от тестировщиков в ходе разработки, помните о том, что исправлением выявленных проблем должен заниматься разработчик, а не тестировщик. Задачей участников игрового тестирования является поиск проблем, а не возможных способов их решения. Тестировщик, как правило, не обладает необходимым опытом для того, чтобы правильно определить источник проблемы и предложить оптимальное решение, за исключением случая, когда его роль берет на себя разработчик. (Даже опытные разработчики игр могут испытывать с этим затруднения, если они еще не успели составить четкое общее представление об игре.) Иными словами:
• если участник игрового тестирования говорит: «Мне не нравится в игре вот это», то это полезная информация — тем самым он сообщает вам о наличии проблемы. После этого вы должны выяснить, почему ему не нравится указанное, а затем выявить и устранить источник проблемы;
• если участник игрового тестирования говорит: «Мне не нравится в игре вот это и вот почему», то это еще более полезная информация, поскольку он делает за вас половину работы. Вам остается лишь выявить и устранить источник проблемы;
• если участник игрового тестирования говорит: «Я думаю, что вот это вы должны заменить на вот это», то тем самым он сообщает вам меньше полезной информации и в два раза увеличивает объем выполняемой вами работы. Вначале следует определить, какой элемент игры не нравится тестировщику, исходя из сделанного им предложения (какую реальную или воображаемую проблему он хочет решить, внося это предложение?). После того как вы это выясните, потребуется узнать, почему ему не нравится этот элемент игры, в чем причина проблемы и как ее можно устранить, — и внесенное вами изменение, как правило, будет отличаться от того, что изначально предлагал тестировщик.
Обычно критика со стороны игроков сводится к тому, что предлагаемая им игра отличается от их представлений об идеальной игре. Вы, как разработчик, должны сначала выяснить, с какой игрой они сравнивают вашу, и определить, действительно ли вы стремитесь создать что-то подобное. После этого либо постарайтесь, чтобы игроки изменили представление о вашей игре (дав им четко понять, какую игру создаете на самом деле), либо внесите изменения в игру.
Более или менее разобравшись с основной механикой игры, можно приступить к созданию математических моделей. К этому моменту вы уже, вероятно, провели достаточное количество игровых тестов для того, чтобы сделать игру увлекательной, и имеете некоторое общее представление о том, какие значения следует использовать для тех или иных элементов и как должны выглядеть кривые вашей игры. Баланс по-прежнему остается не самой приоритетной вещью, но вы уже можете приступить к настройке электронных таблиц с помощью формул, отражающих взаимосвязи между различными механизмами. Эти таблицы могут стать хорошим подспорьем при последующей балансировке, и, зная, что механика игры уже не претерпит больших изменений, можете выполнить эту работу прямо сейчас.
Конечно, ваши первые электронные таблицы будут далеки от идеала. Подобно тому как при определении числовых параметров обычно не удается выбрать идеально сбалансированные числа с первой же попытки, при создании формул, описывающих взаимосвязи между этими числами, вам вряд ли удастся сразу же точно отразить реальное положение дел. Однако вы должны с чего-то начать, и чем раньше это сделаете, тем больше у вас будет возможностей сказать: «Нет, постойте, эта модель неверна, в ней заклинание “Яд” мощнее заклинания “Огненный шар”, что совершенно неверно… А! Я понял, так происходит потому, что урон, получаемый с течением времени, здесь приравнивается к немедленному получению урона. Так давайте уменьшим размер будущего урона… Вот, совсем другое дело!»
Если при последующей балансировке вы собираетесь применять показатели и аналитику, то на этом этапе следует подумать также о том, какие хуки аналитики будут использоваться в игре. Какие данные необходимо собирать и сохранять в игре, чтобы на их основе можно было принимать информированные решения относительно баланса? Вы должны принять во внимание все связанные с этим плюсы и минусы: сколько времени придется потратить программисту на встраивание хуков аналитики, вместо того чтобы потратить это время на непосредственную работу над игрой, и какими будут затраты пропускной способности и места на диске (если вы будете сохранять буквально всю информацию, может заметно уменьшиться частота кадров, что станет серьезной проблемой в игре с очень динамичным игровым процессом). Расставьте приоритеты и решите, какие данные нужно собирать, после чего проработайте этот вопрос со своими программистами.
Главной целью при этом по-прежнему является не активная балансировка игры (что нужно делать лишь в случае, если несбалансированность игры вызывает много нареканий у участников игрового тестирования и препятствует дальнейшему прогрессу), а создание инструментов, которые можно будет использовать для балансировки игры на последующих этапах.
В игровой индустрии нет общего определения того, следует считать альфа-версией (определение может варьироваться в зависимости от компании и издательского контракта), но обычно под этим понимается полнофункциональная версия игры, которая уже содержит все механизмы и работоспособный основной движок и позволяет использовать в ходе игрового процесса практически все системы. На этом этапе игра содержит далеко не весь контент (работа над ним как раз набирает обороты) и в ее программном коде еще имеется множество ошибок, но основной дизайн уже более или менее устоялся. (Хотя вы по-прежнему можете вносить изменения и добавлять новые возможности, после выпуска альфа-версии этот процесс сильно усложняется и часто включает в себя формальную процедуру запроса изменений, которая предусматривает серьезное обоснование их необходимости, поскольку работа над ними может привести к срыву сроков выпуска игры.)
Как раз на этом этапе разработчики создают бóльшую часть контента, наполняя реальным содержанием таблицы монстров и предметов, списки персонажей, деревья диалогов, макеты уровней и т.д. Если на предыдущих этапах вы создали один или несколько «ванильных» ресурсов с целью проверки основной механики игры, на этом этапе следует сбалансировать компоненты относительно этих базовых вариантов. Допустим, речь идет об игре жанра «файтинг»/«массовая драка», такой как Super Smash Bros., где игроку предлагается на выбор более 100 персонажей. В игре с сотней персонажей и четырьмя игроками, даже если не допускается одновременный выбор ими одинаковых персонажей, мы все равно получим 4 млн возможных вариантов матча — это слишком много для того, чтобы можно было провести игровое тестирование каждого из этих вариантов в отношении баланса. Однако если у вас будет некий ряд архетипов персонажей, уже сбалансированных по отношению друг к другу, то вам останется лишь сбалансировать каждого персонажа относительно соответствующего архетипа. В данном примере это означает балансировку около 100 возможных вариантов матча — вполне приемлемое количество. Исходные базовые персонажи могут даже не попасть в финальную версию игры: их назначение не в том, чтобы в итоге стать реальными персонажами, а в том, чтобы выступать в качестве эталонов, с которыми можно было бы сравнивать всех остальных.
Но если вы сбалансируете всех остальных персонажей относительно «ванильных» архетипов персонажей, сделает ли это их автоматически сбалансированными по отношению друг к другу? Вероятно, нет, поскольку каждый отдельный вариант матча может обладать естественными преимуществами и недостатками. Поэтому не исключена вероятность того, что один из ваших персонажей, будучи теоретически сбалансированным по мощности, на деле окажется в более выгодном положении в матчах против большинства остальных персонажей, что означает несбалансированность на уровне метаигры. Таким образом, вы не можете расслабиться, считая, что вся работа уже выполнена. Тем не менее, начав с небольшого набора базовых архетипов и сбалансировав все остальные относительно наиболее подходящего из них, вы сможете получить примерно то, что вам нужно, с минимальными затратами времени и усилий, особенно в случае файтинга, игры жанра MOBA или коллекционной карточной игры, когда нужно сбалансировать множество игровых объектов по отношению друг к другу, не имея времени на то, чтобы тщательно протестировать каждую отдельную комбинацию.
На этом этапе разработки начинает давать результаты выполненная ранее работа по определению связанной с балансом математики. Когда вы начинаете выдавать на-гора большое количество контента, те математические модели, которые вы создали ранее с помощью электронных таблиц, позволяют получать уже прилично сбалансированный контент, прилагая минимальные усилия. (Вы могли убедиться в этом на практике, выполнив побочные квесты из главы 8, где нужно было определить надлежащую стоимость и значения параметров для отдельных предметов с помощью созданной ранее кривой стоимости и вспомогательной математики.) Если вам придется выбирать и изменять числа, еще не имея четкого представления о том, как все соотносится друг с другом, начните с предельных значений: если можно использовать число в диапазоне от 0 до 100, посмотрите, какой результат дают числа 0, 100 и 50, и выполните дальнейшую настройку с учетом этого. При модификации чисел делайте крупные изменения — увеличивайте или уменьшайте число в два раза, если еще не знаете, каким оно должно быть, а если уже примерно понимаете, какое число вам нужно, изменение должно составлять как минимум 10 % (более мелкое вряд ли даст сколько-нибудь заметный эффект). Опыт, полученный при модификации чисел, можно использовать для создания математических моделей с помощью электронных таблиц. Если у вас не будет каких-либо математических моделей, все равно нужно будет присваивать новым элементам значения, но их потребуется часто менять и вам придется тратить больше времени на последующее игровое тестирование.
Что касается игрового тестирования, то на данном этапе оно, как правило, по-прежнему проводится с участием лишь команды разработчиков, родственников и друзей, но при этом уже можно попросить участников тестирования проверить игру на предмет сбалансированности и попытаться найти эксплойты или какие-либо способы нарушения работы игровых систем. Некоторые тестировщики справляются с этой задачей намного лучше других. Как и прежде, главная задача здесь состоит в том, чтобы найти основные эксплойты, не позволяющие подвергнуть игровому тестированию все остальное, но, помимо этого, можно впервые задаться вопросом о том, насколько точны ваши математические модели. Если вам кажется, что определенные части режима кампании в игре намного сложнее других, или один из видов оружия намного мощнее прочих, или что-то еще в этом роде, то посмотрите, насколько с вашим мнением согласны игроки. Если стратегии, используемые большинством участников игрового тестирования, вполне эффективны, но идут вразрез с тем, что предсказывают ваши модели, то сейчас самое время вернуться назад и пересмотреть эти модели, уже располагая более детальными данными и более четким (и постоянно улучшающимся) представлением об игре.
По мере дальнейшего тестирования вы также обнаружите, что, имея свои сильные стороны, каждый тестировщик будет сообщать вам различные сведения об игре. Наряду с тем, о чем информирует тестировщик, учитывайте и то, от кого именно поступает эта информация. В своем уже ставшем классикой выступлении на конференции GDC (ссылку на которое можно найти в конце этой главы) геймдизайнер Джейми Гризмер (Jaime Griesemer) выделил шесть типов тестировщиков.
• Тестировщик, который стремится выиграть. Некоторые тестировщики умеют быстро находить оптимальные решения и склонять баланс игры в свою пользу, выявляя самые мощные элементы ваших систем. Если такой человек ограничивается лишь одним персонажем, предметом, стратегией и т.д., скорее всего, они слишком мощны.
• Недовольный тестировщик. Некоторые тестировщики отличаются очень низким порогом терпимости к дисбалансу и поэтому сразу же начинают выказывать недовольство, жаловаться, переворачивать стол (как в переносном, так и в прямом смысле) и гневно хлопать дверью в случае неблагоприятного для них развития событий. Если такой человек обрушивается с критикой на вашу игру, значит, в ходе игрового процесса его что-то беспокоит. Такие тестировщики чрезвычайно чувствительны к различным шероховатостям игрового мира и хорошо справляются с их выявлением.
• Тестировщик, который всегда играет одинаково. Некоторые тестировщики предпочитают использовать одну и ту же любимую стратегию и потому, когда им дается выбор, всегда пытаются применить один и тот же подход. В идеале у вас должен быть как минимум один такой тестировщик на каждый стиль, поддерживаемый вашей игрой. Например, в шутере от первого лица некоторые геймеры предпочитают использовать снайперскую винтовку. Из предлагаемого вами арсенала они постараются выбрать самую мощную и дальнобойную винтовку и станут пользоваться ею везде, где только возможно. Наблюдение за такими тестировщиками позволяет выявить тот случай, когда одна из предположительно жизнеспособных стратегий на самом деле оказывается нежизнеспособной, поскольку при этом часто только поклонники этой стратегии пытаются ее применить (и, обладая большим опытом, делают это со всем возможным умением).
• Тестировщик, который не умеет играть в вашу игру. Некоторые тестировщики лишь недавно начали играть в видеоигры или мало знакомы с играми того жанра, к которому относится ваша. Такие неопытные или неумелые тестировщики оказывают неоценимую помощь в ходе разработки, позволяя понять, какой игровой опыт будут получать в вашей игре новички и что может стать камнем преткновения для тех, кто играет в нее первый раз.
• Тестировщик, который любит заниматься вредительством. Как показывает практика, в любой многопользовательской игре всегда находятся те, кто старается испортить жизнь другим игрокам. Хотя вы, вероятно, считаете такое поведение недопустимым и не хотите, чтобы такие игроки активно участвовали в доработке игры, их участие в игровом тестировании будет далеко не лишним. Когда вы видите, что такой тестировщик смеется, это означает, что кому-то другому хочется плакать. Выяснив, каким образом можно нарушить игровой процесс другого игрока, вы сможете установить барьеры, не дающие этого делать.
• Тестировщик, играющий на профессиональном уровне. Хотя эта категория в определенной мере пересекается с категорией играющих ради победы, здесь все же предполагается несколько иной тип мышления. Игроки профессионального уровня полагаются на свои навыки, а не на поиск эксплойтов, дающих несправедливое преимущество, и хотя они тоже хотят победить, но очень не любят, когда выигрывает менее искусный геймер за счет фактора случайности или удачи. Хотя определенный элемент случайности может очень хорошо сказаться на игровом процессе, профессиональные игроки прекрасно справляются с выявлением слишком большой доли случайности. Если тестировщик профессионального уровня предлагает полностью выкинуть из игры определенный механизм, это означает, что в нем, на его взгляд, слишком велика доля случайности. Вы можете не удалять весь механизм, а лишь немного убавить эту долю случайности.
Существует старая шутка о том, что на древнегреческом «альфа» означает «программное обеспечение не работает», а «бета» — «программное обеспечение по-прежнему не работает».
Как и в случае с альфа-версией, в игровой индустрии нет общего определения того, что следует считать бета-версией, но обычно под этим понимается версия игры, которая является не только полнофункциональной, но и полноконтентной. То есть это версия, которая позволяет пройти всю игру от начала до конца.
К этому моменту работа над игрой практически завершена, если не считать того, что до ее выпуска еще нужно выявить и исправить как можно больше ошибок. Это напряженное время, когда руководители команд разработчиков регулярно встречаются для того, чтобы пройтись по всем известным ошибкам и решить, какие из них должны быть исправлены в первую очередь, потому что препятствуют дополнительному тестированию, какие — до выпуска игры, а какие еще могут подождать (то есть проводят так называемый триаж — термин заимствован из медицины, где так называется процесс сортировки поступающих в приемное отделение пациентов по степени срочности необходимой им помощи). Именно на этом этапе в основном и выполняется окончательная балансировка игры. Если у команды программистов, как правило, еще полно работы по исправлению ошибок, то команда дизайнеров уже почти закончила работу над механикой, сюжетом и контентом. Остается лишь проследить за тем, чтобы программисты и тестировщики обеспечили надлежащее функционирование всех составляющих игры и как следует ее сбалансировать, поколдовав над цифрами, пока команда программистов по уши завалена работой.
Когда работа над игрой подходит к концу, уже можно выпустить ее в свет либо в виде предварительного релиза, либо в виде закрытой или открытой бета-версии (в закрытом бета-тестировании можно участвовать только по приглашению, а в открытом — всем желающим). В крупных игровых проектах с обширным бета-тестированием на этом этапе можно собрать довольно большой объем данных для эффективного проведения балансировки на основе аналитики. Если компания-разработчик даст понять сообществу игроков, что в игру будут регулярно вноситься изменения из связанных с балансом соображений, это даже может стать источником ажиотажа («Что еще эти сумасшедшие разработчики решат изменить на следующей неделе?»). Отличный доклад о применении такого подхода сделал на конференции GDC Энтони Джованнетти (Anthony Giovannetti), работавший над игрой Slay the Spire в качестве дизайнера (ссылку можно найти в конце этой главы).
Поскольку это последний этап перед выпуском игры, именно сейчас вы будете тратить массу времени на оценку ее сбалансированности, особенно той части, которая требует настройки отдельных чисел, поскольку менять их на этом этапе и проще, и дешевле, чем менять всю механику игры.
При этом помните о том, что степень сбалансированности определяется не только реальной степенью справедливости игры, но и восприятием игрока. Поскольку у вас никогда не будет времени на то, чтобы исправить буквально все, сконцентрируйтесь на тех частях игры, которые производят наибольший эффект и являются наиболее заметными. Старайтесь сбалансировать непосредственно то, что видят и воспринимают игроки. Например, большинство игроков не замечают изменений в размере диапазона случайных отклонений, поскольку случайный выбор каждый раз дает разный результат. Допустим, у вас есть оружие, которое наносит определенный базовый урон с некоторым случайным отклонением. Если вместо диапазона случайных отклонений от 0 до +10 вы начнете использовать диапазон от –3 до +15, это будет гораздо менее заметным, чем изменение базового урона, поскольку игроки не знают, в пределах какого диапазона производится случайный выбор, а видят лишь его результат. Таким образом, вам потребуется выдать довольно много результатов, чтобы игроки хотя бы заметили, что что-то изменилось (конечно, если вы не показываете явно, в каком диапазоне варьируется результат). Вот еще один пример: если у вас есть выбор между изменением физики платформера и математических формул для расчета размера наносимого урона, то изменение физики будет гораздо более заметным и интуитивно понятным для игрока, чем изменение ряда используемых за кадром математических формул, и потому более очевидно повлияет на игровой опыт.
В играх, требующих продолжения разработки после выпуска, таких как MMO-игры, сетевые коллекционные карточные игры или мобильные игры с бесплатным доступом, регулярное добавление нового контента или целых наборов расширения продолжается и на пострелизном этапе. В это время вы уже должны иметь достаточно четкое представление о том, как следует балансировать игру, как выглядит в ней сбалансированное состояние и как соотносятся друг с другом различные числовые параметры.
Иногда новая часть контента или новый набор расширения будет содержать совершенно новую механику. Разработка таких обновлений контента обычно занимает определенное время и проходит через те же этапы разработки, что и в исходной версии игры, только за более короткое время (и здесь вы начинаете разработку, имея больше информации о характере балансируемой игры). В таком случае усилия по балансировке можно сосредоточить на новой механике и на том, как она соотносится со всем остальным.
Преимуществом данного этапа является также то, что вы можете получать реальные пострелизные данные от игроков (в больших объемах, если игра становится популярной), что позволяет лучше понять, насколько хорошо сбалансированы различные элементы исходной версии игры, и обновить математические модели таким образом, чтобы они более точно отражали реальный игровой процесс, что, в свою очередь, обычно упрощает балансировку нового контента. Иногда разработчики даже выпускают балансирующие патчи, которые исправляют наиболее очевидный дисбаланс старого контента, усиливая ранее бесполезные вещи для придания им достаточной ценности и ослабляя слишком мощные компоненты для устранения проблем на уровне метаигры.
На тех этапах разработки, где требуется проводить игровое тестирование для балансировки, легко просто сказать: «Обязательно проводите игровое тестирование с целью балансировки, потому что это действительно необходимо!» Вероятно, на этом стоит остановиться чуть подробнее. Хотя с тестированием, ориентированным на баланс, часто хорошо справляются тестировщики, иногда разработчик должен сам протестировать свою игру или игру коллеги и дать остальным тестировщикам указания относительно того, что именно они должны проверить (если вы просто скажете: «Протестируйте это в отношении баланса», они посмотрят на вас с недоумением).
В случае мелкомасштабного игрового тестирования, например настольной игры или бумажного прототипа с привлечением небольшого круга участников, справедливы все стандартные советы по игровому тестированию.
• Цените время участников тестирования. Вы просите их пожертвовать своим временем и помочь вам в улучшении игры, поэтому прекратите тестирование сразу после того, как получите ответы на основные вопросы, которые хотите найти. Если на определенном этапе наблюдение за игровым процессом перестает приносить пользу, не тратьте время участников и завершите тестирование раньше положенного срока. Продолжайте его лишь в случае, если участники действительно не хотят прерывать игру. (Заметьте, что это кажется нелогичным, поскольку, когда игра проводится ради развлечения, преждевременное ее завершение считается грубостью. Но в случае игрового тестирования, где игра идет с другой целью, это проявление уважения.)
• Проводите игровое тестирование с определенной целью. Выясните, какова эта цель (ответ на какой вопрос вам нужно найти), и настройте тесты соответствующим образом. Возможно, вам нужно понять, насколько увлекательным или сбалансированным является тот или иной компонент, или прояснить иные моменты, но в любом случае вы должны знать, что ищете.
• Если для получения корректных результатов не нужно соблюдать секретность, проинструктируйте участников игрового тестирования относительно цели его проведения и того, как они должны к нему подходить.
Если игровое тестирование проводится с целью балансировки некоторой конкретной вещи, проследите за тем, чтобы эта вещь происходила. Например, если вам нужно выяснить, не дает ли определенная карта слишком большое преимущество при ее вытягивании в начале игры, то перетасуйте колоду и положите эту карту сверху. В случае видеоигры иногда нужно попросить программистов, чтобы они встроили в игру несколько читов для упрощения процесса тестирования. (Обычно эти читы остаются и в окончательной версии игры, так как игроки тоже любят их использовать. Поэтому многие из читов, которые присутствуют в любой видеоигре, являются как раз теми, что применялись для упрощения отладки и игрового тестирования.)
Если же игровое тестирование проводится с целью балансировки игры в целом (то есть вам нужно проверить, нет ли в ней слишком сильных или слишком слабых стратегий, игровых объектов и т.д.), то скажите своим тестировщикам, что они должны стремиться выиграть. Для этого требуется особый тип мышления, и с этим хорошо справляются далеко не все тестировщики или геймдизайнеры. Однако если вы будете проводить игровое тестирование в достаточно большом объеме, то рано или поздно найдете некоторое количество тестировщиков, чрезвычайно хорошо справляющихся с этой задачей. Цените их, потому что они могут оказать вам неоценимую помощь. В общем случае тестировщики могут попытаться сделать следующее.
• Применить вырожденные стратегии. Обнаружив, что определенная вещь слишком мощна, можно просто использовать ее всякий раз, когда представляется такая возможность. В коллекционной карточной игре, не накладывающей никаких ограничений на способ составления колоды, можно составить колоду из 100 копий некоторой сверхмощной карты. В файтинге можно постоянно использовать один и тот же сверхмощный прием. В игре жанра «защита башни» можно строить только один вид башни, игнорируя все остальные. Такая стратегия делает игровой процесс очень скучным для самого игрока, а если она оказывается эффективной — сильно расстраивает соперников, поэтому постарайтесь исключить возможность применения игроками такой «оптимизации», делающей игру совершенно неинтересной.
• Вести себя как полный придурок. Наносите другим игрокам неожиданные удары в спину. Попробуйте использовать совершенно нечестные приемы. Сотрудничайте с другими игроками лишь из корыстных побуждений. Идите на любые уловки, за исключением откровенного обмана, для получения даже малейшего преимущества вне зависимости от того, насколько это понижает градус общего веселья. Попробуйте не соблюдать никаких правил приличия и посмотрите, дает ли такой подход какое-либо преимущество. Если игра будет вознаграждать игроков за недостойное поведение, то кто-то из них обязательно начнет вести себя таким образом. Поэтому в ходе тестирования нужно убедиться в том, что у игроков нет мотивации к недостойному поведению.
• Если вас интересует, какие еще виды стратегий могут использовать игроки, не испытывающие жалости к другим, то этот вопрос хорошо освещается в книге дизайнера Дэвида Сирлина (David Sirlin) «Играй на победу» (ссылку на нее см. в разделе «Дополнительные ресурсы»). Фактически это пересказ трактата «Искусство войны» китайского стратега Сунь-цзы применительно к соревновательным видам игр и киберспорта, хорошо описывающий конкурентный тип мышления.
• Джейми Гризмер (Jaime Griesemer), «Изменение интервала между выстрелами снайперской винтовки с 0,5 до 0,7 секунды в игре Halo 3», выступление на конференции GDC 2010, https://www.youtube.com/watch?v=8YJ53skc-k4.
• Энтони Джованнетти (Anthony Giovannetti), «Slay the Spire: дизайн и баланс на основе метрик», выступление на конференции GDC 2019, https://www.gdcvault.com/browse/gdc-19/play/1025731.
• Дэвид Сирлин (David Sirlin), книга «Играй на победу», http://www.sirlin.net/ptw.
1. Что произойдет, если в ходе разработки вы приступите к балансировке игры слишком рано?
2. Что произойдет, если в ходе разработки вы затянете с началом балансировки игры и начнете ее слишком поздно?
3. На каком этапе разработки следует начинать мелкомасштабное игровое тестирование с непосредственным наблюдением за тестами разработчика?
4. Какой риск несет математическое моделирование игры с помощью электронной таблицы в самом начале разработки, когда вы только начинаете создавать механику игры и еще не успели получить играбельную версию?
5. В чем разница между полнофункциональной и полноконтентной версиями?
6. В чем разница между проведением игрового тестирования в формате открытого и закрытого бета-тестирования?
7. На каком этапе разработки следует заняться решением вопроса о том, какую аналитику должна собирать игра? На каком этапе будут в основном использоваться собранные аналитические данные?
8. В конце раздела «Альфа-версия» в этой главе перечислены шесть типов игровых тестировщиков. Представителей каких из них вы предпочитаете привлекать к тестированию? Каких тестировщиков было бы труднее всего сымитировать, если бы вас попросили это сделать?
9. Допустим, вы проводите игровое тестирование игры жанра «метроидвания», где основным видом оружия изначально является пистолет с небольшой дальностью стрельбы, и тестировщик предлагает вам увеличить дальность. Что вы на это ответите?
10. Какие еще аспекты игры могут проверяться в ходе игрового тестирования, помимо ее сбалансированности?
Выберите для рассмотрения любую видеоигру с определенной системой секретных чит-кодов, позволяющей разблокировать такую функциональность, как неуязвимость, бесконечное количество жизней, выбор уровня, бесконечное количество денег и т.д., путем ввода специального кода с клавиатуры или игровой приставки.
Для выбранной игры составьте список из всех доступных чит-кодов (обычно списки чит-кодов можно найти в Интернете, выполнив поиск по имени игры с добавлением таких уточняющих слов, как «FAQ», «прохождение» или «чит-коды»). Для каждого чит-кода укажите, как, по вашему мнению, его могли использовать разработчики в ходе тестирования.
Эта игра разработана Эриком Циммерманом (Eric Zimmerman) специально для обучения балансировке игр с помощью игрового тестирования. Скачайте ее по адресу http://www.stonetronix.com/gdc-2013/battlebattle.pdf.
Правила игры изложены на последней странице предлагаемого для скачивания документа. Это игра с двумя игроками, где нужно выполнять шесть бросков шестигранного кубика (или два броска кубика, управляя здоровьем и применением особых способностей с помощью каких-либо иных накапливаемых токенов, таких как мелкие монеты или бусы).
Сначала ознакомьтесь с механикой игры. Предпоследняя страница предлагаемого документа содержит четыре копии одной и той же карты с названием Vanilla («Ваниль»). Эта карта изначально предоставляет игроку 5 очков здоровья и 3 токена, каждый из которых может быть использован для увеличения на единицу числа, выпавшего на боевом кубике. Эта карта задает базовый уровень мощности, относительно которого должны быть сбалансированы все остальные карты. Сначала попробуйте поиграть, применяя только карты «Ваниль», делая это самостоятельно или попарно (если в игре участвует целая группа студентов), пока с правилами не ознакомятся все участники.
После того как вы освоитесь с основными правилами игры BattleBattle, введите в игру карты тех 28 персонажей, которые были разработаны для этой игры, — они представлены на первых семи страницах скачанного вами документа. Если вы играете самостоятельно, выберите любого персонажа случайным образом, если в группе, раздайте по одному персонажу каждой паре игроков. Практически все эти персонажи не сбалансированы. Хотя конечная цель состоит в том, чтобы сбалансировать все карты по отношению друг к другу, вместо того чтобы рассматривать все 756 возможных пар, протестируйте каждую из них в поединке против «Ванили». Попробуйте использовать выбранного вами персонажа против нее в течение довольно длительного промежутка времени и определите, обладает ли он слишком большой, слишком малой или вполне приемлемой мощностью. После этого можно внести в персонажа одно-два изменения — модифицируйте количество очков здоровья, количество токенов или результат одного из бросков боевого кубика. В этой игре много «ручек настройки», позволяющих регулировать степень мощности персонажа. После внесения изменений верните персонажа в общий пул и попробуйте задействовать против «Ванили» другого персонажа и т.д.
В случае самостоятельной работы над этим побочным квестом, выбрав четырех персонажей из 28, попробуйте использовать каждого из них против «Ванили» (по одному за раз) и внесите необходимые изменения. Затем попробуйте использовать их друг против друга и постарайтесь сбалансировать игру в рамках этого набора так, чтобы каждый из четырех персонажей был примерно равен по силе «Ванили» и остальным трем персонажам.
В случае групповой работы над этим побочным квестом каждая пара игроков модифицирует предоставленного им персонажа и возвращает его в общий пул персонажей.
В случае работы в достаточно большой группе продолжайте играть, распределяя персонажей между парами, пока не выполните первичную балансировку каждого из них. На этом этапе следует прекратить применение «ванильного» персонажа. Теперь пусть каждая пара игроков произвольным образом выбирает двух модифицированных персонажей, пробует их использовать друг против друга, модифицирует одного или обоих, чтобы сделать их сбалансированными по отношению друг к другу, после чего возвращает в общий пул и выбирает следующую пару персонажей. Этот процесс может длиться от нескольких минут до 1–2 часов в зависимости от того, сколько времени вы готовы на это потратить. Затем обсудите с участниками тестирования, какое впечатление произвел на них этот процесс и не показались ли им какие-либо персонажи слишком сильными или слишком слабыми даже после модификации.
Основная задача. При выполнении этого задания в группе (в одном помещении) после балансировки представленных в документе персонажей дайте каждому участнику пустую карту персонажа. Теперь пусть каждый разработает собственного персонажа. При этом нужно обратить внимание на следующие моменты.
• Обеспечивает ли персонаж увлекательный игровой процесс? Дает ли он игроку достаточную свободу действий и интересные варианты выбора?
Отрицательный пример: при использовании персонажа Dalek (Далек) из исходного набора персонажей у вас вообще нет вариантов выбора. Даже если этот персонаж будет идеально сбалансирован по отношению к «ванильному», использовать его будет неинтересно.
• Сбалансирован ли персонаж по отношению к «ванильному» персонажу? Исключена ли вероятность того, что многие другие персонажи будут намного сильнее или слабее него?
Отрицательный пример: персонаж Cat (Кошка) из исходного набора персонажей сильно отличается от других тем, что использует свои токены для того, чтобы не допустить нанесения урона, вместо того чтобы с их помощью изменять уровень здоровья. Это означает, что любой противник, который наносит повышенный урон или каким-то образом затрагивает токены соперника либо способ их применения, как правило, будет или намного сильнее, или намного слабее Кошки. Даже если Кошка будет сбалансирована по отношению к «Ванили», она, скорее всего, будет очень далека от сбалансированного состояния по отношению к ряду других персонажей.
• Соответствует ли механика персонажа его предполагаемому характеру? Является ли то, что делает карта, естественным и органичным для персонажа с таким названием?
Отрицательный пример: персонаж Sniper (Снайпер) из исходного набора персонажей не имеет каких-либо особых способностей, характерных для снайпера. В шутерах снайперы, как правило, могут точно стрелять с дальней дистанции (с нанесением большого урона), но очень уязвимы в ближнем бою. Данный персонаж совершенно не отражает эти характерные особенности снайпера.
Затем можно собрать заполненные участниками карты и провести турнир с использованием созданных ими персонажей. Случайным образом распределите персонажей между участниками (проследив за тем, чтобы никто не получил своего персонажа) и разбейте участников на пары соперников. Пусть каждый из них ведет учет своего количества побед и поражений, а также количества побед и поражений (и итогового количества жизней) применяемого персонажа. Завершив игру с одним соперником, каждый игрок может сыграть с другим, используя другого персонажа.
Объективной мерой сбалансированности в этом контексте является то, насколько равными оказываются соперники в каждом матче. Если один из них легко одерживает победу над другим, можно предположить, что у победителя персонаж был намного сильнее, чем у проигравшего. Если же у победителя остается только 1 очко здоровья, это говорит о том, что игра представляла собой упорный поединок практически равных соперников. В конце турнира можно определить победителя, исходя из итогового количества побед и поражений у каждого игрока (при таком подходе все участники будут стремиться к победе, даже не используя своего персонажа), и оценить результаты каждого персонажа (самыми сбалансированными можно считать соперничающих персонажей с наименьшим средним уровнем здоровья у обоих в конце игры).
Продолжение. Часть 5 см. в главе 14.
Возьмите карты, которые получили в предыдущих частях данного квеста, и найдите хотя бы еще одного игрока, желающего с вами поиграть. Если вы решили сбалансировать четыре стартовые колоды, предоставьте их своему тестировщику (тестировщикам). Если решили сбалансировать отдельные карты, выдайте их тестировщику (тестировщикам) вместе с соответствующими инструкциями, чтобы они могли создать собственную индивидуальную колоду, содержащую ровно 50 карт и не больше трех копий любой карты действия.
И в первом, и во втором случае задача каждого игрока, включая вас, состоит в том, чтобы каким-то образом сломать игру. В случае балансировки стартовых колод игрок должен попытаться выявить наиболее сильную колоду и использовать ее, чтобы систематически одерживать победы. И наоборот, можно, определить наиболее слабую колоду и заставить своего соперника применять ее. В случае балансировки карт в окружении с конструируемыми колодами каждый игрок должен попытаться составить колоду, способную обеспечить настолько большое преимущество в этом формате игрового процесса, что для того, чтобы иметь шансы на победу, всем остальным потребуется либо использовать эту же колоду, либо специально составить колоду, способную ей противостоять.
Если в ходе игрового тестирования вам удастся выявить слишком мощные отдельные карты, комбинации карт или колоды, внесите вручную необходимые изменения стоимости. Возможно, вам также потребуется вернуться к своей кривой стоимости и вспомогательной математике и посмотреть, не допущена ли там ошибка. Если допущена, то, вероятно, потребуется изменить дополнительные карты.
Это заключительная часть основного квеста Волшебника.
Войти с помощью соц. сетей: