Re: [DSA Manager] Element-Klassen (Entwurf 1)

[Andreas H. <ahu...@gm...>]

Hi,



On Wednesday 14 November 2001 16:01, Alexander Nofftz wrote:


> >>    |     |--> Eigenschaften
> >>    |     |
> >>    |     |     |--> Nicht steigerbar (AT, PA, MR, ST, SO...)
> >>    |     |
> >>    |     |     \--> Steigerbar
> >
> > Besser anders. Man weiß nie, was plötzlich doch steigerbar sein
> > wird.
>
> Dann kann man die Klassenbezeichnung ja überschreiben.

Aber man sollte an der Datenstruktur nacher so wenig wie moeglich aendern 
müssen.


> > Und auf einige Sachen kann man z.B. Boni kaufen.
>
> Ja, aber so etwas sehe ich eher als Vorteil an. LE kann man doppelt
> aufführen, einmal die Basis-LE unter "Meta-Eigenschaften" und dann die
> gekauften LeP als steigerbare Eigenschaft, das kommt auch der Regel sehr
> nahe.
>
> >>Wie man sehen kann, sind etwa die schlechten Eigenschaften gleichzeitig
> >>Nachteile und Eigenschaften, damit können wir wohl einige Diskussionen
> >>leicht lösen ;-)
> >
> > Inwiefern genau?
>
> Nun, schlechte Eigenschaften gelten als Nachteil, haben aber in gegesatz
> zu diesen einen Wert und sind "steigerbar", also genau wie Eigenschaften.

Und du kannst alle Nachteile mit EXP wegbekommen, also wegsteigern. "Die" 
schlechte eigenschaft gibt es nicht mehr es gibt nur noch Eigenschaten, 
Vorteile und Nachteile. Und bei den Nachteilen gibt es welche die so aussehen 
wie die schlechten Eigenschaften von DSA3. Doch es sind Nachteile und 
können  wie alle anderen Nachteile auch weggesteigert werden



> >>Zugeordnet wird alles über das class-Attribut, das als NMTOKEN definiert
> >>ist (wie unter HTML auch):
> >
> > NMTOKEN kommt nicht in Frage. NMTOKEN darf Dinge wie ":", "-", etc.
> > enthalten. Das gibt Operatorenkonflikte, außer die ID's kommen immer in
> > Quotes.
>
> Was willst du mit : und - in den Namen? Die kann man ja explizit
> ausschießen.
>
> >>   <property id="MU" class="EigGut">
> >>     ...
> >>   </property>
> >
> > [...]
> >
> >>  ...
> >>   <advantage id="NatJähzorn" class="Nachteil EigSchlecht">
> >
> > Das geht mir zu weit. Wenn man nachher für alles das gleiche
> > Tag hat, verliert man alle Vorteile, die XML bietet.
>
> Ein Tag für jede *Oberklasse* von Objekten, also eine für Eigenschaften,
> eine für Vor- und Nachteile, eine für Talente und Zauber, also alles,
> was sich nur minimal unterscheidet.
>
> > Abgesehen
> > davon sind Eigenschaften und Vorteile z.B. wirklich nicht das
> > gleiche. Basiseigenschaften haben Eigenschaftswerte, machen
> > aber keine action's, ... Das sind verschiedene Elemente mit
> > verschiedenen Attributen und verschiedenen möglichen Kindern.
>
> Richtig, eine Eigenschaft mit <action>s habe ich Meta-Eigenschaft
> genannt, kann man ja dann auch als <meta-property> definieren.
>
> >>Das mit <advantage> ist Absicht, die Einordnung in Vor- und Nachteile
> >>ist rein bedeutungsbezogen und hat für die Definition keinen Einfluss,
> >
> > Du hast schon recht, da advantage und disadvantage Tag genau die selbe
> > Definition haben werden, könnte man sie zusammenlegen.
> > Ich würd's dennoch lassen, denn man wird Vor- und Nachteile oft
> > getrennt handeln, und dann im Programm aufgrund der ersten
> > Buchstaben der ID's zu trennen ist nicht wirklich elegant.
>
> Nein, das geht anhand der Klasse. Die ersten drei Buchstaben sollen nur
> klar machen, auf was die ID sich bezieht und von vornerein einige
> Namenskollisionen ausschließen. Macht man in großen Klassenbibliotheken
> ja auch so.
>
> >><property id="MU" class="EigGut">
> >
> >      ...
> >
> >></property>
> >><property id="NatJähzorn" class="Nachteil EigSchlecht">
> >
> > Man kann nich fast alles in einen Topf werfen.
>
> Nicht alles, aber denke mal streng nach, worin sich die guten und die
> schlechten Eigenschaften wirklich unterscheiden, außer der logischen
> Einordnung unter "Nachteile" und den abgewandelten Steigerungsregeln (zu
> denen ich schon was geschrieben hatte) eigentlich überhaupt nicht.

Doch es gibt einen ganz gewaltigen Unterschied ... jeder hat alle 
Eigenschaften ( ich lasse das gut jetzt weg) aber nicht jeder muß Nachteile 
haben. 
Nachteile koennen auch nicht von Vorteilen betroffen sein, zb von 
herausragende Eigenschaft, was aber wenn man es unter Eigenschaft legt 
passieren kann. 


> > Auch die Mehrfachvererbung löst nicht nur Probleme, sondern
> > schafft ganz eigene. XML ist geeignet für eine direkte
> > Hierarchie, nicht für Mehrfachvererbung.
>
> Die Mehrfachvererbung bezieht sich ja nicht auf das XML, sondern darauf,
> wie der DSA Manager die darin enthaltenen Daten auswertet. Wenn ich z.B.
> alle Tags heraussuche, deren Klasse "Nachteil" enthält, erhalte ich alle
> Nachteile, auch die schlechten Eigenschaften. Will ich eine Liste aller
> Talente haben, suche ich nach der Klasse "Talente". Will ich nur die
> Kampfzauber haben, suche ich nach der entsprechenden Klasse etc.

Nachteile >= Schlechte Eigenschaft , sprich schlechte Eigenschaften sind eine 
Teilmenge der Nachteile..


> >>Damit brauche ich z.B. bei den schlechten Eigenschaften nur einmal
> >>festzulegen, dass statt zum Steigern dem Base-Wert (21-Base) heran
> >>gezogen werden soll, und schon kann ich die schlechten Eigenschaften wie
> >>normale Eigenschaften definieren.
> >
> > Sowas hatte ich mal angedacht, aber: Es kommt gar nicht so
> > häufig vor, das was vererbt wird (Die Attribute ein Beispiel,
> > aber so viel anderes gibts nicht). Ich denke, es besser, in
> > den paar Fällen die Dinge mehrfach anzugeben.
>
> Es kommt vor bei:
>
>   - Eigenschaften
>   - Meta-Eigenschaften
>   - Vorteilen, Nachteilen
>   - Talenten (erben aus der Talentgruppe)
>   - Talent-Spezialisierungen
>   - Rüstungs- und Waffenkategorien
>
> Soll ich weitermachen? ;-)
>
> >>Dritter Punkt: Da alle Elemente ebenfalls in diese Klassenstrukur
> >>eingeordnet sind, brauche ich mich für Ableitungen oder den
> >>Charakterbögen nur darauf zu beziehen:
> >>
> >>   <property id="MyJähzorn" ref="NatJähzorn">
> >>    <value base="7"/>
> >>   </property>
> >
> > value reicht nicht aus. Manche Dinge haben mehrere Werte (z.B. TaW und AT
> > Wert bei Talenten). Verschiedene Wert-Typen sollten verschiedene Tags
> > haben. Und man braucht auch hier nicht zwangsläufig Vererbung. Es ist eh
> > mehr eine Instanziierung.
>
> Die AT/PA-Werte sind ein Sonderfall, ansonsten reicht <value> wirklich.
> Warum unterschiedliche Tags für Dinge definieren, die im Grunde dasselbe
> meinen?
>
> >>Eventuell kann man das ref-Attribut sogar als xlink definieren, aber mal
> >>schauen, was Xerces aus solchen Angaben macht...
> >
> > Bitte nicht alle Cutting-Edge Features von Xerces ausnutzen, wir
> > werden Xerces für C++ vermutlich nicht benutzen.
>
> Bestimmt nicht, aber wenn ihr den C++-Xerces verwendet, stellen wir
> sicher, dass die XML-Datei gleich ausgewertet und gespeichert werden.
> Vielleicht macht eine andere Bibliothek einige Dinge minimal anders, und
> dann sind die Dateien nach ein paar Mal laden, steigen und speichern
> nicht mehr kompatibel...

wieso sollten sie .. 
wenn man klare regeln definiert wie die Datei auszusehen hat muss man diese 
mit der entsprechenden lib umsetzen können. Wenn sich die ergebnisse dann 
doch unterscheiden liegts an einen schlechten definition oder am unvermögen 
des Menschen an der Tastatur. ;-)
Ausserdem ist doch idee eines C++ frontend die, das wenig Ressourcen benötigt 
werden....



Bye
Andreas

P.S.
Bitte verzeiht meine tippselfehler.. .ich hab hier 2 ami und 1 deutsche 
tastatur....