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

14

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

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

Требования:

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

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

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

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

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

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

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

jmp97
источник
Есть ли какая-то конкретная причина, почему вы решили пропустить какой-либо сценарий? (например, lua / gamemonkey и т. д.).
Саймон
Главным образом из-за недостатка опыта и (возможно, несостоятельных) предположений о том, как это может негативно повлиять на производительность. Также я хотел, чтобы редактирование мира было как можно более простым. Тем не менее, я открыт для использования сценариев.
jmp97
1
Я согласен, без поддержки сценариев будет сложно добавить разнообразие квестам без участия программистов движка.
drxzcl
1
Языки сценариев имеют тенденцию быть достаточно быстрыми, чтобы это не было проблемой. Я настоятельно рекомендую использовать их. Тем не менее, большая часть сценариев WoW основана на запуске заклинаний и событий. «Поговори с А» за кулисами заставит А «наложить заклинание» на игрока, и квест будет фактически закодирован «это успешно, когда на игрока наложено заклинание № 55728». Тогда вам просто нужно немного AI-кодирования, чтобы существа могли накладывать заклинания на игрока, и все готово.
ZorbaTHut
1
Современные скриптовые языки (такие как Lua Vm), вероятно, достаточно быстры для вас. Они просты в использовании, просты в реализации, вы можете перезагружать сценарии во время выполнения, вы можете отлаживать и запускать сценарии во время выполнения, и вы можете выполнять итерацию НАМНОГО быстрее при создании контента. Я настоятельно рекомендую изучить скриптовый движок (примеры: lua и gamemonkey), чтобы писать сценарии квестов.
Саймон

Ответы:

6

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

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

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

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

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

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

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

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

drxzcl
источник
3
Тем не менее, будьте осторожны, машины состояний обычно очень быстро запутываются, если вы хотите, чтобы на пути квестов влияли внешние факторы или если ваши квесты относительно сложны. Также множественные квестовые автоматы (если несколько квестов могут быть активными) могут быть кошмаром. Однако, поскольку по сути каждая программа является машиной состояний, это можно сделать. Но сложные проблемы остаются сложными независимо от того, как вы их заключаете. Хорошим примером (imo) является Oblivion, где некоторые моды мешают работать другим модам - ​​ваши предварительные и постусловия для состояний должны быть либо довольно солидными, либо предельно прощающими / устойчивыми к ошибкам.
Кадж
Да, Кадж прав. Просто зайдите на форумы WoW прямо сейчас и читайте о людях, жалующихся на неокончаемые квесты. Это происходит постоянно, даже в высшей лиге. Это действительно трудно понять все правильно.
drxzcl
3

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

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

coderanger
источник