- Ato_Ome
- Постоялец
Недавно решил создать игру в жанре incremental. Сначала возникла мысль: можно просто накидать всё как душе угодно, самому проходить игру и расставлять цифры на глаз. Но я захотел копнуть глубже и начал составлять документ баланса, чтобы избежать ситуаций вроде «ну тут немного увеличим, тут немного убавим» или «блин, поменял здесь — и в итоге всё сломалось».
За основу взял Cookie Clicker: посмотрел на их систему, провёл небольшой анализ и за пару часов сделал Excel-документ: Анализ Cookie Clicker
В итоге пришёл к выводу, что их система слишком долго держит игрока в ожидании. Нужно долго копить валюту, чтобы купить постройку, которая потом будет приносить больше валюты — собственно, в этом и суть жанра incremental.
Начал с основ: важно понимать, сколько времени у игрока уходит на тот или иной прогресс. Постепенно стал выделять основные этапы и прикидывать, сколько времени теоретически должен занимать каждый из них. В итоге получился такой документ: Баланс документ
Создан он буквально 29.06.2025, поэтому сделано в нём пока немного.
При этом, меняя документ, меня не покидает мысль, что я делаю что-то не так или что есть более простой путь, которого я просто не вижу.
Вопрос к опытным: как вы составляли подобные документы баланса (необязательно для incremental)? Хочу понять сам принцип построения и перенять чужой опыт и наработки.
Сейчас мне кажется, что Cookie Clicker — не самая удачная игра в жанре, потому что со временем она сильно растягивает многие элементы. Но, возможно, это субъективно: я пока не самый опытный балансировщик.
Поэтому прошу всех, кто разбирается, подсказать: как делать надо, а как не надо.
Если хочешь сделать игру в каком-то жанре, так сначала переиграй хотя бы в пару десятков игр этого жанра, включая современные, и составь таблицу отличий этих игр которые тебе понравились/не понравились. Смысл брать только старый куки кликер? Так ты только его клон и сделаешь.
Я переиграл не в одну игру жанра incremental, просто для того чтобы взять примерные цифры прогрессии решил взять Cookie Clicker
lokze
> решил взять Cookie Clicker
Почему? Он тебе больше всех других понравился? Классику вроде Swarm Simulator смотрел? Он вообще текстовый и без графики.
Нет, решил взять его концепт прогрессии, постройка/улучшение/регрессия, если бы решил взять проекты которые мне понравились пришлось бы брать больше вводных и это увеличило бы разработку игры, а я хотел бы сделать игру за 2-5 недель выпустить, закинуть в неё метрики и примерно понимать что больше импонирует людям, а что отталкивает, какие промежутки лучше брать, и тд и тп
Swarm Simulator не видел, сейчас гляну. Спасибо за информацию
Спасибо за ссылку
Когда речь идет про инкрементал в стиме B2P модель, то баланс это не ключевое. Как ты мог заметить, баланс куки кликера не математически рассчитан, а скорее сделан по принципу что-то качнул, что-то качнулось.
Это важный принцип инкременталок - постоянное чувство накопления и прогресса, другой вопрос, если это инкрементал + айдлер с прогрессией и F2P, вот там уже баланс очень тяжелая штука
Но мы в своём проекте по большей части балансим на глаз, балансишь, итерируешь, проверяешь на юзерах и по новой.
Когда у тебя очень много генераторов и производного крафта, балансировать это становится около невозможным
Я просто думаю что если брать во внимание изначально концепт постройка/улучшение/регрессия, то тут не так уж и много факторов влияющих на прогресс игрока:
- Стоимость постройки;
- Приносимое количество ресурсов;
- Увеличение 1-го и 2-го (алгебраически или геометрически);
- Улучшение которое либо уменьшает стоимость, либо увеличивает прирост ресурсов;
- Регрессии которые в последствии увеличивают всё в зависимости от системы которую использует игра (навыки/влияние на прирост ресурса)
И всё это должно умещаться в обычны Excel.
Самая простая схема которую все используют в Roblox как я заметил это
Капает ресурс A, за ресурс A покупаем ресурс B, за ресурс B покупаем C, а так же ресурс A увеличивает получение себя, ресурс B увеличивает себя и ресурс A и так далее, далее.
Простота данной схемы в том что легче балансировать переходы игрока от этапа к этапу и это все быстро и легко делается без Excel таблиц и математики, а регулируется простым пальцем в небо и проверкой на playtest'ах с определенным количество ресурсов
Из других концептов которые помню это:
Игроку дают ресурс, за него он покупает первый источник, улучшил, купил новый, улучшил, купил новый, потом какая-то регрессия/переход на другую локацию и так по кругу с постепенным геометрическим увеличением стоимости, простота в том что делаем 1 регрессию/сценарий и просто дублируем его много раз для увеличения playtime'а игроков
Если где-то ошибся или неправильно сказал, поправьте пожалуйста
lokze
https://www.gamedeveloper.com/design/the-math-of-idle-games-part-i
Тебе нужно это
https://www.gamedeveloper.com/game-platforms/the-math-of-idle-games-part-ii
https://www.gamedeveloper.com/design/the-math-of-idle-games-part-iii
Спасибо большое! Почитаю
У меня недавно появилась идея для одного небольшого сайд проекта тоже жанра incremental/idle-managment. Я не могу прям уверенно говорить о каких-то правилах баланса, так как все зависит от игры, от темпа, от разнообразия контента. Но для себя я пока пришел к таким рассуждениям, может они будут полезны:
- Основная прогрессия в игре базируется чаще всего вокруг нескольких ресурсов. Остальные механики как правило тем или иным способом конвертируют свои бонусы в бонусы к получению основных ресурсов. Поэтому, как говорится без ограничения общности, можно сказать что любая сайд механика имеет заранее известный нам бонус к производству основного ресурса для каждого этапа игры.
- Любая игра может быть разбита на этапы (early/mid/end - game). Для инкременталок эти этапы можно выделять явно, например, если в игре есть механики престижа, то каждый престиж - это отдельный этап.
- Учитывая первые два пункта я делаю вывод, что моя задача посчитать диапазон (min-max) ресурса в секунду, которое можно получить на данном этапе игры. Если в игре много нелинейной прогрессии, то задача конечно будет сложнее, тогда можно формировать просто выборку на глаз из нескольких стратегий и считать диапазоны по ним. Можно даже писать юнит-тесты.
- Основа это ресурс и его получение. Тогда классическая формула R = b * (1 + inc) * (1 + more), где b - базовая генерация ресурса, inc - суммарное аддитивное увеличение (%), more - суммарный мультипликатор (%) отлично подойдет для одного источника ресурса. Получается разумно, например, в рамках престижа делать прибавку к more модификатору, а в рамках прогрессии внутри престижа оперировать только с base и inc. Тогда мы будем получать качественные скачки на каждом этапе игры. Тогда можно ставить цель - на n престиже я хочу предельно не более R ресурса в секунду (из определенного источника), учитывая что more фиксированный в рамках престижа, то задача только оперировать с base и inc.
У меня здесь речь по сути только про баланс получения основного ресурса, отдельные сайд-механики (крафт, шоп) могут иметь уже другие правила. И я не говорю еще про тайминги. Но все сайд механики нужно считать в таком случае после расчета основных ресурсов. Если в игре есть рандом, то можно посчитать мат. ожидание.
А в реальности конечно все равно это гонять на плейтестах и крутить потом туда-суда. Математика нужна для основы, чтобы представлять в голове как у тебя тот или иной параметр влияет на итоговые цифры хотя бы примерно, чтобы не балансить потом вообще вслепую.
Jaxel
> А в реальности конечно все равно это гонять на плейтестах и крутить потом туда-суда. Математика нужна для основы, чтобы представлять в голове как у тебя тот или иной параметр влияет на итоговые цифры хотя бы примерно, чтобы не балансить потом вообще вслепую.
В целом я этого у хочу добиться чтобы примерно понимать курс движения, а потом уже на playtest'ах до калибровать все цифры, т.е. мы сначала делаем примерную модель и считаем её математики, и только потом уже приступаем к проверке в playtest.
Я ранее помню писал скрипт для одной игры где выделял необходимые этапы и он считал оптимальный покупаемый ресурс (максимально прибыль по соотношению цена/приносимые ресурсы) покупал его и шёл до нужного мне этапа с нужным incoming ресурсов и по итогу получал время от этапа к этапу, но это все слишком долго чтобы даже примерно посчитать всю экономику + увеличивает сроки производства. На данный момент считаю это избыточным
Сейчас хотел бы сделать примерную табличку в Excel чтобы хотя бы примерно понимать курс движения и отталкиваться хотя бы от этих цифр, а не от «авось нормально», «думаю нормально»