Screen-Shot-2015-06-09-at-3.23.24-PM

Игровой баланс. Часть 4

Краткое содержание цикла про баланс:
— Введение и подготовка к работе
— Начало работы: константы и прогрессии
— Боевой баланс или расчет эффективности
— Модели и экономика

В этом посте:

  • Модель боя
  • Модель экономики, минимальный вариант
  • Комплексная экономика: поведение и расходы
  • Базовый цикл
  • Монетизация: инструменты, дефицит, конкуренция.
  • Теория вероятностей
  • Кривая обучения
  • Заключение

Дисклеймер: тут будет много картинок, потому что твиттер сказал, что вы любите картинки.

Матмодели

Математическая модель — представление реальности через математику.
Звучит слишком академично. На самом деле, все просто: вычесть DMG из HP — получится модель боя.
Требуемый опыт делим на убитых монстров — модель прокачки.
Сложить доход и вычесть расходы — модель экономики.
Бизнес-план игры, семейный бюджет и т.п. — тоже модели.

И это модель, только не математическая. Зато с “манжетами”.

От балансера, как правило, нужна совмещенная модель экономики и прогресса. Она описывает, как игрок растет по уровню, что получает, на что тратит и т.п.
Но с ней мы познакомимся чуть позже.

Отступление #1

Я уже писал: таблички не помогают, а запутывают; это инструмент, а не цель.
Не лишним будет повторить. Именно в моделирование легче всего допустить эту ошибку: рассчитать абстракцию, которая гладко смотрится на бумаге, но отвратительно играется.
Правильная матмодель ≠ правильная экономика.

Воспринимайте матмодель как гипотезу, которая требует доказательства в геймплее.

Отступление #2

Модель экономики и прогресса — главное и, вероятно, самое сложное, ради чего делается наш «баланс».
Она тесно связана со всей игрой, от задумки до монетизации.
Ошибки в игровом дизайне могут сделать модель невыполнимой, но это будет меньшей из проблем, ведь ошибки вредят самой игре.

Поэтому я уделю некоторое внимание геймдизайну как таковому, в отрыве от моделей и экономики.

Но начнем с самого простого.

Модель боя

В предыдущем посте мы научились считать силу юнитов — поэтому сперва смоделируем бой.

Честно говоря, эта модель не нужна. Параметры у вас уже есть, можно ничего не моделировать, а сразу перейти к тестированию.
Единственный смысл боевой модели — наглядно показать работу нашего баланса. Когда я впервые построил такую модель и увидел, что мои цифры реально работают — это сильно порадовало и подтолкнуло.
Порадуемся вместе.

Итак, наша задача: смоделировать битву двух юнитов.

Вот простейший вариант: по колонке HP на каждого юнита. В каждом ряду из HP отнимается DMG врага. Ряд — это 1 ход или 1 секунда в реалтайме. Все цифры из предыдущего поста.

Собственно, все.
Даже такая простая модель показывает, что раньше мы все правильно посчитали.

Если у нас куча разных параметров — модель может выглядеть довольно запутано.
Например вот так:

Здесь тот же принцип, но больше цифр и параметров. Не факт, что вам это нужно, но глаз радует.
Здесь тот же принцип, но больше цифр и параметров. Не факт, что вам это нужно, но глаз радует.

Подробно изучать модель боя мы не будем.
Основываясь на предыдущих материалах, вы наверняка сможете смоделировать то, что вам нужно.

Отмечу одно: достаточно легко смоделировать столкновение двух юнитов и полностью детерминированные бои (там, где игрок ничего не решает), но смоделировать бой, где игрок активно принимает решения — зачастую просто невозможно.
Да и не нужно. Такая модель не скажет ничего, что вы не увидите в билде. А от постоянного тестирования все-равно никуда не деться.

Приступаем к главному.

Модель экономики

Дисклеймер: постараюсь описывать схему, которая подходит для любой игры — но мы понимаем, что экономика особенно важна во free to play.
Отчасти поэтому мы будем много говорить о монетизации.
Я надеюсь, это будет полезно даже разработчикам платных игр — просто читайте вместо «заплатить» > «заполучить».

Подготовка к работе

В отличие от модели боя — у экономики есть конкретные цели.
С ее помощью мы контролируем другие гейм-дизайнерские решения, в частности:

  • Необходимое количество контента
  • Время, потраченное на разные этапы игры
  • Эффективность игрового процесса и циклов
  • Точку дефицита или его отсутствие
  • Потенциальные дыры баланса и монетизации

Важный акцент: не определяем, а только контролируем. Большинство этих параметров мы должны были уже давно определить.

nenavist-262x300К началу работы над балансом надо знать все о механиках игры, доступных режимах, монетизации, источниках доходов и трат.

Любое изменение может привести к тому, что экономику придется переписывать чуть ли не с нуля.
Скорее всего, так и будет — редко получается учесть все с самого начала.

Вот с чем еще полезно определиться:

  • Чистое время (т.е. игра без перерыва и таймеров), которое игрок потратит, чтобы получить весь контент и достигнуть целей.
  • Расчетное время (то же самое, с учетом таймеров, средней длинны сессии и среднего количества сессий в день/неделю для вашего жанра или из ваших гипотез).
  • Объем контента, который вытянет ваша команда во время.
  • Примерные цены в реальной валюте — поскольку они зависят от жанра и конкурентов. Вы едва ли найдете баттлер с ценой бустера = 1$, т.к. игроки в баттлеры платят много.
    Сюда же относится ценность минуты для игры с таймерами.
  • Жесткость экономики — когда, как и при каких условиях игроку не хватает денег? На что будет хватать всегда?

Итак, начинаем работу.

Минимальная экономика

Самый простой вариант: суммировать стоимость всего контента и разделить на скорость заработка.
Мы получим время, которое нужно игроку, чтобы заработать все ценности, сопоставим его с желаемым и вуа-ля, у нас готова игровая экономика.

В абсолютном большинстве случаев этот вариант недостаточен и не отвечает на массу важных вопросов.
К примеру, захочет ли игрок хоть раз заплатить?
Мы, напоминаю, делаем f2p и хотим заработать (как минимум — и дальше получать зарплату).

Поэтому мы будем рассматривать другую модель, более подробную.
Она совмещает экономику и прогресс; выглядит приблизительно так:

td22

Смысл этой модели: на каждый произвольный этап игры (здесь это уровень, но можно брать время) подробно расписано, что игрок имеет, сколько зарабатывает, сколько тратит.
Чем больше мы знаем об игроке на каждом этапе — тем полезнее наша модель.

Пример, конечно, малоподробный.
Его хватит на простые игры с минимумом механик и режимов, без разных экономических стратегий, с линейной структурой покупок.
Если у нас такая игра — дальше все очевидно и работу можно доделать по аналогии.

Небольшой совет: не обязательно расписывать модель для каждого уровня или этапа. Если уровней за сотню — в ней станет легко потеряться.
Самое главное, чтобы в модели было три этапа: первые часы игры, максимально подробно; переломные моменты экономики (например, на 10-ом уровне у игрока начинается нехватка валюты); и последние уровни для понимания крайних значений и динамики.

Комплексная экономика

В мало-мальски сложной игре наша модель может разрастись до нескольких десятков столбцов и нескольких вспомогательных таблиц.
В ней не будет ничего принципиально сложного: мы просто повысим детальность моделирования, вместо размытой общей картины увидим все четко, в высоком разрешении.

Такой вариант предполагает, что мы учитываем не только усредненный доход/расход, а моделируем все поведение игрока: чем он занимается, сколько времени, где зарабатывает, на что тратит.

Поведение игрока

Наша целевая аудитория

Вспомним пример из поста про константы: есть два режима игры («Кампания» и «PvP»), а игрок получает с них одинаковый доход за единицу времени.
Проще всего сразу вписать средний доход в таблицу.

Но едва ли в игре все так просто.

Наверняка мы захотим что-то добавить. Например, чтобы в нашей Кампании были Боссы с высокой, относительно обычного боя, наградой. Тогда нужно определиться, когда игрок встречает Босса, может ли он переигрывать бой с ним, получит ли он награду за переигрывание и т.д. — вопросов много.

Чтобы не захламлять главную таблицу — можно сделать по модели на каждый режим. А уже оттуда значения будут передаваться в основную модель.
Например так:

 
num11

Здесь я задал прогрессии дохода и расхода, а уже от них вычислил значения в каждом режиме.
Можно и наоборот: расставить значения в режимах, а общий доход расчитывать из них.

Вопрос, что проще контролировать: в первом случае надо следить за значениями режимов, чтобы, к примеру, сильные Боссы не оказались дешевле слабых.
А во втором будет сложнее увязывать доход из одного режима со всеми связанными числами — доходом из других режимов, расходами и т.д.

Модель расходов

Аналогично доходам — моделируются и расходы.
Нужно знать, на что игрок тратит ресурсы и следить за показателями, от которых зависят эти траты.
Например, в RPG есть золото, которое используется для «заточки» брони. Мы должны посчитать, сколько стоит заточка всего, что носит игрок.
Для этого надо знать, что игрок уже «заточил» и как часто «обновляет гардероб».

Незаточенная броня — это показатель, от которого зависят расходы.
А доступность новой брони — это открытая возможность для трат.

Зная, когда открываются возможности что-то купить, мы можем смоделировать, когда игрок захочет потратить ресурсы или докупить их за реальную валюту.
И неправильно предлагать сразу все шмотки в одном магазине: у игрока разбегутся глаза, не будет понимания, что купить/на что копить. И желания занести денег тоже не будет: лучшие товары покажутся слишком дорогими, а доступные — слишком слабыми.
Отрицательный эффект большого выбора:

cans
Из статьи Мегаплана «Как клиенты принимают решения». Принципы покупательского поведения полезны и в геймдизайне.

Итак, желание возникает, когда открывается возможность, а выбор остается небольшим.

Простой пример: новую амуницию можно надеть только на высоком уровне. Получили уровень — что-то новое стало доступным, открылась возможность, появился стимул.
Тоже самое — с уровнем «главного здания» в Clash of Clans и подобных играх.

Да практически любая игра имеет свои ограничения, которые завязывают расходы на показатели прогресса (уровень, рейтинг и т.п.). И это правильно.

Осталось еще пара нюансов про расходы:

  • Сливы и приоритеты
    Если ресурс можно потратить с разными целями — игрок (и мы, вместе с ним) должен расставить приоритеты: что он покупает в первую очередь, во-вторую и так далее.
    Если у расхода очень низкий приоритет — его можно считать «сливным». Такой расход помогает избавится от избытка наличности, которую больше не на что тратить.
    «Слив» должен быть практически неограниченным и, как правило, иметь прогрессивную цену.
  • Скрытые расходы и гача
    Эффективная монетизация должна быть «дорогой» в буквальном смысле слова: глобальное лидерство может обходится в десятки и сотни тысяч долларов, иногда больше.
    Но игрок не должен этого видеть: спугнем. И в этом часто помогает Gacha — особая механика получения ценностей.
    Смысл такой: игрок платит за «кота в мешке» и получает случайную вещь из списка. Чем вещь ценнее — тем ниже вероятность выпадения.
    При этом игроку нужно что-то конкретное, но из-за случайности ему сложно оценить реальную стоимость нужной плюшки: вроде бы недорого, но это если повезет.
    На app2top можно подробно почитать про виды gacha.
Gacha пришла к нам из азии
Gacha пришла к нам из азии

Итоги игрового поведения

Мы уже поняли, что для моделирования нам надо очень много знать про игрока.

Но, возможно, вы скажите «откуда я знаю, что будет делать игрок? В моей игре так много возможностей…» — и проиграете.
Потому что если вы не знаете, чем занимается игрок — он, тем более, не будет знать, чем заняться.
И пойдет играть во что-то другое, более понятное.

Это распространенная ошибка «новичковых» проектов: напихать в игру разных возможностей, но не предложить внятного цикла, который их объединет.
Поэтому отойдем в сторонку от баланса и разберемся с циклом.

Базовый цикл

Это цепочка активностей, из которых состоит обычная игровая сессия.

Хороший геймплей дает игроку очевидные цели: сделаем то, потом другое.
Если игрок не представляет, чем заняться или как распорядится деньгами; если его выбор запутанный и неоднозначный — считайте, что геймплей поломан.

Нет, это не значит, что у игрока вообще не должно быть выбора.
Просто выбор должен быть:

  • либо декоративным (например, «сделать квест Х или квест Y?» или «купить секиру или копье?» — выбор не влияет на экономику, поскольку все квесты и предметы равнозначны по выгоде);
  • либо строго мотивированным (поясню ниже);

Простой цикл

Рассмотрим циклы, в которых, по сути, нет выбора:

  • Все активности необходимы и завязаны друг на друга. Чтобы поиграть в режим А, надо что-то получить в режиме Б и т.д.
  • Активности не связаны, но ограничены. У каждого режима — своя «энергия» или другое ограничение. Предполагается, что игрок по-очереди вовлечен в каждую активность.
  • Активности не ограничены, но выгодная стратегия только одна: поровну совмещать их все. И игроку это очевидно.

Если игра укладывается в эти — и похожие — циклы, мы можем обойтись столбцами «Доход в режиме Х», «Доход в режиме Y» и больше ничего не делать.
Благодаря простому циклу мы точно знаем, на что игрок тратит время, сколько и каких ресурсов заработает. Скорее всего, расходы у нас тоже предсказуемые.

Геймдизайнер - Большой Брат для игрока.
Геймдизайнер — Большой Брат для игрока.

У простого цикла есть достоинства и недостатки: если не давать игроку выбора, он не сможет поломать себе геймплей и будет иметь четкие цели — это хорошо; но одновременно он не сможет подстроить игру под себя, отфильтровать только интересное.
А это уже опасно в играх, где совмещаются активности для разных аудиторий. О подобном я писал в деконструкции демиургов.

Еще важный момент: ресурсы и энергии служат игровому циклу и балансу, а не наоборот. Не надо сочинять баланс под пять ресурсов, которые вы придумали в самом начале.
Напротив: вводите ресурсы только тогда, когда этого требует баланс или базовый цикл.
С их помощью можно связать активности (см. пример простого цикла), избежать немотивированного выбора и сбалансировать развитие.
Возьмем Clash of Clans: два вида внутриигровой валюты нужны, чтобы все игроки одного уровня имели примерно равные по силе войска и защиту, а не вкладывались во что-то одно, лишая себя половины геймплея.

Сложный цикл

Мы хотим предложить разные, несводимые к одному показателю, режимы или стратегии и не хотим сильно ограничивать выбор.

Картинка из известного симулятора бухгалтера.
Картинка из известного симулятора бухгалтера.

Тогда нужно убедиться, что выбор строго мотивирован, не случаен и не слишком запутан, имеет четкие критерии: «если … то вариант 1; если … то вариант 2″.

Если мы не в состоянии объяснить эти критерии — скорее всего, мы плохо подумали, а игре вообще не нужен этот выбор.

А если можем — то без труда поделим игроков на группы, по тем критериям, которыми они руководствуются.
И составим модель для каждой группы.

Просто пример: есть активности для «PvP’ешников» и активности для «PvE’шников». Обычно, игроки легко делятся на тех, кто любит грызть чужие глотки и тех, кто мирно гриндит.

Если активности сильно отличаются по своей «экономике»: приносят разные ресурсы или с разной скоростью/вероятностью, то нам нужно смоделировать различные варианты: «чистый PvPшник», «чистый PvEшник», «все понемногу» и т.д.

И убедиться, что ни один из вариантов не ломает геймплей и баланс.

Подводим итоги:
Для расчета правильной экономики мы должны представлять все действия игрока и его мотивацию при выборе между ними.
Если нам выбор неочевиден — игроку, скорее всего, тоже. А это уже проблема геймплея и ее надо лечить правильным базовым циклом.

Монетизация

Мы уже выяснили, что модель экономики поможет с монетизацией.
Конечно, она не сделает за нас монетизацию. И даже не подскажет, что мы упустили.
Все, чем она поможет: продемонстрирует, как монетизация уживается с остальной экономикой.

При этом 90% все работы с монетизацией заключается не в балансе, а в хорошо продуманной концепции.

Поэтому полезно будет разобраться, как, в принципе, работает монетизация во f2p и freemium.

Зачем люди платят?

because people are stupid
Сколько не иронизируй, но геймдизайнер должен платить в играх и «чувствовать» free2play.

Основные причины можно свести к пяти:

  • Чтобы получить конфетку прямо сейчас (покупка времени; покупка контента, доступного за внутриигровую валюту).
  • Чтобы пройти дальше (анлок уровней, плата за победу).
  • Чтобы получить преимущество (в играх с соперничеством: сильные шмотки, бустера в карточных играх).
  • Чтобы закрыть гештальт (заполнить коллекцию, реализовать все возможности, получить везде 3 звезды, обставить весь замок/ферму/аквариум).
  • Чтобы выделиться (кастомизация, покупка скинов и бейджиков).

Эти причины часто смешаны.
Например, платя за «молоток» в Candy Crash Saga игрок одновременно платит за прогресс, преимущество и время.
Кроме того, причины деляться на многочисленные типы и виды: например, единичный сброс таймера и покупка «домика строителя» (+1 одновременное строительство) — это два разных вида монетизации на времени, один другого не заменяет.

Инструменты монетизации

Кредит
Все жду, когда в играх появится “кристаллы в кредит” или “магический сундук в ипотеку”

Чтобы у игрока появились эти причины, в играх используют разные инструменты: явные и скрытые paywall’ы, стимуляцию конкуренции, таймеры и другие.

Проще всего с таймерами: достаточно определить цену минуты в премиум-валюте (покупаемой за реальные деньги) и расчитывать все ускорения, сбросы таймера и т.п. через эту цену. Можно пойти дальше и все покупки оценивать как время, которое потребовалось бы для получения того же профита без покупки. Плюс коэффициент эмоциональной ценности (например, купить конкретную карту всегда дороже, чем набор случайных карт с той же эффективностью).

Дефицит

Но ближе всего к балансу — дефицит.
То есть, нехватка ресурсов, когда игра предлагает больше открытых возможностей или требует больше расходов, чем игрок может себе позволить.

Проще всего привязать расходы к новой прогрессии, которая с определенного этапа обгонит прогрессию доходов.

Но этого недостаточно, надо продумать несколько важных моментов «уживания монетизации с экономикой».
Например:

  • Что может купить игрок, не вносящий деньги?
    Если разница между доходами и расходами будет постоянно расти, то игрок, скорее всего, совсем потеряет мотивацию.
    Лучше поддерживать эту разницу на опредленном уровне. Например, в Clash Royale можно своевременно, не тормозя и не платя, развивать ровно один отряд. Но хочешь менять его, получать и прокачивать другие карты — изволь платить.
  • Как изменится геймплей для платящего игрока?
    Распространенная ошибка: после платежа игра становится настолько легкой, что пропадает интерес.
    Решение: быстро выравнивать сложность.
    Даже если игрок покупает «силу / преимущество» — его наградой, в конечном счете, становится ускоренный рост до этапа, где купленная сила становится нормой (поэтому цену «усиления» можно пересчитывать в сэкономленном времени).
    И чем прогресс скорее — тем лучше. Но и совсем без него нельзя — за плату должна быть награда.
    Этот нюанс я когда-то уже иллюстрировал:
    1410022652_thumb.jpeg

Конкуренция

Кроме таймеров и дефицита, наша экономика связана со стимулированием конкуренции — одним из самых эффективных способов увеличить доход.
Когда-то я слышал правило: добавление 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-ый уровень) — в кривой обучения особого смысла нет.

В ином случае она может помочь и указать на проблемные этапы.

Делается так: берете список уровней и для каждого уровня считаете, сколько контента (шмотки / карты / абилки ) на нем открывается.
А потом вручную вписываете «сложность освоения» новых механик (режимов, активностей, глобальных целей), которые появляются по мере игры. И строите график.
Пример:
lc2

Заключение

Итак, вы дочитали (или, вероятнее, прокрутили) до конца цикла про игровой баланс для начинающих геймдизов.

У меня стояла цель написать такой текст, который можно вручить любому тестеру, сценаристу или художнику, одновременно с задачей «посчитай баланс моей игры».
И он посчитает, даже впервые в жизни открыв Excel.
Может быть, даже посчитает правильно.

Я старался избегать лишней обстоятельности и академичности, но при этом упомянуть все важное.
Важного оказалось больше, чем я думал.

Если вы знаете, как сделать этот текст лучше — что вырезать или чем дополнить и, особенно важно: что было непонятно, что плохо описано или недостаточно раскрыто — пишите комментарии.

Share on Facebook0Tweet about this on TwitterShare on VK
  • u0447u0430u0441u0442u044c 4 u043au0430u043a u0442u0440u0438 u043fu0440u0435u0434u044bu0434u0443u0449u0438u0435 u0432u043cu0435u0441u0442u0435 u0432u0437u044fu0442u044bu0435, u043du0435 u0431u0430u043bu0430u043du0441u0438u0440u0443u044eu0442)

    • u0410u0441u044c?

      • u0441u0442u0430u0442u044cu044f u0431u043eu043bu044cu0448u0430u044f u043fu043eu043bu0443u0447u0438u043bu0430u0441u044c, u0437u043du0430u0447u0438u0442u0435u043bu044cu043du043e u0431u043eu043bu044cu0448u0435 u043fu0440u0435u0434u044bu0434u0443u0449u0438u0445, u0441u043fu0430u0441u0438u0431u043e u0431u043eu043bu044cu0448u043eu0435 :)

        • u0421u0442u0430u0440u0430u043bu0441u044f u0441u043eu043au0440u0430u0449u0430u0442u044c u043au0430u043a u043cu043eu0433, u043du043e u0432 u0433u043eu043bu043eu0432u0435 u043fu043eu0441u0442u043eu044fu043du043du043e u0432u0435u0440u0442u0435u043bu043eu0441u044c «u0438 u043fu0440u043e u044du0442u043e u0442u043eu0436u0435 u043du0430u0434u043e».nu0420u0430u0434, u0447u0442u043e u043eu043au0430u0437u0430u043bu043eu0441u044c u0438u043du0442u0435u0440u0435u0441u043du043e :)

          • u0410u043bu0435u043au0441u0430u043du0434u0440 u0414u0430u043du0447u0435u043du043au043eu0432

            u0410 u043cu043du0435 u0432u043eu0442 u0432u0441u0435 u0432u0440u0435u043cu044f u0445u043eu0442u0435u043bu043eu0441u044c u0441u043bu043eu0436u043du044bu0445 u043fu0440u0438u043cu0435u0440u043eu0432 u043fu0440u043eu0441u0447u0435u0442u0430 u0432u0437u0430u0438u043cu043eu0441u0432u044fu0437u0435u0439, u0435u0441u043bu0438 u0435u0441u0442u044c u0436u0435u043bu0430u043du0438u0435 u0440u0430u0441u043fu0438u0441u0430u0442u044c u043fu0440u0438u043cu0435u0440 u043fu0440u043eu0441u0447u0435u0442u0430 u0442u043eu0433u043e u0436u0435 u0431u044du0442u043bu0435u0440u0430 u0432 u043cu0435u043bu043eu0447u0430u0445 — u0431u0443u0434u0443 u0440u0430u0434 u0445u0430u0440u0434u043au043eu0440u0443)

          • u0415u0441u043bu0438 u0440u0435u0447u044c u0438u0434u0435u0442 u043fu0440u043e u043au0430u043au0443u044e-u0442u043e u043au043eu043cu0431u0438u043du0430u0442u043eu0440u0438u043au0443, u0441u0438u043du0435u0440u0433u0438u044e u0438 u0442u043e, u0447u0442u043e u0443 u0428u0440u0430u0439u0431u0435u0440u0430 u043du0430u0437u044bu0432u0430u0435u0442u0441u044f u0438u043du0442u0440u0430u043du0437u0438u0442u0438u0432u043du044bu0435 u043cu0435u0445u0430u043du0438u043au0438 (u043au0430u043du043eu0431u0443-u0431u0430u043bu0430u043du0441) u2013 u0442u043e u0438u0445 u043fu043eu0447u0442u0438 u043du0435 u0441u0447u0438u0442u0430u044eu0442.nnu041du0430u043fu0440u0438u043cu0435u0440, u043au0430u043au0438u0435-u0442u043e u0442u0440u0438 u043au0430u0440u0442u044b u0434u0430u044eu0442 u0441u0430u043cu044bu0439 u0431u043eu043bu044cu0448u043eu0439 u044du0444u0444u0435u043au0442 u043eu0442 u0438u0445 u0441u043eu0447u0435u0442u0430u043du0438u044f u0432 u043eu0434u043du043eu0439 u043au043eu043bu043eu0434u0435. u0414u043eu043fu0443u0441u0442u0438u043c, u043cu044b u044du0442u043e u043fu043eu0441u0447u0438u0442u0430u043bu0438.nu0410 u0447u0442u043e u0434u0430u043bu044cu0448u0435? u0421u0431u0430u043bu0430u043du0441u0438u0440u043eu0432u0430u0442u044c u0438u0445 u044du0444u0444u0435u043au0442, u0447u0442u043eu0431u044b u043eu043d u043du0435 u0432u044bu0434u0435u043bu044fu043bu0441u044f? u0422u0430u043a u0432u0435u0434u044c u043eu0441u043du043eu0432u043du0430u044f u0446u0435u043du043du043eu0441u0442u044c u0431u0430u0442u0442u043bu0435u0440u0430 — u0432 u0434u0435u043au0431u0438u043bu0434u0438u043du0433u0435 (u0441u043eu0431u0438u0440u0430u043du0438u0438 u043au043eu043bu043eu0434u044b), u043au043eu0442u043eu0440u044bu0439 u043du0430u043fu0440u0430u0432u043bu0435u043d u043du0430 u043fu043eu0438u0441u043a u043bu0443u0447u0448u0438u0445 u0441u043eu0447u0435u0442u0430u043du0438u0439. u0415u0441u043bu0438 u0432u0441u0435 u0441u043eu0447u0435u0442u0430u043du0438u044f u0431u0443u0434u0443u0442 u0437u0430u0432u0435u0434u043eu043cu043e u0434u0430u0432u0430u0442u044c u043eu0434u0438u043du0430u043au043eu0432u044bu0439 u044du0444u0444u0435u043au0442, u0442u043e u043cu044b u0441u043bu043eu043cu0430u0435u043c u0444u0430u043d u043eu0442 u0434u0435u043au0431u0438u043bu0434u0438u043du0433u0430.nu0412u0437u0430u0438u043cu043eu0434u0435u0439u0441u0442u0432u0438u0435 u0441u0442u0430u043du0435u0442 u043fu0440u043eu0431u043bu0435u043cu043eu0439, u0442u043eu043bu044cu043au043e u0435u0441u043bu0438 u043au0430u043au0438u0435-u0442u043e u043au043eu043cu0431u0438u043du0430u0446u0438u0438 u0431u0443u0434u0443u0442 u043du0430u0441u0442u043eu043bu044cu043au043e u044fu0432u043du043e u044du0444u0444u0435u043au0442u0438u0432u043du0435u0435 u0434u0440u0443u0433u0438u0445, u0447u0442u043e u0431u043eu043bu044cu0448u043eu0439 % u0438u0433u0440u043eu043au043eu0432 u0431u0443u0434u0435u0442 u0441u0442u0440u0435u043cu0438u0442u0441u044f u0441u043eu0431u0438u0440u0430u0442u044c u043fu043eu0445u043eu0436u0438u0435 u043au043eu043bu043eu0434u044b.nu041du043e «u043du0430u0441u0442u043eu043bu044cu043au043e u044fu0432u043du043e» — u044du0442u043e u043du0435 u043cu0430u0442u0435u043cu0430u0442u0438u0447u0435u0441u043au0430u044f u043au0430u0442u0435u0433u043eu0440u0438u044f, u0430 u043fu043eu0432u0435u0434u0435u043du0438u0435 u0438u0433u0440u043eu043au043eu0432 u0437u0430u0432u0438u0441u0438u0442 u043eu0442 u043au043eu043cu043cu044cu044eu043du0438u0442u0438 u043du0435 u043cu0435u043du044cu0448u0435, u0447u0435u043c u043eu0442 u0440u0435u0430u043bu044cu043du043eu0433u043e u0431u0430u043bu0430u043du0441u0430 (u043du0430u043fu0440u0438u043cu0435u0440, u043cu043eu0434u043du044bu0439 u0441u043fu043eu0440u0442u0441u043cu0435u043d u0438u0433u0440u0430u0435u0442 u0432 u043au0430u043au0443u044e-u0442u043e u0442u0430u043au0442u0438u043au0443 u0438 u0432u0441u0435 u043du0430u0447u0438u043du0430u044eu0442 u0434u0443u043cu0430u0442u044c, u0447u0442u043e u044du0442u043e u0438u043cu0431u0430).nu041fu043eu044du0442u043eu043cu0443 u0432u0441u0435, u0447u0442u043e u043du0435u043bu044cu0437u044f u0437u0430u0440u0430u043du0435u0435 u043fu0440u0435u0434u0441u043au0430u0437u0430u0442u044c u043du0430 u0443u0440u043eu0432u043du0435 u0437u0434u0440u0430u0432u043eu0433u043e u0441u043cu044bu0441u043bu0430 — u043du0430u0434u043e u0440u0435u0448u0430u0442u044c u043du0435 u0432 u0431u0430u043bu0430u043du0441u0435, u0430 u043fu043eu0441u0442-u0444u0430u043au0442u0443u043c, u043au043eu0433u0434u0430 u0432u043eu0437u043du0438u043au043du0435u0442 u043fu0440u043eu0431u043bu0435u043cu0430.nnu041cu0430u043au0441u0438u043cu0430u043bu044cu043du044bu0439 u0445u0430u0440u0434u043au043eu0440, u043du0430 u043au043eu0442u043eu0440u044bu0439 u044f u0438u0434u0443 u0432 u0431u0430u0442u0442u043bu0435u0440u0435 — u0443u0447u0438u0442u044bu0432u0430u044e u0432u0435u0440u043eu044fu0442u043du043eu0441u0442u044c u0441u0440u0430u0431u0430u0442u044bu0432u0430u043du0438u044f u043eu043fu0446u0438u043eu043du0430u043bu044cu043du044bu0445 u044du0444u0444u0435u043au0442u043eu0432. u041du0430u043fu0440u0438u043cu0435u0440 «+100 u043fu0440u043eu0442u0438u0432 u043eu0440u043au043eu0432″ = «+100 * u0432u0435u0440u043eu044fu0442u043du043eu0441u0442u044c, u0447u0442u043e u0446u0435u043bu044cu044e u0441u0442u0430u043du0435u0442 u043eu0440u043a (u0442.u0435. u0434u043eu043bu044f u043eu0440u043au043eu0432 u0441u0440u0435u0434u0438 u0441u043eu043fu0435u0440u043du0438u043au043eu0432 u044du0442u043eu0433u043e u044du0442u0430u043fu0430)».

          • u0410u043bu0435u043au0441u0430u043du0434u0440 u0414u0430u043du0447u0435u043du043au043eu0432

            u0421u043fu0430u0441u0438u0431u043e! u0414u0430, u0434u0435u0439u0441u0442u0432u0438u0442u0435u043bu044cu043du043e, u0434u0443u043cu0430u043b u043fu0440u043e u0441u043bu043eu0436u043du043eu0441u0442u044c u0440u0430u0441u0447u0435u0442u0430 u0441u0438u043du0435u0440u0433u0438u0438.

  • Corovaneer

    u0411u043eu043bu044cu0448u043eu0435 u0441u043fu0430u0441u0438u0431u043e. u041du0430 u043fu043eu0434u0441u043eu0437u043du0430u0442u0435u043bu044cu043du043eu043c u0443u0440u043eu0432u043du0435 u044f u0432u0441u0451 u044du0442u043e u0437u043du0430u043b, u0443u0434u043eu0441u0442u043eu0432u0435u0440u0438u043bu0441u044f u0432 u0441u0432u043eu0438u0445 u0440u0430u0441u0441u0443u0436u0434u0435u043du0438u044fu0445.

    • u0420u0430u0434, u0447u0442u043e u043eu043au0430u0437u0430u043bu043eu0441u044c u043au0441u0442u0430u0442u0438 :)

  • u0410u043bu0435u043au0441u0430u043du0434u0440 u0414u0430u043du0447u0435u043du043au043eu0432

    u0441u043fu0430u0441u0438u0431u043e, u043eu0447u0435u043du044c u043fu043eu043bu0435u0437u043du043e!