Jump to content
Unity Insider Forum

Questfortschritt


chrische5

Recommended Posts

Hallo

 

Ich habe mal eine allgemeine Frage: Ich habe mir ein Questsystem gebaut und das funktioniert so, wie ich mir das vorstelle. Den Fortschritt innerhalb der Quests kann ich gut nachvollziehen und speichere ich als enum. Wir handhabt ihr aber das Problem des allgemeinen Fortschritts. Also zum Beispiel, wenn der Spieler ein NPC anspricht, so reagiert dieser ja abhängig von dem Gesprächen vorher, den abgeschlossenen Quest usw. Da fehlt mir gerade die Idee, wie ich das umsetzen sollte. Ich dachte zuerst auch wieder an ein enum mit den jeweiligen Zuständen, aber so richtig elegant scheint mir das nicht zu sein. State Machine wäre auch eine Möglichkeit, aber das würde ja elendig viele States bedeuten. Gibt es da einen ausgetretenen Weg oder probieren da alle individuell?

 

Christoph   

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

 

Ich bringe das hier noch einmal nach vorn. Habe ich die Frage schlecht formuliert? Versteht ihr mein Problem? Es werden doch hier sicher schon einige Leute Spiele mit Quests geschrieben haben. Da muss man doch irgendwie den Gesamtfortschritt tracken. Wie habt ihr das gelöst?

 

Christoph 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also ich habe jetzt noch kein komplexes Questsystem erstellt. Ich würde mir aber wahrscheinlich vorher überlegen, wie weit ich verzweigen würde und mir dann ein oder auch mehrere Punktesystem(e) bauen.
Eine Quest kann dann nur mit einer gewissen Anzahl Punkte begangen werden und der Abschluss einer Quest bringt dann eine gewisse Anzahl von Punkten oder zieht auch welche vom Konto ab.

Z.B. eine Quest die nicht erledigt wurde bringt einen Minuspunkt. Eine, die erledigt wurde aber vielleicht zu lange gedauert hat, bringt 0 Punkte und eine, die in der Zeit erledigt wurde, bringt einen Punkt.
Es würden unterschiedliche Questpools da sein, die alle eine Mindestpunktzahl benötigen würden. Man würde gewisse Quests erst dann bekommen, wenn genug Punkte gesammelt wären. Und natürlich leeren sich die Pools.

Ja und jetzt kommt das Problem. Das kann nämlich ausarten! Vielleicht gibt es mehrere Fraktionen, die die alle Quests geben würden, aber ein erledigen einer Quest für Fraktion A würde dein Ansehen für Fraktion B schmälern.

Deswegen würde "Ich persönlich" mehrere Punkte zählen. Für jede Fraktion extra. Es gäbe dann ein Ansehen für Fraktion A mit +15 Punkten und ein Ansehen für Fraktion B mit -10 Punkten und vielleicht ein Ansehen für Fraktion C mit +2 Punkten.

Jetzt könnte es auch noch Punkte für einzelne Questgeber selbst geben. Der Questgeber würde dir ne Quest geben, wenn du genug Punkte für seine Fraktion hast. Aber vielleicht würde er dir nur ne Folgequest geben, wenn du die erste Quest gut ausgeführt hast. Du müsstest also bei ihm extra Punkte sammeln.
Es kann genauso gut sein, dass du gewisse Quests bei einem gewissen Questgeber nur bekommst, wenn du etwas ganz Bestimmtes schon erledigt hast, was aber von einem ganz anderen Questgeber verlangt wurde.
Diese Quests könnten für die Fraktionen neutral sein oder auch da zählen.
Es wird also immer aufwendiger und man muss sich genau überlegen wo denn die Info gespeichert werden soll.

Ich würde die Punkte der Fraktionen beim Player speichern. Der Questgeber fragt diese Punkte ab. Die Punkte wären also eine Eigenschaft des Players.
Aufbauende Quests müssten beim Questgeber gespeichert werden. Oder eben einer definierten Gruppe von Questgebern. Das könnten dann auch ganz einfache Zahlen sein.

Ich hätte also einige einfache Varibeln beim Player, einige Variablen für die Questgeber(gruppen) und mehrere Listen oder Dictionarys mit Quest je nach Status des Players und Spielgeschehens.

Und das kann natürlich alles noch viel feiner werden. Wenn du z.B. "bringe Dies, Das und Jenes" in einer Quest drin hast, dann könnten Teilergebnisse ja auch irgendwo abgelegt werden müssen. Wäre dann beim Player, weil er hat's ja erledigt.

Na ja.

Keine Ahnung, ob ich dir damit einen Impuls geben konnte.
Ich würde jedenfalls mit Zahlen arbeiten und Bedingungen schaffen ab welcher Zahl was angezeigt oder freigeschaltet werden soll. Ganz so wie bei einem Rollenspiel wo auch alles über Zahlen geregelt ist, die Rahmenbedingungen aber einmalig zu Beginn festgelegt wurden.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also hab sowas auch noch nicht gemacht, aber was @malzbieüber Punkte Sytem schreibt, finde ich nicht besonders gut.Was ist wenn man für einige Queste zu lange braucht und man immer 0 bzw. -5 Punkte bekommt, dann kann es sein, das man irgendwann so wenig Punkte hat, das man keinerlei Queste mehr bekommt.

Ich würde da ganz einfach auf Int Variablen setzen.

Dann könnte man mit mehreren Int Variablen auch alles in Gruppen aufteilen wie Z.B. Region, Stadt, Questgeber und gegebene Antworten usw.

Ich hab da mal was einfaches gemalt. Nun gilt es diese Verknüpfungen per Script zu lösen. Da wäre eine einfache If Verschachtelung oder Case abfragen Sinnvoll. Hab bissel Code geschrieben und nun voll den Faden verloren. Aber sowas würde ich machen. Für Questgeber Int Variablen könnte man auch die Namen der Questgeber verwenden. Aber da würde man schnell Probleme bekommen, wenn man z.b. den Questgeber Hans mit Natalie tauschen würde, da ist eine Zahl doch besser.

Public Static int Questgeber = 1;
Public Static int Antwort = 0;

if(Questgeber == 1) //Erster Questgeber
{
...Antwort 1 und Questgeber 2
...Antwort 2 und Questgeber 3
}

if(Questgeber == 2) //Zweiter Questgeber
{
if(Antwort == 1)
{
Code...
}
if(Antwort == 2)
{
Code...
}
}
usw.

Questgeber.jpg.b97160f532342f1d90550e69c0ffd563.jpg

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also... da musst du dir am besten erstmal (nochmal mehr) bewusst machen, wie das überhaupt oberflächlich funktionieren soll. Dann kannst du das vermutlich am besten in eine Code-Form gießen.

Schau dir z.B. Cyberpunk 2077 an: https://cyberpunk.fandom.com/wiki/Double_Life

Da steht im Wiki direkt, wie deren Questsystem grundlegend funktioniert: Als Baum.

grafik.png

Es gibt eine vorhergehende Quest und diesem Fall zwei nachfolgende Quests. Es kann auch Quests mit mehreren vorhergehenden Quests geben. Es gibt daher zwei Möglichkeiten:

  1. Wenn du also eine Quest abschließt, wird geschaut, welche neuen Quests dadurch verfügbar werden, oder
  2. Wenn du nach Quests suchst, wird geschaut, was alles abgeschlossen ist, und es wird eine entsprechende Liste an verfügbaren Quests gefiltert.

Da man immer irgendwie von NPCs kontaktiert wird, wenn es wieder etwas neues zu tun gibt, können wir bei CP2077 von Variante 1 ausgehen.

Du hast also eine Quest und die wird abgeschlossen. Jetzt muss dein Programm davon ausgehend ermitteln, welche Quests als Nachfolger aktiviert werden. Oder ganz stump ausgedrückt: Quest → Nachfolgequests

Es scheint sowieso sinnvoll, wenn du deine Quests als Objekte hast. Es bieten sich, wie so oft, ScriptableObjects an. Und aus dieser Beobachtung hier schließend, scheint es wiederum sinnvoll, wenn jedes Questobjekt eine Liste mit Nachfolgerquests hat. Wird die Quest abgeschlossen, ruft dein Questobjekt als Konsequent bei den Nachfolgequests auf, dass sie nun freigeschaltet sein sollten. Wird natürlich etwas komplexer, wenn mehrere Quests gleichzeitig Vorbedingung sein können.

Das wäre so das Beispiel, wie man das machen kann, wenn man das so wie in Cyberpunk haben will. Die haben noch ein bisschen mehr; die Quest "They Won't Go When I Go" zum Beispiel hat unterschiedliche Enden. Welches Ende man kriegt, hängt von einer unsichtbaren Punktzahl ab, die man in der gesamten Questline mit seinen Entscheidungen beeinflusst. Die Questline sieht immer gleich aus, aber man hätte das sonst auch so machen können, dass man aufgrund der Punktzahl eine Quest mehr oder weniger am Ende hat. Wenn man so etwas macht, kann's natürlich beliebig komplex werden.

Wenn Cyberpunk gar nicht so funktioniert, wie du das für dein Spiel haben willst, dann sind wir wieder bei meine initialen Aussage: Mache dir bewusst und dokumentiere am besten genau, was du überhaupt willst.

vor 2 Stunden schrieb Sir_Mathew:

Da wäre eine einfache If Verschachtelung oder Case abfragen Sinnvoll.

Nein. Einfach nein. So ein Code ist immer eine schlechte Idee. Kaum wartbar und extrem fehleranfällig.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 23 Minuten schrieb Sascha:

Nein. Einfach nein. So ein Code ist immer eine schlechte Idee. Kaum wartbar und extrem fehleranfällig.

Na ich dachte mir, für ein kleines Spiel wäre das schnell umzusetzen. Glaub kaum das er World of Warcraft nachbautB)

Deine Idee hört sich auch super an. Statt werte weiter zu geben, einfach von Questgeber aus, andere Questgeber freizuschalten.

Auf diese art ist es dann auch ein leichtes, wenn man z.b. beim Questgeber 45 einen weiteren Questpfad anzulegen.

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

 

Hah. Genau auf solch eine Diskussion hatte ich gehofft. Meine erste Idee war so ähnlich, wie die von @Sir_Mathew. Das artet aber total aus, ist kaum lesbar und extrem frickelig. Die Idee von @malzbie klingt auch spannend, aber am Ende der Lektüre rauchte mir schon der Kopf, weil es eben so schnell so kleinteilig wird. 

So @Sascha das beschrieben hat, klingt es gut. Die Quest sind bei mir eh alle SO und da ist es natürlich ein Leichtes Vor- und Nachgänger reinzubauen. Dann könnte man noch verschiedene Bäume nehmen. Zum Beispiel: Main, Fraktion A, Fraktion B, usw. Das klingt sehr gut und ich werde es gleich mal probieren. Danke an euch. 

 

Christoph

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

@Sir_Mathew Wegen dem Punktesystem und den möglichen Negativpunkten, die eine weitere Quest verhindern könnten:
Ja, das muss man natürlich im Auge behalten und sein Punktesystem so aufbauen, dass ein "abgeschlossener" Auftrag für einen Questgeber nicht negativ berechnet wird. Jedenfalls nicht für diesen Questgeber. :)

Ich komme aus einer Zeit, wo es in einem Spiel durchaus möglich war komplett zu versagen. Die alten Sierra Games, wie Larry oder SpaceQuest haben einen in den A*** getreten, wenn du einen Fehler gemacht hast. 😀

War ja nur so ne Idee, wie man es machen könnte.

Link zu diesem Kommentar
Auf anderen Seiten teilen

@malzbie Ahso, sowas gab es mal?

Aber eigentlich auch wieder eine gute Idee. Hat man sich auf dem weg zum Olymp sich falsch entschieden, muss man von vorne Anfangen.

vor 21 Stunden schrieb chrische5:

Hah. Genau auf solch eine Diskussion hatte ich gehofft

Hast ja danach gebettelt. :D

Hätte sogar noch eine Idee zum Questsystem.

Aber erstmal, wie kann man denn von einen Script aus, ein anderes Script Starten?

Weil das wäre meine Idee.

Jeder Questgeber hat sein normales Script.

Und je nach Antwort beim Questgeber, werden die Scripte von den Questgebern gestartet, die freigeschaltet werden sollen.

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

 

Du meinst, jeder Questegeber hat die Quests, die er vergibt bei sich? Und woher weiß er, welcher gestartet wird? Dann sind wir ja wieder bei tausend abfragen. Die Idee des Baums scheint da deutlich besser. Zumal man eine Zentrale hat, die die Quest speichert. Wenn man dann noch verschiedene Questbäume hat, wird das ganze schon cool. 

 

Was meinst du mit scrupt starten? Eine Methode? Na wenn diese public ist, ruft man sie auf.

 

Christoph

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dachte mir schon das jeder seine Quest dabei hat. Nun gut, weiß zwar nicht wie sonst, hab sowas auch noch nie gemacht. War nur so eine Idee. 

So mit dem Script starten. 

Da dachte ich mir, das Script vom Questgeber 2 wird erst bearbeitet, wenn Questgeber 1 es startet. Also das Script z.b. einfach im Ordner lassen und niemanden zuweisen, aber im Script ist Questgeber 2 zugewiesen. Nun startet Questgeber 1 das Script von Questgeber 2 und somit wird Questgeber 2 freigeschaltet. Weiß echt nicht wie ich das richtig erklären soll. Ich denke du machst das schon. Zum Glück werde ich in naher Zukunft kein Quest System nutzen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...