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)

Das ist ein kleines Beispiel? Die Wiedergabe erfolgt natürlich in ner anderen Datei oder wenn der Kampf zu Gunsten des Helden war..

Außerdem bezieht sich das nur auf Abschnitt Held Punkt 1

--Drak 20:43, 20. Nov. 2008 (CET)

Ich sehe den Vorteil davon trotzdem nicht. Soweit ich weis, ist es derzeit nicht möglich Sachen in einer Begegnung zu klauen, sie irgendwo zwischenzuspeichern und dann wiederzugeben, da es keine Variablen gibt, die länger erhalten bleiben. Und wenn es innerhalb einer Begegnung ist, dann kann man es ja durch eine Beschreibung lösen, die Sachen aber in Wirklichkeit gar nicht wegnehmen. Und wenn er sie am Ende nicht wiederbekommt kann man sie dann immer noch wegnehmen. --Tequila 22:10, 20. Nov. 2008 (CET)

Naja zum einen Macht es einen Unterschied ob der Held sich auf einmal ohne Rüstung durchschlagen muss und zum anderen Steht ja da "Gegenstände verloren blabla", also kann man so die Spieler besser schocken :-D

Und wenn die Quest Fortsetzung geht, gibt es auch Variablen die erhalten bleiben und man kann einem Dieb durch ganz Antamar nachlaufen (dämlicher Quest - aber naja)

Meinte ja nur da es als "WICHTIG" drinsteht - wenn nur einer der Meinung war kann mans ja lassen

--Drak 22:24, 20. Nov. 2008 (CET)

Also wenn es möglich ist das über mehrere Quests zu speichern, dann erscheint mir das sinnvoll und dann bin ich da auch dafür. Wobei ich mir nicht sicher bin ob man das nicht über eine Erweiterung von take machen kann, so dass man mehrere Gegenstände auf einmal hinzufügen kann. Dann bräuchte man keinen neuen Befehl. --Tequila 22:27, 20. Nov. 2008 (CET)

Kämpfe

Frei konfigurierbare NCPs. Man sollte AT / PA / RS usw festlegen können. Am besten wären auch noch Lebenspunkte, Ausdauer usw. --Hek tik

NPCs sind keine AOQML Sache, sondern systembedingt (da übergreifend für Questen, ZBs und Kampfschulen). Falls es keine passenden NPCs in der Liste gibt können aber neue angelegt werden. Solche Dinge sollten eigentlich im Forum oder auf der Diskussionsseite besprochen werden bevor sie auf die Artikelseite kommen. --qapla 22:48, 4. Apr. 2009 (CEST)

Oh, dann war ich mal wieder etwas voreilig :)

Ich probiere gerade ein bischen mit Möglichkeiten für Quests rum. Da wollte ich z.B. einen Zwerg als gegner haben.

1. Es gab keinen Zwerg in der NCP Liste
2. Es gibt keinerlei Infos über die Stärke und Eigenschaften der Gegner.
3. Wäre es kompliziert das dahingehen zu ändern, dass es auch nicht systembedingte NCPs gibt? Ich habe da leider gar keinen ::überblick in den Strukturellen Aufbau dieser Abläufe. Gibt es da irgendwas zu lesen?

--Hek tik 22:58, 4. Apr. 2009 (CEST)