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

14

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.

jmp97
la source
Y a-t-il une raison particulière pour laquelle vous avez choisi d'ignorer les scripts? (comme lua / gamemonkey, etc.).
Simon
Principalement en raison du manque d'expérience et en raison d'hypothèses (éventuellement non valables) sur la façon dont cela pourrait affecter négativement les performances. Je voulais aussi que l'édition du monde soit aussi simple que possible. Cependant, je suis ouvert à l'utilisation de scripts.
jmp97
1
Je suis d'accord, sans le support des scripts, il sera difficile d'ajouter de la variété aux quêtes sans impliquer les programmeurs du moteur.
drxzcl
1
Les langages de script ont tendance à être assez rapides pour que ce ne soit pas un problème. Je recommande fortement de les utiliser. Cela dit, une grande partie des scripts de WoW est basée sur le déclenchement de sorts et d'événements. "Parler à A" entraînerait, dans les coulisses, A à "lancer un sort" sur le joueur, et la quête serait en fait codée "cela réussit lorsque le sort # 55728 est lancé sur le joueur". Ensuite, vous avez juste besoin d'un peu de codage AI pour amener les créatures à lancer des sorts sur le joueur et vous êtes prêt.
ZorbaTHut
1
Les langages de script modernes (comme le Lua Vm) sont probablement assez rapides pour vous. Ils sont faciles à utiliser, faciles à implémenter, vous pouvez recharger les scripts lors de l'exécution, vous pouvez déboguer et exécuter les scripts dans l'exécution et vous pouvez parcourir BEAUCOUP plus rapidement tout en créant du contenu. Je suggère fortement de rechercher un moteur de script (exemples: lua et gamemonkey) afin de scripter des quêtes.
Simon

Réponses:

6

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.

drxzcl
la source
3
Soyez averti cependant, les statemachines ont tendance à devenir très compliquées très rapidement si vous voulez que les chemins de quête soient influencés par des facteurs extérieurs ou si vos quêtes sont relativement complexes. De plus, plusieurs statemachines de quête (si plusieurs quêtes peuvent être actives) peuvent être un cauchemar. Cependant, étant donné que chaque programme est essentiellement un statemachine, cela peut être fait. Mais les problèmes complexes restent complexes, peu importe comment vous les résumez. Un bon exemple (imo) est Oblivion où certains mods empêchent d'autres mods de fonctionner - vos pré et postconditions pour les états doivent être soit assez solides, soit extrêmement tolérantes / tolérantes aux erreurs.
Kaj
Ouaip, kaj a raison. Rendez-vous simplement sur les forums WoW en ce moment et lisez des informations sur les personnes se plaignant de quêtes inachevables. Cela arrive tout le temps, même dans la ligue majeure. Il est vraiment difficile de tout faire correctement.
drxzcl
3

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.

coderanger
la source