Thread: [DSA Manager] Elfische-Weltsicht und XML
Status: Planning
Brought to you by:
alexnofftz
From: Tilmann K. <ds...@tk...> - 2002-05-12 10:17:41
|
Hi Leute! Um diesen Nachteil sinnvoll realisieren zu koennen werden wir unsere Modifikatoren etwas erweitern muessen. Ich schlage deshalb vor, dass wir anstatt einem Ziel eine ganze Zielliste und ganze ZielGruppen zulassen und zusaetzlich noch eine Liste von Zielen die widerum von den anderen ausgeschlossen werden (Genauso brauchen wir es ja auch fuer die Modifikator-Auswahlen). Bsp: <WertModifikator wert="-2" wenn="xxxxxxxx"> <Ziel>TAL_Etikette</Ziel> <Ziel>TAL_Sprachen</Ziel> (TAL_Sprachen ist id einer Ganzen Talentgruppe) <Ausser>SPR_Garethi</Ausser> <Ausser>SPR_Mutter</Ausser> </WertModifikator> (SPR_Mutter ist die zuvor in diesem XML festgelegte Id fuer die Muttersprache) Bsp in Kultur: <Muttersprache alias-id="SPR_Mutter" ziel="SPR_Rogolan"/> <Startwert ziel=SPR-Mutter" wert="EIG_KL-3"/> Damit machen die Talente und Gaben schon keine Probleme mehr Wegen der Multiplikation mit 1.5 sehe ich eigentlich keine Probleme, da es ja keine additiven Mods auf Kosten gibt, falls doch muss man die Multiplikation halt hinten anstellen. Dass die Mods erst nach der Generierung gelten muss man damit abfangen, dass in der wenn-Bedingung irgendwie nach der Generierung gefragt werden kann. Bsp: wenn="!has(EIG_TalentGP)" wenn man davon ausgeht, dass ein Held auserhalb der Generierung keine Talent_GP-Eigenschaft hat. Eine Andere Loesung waere z.B., dass man ueber eine feste Id den Charakter direkt ansprechen kann: wenn="CHARAKTER.generierung == 0". Sowas wird auch gebraucht fuer 'Akademische Ausbildung' Die Ausnahme der Elfenlieder macht auch kein Problem. Und die Zauber wuerden wenn nicht die Regel mit der Profession waere auch kein Problem darstellen, weil man dann einfach mit einer Modifikatorauswahl die Modifikation von oben neutralisieren koennte. Aber auch hier muessen wir uns noch ueberlegen wie man in der Ziele-Angabe elfen von anderen Zaubern unterscheiden kann. Das ist wirklich nicht so einfach, da die Gruppierungen wohl schon dazu verwendet werden die Zauber in logische Gebiete einzu teilen??? Zu Modifikatoren auf Einkaufskosten wie z.B. Vorteile oder Spezialfertigkeiten gaebe eine recht einfache Loesung wenn man wie oben erwaehnt Modifikatoren auf den Charakater zulaesst. Bsp: <KostenMultiplikator ziel="CHARAKTER" fuer="VNT_Vorteile" wert="2" Dies liegt daran, dass der Einkauf nacher sowieso ueber den Charakter geregelt werden muss, da dieser erstmal ueberpruefen muss, ob z.B. ein Vorteil ueberhaupt fuer ihn zulaessig ist. D.h. er muss erst mal alle seine 'VorteilBeurteiler' (z.B. Rasse, Profession, andere Vorteile) fragen, ob sie den neuen erlauben. So das wars mal fuers erste. Kritik erwuenscht... Gruss, tilmann |
From: Alexander N. <lists@AlexNofftz.de> - 2002-05-12 11:44:48
|
Hi Tilmann! > Ich schlage vor die XML-Struktur ein bischen zu erweitern, in dem man > Ueber-Gruppierungen auch Ids und Name etc vergeben kann und dass die > Gruppierung auch fuer nicht Talente zulaessig wird: Wieso kommt mir das nur so unglaublich bekannt vor? Ich hab's, das war ja schon in der DTD drin! <ggg> > Um diesen Nachteil sinnvoll realisieren zu koennen werden wir unsere > Modifikatoren etwas erweitern muessen. Ich schlage deshalb vor, dass wir > anstatt einem Ziel eine ganze Zielliste und ganze ZielGruppen zulassen > und zusaetzlich noch eine Liste von Zielen die widerum von den anderen > ausgeschlossen werden (Genauso brauchen wir es ja auch fuer die > Modifikator-Auswahlen). Genau. > Wegen der Multiplikation mit 1.5 sehe ich eigentlich keine Probleme, da > es ja keine additiven Mods auf Kosten gibt, falls doch muss man die > Multiplikation halt hinten anstellen. Die Kostenformel sollte sein: Gesamtkosten = sktFaktor * (SKT[sktSpalte][basisWert] + sktAdd) > Dass die Mods erst nach der Generierung gelten muss man damit abfangen, > dass in der wenn-Bedingung irgendwie nach der Generierung gefragt werden > kann. Bsp: wenn="!has(EIG_TalentGP)" wenn man davon ausgeht, dass ein > Held auserhalb der Generierung keine Talent_GP-Eigenschaft hat. Eine > Andere Loesung waere z.B., dass man ueber eine feste Id den Charakter > direkt ansprechen kann: wenn="CHARAKTER.generierung == 0". Sowas wird > auch gebraucht fuer 'Akademische Ausbildung' Wie wär's einfach mit der Frage nach Stufe == 0 ? > Die Ausnahme der Elfenlieder macht auch kein Problem. Und die Zauber > wuerden wenn nicht die Regel mit der Profession waere auch kein Problem > darstellen, weil man dann einfach mit einer Modifikatorauswahl die > Modifikation von oben neutralisieren koennte. Aber auch hier muessen wir > uns noch ueberlegen wie man in der Ziele-Angabe elfen von anderen > Zaubern unterscheiden kann. Das ist wirklich nicht so einfach, da die > Gruppierungen wohl schon dazu verwendet werden die Zauber in logische > Gebiete einzu teilen??? Richtig. Die Herkunft müssten wir in der Vorlage mit abspeichern, da ja früher oder später auch alle anderen Herkünfte (Auelfisch, Steppenelfisch, Waldelfisch, Firnelfisch, Wüstenelfisch, Gildenmagisch/Weiß, Gildenmagisch/Grau, Gildenmagisch/Schwarz, Borbaradianisch, Hexensprüche, Druidensprüche, Geodensprüche und natürlich alle Spezialgebiete) rein kommen werden. Für den Heldenbogen selbst ist das dann eher uninteressant, da dort ja nur noch zählt, wie man was steigern kann. Eigentlich ist das den Basis/Spezial/Beruf-Talenten so ähnlich, dass wir im Prinzip das Erweitern und dann auch für die Herkunft der Zaubersprüche heran ziehen könnten. Dann braucht man für die Professionen nur noch eine Tabelle der Art, welche Herkunft zu welchen Kosten zu steigern ist. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany Ale...@em... http://www.AlexNofftz.de Jabber: ale...@am... (Jabber?! http://amessage.de) |
From: Tilmann K. <ds...@tk...> - 2002-05-13 11:07:31
|
Hi! Alexander Nofftz wrote: > > Wie wär's einfach mit der Frage nach Stufe == 0 ? Imprinzip schon, das muss ich noch irgendwie hinbiegen, da unsere Formel die Stufe natuerlich mit 1 berechnet, wenn man 0AP hat ;-) Ich denke ich setze die AP waerend der Generierung einfach auf -12.5. > >> Die Ausnahme der Elfenlieder macht auch kein Problem. Und die Zauber >> wuerden wenn nicht die Regel mit der Profession waere auch kein >> Problem darstellen, weil man dann einfach mit einer Modifikatorauswahl >> die Modifikation von oben neutralisieren koennte. Aber auch hier >> muessen wir uns noch ueberlegen wie man in der Ziele-Angabe elfen von >> anderen Zaubern unterscheiden kann. Das ist wirklich nicht so einfach, >> da die Gruppierungen wohl schon dazu verwendet werden die Zauber in >> logische Gebiete einzu teilen??? Halt! Wer hindert uns daran in der Objektstruktur noch eine Zweite Gruppierung einzufuegen. ;-) Im xml koennte soetwas so aussehen: <Talente ID="Talnete"> <Name>Talente</> <Beschreibung>Die Talente des Helden</> <KategorieDefinition ID="TAL_Basis"> <Name>BasisTalente</> <Beschreibung>fjldfjfjfdkldjfjaf</> </> <Talentgruppe ID="TAL_Koerper"> <Name>Koerpertalente</> <Beschreibung>Blaaaaaaaaaaa</> <Talent ID="TAL_Schleichen"> <Name>Schleichen</Name> <Beschreibung> <p>Beschreibung von »Akrobatik«</p> </Beschreibung> <Kategorie ref="TAL_Basis"/> <Proben> <Probe auf="EIG_MU"/> <Probe auf="EIG_GE"/> <Probe auf="EIG_KK"/> </Proben> <Kosten SKT="4" add="0"/> <BE>*2</BE> </Talent> > Dann braucht man für die Professionen nur noch eine Tabelle der > Art, welche Herkunft zu welchen Kosten zu steigern ist. Kosten und Maximalwerte beim Start kann man mit sicherheit dann als diverse Modifikatoren realisieren, ob man die im xml jetzt in einer Tabelle ablegt kann man sich ueberlegen. Ganz so einfach wird Alles aber nicht werden, da wir zwischen XmL und Programm einige Uebereinkuenfte bezueglich diverser Ids treffen muessen. Diese habe ich im Moment in dem Interface ModelOptionen festgehalten: public static final String EIG_Stufe_ID = "EIG_Stufe"; public static final String EIG_APGuth_ID = "EIG_APGuth"; public static final String EIG_AP_ID = "EIG_AP"; public static final String EIG_TalentGP_ID = "EIG_TalentGP"; public static final String EIG_CharGP_ID = "EIG_CharGP"; public static final String EIG_GE_ID = "EIG_GE"; // Fallen evtl. noch public static final String EIG_KK_ID = "EIG_KK"; // weg! public static final String SKT_ID = "SKT_Tabelle"; public static final String TAL_Basis_ID = "TAL_Basis"; Was meint ihr dazu? Gruss, tilmann |
From: Oliver S. <wh...@us...> - 2002-05-12 16:22:03
|
Hi Leute! > Um diesen Nachteil sinnvoll realisieren zu koennen werden wir unsere > Modifikatoren etwas erweitern muessen. Ich schlage deshalb vor, dass wir [...] > So das wars mal fuers erste. Kritik erwuenscht... Kritik nicht, eher eine Frage: Wenn's eh jetzt so komplex wird, meint ihr nicht, daß Scripting dann doch Sinn macht? Das würde jetzt wirklich einiges vereinfachen. Das Konzept "nur Ausdrücke, keine Zuweisungen" wird mittlerweile sehr hart an seinen Grenzen betrieben, und der Aufwand steigt weiter an. Zudem ist es so jetzt wirklich ein Gemisch - einige Sachen in XML ausgedrückt ("wenn=", "<ausser>", ...), andere als Ausdrücke ("a ? b : c", ...), einiges nur als Wert - das ist nicht so richtig klar und konsequent. cu Oliver |
From: Matthias W. <Mat...@gm...> - 2002-05-12 21:05:31
|
Oliver Schulz wrote: > Hi Leute! > > >>Um diesen Nachteil sinnvoll realisieren zu koennen werden wir unsere >>Modifikatoren etwas erweitern muessen. Ich schlage deshalb vor, dass wir > > [...] > >>So das wars mal fuers erste. Kritik erwuenscht... > > > Kritik nicht, eher eine Frage: Wenn's eh jetzt so komplex wird, > meint ihr nicht, daß Scripting dann doch Sinn macht? > Das würde jetzt wirklich einiges vereinfachen. > Das Konzept "nur Ausdrücke, keine Zuweisungen" wird mittlerweile > sehr hart an seinen Grenzen betrieben, und der Aufwand steigt > weiter an. Zudem ist es so jetzt wirklich ein Gemisch - einige Sachen > in XML ausgedrückt ("wenn=", "<ausser>", ...), andere als > Ausdrücke ("a ? b : c", ...), einiges nur als Wert - das ist > nicht so richtig klar und konsequent. Ich finde den XML/Ausdruck - "Mix" eigentlich sehr sinnvoll. Es dient zur logischen Trennung von verschiedenen Modifikatoren Du hast auch mal gesagt, dass wir bei einem Beispiel mit deiner Variante nur einen Ausdruck, mit unserer Variante 2 Ausdrücke hätten. Jetzt frage ich dich: Was ist, wenn unsere Variante 10 oder noch mehr Ausdrücke bräuchten ? Wir erschaffen einfach eine XML-Kapselung. Dein Ausdruck wäre ziemlich lang... Und würde im Endeffekt darauf hinauslaufen, dass wir fast mehr den Arithmetik-Parser als den XML-Parser verwenden. Und jetzt frage ich dich: Was lässt sich besser warten. XML oder unser Code. Ich will mal annehmen, dass die Antwort XML lautet. Und da ich dachte, das Thema sei beendet, wollte ich es damals nicht sagen, da ich glaube, dass das O-Kalkül ohnehin völlig falsche Laufzeit-Aussagen bei dieser Geschichte macht... Aber deine Variante packts auch nur in O(n^3) (Genauer gesagt O(N*n^2), wenn man deine Bezeichner nimmt. Aber auch du bist ja von "n ~ N" ausgegangen) Aber ich will aus besagtem Grund eigentlich nicht darüber diskutieren. (Da du aber wohl wissen willst, warum: Vergleiche jeden Modifikator mit jedem Modifikatur und darin jedes Literal. -> N*n^2. Das braucht man, um die korrekte Reihenfolge zu erstellen) Ganz nebenbei denke ich, dass deine "Frage" viel zu unkonkret ist. Hast du schon bei deiner Methode versucht, Probleme wie Kosten, Muttersprache und Elfische Weltsicht zu lösen ? Du kannst da vielleicht ganz leicht einen Ausdruck erstellen. Aber das Problem bei deiner Methode ist ja eigentlich das richtige Anordnen der Modifikatoren. Und DAS wir dann erst das Problem. Deiner Wert / Ausdruck - Kritik schließe ich mich allerdings an. Auch wenn wir wahrscheinlich etwas Performance gewinnen, wenn wir NUR-Werte als NUR-ints (oder doubles) im Objekt halten, ist es von der Struktur her gesehen etwas sauberer, nur ein Ausruck-Attribute (oder wie man es auch nennen mag) zu verwenden. Ich finde es nur komisch, da eigentlich DU immer nach Performance rufst... *ggg* Gruß Matthias |
From: Oliver S. <wh...@us...> - 2002-05-13 16:46:39
|
Hi Leute! Matthias Wurm wrote: > Du hast auch mal gesagt, dass wir bei einem Beispiel mit deiner Variante > nur einen Ausdruck, mit unserer Variante 2 Ausdrücke hätten. Es geht doch im Kern nicht um Trennung verschiedener Modis - die muß man nicht zusammenführen, auch mit meiner Methode nicht. > Dein Ausdruck wäre ziemlich lang... Und würde im Endeffekt darauf > hinauslaufen, dass wir fast mehr den Arithmetik-Parser als den > XML-Parser verwenden. Wohl kaum. Es geht ja weiterhin nur um Modifikatoren. > Und jetzt frage ich dich: Was lässt sich besser warten. XML oder unser > Code. Ich will mal annehmen, dass die Antwort XML lautet. Nein, das tut sie nicht - dieser Mischmasch wird nicht leicht zu warten sein, im Gegenteil. Wir reden ja schon nicht mehr über euren ursprünglichen Code. Mittlerweile ist die Rede von Zusatzbedingungen in XML, mehreren Ziele, multiplikativen Modis, etc. Und ich sehe bei den aktuellen Erweiterungs-Vorschlägen keine klare Trennung mehr, was worin gemacht werden soll. > Und da ich dachte, das Thema sei beendet, wollte ich es damals nicht Das dachte ich auch. Dann kam die Sache mit den multiplikativen Modis auf - das war ein schönes Beispiel eines Problems, das es auch später mal unvorhergesehen geben kann. So etwas ist immer ein guter Test für ein Design. Die Leistung eures Modells in dieser Situation ist nicht so gut. > sagen, da ich glaube, dass das O-Kalkül ohnehin völlig falsche > Laufzeit-Aussagen bei dieser Geschichte macht... Aber deine Variante > packts auch nur in O(n^3) (Genauer gesagt O(N*n^2), wenn man deine > Bezeichner nimmt. Aber auch du bist ja von "n ~ N" ausgegangen) > Aber ich will aus besagtem Grund eigentlich nicht darüber diskutieren. > (Da du aber wohl wissen willst, warum: Vergleiche jeden Modifikator mit > jedem Modifikatur und darin jedes Literal. -> N*n^2. Das braucht man, um > die korrekte Reihenfolge zu erstellen) Nun, wenn man das derart macht, braucht man in der Tat O(N*n^2). Immer noch nicht langsamer als euer Modell - womit Du Deine frühere Behauptung, mein Vorgehen sei ineffizient, selbst wiederlegt hast. Das geht aber dann doch auch etwas effizienter. Man kann in O(N*n) die direkten Relationen ermitteln, und dann in O(n^2) die zum Sortieren nötige transitive Hülle bilden. Ja, man kann darüber diskutieren, ob da jeweils noch ein log(N)log(n) dazukommt - aber das ist nicht entscheidend. Was eher schon wichtig ist: Der ganze Kram muß nur einmal gemacht werden, und nicht bei jeder Auswertung. > Ganz nebenbei denke ich, dass deine "Frage" viel zu unkonkret ist. Hast > du schon bei deiner Methode versucht, Probleme wie Kosten, Muttersprache > und Elfische Weltsicht zu lösen ? Du kannst da vielleicht ganz leicht Ich bin nicht sicher ob das geht - Hinweise von den Regelspezialisten erbeten ... Man hätte die Möglichkeit, Kosten und Werte beliebigen und bedingten Modifikationen zu unterwerfen. Reicht das? > einen Ausdruck erstellen. Aber das Problem bei deiner Methode ist ja > eigentlich das richtige Anordnen der Modifikatoren. Und DAS wir dann > erst das Problem. Das hatten wir doch schon x-mal. Warum behauptest Du immer wieder, das Anordnen der Modis sei bei meinem Modell ein Problem? Ich hab doch bereits mehrfach auch die einfache Lösung dafür vorgestellt, und Du hast nie ein Argument gebracht, warum sie nicht funktionieren sollte. > auch nennen mag) zu verwenden. Ich finde es nur komisch, da eigentlich > DU immer nach Performance rufst... *ggg* ??? Ich hab mich doch lediglich gegen Deine stete Behauptung verteidigt, meine Lösung sei ineffizient. Ich hab schließlich selbst geschrieben, daß die GUI eh den Löwenanteil der Performance frißt, und daß die Rechenperformance daher nicht so wichtig ist. :-) cu Oliver |
From: Matthias W. <Mat...@gm...> - 2002-05-14 07:12:40
|
Oliver Schulz wrote: > >>auch nennen mag) zu verwenden. Ich finde es nur komisch, da eigentlich >>DU immer nach Performance rufst... *ggg* > > > ??? Ich hab mich doch lediglich gegen Deine stete Behauptung > verteidigt, meine Lösung sei ineffizient. Ich hab schließlich > selbst geschrieben, daß die GUI eh den Löwenanteil der > Performance frißt, und daß die Rechenperformance daher nicht > so wichtig ist. :-) > a) Das was ich gesagt habe, bezog sich auf das stetige anwenden eines Ausdruck-Tags statt Teilung wert / ausdruck und hatte gar nix mit deiner Methode zu tun. b) Ich habe nie behauptet, deine Methode wäre "ineffizient". Ich habe nur als Manko genannt, das wir häufig den Artihmetik-Parser verwenden müssten. Aber da sich das sicher auch umgehen lässt, dann ist halt deine Methode SUPER-effizient... zufrieden ? Und was ich deiner Methode aber wirklich zugute halten muss, ist dass nach einem Durchlauf durch alle Modi-Anweisungen wirklich ALLE Werte aktualisiert sind. Es ist halt die Frage, wie stark die Verflechtungen im Regelwerk sind (oder genauer gesagt, bei der Instanz eines Charakters). Müssen bei der Änderung eines Wertes fasst alle anderen berechnet werden, oder eher wenige ? Das ist wohl schwer abzuschätzen... Es gibt auch bei uns Methoden, Performance rauszuholen, die letzten Endes auf eine ähnliche Art hinauslaufen (Bei Änderung eines Wertes Bestimmung aller abhängigen Werte aus einer Matrix, Einführung einer hasChanged() Methode, um keinen Rekursionsschritt tiefergehen zu müssen...) Was MIR jetzt mittlerweile auch nicht so gefällt, ist das <KostenMultiplikator> - Tag, dass also quasi der Modi-Typ (ob Kosten, Basiswert, oder Effektivwert) und Operation (*,+) als Information in das Tag gemixt werden. Naja, ich muss jetzt los, schreibe nachher vielleicht noch was. Gruß Matthias |
From: Tilmann K. <ti...@tk...> - 2002-05-14 16:40:32
|
Hallo! Matthias Wurm wrote: > Was MIR jetzt mittlerweile auch nicht so gefällt, ist das > <KostenMultiplikator> - Tag, dass also quasi der Modi-Typ (ob Kosten, > Basiswert, oder Effektivwert) und Operation (*,+) als Information in das > Tag gemixt werden. Dann nenn ihn doch einfach <Multiplikator> ;-) das war doch nur so hingeschrieben. Hat ja niemand behauptet, dass der Tatsaechlich so heissen muss. Oder nenn ihn <Relation typ="KostenModifikator" ziel="VNT_Vorteile" mult="1.5"/> oder wie auch immer. Worueber wir uns eigentlich einigen sollten ist 1. Fuer was alles wir multiplikative Modifikatoren zulassen wollen 2. Wie sie zu handhaben sind (hintenanstellen nach den additiven) Zu 2. sind wir uns ja mit dem Hintenanstellen denke ich einig. Zu 1. wuerde mich mal eure Meinung interessieren. Brauchen wir mutliplikative nur fuer Kosten oder auch fuer alles andere? Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-13 12:26:37
|
Tilmann Kuhn wrote: > Zu Modifikatoren auf Einkaufskosten wie z.B. Vorteile oder > Spezialfertigkeiten gaebe eine recht einfache Loesung wenn man wie oben > erwaehnt Modifikatoren auf den Charakater zulaesst. Bsp: > > <KostenMultiplikator ziel="CHARAKTER" fuer="VNT_Vorteile" wert="2" > Denkste! Das ist gar nicht so einfach, weil man Zielgruppen und Auschluesse nur mit viel Aufwand extrahieren kann. Mir ist aber eine bessere Loesung eingefallen: Wir erzeugen einfach fuer alles was man kaufen kann (Rasse, Kultur, Profession, Vorteile, Spezialfertigkeiten) keine normalen Wrapper im Helden sondern solche, die nur zum kaufen geeignet sind. Wird dann einer gekauft wird er zu einer vollwertigen Rasse, Kultur,... Der Einkauf muss dan nicht mehr ueber den Charakter laufen und die Kaufkostenberechnung mit Modifikatoren macht auch keine Schwierigkeiten mehr. Ein weiterer Vorteil davon waere, dass man sich ohne Probleme anzeigenlassen kann, was man gerade kaeuflich erwerben kann. Gruss, tilmann |
From: Tilmann K. <ds...@tk...> - 2002-05-13 23:11:05
|
Tilmann Kuhn wrote: > Zu Modifikatoren auf Einkaufskosten wie z.B. Vorteile oder > Spezialfertigkeiten gaebe eine recht einfache Loesung wenn man wie oben > erwaehnt Modifikatoren auf den Charakater zulaesst. Bsp: > > <KostenMultiplikator ziel="CHARAKTER" fuer="VNT_Vorteile" wert="2" Komisch dass es noch keiner gemerkt hat. Das ist natuerlich Quatsch. Man sollte schon wie Oliver es sagt zwischen xml und Implementierung trennen. Deshalb muss es heissen: <KostenMultiplikator ziel="VNT_Vorteile" wert="2"/> Wenn der Charakter als ziel angesprochen werden sollte ist das natuerlich von der Implementierung umzusetzen nicht vom xml ;-) Gruss, tilmann |