Я планирую приключенческую игру и не могу понять, как правильно реализовать поведение уровня в зависимости от состояния развития сюжета.
Моя однопользовательская игра представляет собой огромный мир, в котором игрок должен общаться с людьми в городе на разных этапах игры. Однако, в зависимости от развития сюжета, игроку будут представлены разные вещи, например, лидер гильдии изменит локацию с городской площади на разные локации вокруг города; Двери будут открываться только в определенное время дня после завершения определенной процедуры; Различные события на экране / триггере происходят только после достижения определенного этапа.
Я наивно думал о том, чтобы изначально использовать оператор switch {}, чтобы решить, что должен сказать NPC или где его можно найти, и сделать задачи квестов взаимодействующими только после проверки состояния глобальной переменной game_state. Но я понял, что быстро столкнусь с множеством различных игровых состояний и переключателей, чтобы изменить поведение объекта. Этот оператор switch также будет сложно отладить, и я думаю, его также сложно использовать в редакторе уровней.
Поэтому я подумал, что вместо одного объекта с несколькими состояниями, может быть, у меня должно быть несколько экземпляров одного объекта с одним состоянием. Таким образом, если я использую что-то вроде редактора уровней, я могу разместить экземпляр NPC во всех разных местах, в которых он может когда-либо появляться, а также экземпляр для каждого состояния диалога, которое у него есть. Но это означает, что будет много неактивных, невидимых игровых объектов, плавающих вокруг уровня, что может быть проблемой для памяти или просто трудно увидеть в редакторе уровней, я не знаю.
Или просто, сделайте идентичный, но отдельный уровень для каждого игрового состояния. Это самый чистый и безошибочный способ сделать что-то, но это похоже на массовую ручную работу, гарантирующую, что каждая версия уровня действительно идентична друг другу.
Все мои методы кажутся неэффективными, поэтому, повторюсь, мой вопрос: есть ли лучший или стандартизированный способ реализации поведения уровня в зависимости от состояния развития сюжета?
PS: у меня еще нет редактора уровней - я думаю об использовании чего-то вроде JME SDK или создании своего собственного.
источник
Выбор, который я бы рассмотрел, - это заставить отдельные объекты реагировать на разные игровые состояния или обслуживать разные уровни в разных игровых состояниях. Выбор между этими двумя будет зависеть от того, что именно я пытаюсь сделать в игре (каковы различные состояния? Как будет переход игры между состояниями? И т. Д.)
В любом случае, однако, я бы не стал делать это путем жесткого кодирования состояний в коде игры. Вместо массивного оператора switch в объектах NPC я бы вместо поведения NPC загружал в ассоциативный массив из файла данных, а затем использовал этот ассоциативный массив для запуска другого поведения для связанных состояний, что-то вроде этого:
источник
Как насчет использования паттерна наблюдателя для поиска изменений вехи? Если изменение происходит, некоторый класс распознает это и обрабатывает, например, изменение, которое должно быть сделано для NPC.
Вместо упомянутого шаблона проектирования состояния я бы использовал шаблон стратегии.
Если у NPC есть n способов взаимодействия с персонажем и m позиций, где он может быть, существует максимум (m * n) +1 классов, которые вы должны разработать. Используя шаблон стратегии, вы получите n + m + 1 классов, но эти стратегии также могут быть использованы другими npcs.
Таким образом, может существовать класс, обрабатывающий вехи, и классы, которые наблюдают за этим классом и обрабатывают либо NPC, либо врагов, либо что-либо еще, что следует изменить. Если наблюдатели получат обновленную информацию, они решат, нужно ли им что-то менять в случаях, которыми они управляют. Например, класс NPC в конструкторе информирует менеджера NPC о том, когда он должен быть обновлен и что должно быть обновлено ...
источник
Все приведенные подходы действительны. Это зависит от ситуации, в которой вы находитесь в данный момент. Многие приключения или ММО используют комбинацию из них.
Например, если основное событие меняет большую часть уровня (например, сборщик долгов очищает вашу квартиру и все в ней арестованы), обычно проще заменить всю комнату второй комнатой, которая просто выглядит похожей.
OTOH, если персонажи ходят по карте и делают разные вещи в разных местах, у вас часто есть один актер, который вращается через различные объекты поведения (например, идти прямо вперед / нет разговоров против стоять здесь / разговор о смерти Митча), который может включать «скрытые», если их цель была выполнена.
Тем не менее, обычно наличие дубликатов объекта, который вы создаете вручную, не должно вызывать никаких проблем. Сколько объектов вы можете создать? Если вы можете создать больше объектов, чем может зациклить ваша игра, посмотрите на их «скрытое» свойство и пропустите, ваш движок работает слишком медленно. Так что я бы не стал слишком беспокоиться об этом. Многие онлайн игры действительно делают это. Определенные персонажи или предметы всегда присутствуют, но не отображаются персонажам, у которых нет соответствующей миссии.
Вы даже можете комбинировать подходы: есть две двери в вашем жилом доме. Один ведет к квартире «до взыскания долгов», другой - к квартире после. Когда вы входите в коридор, на самом деле отображается только тот, который относится к вашему прогрессу в истории. Таким образом, вы можете просто иметь общий механизм для «элемента, видимого в текущий момент истории» и дверь с одним пунктом назначения. С другой стороны, вы можете сделать более сложные двери, которые могут иметь поведение, которое можно заменить, и одна из них - «перейти в полную квартиру», другая - «перейти в пустую квартиру». Это может показаться бессмысленным, если на самом деле меняется только назначение двери, но если меняется и ее внешний вид (например, большой замок перед дверью, который вы сначала должны взломать),
источник