Thread: [DSA Manager] Grammatik =?ISO-8859-1?Q?f=FCr_math=2E_Ausdr=FCcke?=
Status: Planning
Brought to you by:
alexnofftz
Menu
▾
▴
dsaman-list
|
From: Matthias W. <Mat...@gm...> - 2002-04-29 18:40:34
|
Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen, oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das vorgestellt habt ? Gruß Matthias |
|
From: Oliver S. <os...@ep...> - 2002-04-30 03:13:04
|
Hallo Leute! > Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr > euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen, > oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das > vorgestellt habt ? Da im CVS nix gefunden habe, hab mal einen Entwurf gemacht (siehe data/dsascript-grammar.txt). Das Ganze ist an der bisherigen Diskussion hier in der Mailingliste orientert, und sollte in etwa abwärts-kompatibel zu Ingberts Parser sein. Die definierte Sprache geht allerdings deutlich darüber hinaus, und bietet z.B. bedingte Ausdrücke, strings und Variablen der Form "MR.effektiv.xyz". Dennoch sollte sich die Sprache mit einem Parser-Generator problemlos handeln lassen. Die Grammatik ist mit flex/bison getestet, LALR(1) und konfliktfrei. Da alles sehr an C++, Java & Co. angelehnt ist, sollte sie auch recht intuitiv zu benutzbar sein. Ich hoffe, mit einem Ansatz in der Richtung kriegen wir dieses verflixte Regelwerk in den Griff. ;-) cu Oliver |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 07:09:35
|
Oliver Schulz wrote:
>Hallo Leute!
>
>
>
>>Das mit der BNF ist ne gute Frage... Ich weiß selber nicht, auf was ihr
>>euch geeinigt hab. Ist im CVS-Baum irgendeine Spezifikation hochgeladen,
>>oder eine Beispiel-XML, anhand derer ich sehe, wie ihr euch das
>>vorgestellt habt ?
>>
>>
>
>Da im CVS nix gefunden habe, hab mal einen Entwurf gemacht
>(siehe data/dsascript-grammar.txt).
>Das Ganze ist an der bisherigen Diskussion hier in der Mailingliste
>orientert, und sollte in etwa abwärts-kompatibel zu Ingberts Parser sein.
>Die definierte Sprache geht allerdings deutlich darüber hinaus,
>und bietet z.B. bedingte Ausdrücke, strings und Variablen der Form
>"MR.effektiv.xyz". Dennoch sollte sich die Sprache mit einem
>Parser-Generator problemlos handeln lassen.
>Die Grammatik ist mit flex/bison getestet, LALR(1) und konfliktfrei.
>Da alles sehr an C++, Java & Co. angelehnt ist, sollte sie auch recht
>intuitiv zu benutzbar sein.
>Ich hoffe, mit einem Ansatz in der Richtung kriegen wir dieses verflixte
>Regelwerk in den Griff. ;-)
>
>
Im Entwurf beim Thorwalerbeispiel werden wieder ein paar Probleme deutlich:
Ich würde z.B. (auch wenn dies im neuen Regelwerk nicht mehr zutrifft,
aber angenommen es wäre noch so), diesen Sachverhalt als eine Art
bedingten Modifikator in die Rassendeklaration des Thorwalers schreiben.
Und es war doch auch so, dass der Effektiv-Wert die "letzte Instanz"
war, also das der quasi aus allen Basis-Wert und den Modis berechnet
wurde, oder ? Dann würde ich auf keinen Fall den Effektiv-Wert nochmal
ändern.
Dann hätte ich da noch einige Fragen, aber die lasse ich vorerst mal,
weil ich mich selber erst wieder in das Modell einarbeiten muss. Nur
noch eines, und zwar die Arithmetic-Item-Geschichte /
Ausdruck-Geschichte: Vielleicht am Beispiel der AT:
<Talentgruppe id="BspHeld_TagBewaffnet">
<Name>Bewaffnet</Name>
<Talent ref="TalSpeere">
<Wert effektiv="7">7</Wert>
<AT>
<Wert effektiv="10">4</Wert>
</AT>
</Talent>
...
Die 7 steht ja für den TaW, die effektiv-7 kommt dadurch, dass kein Modi
die 7 verändert.
Unter AT haben wir die 4, dazu kommen die 6 Basis-AT, die weiter oben
stehen, macht 10.
<Eigenschaften ref="EigAbgeleitet">
<Eigenschaft ref="EigBasisAT">
<Wert effektiv="6">0</Wert>
</Eigenschaft>
Hier haben wir schon ein klassisches Beispiel der Verkettung. Die
EigBasisAT muss berechnet werden, danach kommt die EigBasisAT auf die AT
des Talents drauf.
Ich denke, dass es darauf hinauslaufen muss, dass wir eine
Vorberechnungs und eine Endberechnunsphase haben. Ich werde nachdem ich
wieder von der Uni heimkomme mal ein Bildchen machen, um das zu
verdeutlichen, wie ich mir es vorstelle.
Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten
nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja
bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie,
sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE,
Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets _totale_
Funktionen verwenden, sonst gibts Ärger.
Damit fällt das Beispiel von Oliver (ich meine MR.effektiv =
(rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das
Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die
wir woanders noch festhalten müssen. Denn welche MR soll genommen werden
? Die modifizierte ? Ja, denn das Ziel ist ja der effektiv-Wert. Da gibt
es sicherlich irgendwann einen Konflikt, wo wir eine vertauschte
Reihenfolge bräuchten. Naja, ich muss mich jetzt aufmachen, ich hoffe,
ich konnte klar machen, wo meine Bedenken sind.
Gruß
Matthias
|
|
From: Oliver S. <wh...@us...> - 2002-04-30 12:26:47
|
Hallo Leute! Matthias schrieb: > Im Entwurf beim Thorwalerbeispiel werden wieder ein paar Probleme deutlich: > Ich würde z.B. (auch wenn dies im neuen Regelwerk nicht mehr zutrifft, > aber angenommen es wäre noch so), diesen Sachverhalt als eine Art > bedingten Modifikator in die Rassendeklaration des Thorwalers schreiben. Die Beispiele sollten reine Sprachbeispiele sein, noch keine konkreten Lösungsvorschläge - natürlich würde man so einen Modi nicht einfach allen Rassen anhängen, und dann abfragen, ob's ein Thorwaler ist - ich wollte nur einen schön komplexen Ausdruck vorführen, wie man ihn in anderen Fällen haben könnte ... :-) > Und es war doch auch so, dass der Effektiv-Wert die "letzte Instanz" > war, also das der quasi aus allen Basis-Wert und den Modis berechnet > wurde, oder ? Dann würde ich auf keinen Fall den Effektiv-Wert nochmal > ändern. Ja. Aber irgendwo muß der Effektivwert ja mal berechnet werden. Ein Modifikator wie der in dem Beispiel würde ich als Teil der Berechnung, nicht als nachträgliche Änderung des Effektivwertes begreifen. Nicht-permanente Modifikatoren, wie der in dem Beispiel, kommen zwangsläufig genau bei der Berechnung des Effektivwertes zum Zuge. Aber man könnte natürlich die Summe aller nicht-permanenten Modis in einem eigenen Wert speichern, der dann nur noch zum Effektivwert addiert werden muß. Ist auch nicht ohne Vorteile. > Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten > nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja > bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, > sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, > Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets Aber das würde doch gut zu meinem Beispiel passen!? Nach dem Motto LE = LE + (KO+KO+KK)/2 ? Oder lieber LE = LE.basis + ... + ... + ... + (KO+KO+KK)/2 ? > _totale_ Funktionen verwenden, sonst gibts Ärger. Was meinst Du mit totalen Funktionen? Im mathematisch-analytischen Sinne total? > Damit fällt das Beispiel von Oliver (ich meine MR.effektiv = > (rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das > Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die > wir woanders noch festhalten müssen. Das Problem der Reihenfolge wird meines Erachtens durch die DSA-Regeln bestimmt, nicht durch die Art, wie wir Modifikatoren darstellen. Wenn laut Regeln X.basis einen Modi auf Y.effektiv und Y.effektiv einen auf Z.effektiv gibt, muß wissen, daß man Y vor Z berechnet. Da Modifikatoren aus unterschiedlichen Regelmodulen zusammenkommen werden, hilft hier die Darstellung der einzelnen Modis nicht weiter. Ich sehe zwei Lösungsmöglichkeiten: 1. Ein Prioritätattribut für Modis: Einfach realisierbar, aber macht Aufbau und Pflege eines modularisierten Regelbestandes evtl. sehr kompliziert und fehleranfällig. 2. Run-Time Dependency Analyse der Modi-Formeln. Aufwendiger zu Implementieren, meines Erachtens aber durchaus machbar. Dafür nicht fehleranfällig, keine Probleme beim Regelbestand. > Denn welche MR soll genommen werden ? > Die modifizierte ? Ja, denn das Ziel ist ja der effektiv-Wert. Da gibt Wie schon gesagt - bitte nicht zu sehr an diesem Beispiel festklammern. Man könnte aber z.B. MR als Kurzschreibweise für MR.effektiv begreifen, das entspräche dem üblichen Gebrauch von MR, KK, ... in den DSA-Regeln. Kann aber auch gern MR Kurzschreibweise für MR.basis sein, wenn XY.basis häufiger als XY.effiktiv oder XY.sonstwas gebraucht wird. cu Oli |
|
From: Matthias W. <Mat...@gm...> - 2002-04-30 12:55:33
|
Oliver Schulz wrote: >>Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten >>nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja >>bescheid. Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, >>sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, >>Wert (KO+KO+KK)/2). Wichtig ist dabei das wir hier stets >> >> > >Aber das würde doch gut zu meinem Beispiel passen!? >Nach dem Motto LE = LE + (KO+KO+KK)/2 ? >Oder lieber LE = LE.basis + ... + ... + ... + (KO+KO+KK)/2 ? > Ja, ich wollte noch eine Mail hinterherschicken, dass es an sich schon ok ist. Aber eben nicht als LE = LE + ... sondern als (ich kenn jetzt nicht die genaue Syntax, darum umschreibe ich es): Modifikator auf : LE, Wert: (KO+KO+KK)/2 Entstellt zwar etwas den Sinn der LE, aber in der Tat ist es ja so, dass nur die Basis-LE gesteigert werden kann, also der Wert, mit dem jeder Held bei 0 anfängt, und bei dem jede zusätzliche LE anhand der SKT bezahlt wird. >>_totale_ Funktionen verwenden, sonst gibts Ärger. >> >> > >Was meinst Du mit totalen Funktionen? Im mathematisch-analytischen >Sinne total? > > Ja, also wie in deinem Beispiel wenn das und das, dann dieser Wert, SONST ein anderer Wert. Damit auf alle Fälle ein Wert da ist, der zu interpretieren ist. Zum Rest schau ich mir wie gesagt den aktuellen Stand nochmal an, nicht dass ich Arbeit doppelt mache. Gruß Matthias |
|
From: Tilmann K. <ds...@tk...> - 2002-04-30 17:34:08
|
Hi Leute! Ich muss jetzt auch mal meinen Senf dazu geben und versuche mal (fuer alle die sich noch nicht in die (Vorschlags-)Implementierung unter net.sf.dsaman eingearbeitet haben einen Enblick zu geben wie ich die Sache angepackt habe. Wenn ich demnaechst mal Zeit finde werde ich auch die dsaman.argo ueberarbeiten. Jeder Held besitzt sogenannte PersonCharakterFeatures. Dieses sind Talente Zuaberfertigkeiten, Rassen etc die jeweils von P.C.F. abgeleitet sind. Alle diese Features implementieren drei Interfaces: 1. dsamath.ArithmeticItem: Dieses besagt nichts anderes, als das das Feature eine resolve()-Methode hat mit der man den aktuellen Effektivwert bekommt. Wie dieser berechnet wird kommt spaeter [2]. 2. model.relation.RelationAkzeptor: Das bedeutet, dass das Feature das Ziel einer Relation sein kann. Auch die Modifikatoren um die es hier geht sind Relationen, wie auch z.B. AT- und PA-Modifikatoren oder die "Auszeichnung" einer Sprache/Schrift als Muttersprache. Mehr zu Relationen in [1]. 3. model.relation.RelationQuelle: Bedeutet, dass von diesem Feature Relationen auf andere Features ausgehen koennen, wie zum Beispiel eine Profession sich (per Modifikator) auf die Talentwerte auswirkt. [1] Relationen sind sozusagen Mitteilungen. Diese haben einen Ursprung (RelationQuelle), der dem Ziel der Relation (RelationAkzeptor) diese Mitteilung ueberbringt. Dann entfaltet die Relation bei ihrem Ziel eine Wirkung oder auch nicht (Wenn mann einen +5 Modifikator auf eine Profession hat, wird die dort einfach verpuffen). Beispiel: Eine Rasse besitzt einen Modifikator mit Ziel:Schwimmen und Wirkung:+1. Dieser Modifikator wird dann, nachdem er von der Rasse an das Talent Schwimmen uebergeben wurde dort die Wirkung entfalten und den Effektivwert um 1 erhoehen. [2] Die Berechnung des Effektivwertes haengt natuerlich von der Art des Features ab, so gibt es z.B. einige Features die als Effektivwert permanent 0 liefern (Rasse, Kultur...). Ich schreibe mal wie es bisher implementiert ist bzw wie ich mir das vorgestellt habe: Talente(/Zauber): Genommen wird der Grundwert, der am Anfang (des Helden) 0 ist und der von Spieler gesteigert werden kann. Damit werden dann einfach die Modifikatoren verrechnet. Technische Realisierung der Berechnung [3]. Eigenschaft: Hier muss man etwas unterscheiden, da es im Modell vier Typen von Eigenschaften geben wird: Einfache Eigenschaften (Generierungspunkte), Steigerbare Eigenschaften (MU, KL...), Abgeleitete Eigenschaften (ATBasis..), und Abgeleitete Steigerbare Eigenschaften (LE...). (Eventuell koennen wir die Abgeleiteten dadurch einsparen, dass wir gerade eine einfache/steigerbare nehmen und einfach einen Modifikator, der die Formel enthaelt darauf anwenden.) Wertberechnung geht im Prinzip so: Formel auswerten falls vorhanden, dazu die gesteigerten Punkte falls vorhanden, dazu die Modifikatoren falls vorhanden. [3] [3] Technische Realisierung der Berechnungen: Die Idee die dahinter steckt ist die, dass man im Prinzip nur einmal parsen muss und so oft wie man will berechnen kann. Das lauft an einem Beispiel so: Ich habe jetzt die Abgeleitete Eigenschaft LE. Diese hat die Formel (KO+KO+KK)/2 und habe einen Modifikator +MU. Schon bevor die erste Berechnung gemacht werden soll (, weil z.B. jemand resolve() dieser Eigenschaft aufgerufen hat), zum Zeitpunkt nachdem alle Relationen an alle Ziele verteilt wurden (konkret in relationenAuswerten()), werden die Strings konkateniert zu (KO+KO+KK)/2+MU und an den Parser geschickt. Dieser bekommt zusaetzlich noch eine Map (Fuer die C Leute: eine Liste) in der alle ArithmeticItems, also alle Features dieses Charakters, sind. Was der Parser jetzt tut ist wieder ein ArithmeticItem (in Form eines dsamath.Term) zurueck geben, das in der Eigenschaft gespeichert wird. Dieser "Term" ist ein Syntaxbaum des Ausdrucks, der die Referenzen auf tatsaechlichen Features des Helden enthaelt. Will ich jetzt alse den Effektivwert der Eigenschaft berechnen rufe ich von diesem Term resolve() auf, dieser Term ruft dan von einem weiteren Term (, der dem Ausdruck "(KO+KO+KK)/2" entspricht,) resolve() auf, und ruft von dem ArithmeticItem MU resolve() auf, addiert die beiden Werte und gibt das Ergebnis zurueck. Das tolle an der Sache ist: Ich muss nicht aufpassen, in welcher Reihenfolge ich was berechne, denn das resolve() wandert sozusagen von oben nach unten durch. In dem Moment indem naemlich resolve von MU aufgerufen wird, wird dort der gleiche Prozess gestartet und ich bekomme immer das richtige Ergebnis auch, wenn sich der MU -Wert seit dem Parsen geaendert haben sollte. Matthias Wurm wrote: > Dann hätte ich da noch einige Fragen, aber die lasse ich vorerst mal, > weil ich mich selber erst wieder in das Modell einarbeiten muss. Nur > noch eines, und zwar die Arithmetic-Item-Geschichte / > Ausdruck-Geschichte: Vielleicht am Beispiel der AT: > > <Talentgruppe id="BspHeld_TagBewaffnet"> > <Name>Bewaffnet</Name> > <Talent ref="TalSpeere"> > <Wert effektiv="7">7</Wert> > <AT> > <Wert effektiv="10">4</Wert> > </AT> > </Talent> > ... > > Die 7 steht ja für den TaW, die effektiv-7 kommt dadurch, dass kein Modi > die 7 verändert. > Unter AT haben wir die 4, dazu kommen die 6 Basis-AT, die weiter oben > stehen, macht 10. Tatsaechlich ist es beim oben beschriebenen Vorgehen nicht erforderlich einen Effektivwert zu speichern, da er immer neu berechnet wird. > <Eigenschaften ref="EigAbgeleitet"> > <Eigenschaft ref="EigBasisAT"> > <Wert effektiv="6">0</Wert> > </Eigenschaft> > > Hier haben wir schon ein klassisches Beispiel der Verkettung. Die > EigBasisAT muss berechnet werden, danach kommt die EigBasisAT auf die AT > des Talents drauf. > Ich denke, dass es darauf hinauslaufen muss, dass wir eine > Vorberechnungs und eine Endberechnunsphase haben. Das spaltet sich nach obigen Ueberlegungen auf in eine Parse- und eine Berechnungsphase, wobei das Parsen nur dann notwendig wird, wenn sich die Modifikatoren aendern! > Im Wesentlichen will ich darauf hinaus, als Interaktion zwischen Werten > nichts anderes als Modifikatoren zuzulassen. Über die wissen wir ja > bescheid. Eventuell koennte man auch noch andere "Abkoemmlinge" von Relation in betracht ziehen sollten wir es brauchen. Im Moment siehts allerdings nicht so aus. > Aber der Modifikator-Wert, also -2 oder 3 oder sonstwie, > sollte durch einen Ausdruck ersetzet werden können (z.B. Modi auf LE, > Wert (KO+KO+KK)/2). Kein Problem mit dem beschriebenen Vorgehen. > Damit fällt das Beispiel von Oliver (ich meine MR.effektiv = > (rasse=='RasThorwaler') && (ST<4) ? MR-2 : MR;) schonmal weg. Das > Problem ist hierbei einfach, dass es eine Reihenfolge impliziert, die > wir woanders noch festhalten müssen. Das faellt aber aus anderen Gruenden weg: 1. Modifikatoren gehen immer auf die Effektivwerte. 2. Im normalfall geht der Modifikator von der Rasse (hier der Rasse "Thorwaler) in Richtung MR, Daher faellt "(rasse=='RasThorwaler') &&" weg Dann wuerde er in etwa so aussehen: Ziel: "EIG_MR" Wirkung: "(EIG_ST < 4) ? -2 : +0" > Denn welche MR soll genommen werden > ? Natuerlich die effektive oder brauchen wir auch anderes? Gruss, tilmann |
|
From: Oliver S. <os...@ep...> - 2002-05-05 11:48:54
|
Hi Leute! > Dann wuerde er in etwa so aussehen: > Ziel: "EIG_MR" > Wirkung: "(EIG_ST < 4) ? -2 : +0" Warum zwei getrennte Attribute/Angaben? Warum nicht einfach EIG_MR = EIG_MR + ... oder einen als Kürzel dafür einen Modifikationsoperator wie EIG_MR += ... oder auch modify(EIG_MR, ...) ? Parsen muß man die Ausdrücke eh, es bringt IMHO keinen Vorteil, Ziel und Wert des Modis in getrennten Angaben zu speichern. Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch flexibler. Der Implementierungsaufwand ist dabei nicht höher. Was meint ihr? cu Oli |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 12:14:12
|
Hallo! Oliver Schulz wrote: >> Dann wuerde er in etwa so aussehen: Ziel: "EIG_MR" Wirkung: "(EIG_ST < >> 4) ? -2 : +0" > > > Warum zwei getrennte Attribute/Angaben? > > Warum nicht einfach EIG_MR = EIG_MR + ... oder einen als Kürzel dafür > einen Modifikationsoperator wie EIG_MR += ... oder auch modify(EIG_MR, > ...) ? Parsen muß man die Ausdrücke eh, es bringt IMHO keinen Vorteil, > Ziel und Wert des Modis in getrennten Angaben zu speichern. Doch! Wir wollen einen Parser fuer Arithmetische/Boolesche Ausdruecke schreiben und keine zuweisungsorientierte Programmiersprache. EIG_MR = EIG_MR + ... soetwas ist weder ein arithmetischer noch ein boolscher Ausdruck, wenn man = als := und nicht als == interpretiert. Ich wuerde es ausserdem nicht gerne zusammenfassen, warum moechte ich kurz verdeutlichen: >> Ziel: "EIG_MR" >> Wirkung: "(EIG_ST < 4) ? -2 : +0" Das wird vom XMLReader interpretiert und in ein Objekt (WertModifikator) mit entsprechendem Ziel und Wirkung um gesetzt, der in einem RegelCharakterFeature liegt. Geparst kann hier eh noch nichts werden, da wir uns noch nicht in einem Helden befinden, sondern nur eine Regeldefinition vorliegt. Dieses Feature wird dann von einem einem PersonenCharakterFeature gewrappt. Dieses wiederum wird dann irgendwann sinen WertModifikator bei dessen Ziel PersonenCharakterFeature registrieren. Auch hier wird noch nichts geparst, wir brauchen aber bereits das Ziel. Geparst wird dann, wenn das Zielfeature seine Realtionen auswertet. Dabei werden aber _alle_ Wertmodifikatoren konkateniert und auf einen Schlag geparst, so dass wir lang nicht fuer jeden Modifikator den Parser extra anstossen muessen. Was man hier nacher noch machen kann, was ich mir gerade im Zusammenhang mit Vorteilen durch den Kopf gehen lasse ist, das man im Wertmodifikator selbst parst und dann einfach den Wert zurueckliefert. Das hat aber den Nachteil, dass wir dan fuer die Relationen auch noch Personen-Wrapper benoetigen. > Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch > flexibler. Der Implementierungsaufwand ist dabei nicht höher. Glaube ich schon. Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine Rueckgabewerte gemamaged werden? Gruss, tilmann |
|
From: Oliver S. <os...@ep...> - 2002-05-05 16:45:26
|
Hallo Leute! Tilmann schrieb: > wir brauchen aber bereits das Ziel. Geparst wird dann, wenn das Zielfeature > seine Realtionen auswertet. Dabei werden aber _alle_ Wertmodifikatoren > konkateniert und auf einen Schlag geparst, so dass wir lang nicht fuer jeden > Modifikator den Parser extra anstossen muessen. Wenn man konkatenieren will, ist es natürlich einfacher, Ziel und Wert getrennt zu speichern. Ich halte das aber für keine gute Idee, u.a., weil daduch Reihenfolge-Konflikte kaum auflösbar sind. Es ist auf jeden Fall stabiler und sauberer, die Modi-Scripts einmal einzeln zu parsen und dann später beliebig oft auszuwerten. Es kostet bei einem anständigen Parser auch nicht viel Performance. Im Gegenteil: Wenn man konkateniert, muß das nach jeder Änderung neu geschehen, und jedesmal der gesamte entstehende Ausdruck neu geparst werden. Und bei jeder Auswertung müßte auch immer der Parser angestoßen werden. Das erscheint mir umständlich. > > Eine Gesamtangabe fände ich sowohl eleganter und "natürlicher", wie auch > > flexibler. Der Implementierungsaufwand ist dabei nicht höher. > > Glaube ich schon. > Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine > Rueckgabewerte gemamaged werden? Ich stelle mir dazu folgendes Modell vor: Es gibt ein Scripting-Environment, das v.a. get und set-Routinen für path's bereitstellt (z.B. set(MU.effektiv, 13), get(IN), ...). Dies ist die Schnittstellen zu den Charakterwerten, etc. Kann man direkt auf XML oder auf Wrapper-Ebene machen, beides kein Problem. Dann Klassen für Nichtterminale: Evaluation, Expression, Function, ... aus denen der Parser den Syntaxbaum aufbaut (man braucht natürlich nicht für jedes Nichtterminal eine eigene Klasse). Diese Klassen haben dann entsprechend Auswerte-Methoden, usw. Auch nicht schwierig, und hält den Parser schlank und sauber getrennt von der Auswertung. Geparst werden muß jedes Script nur einmal (und bei Änderung). Will man auswerten, gibt man dem Environment eine Liste von Syntaxbäumen zum Ausführen. Fertig. Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen Methoden, die ihre Abhängikeiten angeben, also Listen der benutzten Pfade (uses) und Liste der veränderten Pfade (modifies). Kann einfach rekursiv definiert werden. Nun kann man eine strikte Halbordnung für Scripte definieren: "ScriptA < ScriptB wenn (ScriptA.modifies) und (ScriptB.uses) gemeinsame Pfade enthalten." Nach dieser Ordnung kann das Environment die Modifikatorscripte vor der Ausführung aufsteigend sortieren, und fertig. Bin im Moment dabei, das Ganze für C++ testweise zu implementieren, sieht so aus, als ob das gut geht. Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten, handelt es sich um einen Wiederspruch im Regelwerk selbst. Solche Wiedersprüche (falls vorhanden) findet man dann gleich heraus, und kann klären, wie sie zu handhaben sind. cu Oliver |
|
From: Tilmann K. <ds...@tk...> - 2002-05-05 22:57:46
|
Hi Leute! Oliver Schulz wrote: > > Wenn man konkatenieren will, ist es natürlich einfacher, Ziel und Wert > getrennt zu speichern. Ich halte das aber für keine gute Idee, u.a., > weil daduch Reihenfolge-Konflikte kaum auflösbar sind. Welche Reihenfolgekonflikte ueberhaupt? Ich hab jetzt schon einiges hinsichtlich Modifikator-Management implementiert und bis jetzt gabs da noch keine Reihenfolgekonflikte. > Es ist auf jeden Fall stabiler und sauberer, die Modi-Scripts > einmal einzeln zu parsen und dann später beliebig oft auszuwerten. Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele (Modifikatoren-Anzahl x Geladene-Charakter-Anzahl) Bei meiner Implementierung bisher wars so, dass die Modifikations-Strings direkt von der Regelrepraesentation gezogen wurden. > Es kostet bei einem anständigen Parser auch nicht viel Performance. > Im Gegenteil: Wenn man konkateniert, muß das nach jeder Änderung neu > geschehen, und jedesmal der gesamte entstehende Ausdruck neu geparst > werden. Ja, bei jeder Aenderung. > Und bei jeder Auswertung müßte auch immer der Parser angestoßen > werden. Das erscheint mir umständlich. Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet. >>Glaube ich schon. >>Wie sollte ein Parser/Syntaxbaum dafuer aussehen? Wie sollen seine >>Rueckgabewerte gemamaged werden? > > > Ich stelle mir dazu folgendes Modell vor: > > Es gibt ein Scripting-Environment, das v.a. get und set-Routinen > für path's bereitstellt (z.B. set(MU.effektiv, 13), get(IN), ...). > Dies ist die Schnittstellen zu den Charakterwerten, etc. Kann man > direkt auf XML oder auf Wrapper-Ebene machen, beides kein Problem. Waere moeglich (s.u.). > > Dann Klassen für Nichtterminale: Evaluation, Expression, Function, ... > aus denen der Parser den Syntaxbaum aufbaut (man braucht natürlich nicht > für jedes Nichtterminal eine eigene Klasse). Diese Klassen haben dann > entsprechend Auswerte-Methoden, usw. > Auch nicht schwierig, und hält den Parser schlank und sauber getrennt von > der Auswertung. Geparst werden muß jedes Script nur einmal (und bei Änderung). Richtig, und genau so wie beschrieben ist das auch im Moment ;-) Zumindest in meinem Java-Code, der mit Ingberts Parser arbeitet. > Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand > die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen > Methoden, die ihre Abhängikeiten angeben, also Listen der benutzten > Pfade (uses) und Liste der veränderten Pfade (modifies). Kann einfach > rekursiv definiert werden. Nun kann man eine strikte Halbordnung für Scripte > definieren: > "ScriptA < ScriptB wenn (ScriptA.modifies) und (ScriptB.uses) gemeinsame > Pfade enthalten." > Nach dieser Ordnung kann das Environment die Modifikatorscripte vor der > Ausführung aufsteigend sortieren, und fertig. Hierzu sehe ich ehrlich gesagt die Notwendigkeit nicht. Wenn man wie ich es geschrieben habe keine "Zuweisungen" in diesen Ausdruecken zulaesst gibts auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das Ausfindigmachen sowie die Kontrolle ueber die Modifikatoren durch deren Ziel selbst unnoetig kompliziert. > Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten, > handelt es sich um einen Wiederspruch im Regelwerk selbst. Solche Wiedersprüche > (falls vorhanden) findet man dann gleich heraus, und kann klären, > wie sie zu handhaben sind. Die stellen in der Aktuellen java-Version sicher ein Problem dar, das allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht. Gruss, tilmann |
|
From: Oliver S. <wh...@us...> - 2002-05-06 13:44:00
|
Hallo Tilmann!
> Welche Reihenfolgekonflikte ueberhaupt? Ich hab jetzt schon einiges
> hinsichtlich Modifikator-Management implementiert und bis jetzt gabs da noch
> keine Reihenfolgekonflikte.
Man stelle sich folgenden Fall vor:
1. Talent "Meditieren" gibt +1 auf MR, wenn TaW.basis > 10.
2. Artefakt "Mighty Alrik" gibt +5 auf KK, aber
wirkt nur, wenn MR(.effektiv!)<=4.
Nehmen wir an, Modi 1 kommt aus der Regelbox "Mohas in der Wüste",
Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst
Modi 1, dann Modi 2 angewendet werden. Aber das kann unmöglich
schon in den Modulen drin stehen, die gar nix voneinander wissen.
Ergo muß das Programm das schon selbst rausfinden.
Es _wird_ Reihenfolgeprobleme geben (eher früher, als später), und
daß bis jetzt noch keine aufgetreten sind, liegt schlicht daran,
das wir noch kein umfangreiches Regelwerk umgesetzt haben.
> Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden
> Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele
Na und? So groß sind die Syntaxbäume nicht. Es ist ja auch für jede
Eigenschaft, jedes Talent, jedes XYZ ein Wrapper geladen.
> (Modifikatoren-Anzahl x Geladene-Charakter-Anzahl) Bei meiner
Nein, je nach Implementierung entweder
Modifikatoren-im-Regelwerk-Anzahl x 1
oder
Im-Charakter-benutzte-Modis x Geladene-Charakter-Anzahl.
> Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet.
Nun, dann mußt Du eh den gesamten Syntaxbaum im Speicher halten.
Und ein großer Syntaxbaum ist auch nicht viel kleiner als mehrere
einzelne kleine (wenn überhaupt).
Und die Scripte auf (Script-)Quellcodeebene zusammenzukleben -
das fühlt sich wie ein Hack an ... :-)
> > Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand
> > die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen
[...]
> auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise
> mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das
Ist ja nur ein Implementierungsvorschlag, das kann in Java ja völlig
anders gemacht werden, als in C++.
Das mit dem "Relationen als Nachrichten" hat nix damit zu tun,
ob man schreibt ziel="x", quelle="y", oder "x=y" ist semantisch
identisch. Es ist auch kein Problem, im zweiten Fall das Ziel
zu ermitteln, das steht im Syntaxbaum ja deutlich drin.
Ich will auch gar nicht mit dem Scriptdesign eine Implementierung
festlegen, ich möchte, daß das Scriptdesign kompakt, elegant,
leistungsfähig und leicht zu handhaben ist (v.a. in der Anwendung).
Ein Modifikator ist eine logische Einheit (Quelle und Ziel), warum
soll man ihn auseinanderreißen?
Zudem hält man sich mit meinem Ansatz einfach mehr Möglichkeiten offen,
z.B. Modifikatoren mit mehrenen, oder sogar variablen Zielen
("a<b ? MU+=5 : GE+=5"). Mag sein, das wir sowas nicht brauchen, aber
ich möchte nicht drauf wetten. Viele Boxen sind noch nicht geschrieben
... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet,
sollten wir sie wählen.
> > Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten,
[...]
> Die stellen in der Aktuellen java-Version sicher ein Problem dar, das
> allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht.
Wir bauen einen modularen Charaktergenerator. "Rumpfuschen" wird
hoffentlich keiner, aber es werden von unterschiedlichen Leuten
gebaute Regelmodule zusammenkommen, dann noch die Sonderregeln und
Gegenstände der User, usw. Das kann und wird nicht alles genau
aufeinander abgestimmt sein.
cu
Oli
|
|
From: Tilmann K. <ds...@tk...> - 2002-05-06 22:48:54
|
Hallo Oliver!
Oliver Schulz wrote:
> Man stelle sich folgenden Fall vor:
>
> 1. Talent "Meditieren" gibt +1 auf MR, wenn TaW.basis > 10.
> 2. Artefakt "Mighty Alrik" gibt +5 auf KK, aber
> wirkt nur, wenn MR(.effektiv!)<=4.
>
> Nehmen wir an, Modi 1 kommt aus der Regelbox "Mohas in der Wüste",
> Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst
> Modi 1, dann Modi 2 angewendet werden.
Ja.
> Aber das kann unmöglich
> schon in den Modulen drin stehen, die gar nix voneinander wissen.
> Ergo muß das Programm das schon selbst rausfinden.
Ja, aber das tuts bei der java-Implementierung schon von ganz alleine ohne
Ordnung und sortieren, weil der Aufruf von MR in der Berrechnung von 2.
seinerseits eine Berechnung von MR anstoesst. Das Problem mit dem Sortieren
der Reihenfolge gibt es da nicht wenn man nicht zuweisungsorientiert arbeitet.
>
>>Wie gesagt, dass kann man machen, man braucht dann aber wieder fuer jeden
>>Modifikator einen Wrapper im Charakter. Und das sind wirklich sehr viele
>
>
> Na und? So groß sind die Syntaxbäume nicht. Es ist ja auch für jede
> Eigenschaft, jedes Talent, jedes XYZ ein Wrapper geladen.
Ich hab mir diese Moeglichkeit auf jeden Fall mal offen gehalten.
> Nein, je nach Implementierung entweder
> Modifikatoren-im-Regelwerk-Anzahl x 1
So hab ichs im Moment.
> oder
> Im-Charakter-benutzte-Modis x Geladene-Charakter-Anzahl.
Das meinte ich eigentlich.
>
>
>
>>Nein! Beim Auswerten wird direkt auf dem Syntaxbaum gearbeitet.
>
>
> Nun, dann mußt Du eh den gesamten Syntaxbaum im Speicher halten.
> Und ein großer Syntaxbaum ist auch nicht viel kleiner als mehrere
> einzelne kleine (wenn überhaupt).
Im Prinzip schon nur wird der Syntaxbaum vom Parser erstellt, der
seinerseits von Matthias mit SableCC erstellt wurde und wir wollen
eigentlich nicht in diesem Code rumpfuschen.
> Und die Scripte auf (Script-)Quellcodeebene zusammenzukleben -
> das fühlt sich wie ein Hack an ... :-)
Jep, bei der Java-version gibts aber keine Scripte in dem Sinne es gibt nur
Arithmetische und Boolsche Ausdruecke.
>
>
>
>>>Hier bietet sich auch eine schöne Möglichkeit an, mit geringem Aufwand
>>>die Reihenfolge-Problematik zu erledigen. Die Syntaxklassen bekommen
>>
> [...]
>
>>auch keine Reihenfogekonflikte. Ausserdem widerspricht die Vorgehensweise
>>mit den Zuweisungen dem "Relationen als Nachrichten"-Konzept und macht das
>
>
> Ist ja nur ein Implementierungsvorschlag, das kann in Java ja völlig
> anders gemacht werden, als in C++.
sicher
> Das mit dem "Relationen als Nachrichten" hat nix damit zu tun,
> ob man schreibt ziel="x", quelle="y", oder "x=y" ist semantisch
> identisch. Es ist auch kein Problem, im zweiten Fall das Ziel
> zu ermitteln, das steht im Syntaxbaum ja deutlich drin.
Ok ich kann es dann mittels Vorverarbeitung trennen durch Substring
before/after "=", im Syntaxbaum hat es bei uns nix verloren geparst wird
dann nur der zweite Teil.
> Ich will auch gar nicht mit dem Scriptdesign eine Implementierung
> festlegen, ich möchte, daß das Scriptdesign kompakt, elegant,
> leistungsfähig und leicht zu handhaben ist (v.a. in der Anwendung).
Ich frage mich wirklich was du mit dem ganzen script-Zeug machen willst. Ich
fuer meinen Teil will keine DSA-Programmiersprache schreiben.
> Ein Modifikator ist eine logische Einheit (Quelle und Ziel), warum
> soll man ihn auseinanderreißen?
Genauer gesagt Quelle(Rasse), Wirkung(+2), Ziel(Talent Schwimmen)
> Zudem hält man sich mit meinem Ansatz einfach mehr Möglichkeiten offen,
> z.B. Modifikatoren mit mehrenen, oder sogar variablen Zielen
> ("a<b ? MU+=5 : GE+=5").
Geht bei meiner doch auch:
1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0]
2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5]
Dabei wird der erste Modifikator sauber bei seinem Ziel dem MU-Objekt
registriert und der Zweite beim GE-Objekt. Und diese beiden wissen nacher
sogar noch welche Modifikationen von wo gekommen sind ;-)
> ... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet,
> sollten wir sie wählen.
Ich muss dazu mal folgendes Vermutung aeussern:
Ich hab jetzt die Grundregeln in java implementiert es fehlen noch
(Sonderfertigeiten, Zauber, SchlechteEigenschaften, Gaben und Vorteile zuer
Haelfte). Dabei habe ich einige Regelteile hart codiert. Und die waren zum
teil so Umfangreich, dass ich glaube, dass du eine Script-Sprache fuer DSA
zu einer fast kompletten Programmiersprache ausbauen musst, wenn du schon
die im Standardregelheft vorkommenden Faelle damit abdecken willst.
>
>>>Sollten Wiedersprüche der Form ScriptA < ScriptB < [...] < ScriptA auftreten,
>>
> [...]
>
>>Die stellen in der Aktuellen java-Version sicher ein Problem dar, das
>>allerdings nur dann auftritt, wenn jemand in den Regeldefinitionen rumpfuscht.
>
>
> Wir bauen einen modularen Charaktergenerator. "Rumpfuschen" wird
> hoffentlich keiner, aber es werden von unterschiedlichen Leuten
> gebaute Regelmodule zusammenkommen, dann noch die Sonderregeln und
> Gegenstände der User, usw. Das kann und wird nicht alles genau
> aufeinander abgestimmt sein.
>
Das hat sich erledigt ich hab eine simple Loesung fuer solche Schleifen
gefunden.
Viele Gruesse, tilmann
|
|
From: Oliver S. <os...@ep...> - 2002-05-07 13:47:37
|
Hallo Tilmann! > > Modi 2 aus "Tausend und ein Ding". Offensichtlich sollte erst > > Modi 1, dann Modi 2 angewendet werden. [...] > Ja, aber das tuts bei der java-Implementierung schon von ganz alleine ohne > Ordnung und sortieren, weil der Aufruf von MR in der Berrechnung von 2. > seinerseits eine Berechnung von MR anstoesst. Das Problem mit dem Sortieren > der Reihenfolge gibt es da nicht wenn man nicht zuweisungsorientiert arbeitet. Ah, jetzt hab ich verstanden, warum Du dieses Problem nicht hast. Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > > Nein, je nach Implementierung entweder > > Modifikatoren-im-Regelwerk-Anzahl x 1 > > So hab ichs im Moment. Das ist mir jetzt nicht ganz klar. Du kannst doch erst parsen, wenn Du konkateniert hast? Und das kannst mußt Du doch für jeden Char einzeln machen, oder? > Ich frage mich wirklich was du mit dem ganzen script-Zeug machen willst. Ich > fuer meinen Teil will keine DSA-Programmiersprache schreiben. Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht wirklich aufwendig ist, neben den ganzen mathematischen Op's noch einen Zuweisungsoperator zu implementieren, der einem dann aber eine Menge Möglichkeiten eröffnet. > Geht bei meiner doch auch: > 1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] > 2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo einer vielleicht von der Regellogik her eine Einheit gebildet hätte. > > Dabei wird der erste Modifikator sauber bei seinem Ziel dem MU-Objekt > registriert und der Zweite beim GE-Objekt. Und diese beiden wissen nacher > sogar noch welche Modifikationen von wo gekommen sind ;-) > > > > ... wenn uns Flexibilität keinen (oder nicht viel) Aufwand kostet, > > sollten wir sie wählen. > > Ich muss dazu mal folgendes Vermutung aeussern: > Ich hab jetzt die Grundregeln in java implementiert es fehlen noch > (Sonderfertigeiten, Zauber, SchlechteEigenschaften, Gaben und Vorteile zuer > Haelfte). Dabei habe ich einige Regelteile hart codiert. Und die waren zum > teil so Umfangreich, dass ich glaube, dass du eine Script-Sprache fuer DSA > zu einer fast kompletten Programmiersprache ausbauen musst, wenn du schon Was heißt komplette Programmiersprache? Schleifen kommen meines Erachtens nicht in Frage, desgl. Funktionsdefinitionen, etc. Aber: Arithmetik, Boolarithmetik, Schachtelung und bedingte Ausdrücke sind eh schon eine nette Grundlage, und die hast Du doch auch vorgesehen. Wenn man da lediglich Zuweisungen und die Möglichkeit mehrer Anweisungen (Script) hinzufügt, gewinnt man sehr "kostengünstig" die Möglichkeit, so manches Regelproblem elegant lösen zu können. In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion unter die Leute bringen zu müssen, ist keine akzeptable Alternative. Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, ist auch ein Riesenproblem. cu Oliver |
|
From: Matthias W. <Mat...@gm...> - 2002-05-07 19:08:31
|
Oliver Schulz wrote: > Hallo Tilmann! > > > Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon > angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst > wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese > diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht > wirklich aufwendig ist, neben den ganzen mathematischen Op's noch > einen Zuweisungsoperator zu implementieren, der einem dann aber > eine Menge Möglichkeiten eröffnet. > > > >>Geht bei meiner doch auch: >>1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] >>2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] > > > Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo > einer vielleicht von der Regellogik her eine Einheit gebildet > hätte. Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* > In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion > unter die Leute bringen zu müssen, ist keine akzeptable Alternative. > Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, > ist auch ein Riesenproblem. Was redest du da eigentlich ständig von hart coden ? Nur weil wir schonmal mit einem Implementierung des Charaktermodells angefangen haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir aus XML. Die Ziele holen wir aus XML. Das ganze wird auf Objekte gemappt. Die Objekte stehen in Verbindung anhand der in XML beschriebenen Relationen. Wo, bitte, ist da die Hartkodierung ??? Wenn du Performance-Problem befürchtest, dann ist das ok. Das müssten wir in unserer Implementierung mal abschätzen. Aber wenn du die ganze Zeit von hartkodieren redest, dann ist das schlichtweg Humbug. Gruß Matthias |
|
From: Oliver S. <wh...@us...> - 2002-05-07 19:21:57
|
Hallo Matthias! > Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* ;-) > Was redest du da eigentlich ständig von hart coden ? Nur weil wir > schonmal mit einem Implementierung des Charaktermodells angefangen > haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir Tillmann schrieb, er sei zum hart coden gezwungen gewesen ... cu Oli |
Oliver Schulz wrote: > Hallo Matthias! > > >>Irgendwie wußte ich, dass dieses Argument kommen wird *ggg* > > > ;-) Aber zu dem Argument... Ok, die beiden gehören logisch zueinander und sind bei dir in einer Formel. Aber bei der anderen Variante sieht man auch, dass die zusammengehören, da sie ja letzten Endes in XML als Modifikatoren unter das selbe Element gehören, also z.B. als 2 Modifikatoren-Elemente unter einem Artefakt-Element. Die Übersicht wird zwar nicht in der Formel bewahrt, aber in der Datenstruktur. > > >>Was redest du da eigentlich ständig von hart coden ? Nur weil wir >>schonmal mit einem Implementierung des Charaktermodells angefangen >>haben, codieren wir noch lange nix 'hart'. Die Modi-Ausdrück holen wir > > > Tillmann schrieb, er sei zum hart coden gezwungen gewesen ... achso... Naja, ich hab den riesig langen Thread nicht ganz verfolgt. Gruß Matthias |
|
From: Tilmann K. <ds...@tk...> - 2002-05-07 21:35:19
|
Hi Oliver! Oliver Schulz wrote: > Ah, jetzt hab ich verstanden, warum Du dieses Problem nicht hast. > Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür > wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > Berechnet ja, siehe andere Mail. >>>Nein, je nach Implementierung entweder >>> Modifikatoren-im-Regelwerk-Anzahl x 1 >> >>So hab ichs im Moment. > > > Das ist mir jetzt nicht ganz klar. Du kannst doch erst parsen, > wenn Du konkateniert hast? Und das kannst mußt Du doch für > jeden Char einzeln machen, oder? Ja, die Anzahl der Modifikatoren ist aber die obige, da es im Moment keine Personenwrapper gibt. Baue ich aber noch Personenwrapper ein, so habe ich die andere von dir genannte Anzahl und ich muss jeden Modifikator nur einmal parsen. Das werde ich bei gelegenheit einbauen aendert aber an der Funktion nichts, nur an der Geschwindigkeit und Uebersichtlichketi. > Ich will verhindern, daß viel hart gecodet wird (womit Du ja schon > angefangen hast). Ursprünglich war vorgesehen, daß DSAMan mit möglichst > wenig Hardcoding auskommen soll, und meines Erachtens nach ist diese > diese Anforderung nach wie vor aktuell. Hinzu kommt, daß es nicht > wirklich aufwendig ist, neben den ganzen mathematischen Op's noch > einen Zuweisungsoperator zu implementieren, der einem dann aber > eine Menge Möglichkeiten eröffnet. Das er das tut moechte ich nicht leugnen die Frage ist nur ob wir das wollen. Auch ich moechte auch moeglichst viel von der Programmierung her offen lassen. Ich finde aber auch dass zuweisungsorientiertes Scripting zu Undurchsichtigkeit fuehrt und es hat noch weitere Nachteile: - es ist extrem schwer zu debuggen - es koennen durch Fehleranfaelligkeit wirklich chaotische Effekte auftreten > >>Geht bei meiner doch auch: >>1. Modifikator: Ziel: MU Wirkung: [a<b ? 5 : 0] >>2. Modifikator: Ziel: GE Wirkung: [a<b ? 0 : 5] > > > Ja, ist mir schon klar. Aber dann sind's halt zwei Modis, wo > einer vielleicht von der Regellogik her eine Einheit gebildet > hätte. Finde ich nicht es gibt entweder einen Modifikator auf MU oder einen anderen auf GE nicht einen auf beides. Aber darueber koennten wir warscheinlich noch ewig diskutieren ;-) Ausserdem muss man da arg aufpassen ein Modifikator auf eine Eigenschaft ist z.B. nicht wirklich trivial mit "MU.effektiv = MU.effektiv + 3" ist's da nicht getan. Warum kann sich mal jeder selbst ueberlegen. > Was heißt komplette Programmiersprache? Schleifen kommen meines > Erachtens nicht in Frage, desgl. Funktionsdefinitionen, etc. > Aber: Arithmetik, Boolarithmetik, Schachtelung und bedingte > Ausdrücke sind eh schon eine nette Grundlage, und die hast Du doch > auch vorgesehen. > Wenn man da lediglich Zuweisungen und die Möglichkeit mehrer Anweisungen > (Script) hinzufügt, gewinnt man sehr "kostengünstig" die Möglichkeit, > so manches Regelproblem elegant lösen zu können. Ok ich mach mal ein beispiel fuer die Berechnung der Steigerungskosten am Talent schwimmen. Schwimmen.SteigerungsKosten = (Schwimmen.effektiv < 0 ? skt(Stufe.effektiv,Schwimmen.sktSpalte) : (Schwimmen.effektiv == 0 ? (Schwimmen.kategorie == "Basis-Talent" ? skt(Schwimmen.effektiv + 1,Schwimmen.sktSpalte) : (Charakter.inGenerierung ? Schwimmen.sktSpalte : skt(Stufe.effektiv,Schwimmen.sktSpalte)))) : skt(Schwimmen.effektiv + 1,Schwimmen.sktSpalte)) Zugegebenermassen kann man das auch beim Scripting in mehrere Zeilen aufspalten um die Uebersichtlichkeit zu erhoehen. Dann hab ich das aber nochmal fuer das Talent Schleichen, wobei ich jeweils Schwimmen durch Schleichen ersetzen muss, dann noch fuer Klettern, Etikette,.... (Moechte gar nicht wissen wie lange man den Fehler suchen muss, wenn einmal irgendwo Schwimmen nicht ersetzt wurde, vorrausgesetzt es wurde ueberhaupt bemerkt, dass irgendwo ein Fehler vorliegt) > In solchen Fällen hart zu coden, und erst mal wieder eine neue Programmversion > unter die Leute bringen zu müssen, ist keine akzeptable Alternative. > Und sicherzustellen, daß in Java und C++ hart gecodete Regeln das Gleiche tun, > ist auch ein Riesenproblem. Code ich das hart habe ich es genau einmal fuer alle Talente. Werden die Regeln geaendert (gilt nicht fuer Aenderung der Skt) muss ichs halt im Code aendern. Aber hier sollten die Regeln eigenltich festgelegt sein, kommt also beim einen Programm was anderes raus als beim anderen, so ist eines schlicht und ergreifend falsch. Bis dann, tilmann |
|
From: Oliver S. <wh...@us...> - 2002-05-07 22:51:25
|
Hi Tilmann! > > Ok, auf die Weise gibt's keine Reihenfolgeprobleme, aber dafür > > wird ein Haufen Werte mehrfach, evtl. sogar sehr oft berechnet. > Berechnet ja, siehe andere Mail. Jau, das ist jetzt klar. > Das er das tut moechte ich nicht leugnen die Frage ist nur ob wir das > wollen. Auch ich moechte auch moeglichst viel von der Programmierung her Ich auch - darum rede ich ja immer wieder davon, beim Design nicht so sehr auf die Implementierung zu schauen. > offen lassen. Ich finde aber auch dass zuweisungsorientiertes Scripting zu > Undurchsichtigkeit fuehrt und es hat noch weitere Nachteile: > > - es ist extrem schwer zu debuggen > - es koennen durch Fehleranfaelligkeit wirklich chaotische Effekte auftreten Warum genau? Ich halte zuweisungsorientiertes Scripting für wesentlich fehlerunanfälliger. Auch weiß ich nicht, wo das Problem beim Debuggen sein soll. Zuweisungsorientiertes Scripting bedeutet, die Charakter(effektiv)werte einzeln und nacheinander jeweils einmal zu berechnen. Da das genau das ist, was man mit Pen&Paper auch macht, halte ich es im Gegenteil für sehr intuitiv, übersichtlich und leicht zu debuggen. Man könnte sich im Zweifelsfall den ganzen Berechnungsprozeß linear anzeigen lassen, ohne daß das sehr lang wird. Das wird bei euren tiefen und mehrfachen Rekursionen sehe ich genau da viel eher Probleme. > Finde ich nicht es gibt entweder einen Modifikator auf MU oder einen anderen > auf GE nicht einen auf beides. Aber darueber koennten wir warscheinlich noch > ewig diskutieren ;-) Jau ... :-) > Ausserdem muss man da arg aufpassen ein Modifikator auf eine Eigenschaft ist > z.B. nicht wirklich trivial mit "MU.effektiv = MU.effektiv + 3" ist's da > nicht getan. Warum kann sich mal jeder selbst ueberlegen. Warum ist das ein Problem? Wenn sichergestellt ist, daß bei Berechnung des Effektivwertes jeder Modi nur einmal angewendet wird (und das war in meinem Konzept ja drin), geht das doch einwandfrei, oder? > Ok ich mach mal ein beispiel fuer die Berechnung der Steigerungskosten am > Talent schwimmen. [...] > Code ich das hart habe ich es genau einmal fuer alle Talente. Werden die Da sind wir uns sicher einig. Dinge wie Steigerungskosten, also tiefste DSA4-Grundkonzepte, die wirklich für alles gleich sind, werden hart gecodet. Ich hatte gedacht, Du hättest auch viele Sonderregeln und so hart gecodet, weil's mit den Modis allein nicht ging. cu Oli |
Oliver Schulz wrote: >>Ausserdem muss man da arg aufpassen ein Modifikator auf eine Eigenschaft ist >>z.B. nicht wirklich trivial mit "MU.effektiv = MU.effektiv + 3" ist's da >>nicht getan. Warum kann sich mal jeder selbst ueberlegen. > > > Warum ist das ein Problem? Wenn sichergestellt ist, daß bei > Berechnung des Effektivwertes jeder Modi nur einmal angewendet > wird (und das war in meinem Konzept ja drin), geht das doch > einwandfrei, oder? Ja, ich meinte schlicht und einfach, dass der Modifikator, sollte er z.B. von einer Rasse ausgehen zusaetzlich zum Effektivwert auch noch den Maximalwert mofifiziert. ;-) Gruss, tilmann |
Thanks for helping keep SourceForge clean.
X