Conseils pour implémenter la mécanique des quêtes MMO?

Quels outils, modèles ou meilleures pratiques recommanderiez-vous pour implémenter les mécanismes de quête indiqués ci-dessous?

Je parle de l'architecture logicielle (à quel point devez-vous être générique) et des choix de câblage d'objet, d'abonnement aux événements et de représentation des conditions. La mention des outils / bibliothèques que vous avez utilisés avec succès est la bienvenue. Modifier: si vous utilisez des scripts, quelle configuration recommandez-vous?

Exigences:

• mmo 2D simple (rpg)
• toutes les données du jeu, y compris les quêtes, sont stockées dans une base de données relationnelle
• n'importe quel événement dans le jeu pourrait déclencher une nouvelle quête pour les joueurs ou l'avancement des quêtes existantes
• une quête peut avoir un nombre arbitraire de conditions qui doivent être remplies avant que la quête ne soit disponible pour les joueurs
• une quête peut consister en un nombre arbitraire de sous-quêtes / étapes avec des conditions arbitraires

• les quêtes allaient de simples:

  parlez à A - tuez 5 B - parlez à A - augmentez de façon permanente la santé

• à assez impliqué:

  utilisez l'objet dans la zone X - allez dans la zone Y - un bot apparaîtra - tuez le bot sans subir plus de 10% de dégâts - le bot dépose l'objet - ramassez l'objet - le portail se déverrouille - livrez l'objet à J derrière le portail - recevez de l'or et de l'expérience - laisser passer le portail une fois de plus - verrouiller le portail pour ce joueur

• les instances de niveau sont une possibilité (les joueurs peuvent terminer certaines quêtes en équipe ou isoler ce qui engendrera l'emplacement de niveau juste pour ces participants)

• Les quêtes doivent de préférence être gérables à l'aide d'un éditeur mondial sans connaissances en scripting ou en programmation ( Edit: ne préconise cependant pas les scripts en général)
• Je suppose que C ++ est le langage d'implémentation

Je pensais que si je pouvais combiner n'importe quelle chaîne d'événements et de conditions, nous pourrions modéliser des quêtes plus complexes et donc peut-être plus engageantes. J'ai essayé de lancer mon propre moteur ECA (événements-conditions-actions) mais cela pourrait être exagéré. Il a été particulièrement difficile de modéliser des conditions génériques sans utiliser aucune sorte de script.

D'abord un avertissement, puis quelques conseils.

La dernière fois que j'avais besoin d'implémenter un système comme celui-ci, je n'utilisais pas un moteur initialement destiné aux applications de type MMO. Le système de quêtes avec lequel il était livré était conçu pour les efforts en solo et ne pouvait pas être utilisé.

J'ai fini par devoir bourrer les scripts sur tous les objets impliqués dans les quêtes plus ou moins à la main, comme ceci (pseudocode):

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

Ceci est un cauchemar complet. Il n'y a aucun moyen de comprendre comment fonctionne la quête sans récupérer tout au long du jeu. Ne faites pas cela.

Je recommanderais de créer un système où toute la quête (ligne) est représentée comme une machine à états finis, avec des événements pour vérifier les transitions et des scripts pour réagir à ladite transition. Cela permet de suivre facilement où vous en êtes dans une quête (ligne) donnée et de garder tout l'état de la quête soigneusement encapsulé.

Si vous le souhaitez, vous pouvez créer une bibliothèque de scripts / modèles de script dans votre éditeur de monde pour les occurrences courantes (le joueur parle au PNJ, le joueur tue la foule, etc.)

Je ne m'inquiéterais pas trop des performances des scripts, tant que vous ne déclenchez pas trop souvent vos scripts d'événements. En règle générale, les scripts doivent tirer au moins un ordre de grandeur inférieur à la logique de jeu "de base" (animation, physique, etc.). Ils devraient réagir aux événements, au lieu de tirer régulièrement pour vérifier si une condition est remplie.

Notre système implique essentiellement d'exécuter une expression (un mini langage de script personnalisé mais tcl / lua / python fonctionnerait tout aussi bien, ou créerait quelque chose vous-même) chaque châssis de serveur pour chaque étape de la mission. C'est pour les "missions personnelles" qui sont liées à un joueur spécifique. Chaque sous-étape fait alors partie d'une FSM (machine à états finis) pour la mission elle-même (qui pourrait simplement être une sous-étape d'une autre mission). Il existe également des "missions de carte" qui ont un seul FSM et sont liées à la carte au lieu d'un joueur (pensez aux quêtes publiques de WAR), mais les sous-étapes fonctionnent essentiellement de la même manière.

Ce que ces expressions regardent réellement, ce sont des événements diffusés par le système comme "NPC mort" ou "interaction terminée". Cela signifie que vous pouvez quelque peu découpler les différentes parties, les systèmes de gameplay envoient simplement les événements selon les besoins, que les scripts de mission écoutent simplement les événements et ne se soucient pas d'où ils viennent. Si vous insistez également sur le fait que les FSM de la mission peuvent interagir avec l'état du monde (ne montrer ce contact qu'en état de mission X), vous pouvez obtenir beaucoup de puissance du système.