Вместо предисловия
Каждая игра начинается с чего-то. Это логично. На старте это просто идея, которая перерастает в концепт, потом в игровой прототип, а затем, если повезет — в саму игру. Баланс тоже должен иметь свою собственную точку отсчёта. В этой короткой статье я хочу поделиться своим опытом и мыслями касательно того, с чего же начинать баланс игры.
Бывает иногда: садишься с чашкой кофе, чая или виски и начинаешь балансить свой карточный шутер с элементами матч-3 на Oculus Rift, берёшься за одну сущность, потом за другую и так топчешься на месте целую вечность. Я подскажу методы, по которым можно легко определить зависимости всех сущностей в балансе и отыскать отправную точку для всего.
Зависимости
Определение зависимостей всех игровых сущностей — это 90% всего успеха в построении баланса. Конечно же, с учетом того, что вы умеете считать этот самый баланс.
Чаще всего — зависимости уже давным давно построены, я сейчас говорю про core loop.
Первое что вам нужно сделать — определить кор луп и выписать всё, что зависит друг от друга в наглядном и удобном виде.
Для примера: мы можем взять любую ферму вида Hay Day.
После описания основного кор лупа, требуется выделить начальную точку и от неё отталкиваться. В предложенном примере мы имеем:
- Игрок сажает культуры (Начальная точка)
- Собирает культуры
- Тратит их на кормление животных и производство
- Выполняет заказы
- Улучшает свою ферму
- Профит!
Дальнейший шаг состоит в том, чтобы расписать что игрок получает и тратит на каждом этапе.
Получаем вот такую схему, из которой можно понять, что у игрока есть: время, опыт, монеты, ресурсы и культуры.
Здесь видно, что игрок не может начать производство без ресурсов или культур. Не может кормить животных без культур, и только культуры по сути это то, что игрок имеет «бесплатно» и в неограниченных количествах. «Бесплатно», потому что он их приобретает за время, а время игрок не может получать за действия в игре. Таким образом и выделяется в кор лупе самый начальный этап.
Чтобы получить какие-либо значения монет, опыта и так далее в заказах, производстве — для начала следует задать эти значения для культур. Культуры ограничены временем роста и уровнем игрока. Отталкиваясь от этих двух значений — высчитываем опыт и стоимость культур, а потом, по накатанной, вычисляем опыт и стоимость последующих цепочек: ресурсов с животных, ресурсов с фабрик, количество получаемого опыта и монет с заказов, таблицу уровней игрока и так далее…
Интересный момент. Я часто сталкивался с мнением, что игру требуется начинать балансить с таблицы уровней игрока, но я с ним не согласен.
Начиная с таблицы опыта, геймдизайнер загоняет самого себя в рамки и сложности. Если начинать с культур и продолжать далее, приходя в итоге к таблице опыта, то мы используем динамический способ изменения опыта, и он конечен. Конечен в том смысле, что опыт уровней можно подгонять уже под финальные значения опыта за действия. Если же изначально считать опыт уровней, то при малейших изменениях таблицы опыта, придется пересчитывать все исходящие из опыта сущности, что повышает шанс ошибиться, не особо гибко, да и просто куда больше действий.
Для наглядности 2 небольших схемы.
В первом случае: все сущности ведут к финальной таблице опыта, и все изменения автоматически пересчитают финальные значения.
Во втором случае: изменение в таблице опыта влекут за собой изменения во всех сущностях, которые завязаны на эту таблицу.
NB! Это лишь моё мнение, и я с радостью выслушаю ваши возражения в комментариях или личке.
Ещё примеры
Возьмём для нового примера:…
Heroes charge
Тут все просто, Core loop:
- Трата энергии
- Бой
- Прокачка героев
- Восстановлении энергии
- …
За каждый бой игрок получает различные расходники, опыт и монеты, которые тратит на улучшение своих персонажей. Чтобы войти в бой, игрок тратит время, то есть энергию. Опять же, тот ресурс, который он не сможет получить, играя в игру, а значит, весь баланс будет строиться вокруг энергии и её количества на бой (суммарной и единичной).
Количеством энергии ограничивается время сессии\прокачка. Закладывается фундамент на то, сколько нужно энергии (времени), чтобы игрок дошел до определённого уровня, из этого высчитывается количество опыта\расходников за бой, а также сила противников.
Энергия → Опыт/монеты/расходники за миссию (из энергии и уровня миссии) → Баланс героев → Таблица опыта игрока → Восстановление энергии.
Таким образом, всего 1 начальный ресурс даёт толчок для баланса всех сущностей в игре.
NB! Игры вообще имеют огромное количество сущностей. Такое, что для их разбора потребуется писать целый цикл статей с подробным описанием того, что откуда идёт, здесь же я постарался показать, как просто можно вычленить отправную точку для баланса игры.
Спасибо за внимание!
11 комментариев
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.
Имха, первый подход к распределению уровней в игре можно использовать только на стадии прототипирования, т.к. позволяет очень быстро сгенерировать нужную прогрессию уровней под сырой баланс.
В реальности же, когда продут находится на стадии оперирования, в первом подходе появляется больше проблем, чем он дает пользы. Т.е. игра уже запущена и после сбора какой-то статистики мы понимаем, что игрок залипает в промежутке между какими-то уровнями. Нам нужно что-то изменить. Например, мы увеличиваем кол-во опыта от кропа, который появляется на этом уровне, меняя таким образом скорость прогресса игрока.
В случае с первой моделью — меняется целая структура сущностей, иногда вплоть до последующих уровней, если от предыдущих кропов берутся какие-то рассчеты.
Во-втором случае мы точечно меняем некоторые показатели, которые в явном виде зависимы от производной уровня и не рушим структуру в целом.
Это что касается самой слабой стороны первой модели. Я лично придерживаюсь обеих моделей использую их в рассчетах баланса. Первый — на стадии прототипирования и тестирования баланса на невыпущенной игре. Затем конвертирую его вторую модель, когда текущий баланс уже начинает считаться финальным.
Хотелось бы просто отметить, что в данном случае нет смысла обесценивать вторую модель и противопоставлять ее первой, т.к. они служат разным целям и каждая имеет свои плюсы и минусы, которые можно нивелировать, если использовать их по назначению.
Опять же — это имха, но стоит сформировать понимание обеих моделей, и не делить баланс игры на два лагеря, которые на самом деле являются частью единого целого.
Речь идет изначально об отправной точке построения баланса. Все что идет дальше немного не в ту степь.
Само собой, когда есть готовая модель баланса, ты выгрузил игру в стор, пошла статистика и ты видишь какие-то определенные проблемы тут возникает вопрос, что именно править.
Если отвалы игроков к примеру между 5 и 6 уровнем, нужно смотреть в стату и анализировать что не так. После получения ответа, что отвалы связаны с суммарным опытом уровня, ты вручную правишь значения опыта, а в точности — время нахождения на уровне, которое должно быть просчитано уже изначально.
Если же статистика говорит, что игроки не любят сажать какой-то кроп в начале игры, ты правишь время кропа. И он само собой поправит все крафты, в которые он входит, иначе будет дисбаланс (Исключая те случаи, когда целенаправленно апаешь сущность в сторону дисбаланса).
Т.е.: Правится время, автоматом изменяется опыт и стоимость (баланс же!), автоматом изменяются крафты, чтобы что-то не сломалось.
И в этом случае, нужно иметь 2 таблицы опыта:
— Динамическая, которая пересчитывается.
— Статическая, которую выгружаем в игру.
После всех правок — сравниваем таблицы показатели и если правки устраивают — изменяем статическую таблицу и льем изменения. Если нет, оставляем суммарный опыт игрока как есть.
Изначально посчитанное время на уровне совсем не скажет тебе в модели о том, что именно на этом уровне будут отвалы. Это говорит статистика.
Уже после релиза вообще в принципе использование динамических рассчетов в уровни, в играх типа ферм, приведет к тому, что тебе:
А — надо менять прогрессию уровней в игре, т.к. любые изменения сущностей ниже будут влиять на нее напрямую.
Б — надо конвертировать баланс в зависимость нижних сущностей от прогрессии уровней.
Отсюда и делается вывод, что это не единственный вариант балансировки и явно не предпочтительный. Скорее это один из этапов расчетов, которым, в некоторых случаях, даже можно пренебречь.
Но в целом подход правильный, я начинаю балансить именно так. Спич весь о том, что ты явно в тексте противопоставляешь подходы, отдавая предпочтение первому, что несовсем правильно.
Я и не говорил, что изначально время покажет отвалы.
Я сказал, что оно должно быть изначально посчитано. Так же, как я и сказал, что все покажет статистика и анализ игры. 🙂
Мне кажется первая схема больше подходит для игр с «комнатами-уровнями», типа три-в-ряд и пазлами. Изменения баланса внутри комнаты не повлияют на готовую линейку и эти две сущности будут независимыми.
А вот в играх, типа фермы, где мы прямым образом влияем на параметр exp/time, первая система может привести к тому, что из-за финансовых целей (увеличение времени прохождения, пейволы и тд) игрок может застрять на бесконечном фарме айтемов.
Так же, как было сказано Максимом, если мы делаем расчеты минимальных айтемов, в качестве константы, а потом понимаем, что «7 минут роста, с точки зрения игрока это очень много для первого айтема», приходится все пересчитывать. А так как такие изменения будут частыми (составляющие крафта к примеру), вторая модель кажется более удобной.
Первый способ дает глобальное понимание и связку всех сущностей по сути, при построении баланса.
И он подходит как для игр-комнат, так и для ферм.
Нет противоречия. Как в первом, так и во втором случае мы можем регулировать параметр exptime динамически и без серьезных затрат.
«Heroes charge
Тут все просто, Core loop:»
вот на этом я бросил читать эту статью. Спасибо, автор.
На самом деле, чуть-чуть выдохнув, я понял, что для начинающих гд это нормальные допущения и примитивизация. так что, автор, все ок. я передумал. реально, спасибо 🙂
Когда я писал статью, я как раз и задумался, что у некоторых людей после примера с HC будет такая реакция, но оставил так как есть, потому что как я написал в конце, если расписывать все более подробно, выльется все в целый цикл статей, что не подходит под изначальную цель — просто дать толчок для понимания построения баланса.
Т.е. как быстрый пример — ок. Как полноценный разбор — не ок.
Толчок дан, теперь было бы неплохо цикл статей)
по факту, у меня, как у человека, который капельку понимает про мобильные баттлеры бомбануло от фразы «тут все просто». 🙂 в целом, вы правы, да. 🙂