Presumption
Презумпция (не)компетентности
narratorika_narrative_design
Нарраторика: лекция про нарративный дизайн

Задача про баланс

  • Декабрь 01, 2014
  • 34 комментария

На прошедшем недавно DevNight в Москве я увидел игру, тактическую стратегию по второй мировой, которая напомнила мне про классическую задачку по балансировке.

На вопрос “кто такой геймдизайнер?” часто отвечают что-то про баланс и таблицы цифр. Порой кажется, что в представлении некоторых людей достаточно заменить одни числа на другие, как игра сразу же станет сбалансированной, что бы это ни значило.

Итак, задачка. Сначала обозначим исходные данные. У нас есть персонаж игрока, у которого сколько-то здоровья и урона в секунду по одной цели. Есть враги, у которых свои значения здоровья и урона по игроку в единицу времени. Также у нас есть влияние скилла (skill — умение, в данном случае умение играть в игру). Игрок, проявив свои умения, может уворачиваться от атаки противника, тем самым снижая урон от него, а если игрок будет мешкать, то у него упадет собственный урон.

Если бы скилла не было, то исход боя был бы предрешен ещё до его начала. Следовательно сам бой был бы для игрока пустой тратой времени. Требование скилла дает игроку риск. Он может как проиграть из-за своей нерасторопности, так и выиграть меньше времени боя, больший остаток здоровья после боя, какие-нибудь бонусные очки за разнообразие комбо. Менеджмент риска — это основа геймплея.

Теперь переходим к проблеме. По ходу игры мы наверняка захотим увеличивать сложность стычек. Сначала один противник, потом два, потом три, и так далее. Но смотрите, что получается, когда противников несколько. Например, три штуки. В начале боя игроку наносится урон 3x , а в конце боя, когда остался один противник, урон будет 1x. То есть в начале боя ошибки игрока будут стоить ему в три раза дороже, чем в конце боя. Иными словами, сложность боя в начале выше, чем в конце.

Надеюсь, не нужно объяснять, почему не правильно, когда высокая сложность в начале и равномерное спадание к концу. Тысячи лет драматургии показывают, что напряжение большую часть времени должно нарастать, а не падать. Иначе зритель начнет храпеть, а это неприятно.

balancing_multiple_enemies_2

Соответственно вопрос: как сбалансировать бой с несколькими противниками, чтобы сложность во время схватки нарастала, а не падала?

Вопрос открытый, он не имеет единственного верного ответа. Предлагаю писать свои варианты в комментариях. Для затравки напишу несколько самых очевидных вариантов:

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

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

* Противники, сколько бы их ни было, нападают на игрока по очереди. Например, в Batman: Arkham Origins. Таким образом количество противников не увеличивает урон в секунду по игроку, но увеличивает общую сложность боя — при плохом скилле здоровья может не хватить до конца схватки.

* ММО игры, чтобы поддерживать разнообразие противников на протяжении сотен и тысяч часов геймплея, позволяют противникам иметь, скажем так, странные способности. Например, увеличивать в разы урон, если погиб товарищ. Таким образом в начале боя противников много, но бьют они слабо, а в конце боя противников мало, но урон от них приходит ого-го. Это вынуждает игроков оптимизировать тактику, доводя противников до предсмертного состояния, но не убивая. Такая тактика противоречит основной идее core-геймплея, что противников нужно убивать. Поэтому используется редко, в виде исключений для боссфайтов.

* Ещё пример странной абилки: повышение урона после нескольких секунд (ходов) от начала боя. Если противников мало, то мы их успеваем убить до того, как они применят свою абилку. Если противников много, то кто-нибудь успеет её применить, чем поддержит высокую сложность боя после того, как несколько противников лягут.

У меня есть ещё несколько вариантов, но сначала покажите, как вы бы подошли к решению этой задачи.

  • Ilya

    Убитые противники меняют поле боя, ограничивая возможность маневра. Divinity Original Sin — убил зомби и на его место появляется ядовитое облако.

  • Добавлю в копилку:

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

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

  • c1tr00z

    Частично сценарный момент похожий на ответ @Marther:disqus: постепенное увеличение количества противников (например убиваем одного, на его место приходят двое) и так продолжается пока мы не набьём определённый счётчик (пусть это будет счётчик морали), который опускается до 0 и тогда противники разбегаются (от ужаса, например)
    Или добавление одного супержирного босса в конце, который равен по силе и жизням некоторому количеству обычных противников в игре. Например
    1 противник => 2 противника => 4 противника => Босс (6 противников)

  • Александр

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

  • Torick

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

    А в остальном — согласен с одним из ораторов насчет того, что вариантов слишком много, без контекста сложно что-то универсальное предлагать.

    • Никто не запрещает предлагать свой контекст. Для того он и отсутствует, чтобы был простор для своих вариантов.

      • Александр

        Мне вот что интересно.

        Ты же в курсе про подходы к проектированию сверху вниз и снизу вверх? Сверху вниз — это когда сначала делаешь общую структуру, а потом начинаешь уточнять детали. А снизу вверх, соответственно, наоборот: делаем атомарные детальки, а потом, когда начнём соединять друг с другом, то общая структура сама собой вырисуется.

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

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

        • Это же просто задачки, они иначе как получатся?..

        • А что если каркас — это деталька ещё большего каркаса, а деталь — это каркас для ещё меньшей детали? :о)

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

          Я себе вижу работу над дизайном как постоянную беготню сверху вниз и обратно. Часто спускаясь вниз натыкаешься на проблемы, которые можно решить поднявшись на уровень выше. Тут рядом есть подобные решения, когда для решения проблемы боя с несколькими противниками вводится система кулдаунов. Конечно, надо знать меру, но если ситуация с противниками случается часто, а кулдауны ничего не ломают, то почему бы и нет.

          • Александр

            > каркас — это деталька большего каркаса, а деталь — это каркас меньшей детали
            Ну, тут всё верно. Понятно, что уровней вложенности не два, а много.

            > постоянную беготню сверху вниз и обратно
            Ну, это я тоже прекрасно понимаю. Вопрос откуда у тебя беготня начинается: сверху или снизу? И вообще, можно ли, на твой взгляд, начинать снизу в реальном проекте (мы говорим о 99% типичных проектов, экзотику в расчёт не берём)?

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

          • Чисто теоретически, конечно, правильно начинать сверху вниз. Сначала глобальная идея, вижен, а потом уже детали. Но на практике часто бывает, что проект начинается с детали. Скажем, есть у тебя шейдер воды, какого ни в какой другой игре нет. Вот сидишь и думаешь какую бы игру навернуть, чтобы воды побольше было :о)

            В этом есть резон. Игру продают её USP (unique selling points), которые могут быть как общим виженом, так и маленькой деталькой. Типа решил сделать игру про поезда. Но поезда это лишь деталь, которая катается по ландшафту и участвует в экономике.

          • Александр

            Ясно, понятно.

        • Alderfly

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

          • Александр

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

            Но да, сверху-вниз считается крутым навыком архитектора. Но, во-первых, почти нереально правильно спланировать архитектуру, если ты не делал нечто подобное раньше. А, во-вторых, я считаю, что в программировании не стоит пытаться делать что-то правильно, только потому, что это считается правильным. Если не чувствуешь ООП, то лучше писать в процедурно-событийном стиле до тех пор, пока этих средств станет недостаточно, когда реально столкнёшься с теми проблемами, которые ООП призвано решать. Тогда всё получается гармонично. Если же просто бездумно хвататься за паттерны и новомодные приёмчики, не прочувствовав на практике пользу от них, то обычно рождаются кривые монструозные конструкции и сооружения. Keep It Simple, пока это возможно, короче.

  • Max

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

  • Alderfly

    Не обязательно применять «правило драматургии» в каждую минуту игры. Если бои репетативные, то сложность нарастает из боя к бою. А в каждом конкретнем бою это становится не столь критичным. Все класические тактические игры построены так, что к концу каждого отдельно взятого боя легче и все в восторге от этих игр. Герои, икскомы, горький 17 (кстати переигрываю сейчас, крутая игра) и т.д., везде игроком вначале выносится опасный враг, после чего становится легче. За исключением боев с боссами и групкой приспешников, там могут быть вариации.
    Но если упустить возможность оспаривания «аксиомы» взятой вами вначале. То могу предложить такие варианты:
    — Прокачку врага во время боя, за счет чего юниты получают абилки и становятся сильнее;
    — Подбор врагом бонусов и использование локации для занятия более выгодных позиций, которые дают преимущества
    — Давать игроку и противникам примерно одинаковое количество юнитов и балансировать бой так, что в большинстве случаев идет обычный размен юнитами и напряжение держится до конца. Класичекий пример — шахматы.
    — Ускорять финальную часть (добивание). Как только игрок получает основательное преимущество, бой очень быстро заканчивается. Таким образом по времени кульминация окажется во второй половине боя.

    • Александр

      Плюсанул за Горький

  • Поросёнок Пётр

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

    Миллионные продажи обеспечены.

  • Поросёнок Пётр

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

    Потому что жанр не обозначен, перспектива не обозначена, стилистика не обозначена, «сеттинг» не обозначен, центральная идея не обозначена, сюжет не обозначен, цель не обозначена.

    • блин, технические требования забыл указать и цену в стиме/аппсторе

      • Поросёнок Пётр

        Кстати цена тоже влияет. И требования.

        Мы же не забываем ass ass unity?

  • Nick

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

  • Я сторонник задротского «реализма», и механики, при которой бой против превосходящих сил противника заведомо проигрышный. Следовательно, я бы делал такую механику, при которой требовалось разделять/изолировать/обходить врагов, сводя любое столкновение к череде поединков 1 на 1.

  • Slava Bushuev

    Сама задача изначально поставлена не правильно. Типа, давайте придумаем костылей и непонятных механик в том месте где ничего делать не надо.
    Бой с 10 противниками одновременно сложный в начале, чо делать?
    -Ничего не делать.
    Пачка из 10 врагов не первая на уровне, и до нее стоят группы мобов попроще. Соответственно если смотреть на кривую интенсивности-сложности всего уровня, то там (если левел дизайнер не налажал) все будет нормально — вначале легкие группы мобов в конце сложные. Если хочется сделать длинный комбат, то проверенный временем механизм — волны мобов, каждая следующая злее предыдущей.

    Лучше подумайте над тем, как сделать боевку интересной и фановой. Вместо того, чтобы углубляться в странные детали.

    • Slava Bushuev

      Ярик, у тебя багло на сайте:) Почему мой коммент добавился куда-то в центр?

      • Это особенность Disqus, системы комментариев, используемой тут и на многих других сайтах. Она по-умолчанию сортирует комментарии по количеству лайков. Просто поменяй сортировку, чтобы новые комменты были вначале.

  • Ilya

    Увеличение урона (снижение брони) с течением времени — в начале боя необходимо пять ударов для убийства противника или смерти игрока, в концу уже хватает одного-двух ударов.

    Убивать последнего противника скриптом.

  • Ilya

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

    • Такой подход с рейтингом хорош тем, что игра проходима для новичков, но вознаграждает за скилл. Другой вопрос насколько вознаграждение мотивирует.

  • Alina Brazdeikene

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

  • Alexander Smirnov

    Если абстрагироваться от конкретных уточнений в постановке задачи, а взять за основу только два момента:
    1. Игрок убивает врагов, внешне количество врагов уменьшается
    2. Напряжение в процессе боя должно нарастать, чем ближе к концу боя, тем больше зависит от навыков игрока.

    Я вижу только два базовых направления раскрутки механики:
    1. Оставшиеся противники усиливаются в процессе боя.
    2. Относительная мощь персонажа игрока падает в процессе боя.

    Как именно обыграть каждое из направлений зависит от сеттинга и физики мира (ниже то, что придумал за полчаса).

    Варианты усиления оставшихся противников:
    1. Враги жрут павших и от этого толстеют 🙂
    2. Враги становятся злее, хотят все сильнее мстить за своих братьев, съезжают с катушек, применяют все более безумные орудия (которые поначалу не применяли из-за воспитания) 🙂
    3. Враги поглощают энергию из душ павших
    4. Враги приобретают иммунитет от ударов персонажа игрока, учатся глядя на смерти товарищей (как вирусы)
    5. Толстый враг жертвует слабых врагов и только в конце вступает в бой по настоящему (аля фильмы про китайское кунфу)
    6. Враги для боя используют общий «котел» энергии. Чем меньше врагов, тем более сильные атаки они применяют.
    7. Враги мешают друг другу, чем меньше врагов, тем меньше они ранят своих собратьев и тем больше достается игроку.
    8. Враги — порождение компьютера. Чем меньше врагов, тем проще компьютеру
    их рассчитывать, тем быстрее они начинают действовать. 🙂
    9. Враги умирая превращаются в новые более сильные сущности, но только каждый
    второй превращается в «бабочку». Т.о. количество врагов уменьшается, но
    сила врага растет.
    10. Враги изначально атакуют каждый своим оружием, но подбирая оружие своих братьев, они комбинируют оные в более мощные модификации.
    11. Враги надевают броню павших. Т.о. через более толстую броню постепенно все меньше дамага заливается игроком оставшимся.

    Варианты ослабления игрока:
    1. Персонаж игрока потребляет конечный оперативный ресурс. Если в начале боя он может применять массовые заклинания, то в конце ресурса хватает только на уколы перочинным ножом.
    2. Персонаж игрока обладает свойством питаться энергией от живых противников. Чем меньше оных, тем ниже скорость восстановления.
    3. Персонаж теряет броню. Т.о. он становится более уязвимым для атак противника.
    4. Персонаж слабеет, устает, теряет кровь.
    5. Персонаж расстраивается, убивая людей, теряет вкус к убийствам 🙂
    6. Персонаж игрока составной, например, это целый отряд бойцов. Бойцы в процессе боя расходуются. Совокупная мощность атак падает.
    7. Персонаж игрока после каждого убийства попадает все больше в немилость богов и теряет абилки.
    8. Персонаж игрока телепатически может контролировать только слабую половину врагов, силами которых атакует остальных. Чем меньше врагов, тем меньше относительная сила контролируемой половины.
    9. Персонаж обладает только массовыми атаками. Враги позиционно расположены так, что все большая часть воздействия расходуется впустую.
    10. Персонаж пачкается в крови, земля становится скользкой, глаза заливает кровь. Он начинает поскальзываться и ошибаться.
    11. Персонаж видя, что врагов становится все меньше, начинает лениться, расслабляется, начинает бахвалится и пропускает удары. 🙂

    Ну и еще 100500 других вариантов.

    Если сформулировать одной фразой, то я бы сказал, что в общем случае в процессе боя рост мощи персонажа должен отставать от роста мощи оставшихся врагов. Наиболее приятный для игрока вариант, когда персонаж «толстеет» (активируется много разных свойств), но оставшиеся враги «жиреют» быстрее его. И их все сложнее атаковать, но при этом за счет вариативности интереснее.

  • ZyXyS

    Слоупок в теме xD Где я раньше был?

    Перечитал комментарии, не заметил (или просмотрел) одного — дать и сопернику, и персонажу одинаковые способности. Т.е., если очень грубо, он тебя с двух ударов, и ты их точно также. Эта тема шикарно работает в серии Souls и, теперь уже, переехала в Bloodborne.

    Получается, что оставшийся противник несёт ровно такую же угрозу, как два и больше. В свою очередь, большая группа врагов будет заставлять либо:
    — вытаскивать их за угол по одному, что не уменьшает напряжение от схватки;
    — выезжать за счёт собственного скилла, врываясь в толпу, что ещё больше накаляет обстановку (и быстро отучивает так делать xD).

    3х урон тут также далеко не всегда будет работать, поскольку противники в группе ведут себя всё равно индивидуально и если пропускаешь удар, то чаще всего попадаешь на комбинацию лишь от одного из врагов.

  • Постановка задачи неверная. Вот тут:

    > В начале боя игроку наносится урон 3x

    надо вставить возможность уклониться от атак. Это *вероятность* получения урона 3x, а не количество получаемого. Если игрок собирается бить большую толпу врагов, он идёт на больший риск, чем если бы он сражался один на один. Значит, ему нужно изобретать, как бы эту толпу разбить на мелкие кучки.

    А дальше всё зависит от того, какую игру вы делаете и каких эмоций хотите от игрока.

Switch language:
Facebook