• Как проектируются такие приложения как игры? А именно, откуда берутся расчеты баланса и т.п.?

    @zlumer
    По моему опыту используются 5 основных видов балансировки цифр (сюда входит опыт, требуемый для левелапа, количество монстров на миссии, всякие характеристики персонажа в РПГ и т.п. - что угодно, что можно выразить в числовом виде):

    1. Клонирование.
    Берётся популярная игра похожего жанра (или совершенно другого), и цифры воруются с неё. За неимением профессионального дизайнера-балансировщика в команде этот метод часто даёт приемлемые результаты (см. многие социальные игры на российском рынке, склонированные с западных аналогов).
    Плюсы:
    * Не нужно толком ничего считать.
    * Отлично подходит для первой итерации баланса (в комбинации с другими методами на последующих итерациях).
    Минусы:
    * Все недостатки копируются вместе с достоинствами. Возможно, в исходной игре есть фундаментальные проблемы, которые не заметны на поверхности.
    * При изменении баланса трудно предсказать, в каком месте игра может сломаться. Самое маленькое изменение, типа добавления коэффициента на дамаг героя, может поломать весь баланс.
    * Непонятно, какие проблемы решали дизайнеры исходной игры. "Почему коэффициент повреждений умножается на 1.1?" "Почему формула кубическая а не квадратичная?" и т.п.

    2. Интуиция.
    Берутся значения наугад, на основе опыта гейм-дизайнера. Если это уже пятая по счёту ММО, в которой принимал участие геймдиз, то он может в блокноте накидать несколько формул с учётом многих будущих проблем.
    Плюсы:
    * Результат есть очень быстро, после нескольких расчётов.
    * Отлично подходит для первой итерации баланса, после которой можно переходить к п.3 - экспериментам.
    Минусы:
    * Нужен очень компетентный гейм-дизайнер, прежде разработавший не один похожий проект.
    * Даже очень опытные люди могут грубо ошибиться.

    3. Эксперименты.
    В игру забиваются первые попавшиеся значения (либо на основе п.1 - берутся из любой игры, либо на основе п.2 - интуитивно подбираются), затем гейм-дизайнер садится за игру (либо сам, либо просит товарищей по команде/друзей/фокус-тестировщиков), начинает играть и изучает, где в балансе дыры - какие уровни проходятся слишком долго, какие заклинания слишком слабые и т.п.
    Эксперименты нужно использовать в каждом проекте, чтобы отловить поверхностные проблемы. Некоторые разработчики модов к играм балансируют так весь игровой экспириенс: поиграл, покрутил цифры, поиграл ещё.
    Плюсы:
    * Все поверхностные проблемы сразу видны.
    * Не нужно никакой теоретической подготовки и расчётов, достаточно просто запустить игру и посмотреть.
    * Проверять работу всё равно нужно будет, можно сделать это на этапе начального баланса.
    Минусы:
    * Проверки занимают очень много времени.
    * Игроки зачастую проводят в игре больше времени, чем может себе позволить геймдиз (касается ММО и прочих больших игр), поэтому некоторые области не удастся проверить.
    * Персональные ощущения - это хорошо, но всегда стоит помнить, что стиль игры у разных людей отличается, и игрок может пойти по другому пути, чем дизайнер.

    4. Расчёты.
    Самый теоретический метод: задаётся некая величина, в которой оценивается балансировка (время, некий коэффициент сложности и проч.), а потом все цифры к ней подводятся.
    Пример 1: мы хотим, чтобы игрок получал левел-ап каждые 3 минуты. На каждом уровне просчитывается средняя скорость набора экспы, например 10 единиц в секунду на 5 уровне и 11 единиц в секунду на 6 уровне. 10*60*3 = 1800 опыта нужно с 5 по 6; 11*60*3 = 1980 опыта нужно с 6 по 7.
    Пример 2: мы делаем казуальную match-3 игру и чередуем сложные уровни с лёгкими. Сложным считается уровень с вероятностью победить около 50%, лёгким - с вероятностью победить около 95%. Мы рассчитываем вероятность победы в каждом из уровней (на основе исходных позиций шариков, например), и размещаем их в желаемом порядке.
    Плюсы:
    * Можно заранее запланировать экспириенс игрока, даже на очень высоких уровнях.
    * Легко вносить значительные изменения в баланс - просчитанные таблицы сразу покажут, где возникают проблемы.
    * Таблица может просто лежать на столе и напоминать, какие математические ограничения следует учитывать.
    Минусы:
    * Нужен человек, разбирающийся в математике. Хотя бы уметь рисовать параболы.
    * Много работы в Excel, тысячи цифр (на одном проекте у меня был документ с где-то 30 таблицами, в которых было по 10-25 столбцов и сотни строк - помнить их все и поддерживать в актуальном состоянии было очень затратно по времени).
    * Игра может быть просчитана очень хорошо, но играть в неё при этом будет не интересно - удовольствие от игры гораздо легче нащупать п. 3 - экспериментами.

    5. Статистика.
    Измеряются статистические показатели игроков: какой уровень они получают в первые 10 минут игры, какие миссии проходят, сколько шагов туториала смотрят, прежде чем отменить его. На основе этих данных делаются выводы.
    Например, если квест №7 выполняет 97% игроков, квест №8 - 45% игроков, а квест №9 - 95% игроков (считается процент от тех, кто дошёл до этого квеста), то сразу видно, что квест №8 чем-то сильно игроков смущает, надо проверить текст миссии, условия выполнения и прочее.
    Плюсы:
    * Реальные данные от тысяч игроков, сразу видны проблемы.
    Минусы:
    * Надо знать, что считать. Выбор метрик определяет эффективность этого метода.
    * Для этого способа подходят не все игровые платформы: нужно соединение с интернетом и желательна возможность быстрого обновления игры (например, в соц.сетях можно иметь очень кривой баланс, но в первые дни после релиза собирать статистику и крутить его до приемлемого).
    Ответ написан
    Комментировать