spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ein Questsystem sollte vom eigentlichen Programm getrennt sein. D.h. Dialoge usw. sollten nicht direkt in das Spiel einkompiliert sein, um volle Flexibilität bei der Levelgestaltung zu gewährleisten, ohne jedes mal das Spiel neu kompilieren zu müssen. Es bietet sich deshalb an, Quests in Skripte auszulagern und diesen Zugriff auf benötigte, den Spielzustand angehende, Parameter zu bieten. In diesem Zusammenhang wird oft die Skriptsprache Lua genannt.

Halte ich für keine gute Idee. Ich würde möglichst versuchen das Event-basiert zu halten. Erstens weil es weniger Performance fordert als bei jedem Update alle Quests zu fragen und zweitens weil die Quest-Scripte dann mit viel weniger State-Checks auskommen. Kandidaten für Events für die sich Quests registrieren könnten sind z.B.: Gegenstand erhalten oder verloren, Monster besiegt, Position erreicht, mit NPC gesprochen, etc, etc.

wenn ich ihn richtig verstanden habe, dann könnte das wie folgt gelöst werden:
du hast deinen Manager für die Quests, bei dem die Quests sich für ihr aktuell notwendiges Event registrieren
ein solches Event könnte das Töten eines bestimmten Monster oder das Einsammeln eines bestimmten Gegenstands sein
alle Aktionen, die für eine Quest interessant sein können, wie beispielsweise das Einsammeln eines Gegenstands, das Töten eines Gegners, das Führen eines Dialogs oder das Betreten eines bestimmten Gebiets, lösen ein Event aus
damit ist gemeint, dass dem Questmanager bescheid gegeben wird, dass beispielsweise gerade ein Monster getötet wurde
dieser schaut dann allen Quests Bescheid, dass gerade dieses Event eingetreten ist, die vorher sich für dieses registriert haben

die Quest könnte nun schauen, ob alle anderen, so nicht direkt oder etwas umständlicher erfassbaren Bedingungen erfüllt sind, wie beispielsweise, dass genug Monster dieser Art getötet wurden oder dass man beim Betreten eines Gebiets einen ganz bestimmten Gegenstand ausgerüstet hat


da ich schonmal am Antworten bin, möchte ich auch ein wenig etwas über Aspekte des Game Designs in Bezug auf Quests und Questsysteme schreiben:
in vielen Spielen ist es so, dass das Questsystem sehr generisch umgesetzt wird und nicht ideal an das Game Design angepasst wird
so hat man dann beispielsweise jedes Mal, wenn eine Quest gestartet wird, den Hinweis "willst du diese Quest annehmen", wo man auch gleich die Belohnung und die Aufgabe an sich sieht
genauso hat man bei "Zwischenzielen" (man hat gerade die 10 Monster besiegt und soll danach wieder zurück zum Questgeber) immer die Hinweise "du bist in der Quest weiter gekommen, du muss jetzt das Ziel Xyz erfüllen"
abgesehen davon, dass es nicht unbedingt einfach ist, zu definieren, was genau eine einzelne Quest ist und dass es da (beispielsweise seitens des Spielers) zu sehr abweichenden Auffassungen kommen könnte, könnte der Beginn einer Quest so einfach völlig unnötigerweise nochmal durch eine bereits erwähnte Meldung verdeutlicht werden, obwohl es evtl. aus einem Dialog heraus klar geworden ist
um es an einem Beispiel aus dem realen Leben zu verdeutlichen: grundsätzlich jedem dürfte es egal sein, dass beim Kaufen einer Tüte Chips oder einer Flasche Cola im Supermarkt des Vertrauens automatisch ein Kaufvertrag abgeschlossen wird und ich denke die meisten würden es eher als störend ansehen, wenn sie von der Kassierein oder dem Kassierer nach dem Bezahlen nochmals darauf hingewiesen werden

durch das Questsystem ist es relativ einfach möglich, dem Spieler mitzuteilen, was er gerade zu erledigen hat
viele Spiele machen das, indem sie transparent alle Quests mit ihrem Status in einem separaten Menü/Untermenü anzeigen, was allerdings wiedereinmal eine sehr generische Lösung ist
ein Gegenbeispiel dazu ist Zelda (auf jeden Fall mehrere Teile der Reihe, allerdings nicht unbedingt alle), wo man sich bei einem Wahrsager einen Hinweis bekommen konnte, was man als nächstes machen muss oder wo man seinen Begleiter befragen konnte (bspw. Navy, Saly oder Midna)

je nach Umsetzung kann ein Questsystem auch verhindern, dass man ein paar Rätsel einbauen kann, wie das ständige Tauschen von Gegenständen der verschiedenen Zelda-Teile, bis man zum Schluss einen sehr guten Gegenstand bekommt
ein Beispiel dafür wäre Ocarina of Time, wo man beispielsweise alle Masken an die richtigen Personen bringen musste, um zum Schluss 3 weitere Masken zur Verfügung zu haben oder der Tauschhandel der nötig war, um an das Biggoron-Schwert zu kommen (größer als das Master-Schwert und unzerstörbar im Gegensatz zu einem anderen Schwert eines anderen Schmieds der Goronen)

abschließen möchte ich sagen: ein Questsystem ist an und für sich kein Problem, allerdings verleitet es dazu, sich weniger Gedanken über eine gute Integrierung in das Spiel zu machen
letztendlich sollte es auch nur ein "Implementierungsdetail" sein

Ich würde den Vektor komplett weglassen und direkt die registrierten Quests bei einem Event aufrufen. Beim Quest-Manager würde ich meine Scripte auch nicht registrieren, sondern direkt bei den NPCs, dem Player, der World oder whatever. Je nachdem von wem ich was brauche.

mit "registrieren" ist übrigens gemeint, dass der jeweiligen Stelle für ein bestimmtes Ereignis eine Callback-Methode oder -Funktion übergeben wird, die dann automatisch beim Eintreten des Events aufgerufen wird

@BlueCobold:
das kommt auch ein wenig darauf an, wie sein Spiel bisher aufgebaut ist, aber grundsätzlich wäre es natürlich besser, einen direkten Weg zu gehen

Joar. Deswegen sagte ich ja auch, dass ich es so machen würde, nicht dass das generell mehr Sinn macht.