Da mir das E-Book dazu nichts verraten hat und ich dem Problem nicht so recht auf die Spur komme, wüsste ich gerne, wie ich am besten einen Questlog zurechtbastle.
Ich hab mir versucht den in Vampires Dawn 2 anzusehen, da ich es in dieser Machart ungefähr ebenfalls haben will, aber ohne Kommentare und mit diesen Massen an mir fremden Switches und Variablen werde ich nicht schlau daraus.
Hat irgendjemand ein Tutorial oder ähnliches zur Hand, das mir verrät, wie ich das aufgebaut kriege?
Danke im Vorraus für eure Mühe.
09.11.2009, 00:07
TrueMG
Och, ich denke dafür ist ein Tutorial überhaupt nicht notwendig.
Man stelle sich schlichtweg vor, dass jede Quest im Idealfall in mehrere Etappen eingeteilt ist. Hat man einen Teil der Aufgabe erledigt, soll sich das Questbuch aktualisieren, da nun der nächste Teil ansteht. Daher wäre es logisch eine einzige Quest von einer einzigen Variable abhängig zu machen. Immer wenn ein Teil der Quest erfüllt ist, wird die Variable auf den entsprechenden Wert gesetzt und im Questbuch dargestellt.
Wie man Messages oder Pictures (je wie man möchte) von einer Variable abhängig macht, solltest du ja wissen. Quests, die noch nicht angenommen sind, stehen ansonsten auf dem Wert Null und werden [für gewöhnlich] nicht dargestellt.
Oder wo genau liegt jetzt das Problem :)
[EDIT] Vergiss meinen Post. Was zur Hölle hat denn Corti da gepostet? O___O Ein Mensch mit zu viel Zeit. Aber hilfreich ist es allemal.
[Tm]
09.11.2009, 01:37
Corti
Ein richtig gutes Questlog machen ist gar nicht einfach. Das ganze ist allerdings nicht wirklich technisch kompliziert sondern eher eine Frage des Umfanges.
Den Questtext anzuzeigen und, dass man schon 10 von 15 Wölfen gekillt hat ist nicht so schwer. Die vorhandenen Quests vernünftig aufzulisten schon eher.
Dynamische Listen sind im Maker schwer zu machen.
Mit Cherrys Picturepornopatch ließe sich, sicherlich ein gutes System basteln und somit die Herausforderung Questlog grundlegend zur Parametrierungssache machen, aber das Topic hier vermittelt, dass dir wohl eine Lösung ohne exzentrische Makerpatchungen und Pointerspiele lieber wären.
Ich saug mir jetzt einfach mal was aus den Fingern wie ich wohl drangehen würde.
Teil 1: Questdaten
Variablen:
Statusvariable
0 = quest kann nicht angenommen werden
1 = Quest kann angenommen werden
2 = Quest ist angenommen und unfertig
3 = Quest ist angenommen, erfüllt abe rnicht abgegeben
4 = Quest ist abgegeben
Als nächstes die Questziele. Da die Darstellung z.B. 10/15 Wölfen und der Questtext auf eine Seite passen müssen solltest du die Anzahl der Ziele beschränken zB auf 4.
Daraus ergibt sich, dass man 5 Variablen braucht um den Fortschritt einer Quest zu verfolgen.
Statusvariable
Zielvariable 1
Zielvariable 2
Zielvariable 3
Zielvariable 4
Soviel minimal.
Zur Prüfung der Erfüllung der Ziele muss verhanden sein, was das Maximum wäre.
Den Maxwert kann man jetzt etweder mit in die Variable packen in den man in verschiedenen Ziffern speichert (#A)...
Beispiel:
150010 = 10 von 15 Wölfen gekillt
Hierzu müsste man natürlich beim Prüfen der Erfüllung die Ziffern wieder zerlegen mit Modulo.
...oder man legt sich nochmal 4 Variablen (#B) an~ oder man speicherts im Eventcode (#C) und legt dort eine Liste an, in der jede Quest geprüft wird.
Während #A fachlich am anspruchsvollsten ist, ist es dafür besser zu verarbeiten, während #C für Anfänger einfacher zu handhaben ist. #B ist ein Kompromiss aus beiden, bietet die Möglichkeit der systematischen Verarbeitung ohne dabei zu abstrakt zu werden in den Algorithmen.
Wichtig:
Bei der Anordnung der Variablen sollte System herrchen. Es hilft kein bischen, Quests in die Variablen zwischen Kampfsystem und Minigame zu quetschen um ein paar Variablen zu speichern.
Schlechtes Beispiel:
Gutes Beispiel:
Auch wenn Quest1 keine Ziel 3 und 4 hat. Macht nichts. So kann man die Questdaten systematisch ansprechen.
Wir wollen zB die Daten von Questziel 3 von Quest 2 haben, zu finden in Variable 19
Formel:
10 + (QuestNr - 1)*5 + (QuestZielNr +1)
Beispiel:
10 + (2 - 1)*5 + (3 +1) = 19
Soviel zur Speicherung der Daten.
Questfortschritt abchecken:
Questfortschritts-check passiert wenn an einer Stelle eine Quest erfüllt werden könnte z.B. Wolf geskillt, Item bekommen , Variable + 1
a) Systematischer Ansatz
Common Event bauen, dass in Abhängigkeit des Wertes einer Variable die Erfüllung der jeweiligen Quest prüft. Siehe Rechenbeispiel.
b) Einfacher Ansatz
Common Event bauen, dass als Liste dient. In dieser Liste wird jede Quest angesprochen und ihr gewährt sich zu prüfen, falls sie gerade angenommen ist (Statusvariable lässt grüßen).
Ob im Falle einer Fetrigstellung (Statusvariable ändern von 2 auf 3) eine Nachricht erscheinen soll~ Geschmackssache.
Teil 2: Quests anzeigen/durchblättern/browsen
Im einfachsten Fall kann man das Questlog als "Buch" machen, dass man durchblättert. Iconübersichtsoberflächen und dynamische Listen stellen vor Folgeprobleme, darum als EInsteigerlösung weniger empfehlenswert.
Gehen wir von der "Durchblätterlösung" aus.
Hier brauchst du wieder ein CommonEvent, dass dir die Daten einer Quest anzeigt zuerst einmal. Hintergrundbild, Text, die Zahlen 10/15 Wölfen etc.
Was das durchblättern angeht gibts wieder verschiedene Möglichkeiten.
Simpelste:
Am Anfang anfangen und Quest 1 checken, ob sie grad angenommen ist.
Wenn ja -> Infoscreen anzeigen
Wenn nein- > weiter zu Quest 2
Nach dem Anzeigen eine Tastenabfrage.
Wenn gedrückt -> weiter zu Quest 2
Wenn Quest 1 nicht vorhanden ist, oder man weiter klickt kommt man automatisch durch das ganze Questlog.
Vorteile:
Einfacher Aufbau
Überschaubar als Entwickler
Erfüllt den Zweck
Nachteile:
Falls 3 Quest angenommen sind und 3000 im System vorhanden werden viele viele unnütze Abfragen gemacht
Wenn viele Quest gleichzeitig angenommen sind kanns den Spieler nerven sich durchklicken zu müssen, besonders wenn er ungewollt die übersüringt zu der er wollte
Komfortfunktionen wie z.B. Blätterbarkeit in 2 Richtungen setzen einen anderen Ansatz voraus. Man könnte z.B. das Durchgehen der Liste von einer übergeordneten Kontrollschleife machen lassen.
Andere Ansätze wären temporäre Listen mit angenommenen Quest-Nummern, und eine Beschränkung des Questlogs auf eine bestimmte Anzahl Quests zur Zeit. Somit könnte man zwichen Nummern in der Liste springen.
Teil 3: Quest als Spieleführer
Nebenquests kann man auf diese Weise super managen, aber auch Haupthandlungen. Der Trick ist es, die Mainquests vernünftig zu formulieren.
Beispiel:
Du willst, dass die Gruppe in nem Schloss vom besten Freund verraten wird, also sollte man nicht reinschreiben [v]Verraten und verkloppt worden
sondern eher
[v]Geheimnis im Schloss untersucht.
oder irgend was in der Art. Um die Ecke denken. Questlogs können sehr hilfreich sein um den Spieler etwas an die Hand zu nehmen.
Fazit:
Ein Questlog ist vor allem dann herausfordernd, wenn man es unabhängig von der Anzahl der im Spiel vorhandenen Quests machen möchte.
Technische Kniffe setzen Knowhow voraus und verkomplizieren das System.
Das Questlog als ein Inhalt, dass eher vom Gamedesigner als vom Techniker gefüllt wird sollte somit lieber kein von Dritten produziertes Technikmonster sein. Wenn du die Daten vernünftig strukturiert wegspeicherst kannst auch im Nachinein noch ein anderes System zum Quests durchgucken draufbauen.
Tipp: Wenn du jetzt Variablen 1 bis 6000 benutzt und zwischen 2000 und 2500 noch alles frei hast, denk trotzdem nicht dran sie da hin zu packen.
Irgendwo weit weg, wo ganz viel Platz ist. Momentane PCs sterben nicht daran, dass du 20.000 Variablen anlegst.
PS: Es ist halb 3 und mein Winamp spielt irgend nen Jammersong von Simple Plan~ bääääh
09.11.2009, 21:15
Spongie *W*
Tausendfachen Dank, Corti! Mit so einer ausführlichen Erklärung hatte ich gar nicht gerechnet. Wirklich spitze von dir, das werde ich die Tage mal durchtesten, sobald ich dazu komme.
