Найти в Дзене

Об управлении, течении времени и о том, почему одно из жанровых заблуждений является таковым (взгляд с другой стороны)

Оглавление

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

В голове среднестатистического игрока имеются такие категории, потому что он очень легко представляет себе эти два полюса. Скоростные клики и часовые раздумья. Бокс и шахматы. Варкрафт и Герои. Стронгхолд и Генералы. Тоталвар и Тоталвар. Эти подходы являются интуитивно понятными и, как кажется, единственными. Но это всё абсолютно не так.

Единство и борьба противоположностей

Начать стоит с тех качеств, которыми определяются (субъективно, объективно и механически) оба подхода.

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

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

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

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

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

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

Так что, идейной разницы нет? Нет, ведь есть и второй ключевой пункт, который мы не опровергли, а именно - длительность атомарных действий. Несмотря на то, что многие из подобных последовательностей действий длительности 0 могут быть сведены к действиям длительности ход (например, передача юнитов в Героях по цепочке или использование там же для постройки ресурсов, которые собраны в течение хода, могут быть рассмотрены как комбинированные модальные действия с определённым правилами и состоянием игры шансом на выбор того или иного мода), два момента всё равно не дадут нам полностью совместить их. Первый - это возможность цепочек бесконечной длины. Встречается подобное крайне редко, но если встречается, то проблем с логикой не оберёшься. И ладно бы речь шла о бесконечном периодическом или безусловном возврате в исходное состояние - с этим правила обычно бороться умеют. Хуже, если возвращение непериодическое или условное (бесконечные последовательности, не возвращающиеся в исходное состояние, обычно имеют тенденцию к завершению партии в процессе, но тоже не факт). В этом случае для любого ограничения длины последовательности действий её суммарная продолжительность должна по-прежнему считаться нулевой.

Второй момент - действия, чей результат (распределение результирующих состояний) не определяется правилами и текущим состоянием, а зависят от игрока (или даже игроков). То есть, такие, чей исход явно требует завершённости для корректной оценки результата (в этом смысле важно именно то, что поведение игрока не детерминировано). Частный случай этого момента - синхронные действия игроков (нарушающие ещё и пункт про стабильность игрового состояния). Да походовые игры с полностью синхронными ходами существуют...

От теории к практике

Итак, у нас есть следующие инструменты и характеристики:
1) действия длительности 0 (или их отсутствие, актуально только для ходов)
2) одновременный доступ к командному интерфейсу (или строго последовательный, ходы)
3) одновременное исполнение действий (или так или иначе организованное последовательное, ходы)
4) одновременные команды (или их невозможность, актуально для реалтайма)
Каждый из этих пунктов требует определённой технической начинки для реализации (помимо ортогональных конструкций типа таймеров/множителя скорости). Сам же факт того, что пункты 2 и 3 разделены, показывает, что важным инструментом является то, отделены ли команды от их исполнения (и если отделены, то пункт 1 заведомо принимает значение "нет", а если нет, то 2 и 3 принимают одинаковое значение). Попутно отделение команд от исполнения ставит вопрос об их хранении (особенно важный для реалтаймовых вариаций, где любое состояние валидно, стало быть, отданные команды являются частью этого состояния).

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

  1. Классический реалтаймовый - прост в описании и реализации в базовой версии, но максимально "нестратегичен". Поскольку выигрывает обычно тот, кто отдаёт команды быстрее. При этом любые ортогональные механики могут чрезмерно усложнять игровые объекты.
  2. Реалтаймовый с активной паузой - в базовой версии ситуация аналогичная, кроме того, что "перекликать" противника больше нельзя. Разом плюс и минус - в мультиплеере этот подход не любят ("ломает динамику" и затягивает партии, не исключатся и абуз паузы одним из игроков). Чреват двойной задержкой исполнения - за счёт паузы и "встроенной" (пример - время каста заклинаний в каких-нибудь PoE).
  3. Походовой с отложенным одновременным исполнением команд - по факту, аналогичен предыдущему, но а) пауза периодически вызывается системой, б) нельзя отдавать команды вне паузы. С одной стороны, полностью или частично гасит мультиплеерые минусы этого прошлого пункта, с другой - сводит микроконтроль на нет. Тот случай, когда признаки побиты примерно 50/50 и неспециалист запросто может встать в ступор по поводу классификации (с одной стороны - чёткие окна выдачи приказов, с другой - классическая реалтаймовая система описания мира). Возможно исполнение с последовательной отдачей команд игроками (актуально только для игры на одном компьютере). На деле же часто жутко неудобен именно в плане управления юнитами - которые или вынуждены торчать на месте, или бесконтрольно шатаются по карте, постоянно проходя мимо ожидаемой цели.
  4. Походовой с отложенным последовательным исполнением команд - вот тут уже обмануться невозможно - всё делается по-очереди. Тем не менее, в сравнении с пунктом выше, никакого существенного выигрыша не будет - коллизии никуда не денутся. Однако по какой-то субъективной причине (вероятно, из-за тяготения к более масштабным пространствам) эти коллизии раздражают куда как меньше. Да, их можно решить явно (за счёт приоритета на основе порядка), но это вызывает свои сложности (проблема баланса/сноуролла).
  5. Классический походовой с исполнением команд "сразу" - максимум предсказуемости действий. Что стоит помнить - она не бесплатна. Первая проблема - длительность партии и время простоя игрока (вообще говоря, это разные проблемы, но тут они связаны). Вторая - преимущество порядка хода (обычно или у первого ходящего, или у последнего).
  6. Походовой с исполнением команд сразу, но с одновременным доступом к игре - попытка разительно ускорить пункт выше для сетевой игры. У пункта 3 большое время ожидания (поскольку сам ход в динамике длится довольно долго), у пункта 4 иногда возникают длинные паузы, когда всё-таки требуется порядок решений, про 5 даже говорить не стоит - там весь геймплей - это очередь (хотя некоторые дизайнерские решения с длинным простоем весьма изящно борются). Но при этом в 3 и 4 ты ждёшь, прежде всего, систему. В 5 ты ждёшь других игроков (долго, дольше, чем в 3 и 4), а вот своя активность весьма динамична. Так почему бы не попробовать скрестить? Все действия выполняются одновременно всеми игроками, но их объём ограничен. На практике - это гора головной боли по синхронизации клиентов и таймеров. И не меньшая - геймплейно. Отдельные действия вызывают гонку (кто раньше успеет прийти в точку). Отдельные - наоборот, сюрпляс (когда задача - не показывать противнику информацию и/или давать время на реакцию). Таймеры при этом весьма щадящие - и можно наблюдать, как игроки лихорадочно перекликивают друг друга в последние 30 секунд своих пятиминутных ходов (до этого не делая ничего). Как тактика в боях в Героях - сначала подождать, а потом иметь две атаки подряд, только во времени игрока, а не во внутриигровом. Представьте шахматы, где очерёдность каждого хода определяется тем, кто первым схватил свою фигуру (зато второй сможет, по факту, сходить своей фигурой дважды подряд - ведь конец хода определяется по его действию, и он в следующем уже сразу будет держаться за фигуру). Бонусом - ИИ в этом режиме максимально в нечестном положении (поэтому он-то одновременно действовать не будет). Поэтому для одиночной игры способ не подходит.

Как видим, несколько сложнее привычной дихотомии...

#геймдизайн #разработкаигр