Игровой баланс #1
Подход к балансу с нуля
Это игровой баланс для начинающих — не обязательно гейм-дизайнеров. Любой тестер, сценарист, бухгалтер может прочесть его и посчитать баланс несложной игры. Примеры простые, а теории настолько мало, насколько это возможно.
Здесь я отвечаю на вопросы и исправляю ошибки, которые возникали у меня, когда я сам только учился балансу.
Краткое содержание всего цикла про баланс:
— Введение и подготовка к работе
— Начало работы: константы и прогрессии
— Боевой баланс или расчет эффективности
— Матмодели и простая экономика
— Комплексная экономика: поведение и цикл
— Монетизация и экономика
— Дополнительно: тервер, кривая обучения, заключение
Что такое баланс
Самое простое определение: любые числа, влияющие на геймплей.
Возьмем простейшую змейку: она перемещается со скоростью 1 клетка в 0.5 секунд по квадратному полю 10х10 клеток. Весь баланс в этих двух числах — скорость змейки и размер поля.
Они взяты с потолка и правятся на глаз: запускаем прототип, играем, меняем числа, снова играем. Нам плевать на «баланс», мы о нем не думаем, просто делаем игру веселее.
Из этого получится хороший геймплей, и не надо никаких табличек и формул.
Вывод №1: без табличек можно обойтись. И не только со змейкой.
Но… Как же таблички?!
А теперь возьмем World of WarCraft: несколько режимов игры, десяток классов, десятки локаций, сотни абилок, тысячи врагов, море взаимодействия — драки, торговля, гильдии…
Подобрать все это «на глаз» физически невозможно.
Здесь и пригодятся таблички и формулы. Они автоматизируют подбор чисел и позволяют контролировать сложные системы.
Однако любая автоматизация создает погрешности. Как только вы беретесь за вычисления, становится сложнее проследить смысл, стоящий за числами. Скорее всего, ваши первые модели будут математически верными, но более вредящими геймплею, чем помогающими.
Вывод №2: таблички упрощают вашу работу, но не делают её лучше.
Reverse engineering
Еще один способ обойтись без табличек: сделать reverse engineering баланса любой успешной игры. То есть: выписать оттуда все параметры и цены, найти зависимости и применить в своей игре.
Но если вы делаете не зеркальный клон, а более-менее оригинальную игру, то “реверс” вам скорее навредит, чем поможет. Без опыта и понимания принципов у вас больше шансов сделать “рабочий” баланс, руководствуясь только догадками и здравым смыслом, чем использовав данные из другой игры.
Подготовка к работе
Точность автоматизации зависит от количества входных данных — чем больше мы знаем заранее, тем точнее и лучше получится наш баланс.
Часть нужных чисел определяется еще на этапе идеи, часть подбирается в прототипе, другие логически выводится из жанра, платформы, особенностей игры — и все это до начала работы с таблицами.
Если мы решим делать «змейку-rogue-like» с процедурной генерацией локаций, предметами и прочим, нам все же понадобятся расчеты.
Но исходные данные по-прежнему придется подбирать вручную. Добавили, например, тролля, который бегает и обрубает змейке хвост — сколько таких троллей мы можем сгенерировать на локацию, чтобы игра не стала слишком сложной?
Ответ можно узнать только в прототипе.
Вот еще несколько примеров:
- В тактических боях игрок много считает в уме, поэтому для параметров юнитов лучше брать маленькие числа.
- У жанра idle/incremental есть потребность в огромных числах, чтобы сохранить иллюзию постоянного быстрого роста.
- В action-играх, где визуализируют нанесенный урон, не подойдут ни слишком мелкие числа — никого не впечатлит пафосно отлетающая единичка — ни слишком большие, т.к. получится информационный перегруз и будет сложно отличить 131348 от 12883.
- В мобильных играх надо помнить даже о размере экрана: если какие-то числа необходимо выводить на экран и нельзя сокращать, ими можно замусорить интерфейс.
- В RPG параметры предметов и оружия должны отличаться так, чтобы игрок почувствовал разницу и свой рост.
- Но с PvP эти различия не должны быть слишком большими, иначе драка между игроками чуть-чуть разных уровней станет совсем предсказуемой и неинтересной.
- В развитии и экономике надо помнить про быстрый рост на старте и равномерную подачу контента по времени, чтобы он не успевал приедаться. Конечно, отчасти эта работа делается уже вместе с табличками. Но чем больше мы представляем заранее, тем меньше переделывать потом.
Итоги первой части: работа с балансом это не столько математика, сколько по-прежнему игровой дизайн.
Правильные ответы — не в формулах, а в геймплее. До расчетов баланса у вас должен быть как минимум четкий вижен, а желательно — рабочий прототип с редактором параметров.
Придумывая первые числа, задумайтесь, как изменится игра, если это число будет больше или меньше. А если все числа этого типа умножить на два — как изменится геймплей