Diskussion:Featurewünsche AOQML

Zufallsauswahl

Bei der Prozentverteilung sollte man vielleicht eher einen ProzentBEREICH (01 bis 37%) statt einer Prozentzahl (37%) eingeben, da sonst mehrere Ereignisse gleichzeitig eintreten können oder einfach gar nichts passiert. Oder irre ich mich da? --Neonix 14:47, 10. Jun. 2008 (CEST)

Beispiel: Switch --Drak 17:49, 20. Nov. 2008 (CET)

Besser noch ohne Prozentdefinition sodern Anteilig. Keine Angabe = 1, ansonsten den Valuewert.--Inanna 15:26, 10. Jun. 2008 (CEST)

Questunterbrechung

Die möglichkeit eine andere Quest als vorbedingung ermöglicht eine umfangreiche Verzweigung. --Inanna 00:55, 14. Jun. 2008 (CEST)

Das könnte man z.T. auch mit Questgegenständen regeln, wenn die denn da sind. Aber eine der beiden Lösungen wäre für Midiquests schon sehr sinnvoll. --Neonix 08:23, 14. Jun. 2008 (CEST)

Man muss sich jetzt aber nicht unbedingt in etwas verrennen, viele "übergreifende" Quests sind nicht auf solch eine Funktion angewiesen. Man muss sich nur in die Lage der Personen versetzen und die Kommunkitaionsmöglichkeiten bedenken. zB. könnte man in einem Ort von einem Händler die Information bekommen, dass weiter nördlich ein Rudel Wölfe sein Unwesen treibt. Reist man jetzt dorthin bekommt man eine Quest "Wölfe verjagen". Beides kann völlig unabhängig geschehen, man könnte also aus dem Norden kommen, selbiges schon erledigt haben. Der Händler weiß dies natürlich noch nicht, warnt dich aber trotzdem. Beides ist weiterhin schlüssig. --Tommek 14:41, 1. Jul. 2008 (CEST)

Ja, aber bislang gibt es ja noch nicht einmal ortsfeste, ständig verfügbare Questen, oder? Und irgendeine Form der Datenübertragung ist schon SEHR sinnvoll, damit die Questen besser mit den Helden interagieren. So könnten Helden z.B. beim zweiten Besuch bei einem NSC wiedererkannt werden, statt immer den selben unpassenden Eingangstext zu erhalten. Und vor allem könnten Teilquesten einer Midiqueste dann wesentlich besser aufeinander aufbauen, als nur durch Quest A weist auf unabhängiges Quest B hin. Quest A ermöglicht dann Quest B, wenn bestanden dann Quest C Variante 1, wenn nicht dann Quest C Variante 2 und so weiter. Somit könnte man echte kleine Kampagnen mit durchgehender Story und dauerhaft vorhandenen NSC aufbauen, die Antamar echt bereichern, den einzelnen Orten und Regionen viel mehr Würze geben und von den Spielern als Institution verstanden werden statt als beliebige Zufallsqueste. --Neonix 15:39, 1. Jul. 2008 (CEST)

Man muss doch nicht immer ein zweites mal zu dem selben NPC. Da gibt es doch unendliche Möglichkeiten. Ich versuche mich auch von diesen sklavischen Vorgaben aus all den schlechten Rollenspielen zu lösen "Auftraggeber -> töten -> Auftraggeber -> Belohnung". Ortsfeste, ständig verfügbare Questen sind bereits möglich. --Root 19:42, 1. Jul. 2008 (CEST)

Nein, man MUSS nicht immer. Aber man KANN MOMENTAN NICHT und das stört mich, weil ich es in meine Questen einbauen möchte. Und glaube mir, die können durchaus etwas elaborierter werden als "Bringe mir 5 Rattenschwänze und du bekommst Gold" wenn ich die nötigen Mittel bekomme. Eingeschränkte Möglichkeiten (denn sie sind eben definitiv nicht unendlich) sind vielleicht eine Herausforderung, aber mit Sicherheit kein Bonus! Ich MÖCHTE nun mal NSC einbauen, mit denen die SC so was wie eine minimale Beziehung aufbauen und die nicht nur in einer Queste auftauchen und dann wieder verschwinden oder, schlimmer noch, immer wieder auftauchen ohne auf die SC einzugehen. Und das Schema Auftraggeber --> Auftrag --> Reaktion des Auftraggebers gibt es, weil es bewährt ist und funktioniert, nicht weil alle Spieledesigner so unkreativ sind. Klar kann ich auch mit den bisherigen Mitteln Questen schreiben, und durch Questgegenstände auch ein Minumum an Datenübertragung herstellen. Aber es ist schlicht und einfach unelegant, störanfällig, stark eingeschränkt und daher nur eine Notlösung. Ich möchte den Spielern Kampagnen, mehrteilige Storys und vielleicht sogar etwas Metaplot liefern. Nette kleine Einzelerlebnisse bieten schon die ZB - und davon habe ich ja wohl schon genug verfasst. --Neonix 20:04, 1. Jul. 2008 (CEST)

Ja klar, ich wünsche mir die Möglichkeiten auch, nur kamen im Forum dann bei mir die falschen Gründe an. Dachte eben, dass es nur um soclhe einfach gestrickten Dinge gehen soll. Das war keineswegs als Kritik gedacht ;) --Root 20:21, 1. Jul. 2008 (CEST)

OK. Bin nur leicht genervt, weil ich wieder mal mehr Pläne als Möglichkeiten habe. --Neonix 20:31, 1. Jul. 2008 (CEST)

Benutzer:Lowlander 11:20, 18. Aug 2008 (CEST): Quest-Unterbrechnung ist von der Idee schon vorbereitet. Und war so: Ein Quest kann in den Status pending gesetzt werden (Tabelle usr_held_quest_status_), zudem wird in diese Tabelle ein obstacle eingetragen. Dieses Obstacle ist erstmal ein (programmatischer) Text, wir müssten hier noch festlegen, was es sein soll, z.B. SQL, AOQML oder auch nur eine AOQML-Expression (was z.B. in einem <if ...> statt des ... dort steht). in quest.inc.php würde dann am Anfang abgefragt, ob die Bedingung erfüllt ist, wenn ja, ginge es weiter in dem Quest, wenn nicht, ginge es weiter wie jetzt in quest.inc.php (herausfinden, ob ein neues Quest gestartet werden soll). Das gespeicherte Obstacle sollte nur einfache Bedingungen enthalten, komplexe Bedingungen sollte man dann in der Fortsetzungs-Szene abfragen und ggf. sofort wieder in den Status pending zurückfallen - ggf. ohne dass der Spieler überhaupt merkt, dass der Code ablief. Vielleicht traut sich das ja schon jemand zu, das einzubauen?

Prioritäten

Ich habe mal die Wünsche nach Wichtigkeit neu geordnet. Dabei habe ich die für Midi-Questen wichtigen Sachen nach oben gepackt, die für die weiteren Questfunktionen in die Mitte und die Gimmiks nach unten. Bitte reißt mir nicht den Kopf ab, wenn ich eure Einträge nach unten verbannt habe... Wer anderer Meinung ist, darf und soll das hier kund tun, damit wir das dann überarbeiten können. --Neonix 08:44, 30. Jun. 2008 (CEST)

Kontinuität und Übersicht

Eine klarere Definition wann z.B. quality und wann attribute benutzt werden muss wäre schön. Mal scheint es attribute für alles außer Eigenschaften zu gelten, mal wird quality für AP-Vergabe genutzt, mal attribute. Ähnliches gilt bei Abfragen für Kultur und Rasse - und da gibt es noch eine unschöne Stelle. Warum wird die Kultur mittels attribute="Kultur", die Rasse aber mittels quality="race" abgefragt? Auch hier würde ich eine Art bevorzugen und auch eine Sprache (also culture und race oder Kultur und Rasse). Wenn ich es richtig im Kopf habe wird an manchen Stellen sogar mittels name="irgendwas" abgefragt... Das hat sicherlich keine Top-Priorität, sorgt aber immer wieder für Verwirrung und erschwert das Schreiben doch beträchtlich. Falls jemand solche Dinge an einer zentralen Stelle im Wiki endgültig als korrekt (und das vielleicht auch noch einheitlich) auflistet würde ich auch alle unpassenden Stellen suchen und überarbeiten. --Qapla 23:23, 16. Aug. 2008 (CEST)

Gegenstände entfernen und zwischenspeichern

Wie wär es mit Drop + Replay (take fänd ich da nicht sooo gut, da es ja mehrere Gegenstände sein können)

Also in etwa:

<p>Ein Goblin klaut dir alles</p>
<Drop item="*100%" name="alleGegenstaende" /><!--Einkassieren-->
<p>Du findest das nicht so toll, versohlst ihm den Popo und packst dein Zeug wieder ein.</p>
<replay name="alleGegenstaende"/><!--Rückerstattung-->

@Lowlander: Ist doch auch nur Speichern? (Namen der Gegenstände die per Drop entfernt werden)

Replay würde sich halt ganz anders Verhalten..

--Drak 17:26, 20. Nov. 2008 (CET)

Warum willst du sie überhaupt wegnehmen? Da das eh erst am Ende angezeigt wird ist es doch egal, ob du sie nimmst und dann wiedergibst. --Tequila 20:32, 20. Nov. 2008 (CET)