Советы по реализации MMO квестовой механики?

Какие инструменты, шаблоны или лучшие практики вы бы порекомендовали для реализации квестовой механики с учетом перечисленных ниже требований?

Я говорю об архитектуре программного обеспечения (насколько вы должны быть универсальны) и выборе для связывания объектов, подписки на события и представления условий. Упоминание инструментов / библиотек, которые вы успешно использовали, приветствуется. Изменить: Если вы используете сценарии, какие настройки вы рекомендуете?

Требования:

• простая 2D MMO (RPG)
• все данные игры, включая квесты, хранятся в реляционной базе данных
• любое событие в игре может вызвать новый квест для игроков или продвижение существующих квестов.
• квест может иметь произвольное количество условий, которые должны быть выполнены, прежде чем квест станет доступен для игроков
• квест может состоять из произвольного количества подквестов / шагов с произвольными условиями

• квесты будут варьироваться от простых:

  поговорить с A - убить 5 B - поговорить с A - навсегда улучшить здоровье

• к весьма вовлеченному:

  использовать предмет в области X - перейти в область Y - бот будет порождаться - убивать бота, не получая более 10% урона - бот отбрасывает предмет - поднимать предмет - портал разблокируется - доставить предмет J за порталом - получить золото и опыт - разрешить пройти портал еще раз - заблокировать портал для этого игрока

• Возможны инстансы уровней (игроки могут выполнять определенные квесты в командах или в изоляции, которая порождает локацию уровня только для этих участников)

• Желательно, чтобы квестами можно было управлять с помощью редактора мира без написания сценариев или знаний по программированию ( Редактировать: хотя вообще не выступаю против сценариев)
• Я принимаю C ++ в качестве языка реализации

Я думал, что, если бы я мог объединить любую цепочку событий и условий, мы могли бы смоделировать более сложные и, следовательно, возможно, более интересные квесты. Я экспериментировал с вращением моего собственного двигателя ECA (События-Условия-Действия), но это может быть излишним. Было особенно трудно моделировать общие условия без использования каких-либо сценариев.

Сначала предупреждение, потом несколько советов.

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

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

Lever004_on_activate() {
    if isOnQuest(player, QUEST_0012) do_something();
    if isOnQuest(player, QUEST_0015) do_something_else();
}

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

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

При желании вы можете создать библиотеку сценариев / шаблонов сценариев в своем редакторе мира для общих случаев (игрок разговаривает с NPC, игрок убивает моба и т. Д.)

Я не стал бы сильно беспокоиться о производительности сценариев, если вы не запускаете сценарии событий слишком часто. Как правило, сценарии должны запускаться как минимум на порядок меньше, чем «основная» логика игры (анимация, физика и т. Д.). Они должны реагировать на события, а не периодически запускать, чтобы проверить, было ли выполнено условие.

Наша система в основном включает в себя запуск выражения (пользовательский язык мини-сценариев, но tcl / lua / python будет работать так же хорошо, или делать что-то самостоятельно) каждого фрейма сервера для каждого шага миссии. Это для «личных миссий», которые привязаны к конкретному игроку. Каждый подшаг является частью FSM (конечного автомата) для самой миссии (которая может быть просто подшагом другой миссии). Существуют также «миссии на карте», которые имеют одного FSM и привязаны к карте, а не к игроку (подумайте об открытых квестах WAR), но подшагы работают в основном одинаково.

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