Tipps zur Implementierung der MMO-Questmechanik?

Welche Tools, Muster oder Best Practices würden Sie zur Implementierung der unten aufgeführten Questmechaniken empfehlen?

Ich spreche über die Softwarearchitektur (wie allgemein sollten Sie sein) und die Auswahlmöglichkeiten für die Objektverdrahtung, das Ereignisabonnement und die Darstellung von Bedingungen. Erwähnung von Tools / Bibliotheken, die Sie erfolgreich verwendet haben, sind willkommen. Bearbeiten: Wenn Sie Skripte verwenden, welches Setup empfehlen Sie?

Bedarf:

• einfaches 2D mmo (rpg)
• Alle Spieldaten, einschließlich Quests, werden in einer relationalen Datenbank gespeichert
• Jedes Ereignis im Spiel kann eine neue Quest für Spieler oder die Weiterentwicklung bestehender Quests auslösen
• Eine Quest kann eine beliebige Anzahl von Bedingungen haben, die erfüllt sein müssen, bevor die Quest Spielern zur Verfügung steht
• Eine Quest kann aus einer beliebigen Anzahl von Unterquests / Schritten mit beliebigen Bedingungen bestehen

• Quests würden von einfach reichen:

  rede mit A - töte 5 B - rede mit A - erhöhe dauerhaft die Gesundheit

• zu ziemlich involviert:

  benutze den Gegenstand in Bereich X - gehe zu Bereich Y - ein Bot wird erscheinen - töte den Bot ohne mehr als 10% Schaden zu erleiden - Bot lässt den Gegenstand fallen - nimm den Gegenstand auf - Portal entriegelt - bringe den Gegenstand zu J hinter dem Portal - erhalte Gold und Erfahrung - Portal erneut passieren lassen - Portal für diesen Spieler sperren

• Level-Instanzen sind eine Möglichkeit (Spieler können bestimmte Quests in Teams oder in Isolation abschließen, wodurch der Level-Standort nur für diese Teilnehmer entsteht).

• Quests sollte vorzugsweise überschaubar , ein Welt - Editor ohne Scripting oder Programmierkenntnisse ( Edit: nicht gegen Scripting im Allgemeinen obwohl befürworten)
• Ich gehe von C ++ als Implementierungssprache aus

Ich dachte, wenn ich eine Kette von Ereignissen und Bedingungen kombinieren könnte, könnten wir komplexere und damit möglicherweise spannendere Aufgaben modellieren. Ich habe mit dem Rollen meiner eigenen ECA-Engine (Events-Conditions-Actions) experimentiert, aber das könnte übertrieben sein. Es war besonders schwierig, generische Bedingungen zu modellieren, ohne Skripte zu verwenden.

Erst eine Warnung, dann ein Rat.

Als ich das letzte Mal ein solches System implementieren musste, verwendete ich keine Engine, die ursprünglich für MMO-ähnliche Anwendungen gedacht war. Das Questsystem, mit dem es ausgeliefert wurde, war auf Einzelspieler ausgelegt und konnte nicht verwendet werden.

Es endete damit, dass ich Skripte für alle Objekte, die mit den Quests zu tun haben, mehr oder weniger von Hand schreiben musste (Pseudocode):

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

Dies ist ein absoluter Albtraum. Es gibt keine Möglichkeit herauszufinden, wie die Quest funktioniert, ohne das ganze Spiel über zu spülen. Mach das nicht.

Ich würde empfehlen, ein System zu erstellen, in dem die gesamte Quest (Zeile) als endliche Zustandsmaschine dargestellt wird, mit Ereignissen, die auf Übergänge geprüft werden sollen, und Skripten, die auf diesen Übergang reagieren sollen. Das macht es einfach, den Überblick zu behalten, wo Sie sich in einer bestimmten Quest (Zeile) befinden, und hält den Status aller Quests sauber gekapselt.

Wenn Sie möchten, können Sie in Ihrem World Editor eine Bibliothek mit Skripten / Skriptvorlagen für häufige Vorkommnisse erstellen (der Spieler spricht mit dem NPC, der Spieler tötet den Mob usw.).

Ich würde mich nicht zu sehr um die Skriptleistung kümmern, solange Sie Ihre Ereignisskripte nicht zu oft auslösen. Als Faustregel gilt, dass Skripte mindestens eine Größenordnung unter der "Kern" -Spiellogik (Animation, Physik usw.) abfeuern sollten. Sie sollten auf Ereignisse reagieren, anstatt regelmäßig zu feuern, um zu überprüfen, ob eine Bedingung erfüllt ist.

In unserem System wird grundsätzlich für jeden Missionsschritt ein Ausdruck ausgeführt (eine benutzerdefinierte Mini-Skriptsprache, aber tcl / lua / python funktioniert genauso gut oder Sie erstellen selbst etwas). Dies gilt für "persönliche Missionen", die an einen bestimmten Spieler gebunden sind. Jeder Unterschritt ist dann Teil einer FSM (Finite State Machine) für die Mission selbst (die möglicherweise nur ein Unterschritt einer anderen Mission ist). Es gibt auch "Kartenmissionen", die eine einzige FSM haben und an die Karte gebunden sind, anstatt an einen Spieler (denken Sie an die öffentlichen Quests von WAR), aber die Unterschritte funktionieren im Grunde gleich.

Was diese Ausdrücke tatsächlich betrachten, sind Ereignisse, die vom System gesendet werden, wie "NPC gestorben" oder "Interaktion abgeschlossen". Dies bedeutet, dass Sie die verschiedenen Teile etwas entkoppeln können. Die Spielsysteme senden Ereignisse nur nach Bedarf aus. Die Missionsskripte hören Ereignisse nur ab und kümmern sich nicht darum, woher sie kommen. Wenn Sie sich auch darauf einlassen, dass die Missions-FSMs mit dem Weltzustand interagieren (diesen Kontakt nur im Missionszustand X anzeigen), können Sie viel Leistung aus dem System herausholen.