Hier hatte ich Helix folgendes vorgeschlagen:

Die eigentliche Zielszene wird geschrieben, inklusive der Variablen-Abfragen.

Von der Quellszene wird auf die jeweiligen Szenen normal verlinkt. In diesen wird nur die Variable entsprechend gesetzt und das eigentliche Ziel über einen include eingebunden.

Damit hat man zwar mehr Dateien im Filesystem, aber es bleibt im Code trotzdem sehr übersichtlich ohne größere Umbauten.

Die Jagd in der Rast fragt irgendwann ab welche Waffe man nehmen will. Maximal glaube ich gibt es 5 Optionen, welche alle auf je eine Szene verlinken.

Man hat also 6 Szenen: Auswahlszene + 5 Szenen (je 1 pro Option). Wenn man den Optionen in der Auswahl bereits den jeweiligen Parameter mitgibt, brauche ich nur 2 Szenen. 1 Auswahlszene und eine Szenen mit Auswertung der Waffe.

Das was Tommek mir vorgeschlagen hat funktioniert einwandfrei und ich dachte erst es sei die Lösung, aber es macht am Ende ja doch noch 1 Szene mehr.

1 Auswahlszene + 5 Hilfsszenen + 1 Auswertungsszene.

Der Code wäre dennoch "gebündelt" in einer Szene. Daher halte ich den Featurewunsch nicht mehr für unbedingt nötig, aber falls irgendwann mal was gemacht wird, dann bitte beachten

Gerade großen Questen werden durch solche technischen Hilfsszenen unnötig unübersichtlich, daher finde ich das Feature nach wie vor sinnvoll.

Der Aufwand ist allerdings recht groß, weil nicht nur der ChoicePlayer (der Programmcode, der das choice-Tag auswertet) angepasst werden muss, sondern die Werte auch durch die URL geschleust, dann in der nächsten Questszenen-Aktivierung (quest.inc.php) aus der URL extrahiert und von dort an die QuestScene.class.php weitergeleitet werden müssen, da die Variable erst in der Ziel-Szene tatsächlich gesetzt werden, um auf die Spieler-Auswahl zu reagieren.

Ich stelle mir das am ehesten analog zu <set .../> so vor:

Code: Alles auswählen

<choice target="ziel-szene" name="variablenName" value="variablen-Wert" scope="scene"/>

Bereits geneierte Quest-Navigations-URLs müssen natürlich gültig bleiben, damit laufende Quests weiter funktionieren.

Bei dem Umbau würden einige Funktionen, die eh schon recht viele Parameter haben, mindestens einen weiteren bekommen (ich würde name/value/scope in einem Objekt zusammenfassen). Evtl. steht hier dann daher noch ein Refactoring an.