Краткое содержание цикла про баланс:
— Введение и подготовка к работе
— Начало работы: константы и прогрессии
— Боевой баланс или расчет эффективности
— Модели и экономика
В этом посте:
- Модель боя
- Модель экономики, минимальный вариант
- Комплексная экономика: поведение и расходы
- Базовый цикл
- Монетизация: инструменты, дефицит, конкуренция.
- Теория вероятностей
- Кривая обучения
- Заключение
Дисклеймер: тут будет много картинок, потому что твиттер сказал, что вы любите картинки.
Матмодели
Математическая модель — представление реальности через математику.
Звучит слишком академично. На самом деле, все просто: вычесть DMG из HP — получится модель боя.
Требуемый опыт делим на убитых монстров — модель прокачки.
Сложить доход и вычесть расходы — модель экономики.
Бизнес-план игры, семейный бюджет и т.п. — тоже модели.
И это модель, только не математическая. Зато с “манжетами”.
От балансера, как правило, нужна совмещенная модель экономики и прогресса. Она описывает, как игрок растет по уровню, что получает, на что тратит и т.п.
Но с ней мы познакомимся чуть позже.
Отступление #1
Я уже писал: таблички не помогают, а запутывают; это инструмент, а не цель.
Не лишним будет повторить. Именно в моделирование легче всего допустить эту ошибку: рассчитать абстракцию, которая гладко смотрится на бумаге, но отвратительно играется.
Правильная матмодель ≠ правильная экономика.
Воспринимайте матмодель как гипотезу, которая требует доказательства в геймплее.
Отступление #2
Модель экономики и прогресса — главное и, вероятно, самое сложное, ради чего делается наш «баланс».
Она тесно связана со всей игрой, от задумки до монетизации.
Ошибки в игровом дизайне могут сделать модель невыполнимой, но это будет меньшей из проблем, ведь ошибки вредят самой игре.
Поэтому я уделю некоторое внимание геймдизайну как таковому, в отрыве от моделей и экономики.
Но начнем с самого простого.
Модель боя
В предыдущем посте мы научились считать силу юнитов — поэтому сперва смоделируем бой.
Честно говоря, эта модель не нужна. Параметры у вас уже есть, можно ничего не моделировать, а сразу перейти к тестированию.
Единственный смысл боевой модели — наглядно показать работу нашего баланса. Когда я впервые построил такую модель и увидел, что мои цифры реально работают — это сильно порадовало и подтолкнуло.
Порадуемся вместе.
Итак, наша задача: смоделировать битву двух юнитов.
Вот простейший вариант: по колонке HP на каждого юнита. В каждом ряду из HP отнимается DMG врага. Ряд — это 1 ход или 1 секунда в реалтайме. Все цифры из предыдущего поста.
Собственно, все.
Даже такая простая модель показывает, что раньше мы все правильно посчитали.
Если у нас куча разных параметров — модель может выглядеть довольно запутано.
Например вот так:
Подробно изучать модель боя мы не будем.
Основываясь на предыдущих материалах, вы наверняка сможете смоделировать то, что вам нужно.
Отмечу одно: достаточно легко смоделировать столкновение двух юнитов и полностью детерминированные бои (там, где игрок ничего не решает), но смоделировать бой, где игрок активно принимает решения — зачастую просто невозможно.
Да и не нужно. Такая модель не скажет ничего, что вы не увидите в билде. А от постоянного тестирования все-равно никуда не деться.
Приступаем к главному.
Модель экономики
Дисклеймер: постараюсь описывать схему, которая подходит для любой игры — но мы понимаем, что экономика особенно важна во free to play.
Отчасти поэтому мы будем много говорить о монетизации.
Я надеюсь, это будет полезно даже разработчикам платных игр — просто читайте вместо «заплатить» > «заполучить».
Подготовка к работе
В отличие от модели боя — у экономики есть конкретные цели.
С ее помощью мы контролируем другие гейм-дизайнерские решения, в частности:
- Необходимое количество контента
- Время, потраченное на разные этапы игры
- Эффективность игрового процесса и циклов
- Точку дефицита или его отсутствие
- Потенциальные дыры баланса и монетизации
Важный акцент: не определяем, а только контролируем. Большинство этих параметров мы должны были уже давно определить.
К началу работы над балансом надо знать все о механиках игры, доступных режимах, монетизации, источниках доходов и трат.
Любое изменение может привести к тому, что экономику придется переписывать чуть ли не с нуля.
Скорее всего, так и будет — редко получается учесть все с самого начала.
Вот с чем еще полезно определиться:
- Чистое время (т.е. игра без перерыва и таймеров), которое игрок потратит, чтобы получить весь контент и достигнуть целей.
- Расчетное время (то же самое, с учетом таймеров, средней длинны сессии и среднего количества сессий в день/неделю для вашего жанра или из ваших гипотез).
- Объем контента, который вытянет ваша команда во время.
- Примерные цены в реальной валюте — поскольку они зависят от жанра и конкурентов. Вы едва ли найдете баттлер с ценой бустера = 1$, т.к. игроки в баттлеры платят много.
Сюда же относится ценность минуты для игры с таймерами. - Жесткость экономики — когда, как и при каких условиях игроку не хватает денег? На что будет хватать всегда?
Итак, начинаем работу.
Минимальная экономика
Самый простой вариант: суммировать стоимость всего контента и разделить на скорость заработка.
Мы получим время, которое нужно игроку, чтобы заработать все ценности, сопоставим его с желаемым и вуа-ля, у нас готова игровая экономика.
В абсолютном большинстве случаев этот вариант недостаточен и не отвечает на массу важных вопросов.
К примеру, захочет ли игрок хоть раз заплатить?
Мы, напоминаю, делаем f2p и хотим заработать (как минимум — и дальше получать зарплату).
Поэтому мы будем рассматривать другую модель, более подробную.
Она совмещает экономику и прогресс; выглядит приблизительно так:
Смысл этой модели: на каждый произвольный этап игры (здесь это уровень, но можно брать время) подробно расписано, что игрок имеет, сколько зарабатывает, сколько тратит.
Чем больше мы знаем об игроке на каждом этапе — тем полезнее наша модель.
Пример, конечно, малоподробный.
Его хватит на простые игры с минимумом механик и режимов, без разных экономических стратегий, с линейной структурой покупок.
Если у нас такая игра — дальше все очевидно и работу можно доделать по аналогии.
Небольшой совет: не обязательно расписывать модель для каждого уровня или этапа. Если уровней за сотню — в ней станет легко потеряться.
Самое главное, чтобы в модели было три этапа: первые часы игры, максимально подробно; переломные моменты экономики (например, на 10-ом уровне у игрока начинается нехватка валюты); и последние уровни для понимания крайних значений и динамики.
Комплексная экономика
В мало-мальски сложной игре наша модель может разрастись до нескольких десятков столбцов и нескольких вспомогательных таблиц.
В ней не будет ничего принципиально сложного: мы просто повысим детальность моделирования, вместо размытой общей картины увидим все четко, в высоком разрешении.
Такой вариант предполагает, что мы учитываем не только усредненный доход/расход, а моделируем все поведение игрока: чем он занимается, сколько времени, где зарабатывает, на что тратит.
Поведение игрока
Вспомним пример из поста про константы: есть два режима игры («Кампания» и «PvP»), а игрок получает с них одинаковый доход за единицу времени.
Проще всего сразу вписать средний доход в таблицу.
Но едва ли в игре все так просто.
Наверняка мы захотим что-то добавить. Например, чтобы в нашей Кампании были Боссы с высокой, относительно обычного боя, наградой. Тогда нужно определиться, когда игрок встречает Босса, может ли он переигрывать бой с ним, получит ли он награду за переигрывание и т.д. — вопросов много.
Чтобы не захламлять главную таблицу — можно сделать по модели на каждый режим. А уже оттуда значения будут передаваться в основную модель.
Например так:
Здесь я задал прогрессии дохода и расхода, а уже от них вычислил значения в каждом режиме.
Можно и наоборот: расставить значения в режимах, а общий доход расчитывать из них.Вопрос, что проще контролировать: в первом случае надо следить за значениями режимов, чтобы, к примеру, сильные Боссы не оказались дешевле слабых.
А во втором будет сложнее увязывать доход из одного режима со всеми связанными числами — доходом из других режимов, расходами и т.д.
Модель расходов
Аналогично доходам — моделируются и расходы.
Нужно знать, на что игрок тратит ресурсы и следить за показателями, от которых зависят эти траты.
Например, в RPG есть золото, которое используется для «заточки» брони. Мы должны посчитать, сколько стоит заточка всего, что носит игрок.
Для этого надо знать, что игрок уже «заточил» и как часто «обновляет гардероб».
Незаточенная броня — это показатель, от которого зависят расходы.
А доступность новой брони — это открытая возможность для трат.
Зная, когда открываются возможности что-то купить, мы можем смоделировать, когда игрок захочет потратить ресурсы или докупить их за реальную валюту.
И неправильно предлагать сразу все шмотки в одном магазине: у игрока разбегутся глаза, не будет понимания, что купить/на что копить. И желания занести денег тоже не будет: лучшие товары покажутся слишком дорогими, а доступные — слишком слабыми.
Отрицательный эффект большого выбора:
Итак, желание возникает, когда открывается возможность, а выбор остается небольшим.
Простой пример: новую амуницию можно надеть только на высоком уровне. Получили уровень — что-то новое стало доступным, открылась возможность, появился стимул.
Тоже самое — с уровнем «главного здания» в Clash of Clans и подобных играх.
Да практически любая игра имеет свои ограничения, которые завязывают расходы на показатели прогресса (уровень, рейтинг и т.п.). И это правильно.
Осталось еще пара нюансов про расходы:
- Сливы и приоритеты
Если ресурс можно потратить с разными целями — игрок (и мы, вместе с ним) должен расставить приоритеты: что он покупает в первую очередь, во-вторую и так далее.
Если у расхода очень низкий приоритет — его можно считать «сливным». Такой расход помогает избавится от избытка наличности, которую больше не на что тратить.
«Слив» должен быть практически неограниченным и, как правило, иметь прогрессивную цену. - Скрытые расходы и гача
Эффективная монетизация должна быть «дорогой» в буквальном смысле слова: глобальное лидерство может обходится в десятки и сотни тысяч долларов, иногда больше.
Но игрок не должен этого видеть: спугнем. И в этом часто помогает Gacha — особая механика получения ценностей.
Смысл такой: игрок платит за «кота в мешке» и получает случайную вещь из списка. Чем вещь ценнее — тем ниже вероятность выпадения.
При этом игроку нужно что-то конкретное, но из-за случайности ему сложно оценить реальную стоимость нужной плюшки: вроде бы недорого, но это если повезет.
На app2top можно подробно почитать про виды gacha.
Итоги игрового поведения
Мы уже поняли, что для моделирования нам надо очень много знать про игрока.
Но, возможно, вы скажите «откуда я знаю, что будет делать игрок? В моей игре так много возможностей…» — и проиграете.
Потому что если вы не знаете, чем занимается игрок — он, тем более, не будет знать, чем заняться.
И пойдет играть во что-то другое, более понятное.
Это распространенная ошибка «новичковых» проектов: напихать в игру разных возможностей, но не предложить внятного цикла, который их объединет.
Поэтому отойдем в сторонку от баланса и разберемся с циклом.
Базовый цикл
Это цепочка активностей, из которых состоит обычная игровая сессия.
Хороший геймплей дает игроку очевидные цели: сделаем то, потом другое.
Если игрок не представляет, чем заняться или как распорядится деньгами; если его выбор запутанный и неоднозначный — считайте, что геймплей поломан.
Нет, это не значит, что у игрока вообще не должно быть выбора.
Просто выбор должен быть:
- либо декоративным (например, «сделать квест Х или квест Y?» или «купить секиру или копье?» — выбор не влияет на экономику, поскольку все квесты и предметы равнозначны по выгоде);
- либо строго мотивированным (поясню ниже);
Простой цикл
Рассмотрим циклы, в которых, по сути, нет выбора:
- Все активности необходимы и завязаны друг на друга. Чтобы поиграть в режим А, надо что-то получить в режиме Б и т.д.
- Активности не связаны, но ограничены. У каждого режима — своя «энергия» или другое ограничение. Предполагается, что игрок по-очереди вовлечен в каждую активность.
- Активности не ограничены, но выгодная стратегия только одна: поровну совмещать их все. И игроку это очевидно.
Если игра укладывается в эти — и похожие — циклы, мы можем обойтись столбцами «Доход в режиме Х», «Доход в режиме Y» и больше ничего не делать.
Благодаря простому циклу мы точно знаем, на что игрок тратит время, сколько и каких ресурсов заработает. Скорее всего, расходы у нас тоже предсказуемые.
У простого цикла есть достоинства и недостатки: если не давать игроку выбора, он не сможет поломать себе геймплей и будет иметь четкие цели — это хорошо; но одновременно он не сможет подстроить игру под себя, отфильтровать только интересное.
А это уже опасно в играх, где совмещаются активности для разных аудиторий. О подобном я писал в деконструкции демиургов.
Еще важный момент: ресурсы и энергии служат игровому циклу и балансу, а не наоборот. Не надо сочинять баланс под пять ресурсов, которые вы придумали в самом начале.
Напротив: вводите ресурсы только тогда, когда этого требует баланс или базовый цикл.
С их помощью можно связать активности (см. пример простого цикла), избежать немотивированного выбора и сбалансировать развитие.
Возьмем Clash of Clans: два вида внутриигровой валюты нужны, чтобы все игроки одного уровня имели примерно равные по силе войска и защиту, а не вкладывались во что-то одно, лишая себя половины геймплея.
Сложный цикл
Мы хотим предложить разные, несводимые к одному показателю, режимы или стратегии и не хотим сильно ограничивать выбор.
Тогда нужно убедиться, что выбор строго мотивирован, не случаен и не слишком запутан, имеет четкие критерии: «если … то вариант 1; если … то вариант 2″.
Если мы не в состоянии объяснить эти критерии — скорее всего, мы плохо подумали, а игре вообще не нужен этот выбор.
А если можем — то без труда поделим игроков на группы, по тем критериям, которыми они руководствуются.
И составим модель для каждой группы.
Просто пример: есть активности для «PvP’ешников» и активности для «PvE’шников». Обычно, игроки легко делятся на тех, кто любит грызть чужие глотки и тех, кто мирно гриндит.
Если активности сильно отличаются по своей «экономике»: приносят разные ресурсы или с разной скоростью/вероятностью, то нам нужно смоделировать различные варианты: «чистый PvPшник», «чистый PvEшник», «все понемногу» и т.д.
И убедиться, что ни один из вариантов не ломает геймплей и баланс.
Подводим итоги:
Для расчета правильной экономики мы должны представлять все действия игрока и его мотивацию при выборе между ними.
Если нам выбор неочевиден — игроку, скорее всего, тоже. А это уже проблема геймплея и ее надо лечить правильным базовым циклом.
Монетизация
Мы уже выяснили, что модель экономики поможет с монетизацией.
Конечно, она не сделает за нас монетизацию. И даже не подскажет, что мы упустили.
Все, чем она поможет: продемонстрирует, как монетизация уживается с остальной экономикой.
При этом 90% все работы с монетизацией заключается не в балансе, а в хорошо продуманной концепции.
Поэтому полезно будет разобраться, как, в принципе, работает монетизация во f2p и freemium.
Зачем люди платят?
Основные причины можно свести к пяти:
- Чтобы получить конфетку прямо сейчас (покупка времени; покупка контента, доступного за внутриигровую валюту).
- Чтобы пройти дальше (анлок уровней, плата за победу).
- Чтобы получить преимущество (в играх с соперничеством: сильные шмотки, бустера в карточных играх).
- Чтобы закрыть гештальт (заполнить коллекцию, реализовать все возможности, получить везде 3 звезды, обставить весь замок/ферму/аквариум).
- Чтобы выделиться (кастомизация, покупка скинов и бейджиков).
Эти причины часто смешаны.
Например, платя за «молоток» в Candy Crash Saga игрок одновременно платит за прогресс, преимущество и время.
Кроме того, причины деляться на многочисленные типы и виды: например, единичный сброс таймера и покупка «домика строителя» (+1 одновременное строительство) — это два разных вида монетизации на времени, один другого не заменяет.
Инструменты монетизации
Чтобы у игрока появились эти причины, в играх используют разные инструменты: явные и скрытые paywall’ы, стимуляцию конкуренции, таймеры и другие.
Проще всего с таймерами: достаточно определить цену минуты в премиум-валюте (покупаемой за реальные деньги) и расчитывать все ускорения, сбросы таймера и т.п. через эту цену. Можно пойти дальше и все покупки оценивать как время, которое потребовалось бы для получения того же профита без покупки. Плюс коэффициент эмоциональной ценности (например, купить конкретную карту всегда дороже, чем набор случайных карт с той же эффективностью).
Дефицит
Но ближе всего к балансу — дефицит.
То есть, нехватка ресурсов, когда игра предлагает больше открытых возможностей или требует больше расходов, чем игрок может себе позволить.
Проще всего привязать расходы к новой прогрессии, которая с определенного этапа обгонит прогрессию доходов.
Но этого недостаточно, надо продумать несколько важных моментов «уживания монетизации с экономикой».
Например:
- Что может купить игрок, не вносящий деньги?
Если разница между доходами и расходами будет постоянно расти, то игрок, скорее всего, совсем потеряет мотивацию.
Лучше поддерживать эту разницу на опредленном уровне. Например, в Clash Royale можно своевременно, не тормозя и не платя, развивать ровно один отряд. Но хочешь менять его, получать и прокачивать другие карты — изволь платить. - Как изменится геймплей для платящего игрока?
Распространенная ошибка: после платежа игра становится настолько легкой, что пропадает интерес.
Решение: быстро выравнивать сложность.
Даже если игрок покупает «силу / преимущество» — его наградой, в конечном счете, становится ускоренный рост до этапа, где купленная сила становится нормой (поэтому цену «усиления» можно пересчитывать в сэкономленном времени).
И чем прогресс скорее — тем лучше. Но и совсем без него нельзя — за плату должна быть награда.
Этот нюанс я когда-то уже иллюстрировал:
Конкуренция
Кроме таймеров и дефицита, наша экономика связана со стимулированием конкуренции — одним из самых эффективных способов увеличить доход.
Когда-то я слышал правило: добавление PvP в любую игру повышает доход минимум на 30%.
Вряд ли правило такое уж универсальное, но дает повод задуматься.
Часто объясняю, что конкурентная механика во F2P — это замаскированный аукцион. Чтобы получить желаемое придется заплатить не просто много — а больше других участников.
Так даже небольшое число «китов» (особенно щедрых плательщиков) превращают игру в битву на повышение ставок.
При этом надо помнить о других игроках, которые тоже платят и играют, но не могут и не собираются соревноваться с китами. В хорошо продуманной игре у каждого есть цели по плечу.
Но конкуренция — это не обязательно PvP.
Иконки друзей на общей карте — как в Candy Crush Saga — тоже конкуренция, просто без прямой конфронтации (считается, что женщины ее не любят).
И не обязательно стимулировать конкуренцию экономически. В том же примере из CCS нет никакой экономической стимуляции.
Но зачастую в играх с конкуренцией самая большая награда и самые высокие результаты доступны только за соревновательные успехи.
Это можно реализовать по-разному: лиги и рейтинги, специальная pvp-валюта, соревновательные эвенты и так далее.
Универсального решения нет, а стимуляция одной активности (в ущерб остальным) может поломать всю экономику.
Модель для соревновательных механик поможет это вовремя заметить.
В ней, для большей точности, можно учитывать не среднюю активность игрока, а предполагаемый разброс активностей и платежей.
Вот еще пример:
В одной популярной игре были еженедельные соревнования — надо было получить лучший результат в группе из 30 случайных игроков. От механики быстро отказались: выяснили, что цена лидерства в группе совсем невелика.
Это достаточно легко смоделировать, зная, как разняться результаты всех игроков: кто-то играет 3 раза в неделю по 15 минут, кто-то несколько часов каждый день.
Случайное формирование групп приводит к тому, что реально соревнуются только 2–3 участника, которые и раньше играли больше/лучше других. А ведь цена лидерства зависит от количества реальных конкурентов.В той игре механику совсем убрали и не решились проверить, что получиться, если формировать группы не случайно, а основываясь на предыдущих результатах — чтобы в одну группу попадали примерно равные игроки. Смоделировать это не сложно, а цена лидерства, очевидно, сильно вырастает.
Так моделирование помогло бы изначально оценить эффективность конкурентной механики.
На этом считаем, что вопросы экономики мы закрыли.
Рассмотрим пару вспомогательных тем: тервер и кривую обучения.
Теория вероятностей
Самое частое применение тервера в геймдизайне: пугать молодых.
Поспешу успокоить: реально она почти не используется.
Возьмем известную задачу (иногда спрашивают на собеседованиях): из сундука с вероятностью 10% выпадает меч, какая вероятность получить меч, открыв 10 сундуков?
Правильный ответ: точно меньше 100%.
Для такого ответа достаточно головы на плечах, тервер не нужен.
Имея голову — остальные знания можно подтянуть под конкретную задачу.
Если все-таки вынуждают посчитать точную вероятность, отвечайте что вы Байеса на Пуассоне вертели, вставайте и уходите.
В чем же тут подвох?
В том, что делая баланс вы моделируете усредненное поведение игрока, а «шанс вытащить меч» — это чей-то конкретный сценарий. Скорее всего, этот шанс нам просто никогда не понадобится.
Вместо этого нам потребуется знать «сколько мечей, в среднем, игрок вытащит из 100 сундуков».
А для этого тервер не нужен, сами понимаете.
Чисто для вашего успокоения, приведу ответ про сундуки.
Это задача на вероятность хотя бы одного успеха среди N попыток.
Вычисляется так:
Шанс = 1 – ( 1 – Шанс 1 попытки) * <…> * ( 1 – шанс N-ой попытки)
В нашем случае шанс у всех попыток одинаковый, нам проще:
Шанс получить меч = 1 – ( 1–10%)^10 = 1–0.9¹⁰ = 1–3.5 = 65%
И небольшой совет
Есть несколько формул вероятности, которые применяются в разных ситуациях, в зависимости от числа попыток, постоянства шансов и так далее.
Учить формулы сами по себе — бессмысленно. Сначала нужно понять, какие они бывают и для каких ситуаций годятся. А главное — разобраться в ситуации, ради которой нам понадобилось вероятность.
Очень может быть, что в процессе вы и вовсе обойдетесь без тервера.
Кому не терпится разобраться глубже, рекомендую список типовых задач с решениями.
По ссылке будет немало примеров и разъяснений, какая именно формула подходит и почему.
Про сами формулы можно почитать на Википедии.
Кривая обучения
Кривая обучения (learning curve) — это график знакомства с новыми правилами, механиками, контентом.
Выглядит примерно так:
И не путайте с кривой сложности, про которую писал Ник.
У кривой обучения есть две задачи:
- Убедить нас, что на игрока не сваливалось слишком много нового, что заставит его напрягаться
- И наоборот: что в игре не будет длинных этапов, где нет ничего нового, а игрок может заскучать.
Если ваш контент распределен заведомо равномерно (например, все режимы открыты сразу, а новые шмотки появляются ровно каждый 5-ый уровень) — в кривой обучения особого смысла нет.
В ином случае она может помочь и указать на проблемные этапы.
Делается так: берете список уровней и для каждого уровня считаете, сколько контента (шмотки / карты / абилки ) на нем открывается.
А потом вручную вписываете «сложность освоения» новых механик (режимов, активностей, глобальных целей), которые появляются по мере игры. И строите график.
Пример:
Заключение
Итак, вы дочитали (или, вероятнее, прокрутили) до конца цикла про игровой баланс для начинающих геймдизов.
У меня стояла цель написать такой текст, который можно вручить любому тестеру, сценаристу или художнику, одновременно с задачей «посчитай баланс моей игры».
И он посчитает, даже впервые в жизни открыв Excel.
Может быть, даже посчитает правильно.
Я старался избегать лишней обстоятельности и академичности, но при этом упомянуть все важное.
Важного оказалось больше, чем я думал.
Если вы знаете, как сделать этот текст лучше — что вырезать или чем дополнить и, особенно важно: что было непонятно, что плохо описано или недостаточно раскрыто — пишите комментарии.