Re: [DSA Manager] Fragen zur Struktur

[Matthias W. <Mat...@gm...>]

Andreas Hugenroth wrote:
> 
> >
> >Genauso bei Talenten:
> >Im Grunde bräuchten wir pro Talent nur die ID und den TaW, mehr nicht,
> >da anhand der ID ja schon _alles_ (Name, Probe, Kategorie,
> >Steigerungsspalte) beschrieben ist. Zwar werden wir hier aufgrund
> >solcher Vorteile wie "Begabung für... Unfähigkeit für..." noch ein paar
> >mehr Infos zu den Talenten geben müssen, die aber wohl in der Regel
> >EMPTY sein werden, dazu gehören dann solche Regelungen zur
> >Steigerungsmodifikation (wie die von dir oben genannten)
> >
> Und wie willst du diese Infos nun gestallten ? Das laueft dann doch auf
> meine Misch-Idee hinaus. Es gilt so lange default bis die emptyfelder
> einen Wert haben.
> Nur du musst dann fuer sehr viele Punkte diese Sonderfelder mitnehmen.
> Nimm zb den Zweihaender fuer 300 Dukaten der mit einem normalen
> Zweihaender nur noch den Namen gemeinsam hat.
> 
> >
> >Die von dir angesprochene Freiheit lässt sich ja ohne Probleme mit dem
> >von Tilmann angesprochenen Prinzip vereinigen (wie eben beschrieben).
> >Und im Sinne von sauberer Programmierung sollten wir das, was sich auf
> >einen Kernpunkt reduzieren lässt, auch reduzieren, und nicht
> >überflüssigerweise woanders noch mitschleppen (wie z.B. den Namen der
> >Rasse, des Talents oder ähnliches)
> >
> Das ist schon richtig, ich komme aus der Datenbankecke und bin
> garantiert kein Fan von doppelt und dreifachspeicherung ein und
> derselben daten nur um Sonderfaelle abzufangen.
> Hmm wir koennen natuerlich auch versuchen solche Modifikatoren vor der
> Steigerung/ Ausdruck aufloesen zu lassen.
> Dann muss der Zweihaender als neue Waffe aufgenommen werden und zb mit
> der ID 2handfuer300D laufen ...
> 
> Und je laenger ich darueber nachdenke ist das sicher auch ein guter Weg.
> 
>     suche passende SKT-Spalte
>                 if  HerausragendeTalentGruppe=Talentgruppegewaehlt
>                             SKT-Spalte--
>                 fi
>     usw usw
> 
> D.h aber das wir jeden neuen Vorteil der sisch auf steigerbare Werte und
> deren Kosten auswirkt coden muessen, oder sieht da jemand einen anderen
> Weg?

Nein nein, das wäre ja vollkommen ab von unserem Weg.

1.) Solche Sachen wie Zweihänder für 300 D können ja von Zöllen (die
Herkunftsfaktoren aus Kaiser Retos Waffenkammer) kommen, oder dadurch,
dass sie Spezialfertigungen sind, die dann auch noch mehr TP machen etc.
Zwar wollen wir solche Sachen wohl erstmal nicht implementieren, aber
zumindest mal berücksichtigen. Von daher: rein in die probleme.txt,
unter "Waffen" oder so.

2.) Zu der Misch-Idee:
Nein, die will ich auch nicht. Dazu tragen wir das ja in der
brainstorming.txt ein. Man kann ja diverse Objekte als "modifizierend"
betrachten (dabei muss man wiederum die Art der Modi betrachten:
permanent, temporär, permanent unter gewissen Umständen)
Jedes dieser modifizierenden Objekte modfiziert ein anderes. Naja, ich
sags mal lieber mathematisch, ist einleuchtender.
Sei B ein modifizierendes Objekt, A1 und A2 seien in der Lage, von B
modifiziert zu werden.
Ich denke man kann davon ausgehen, dass A1 und A2 von der selben Klasse
sind, oder zumindest von der selben abgeleitet. Damit meine ich, dass
Ringe nur Lebewesen modifizieren, besondere Metalle nur Waffen. Alle
Lebewesen habe in etwa die gleichen Attribute, ebenfalls die Waffen.
Das läuft dann darauf hinaus, dass wir versuchen, unsere Objekte
vernünftig zu gruppieren.
Dann können wir z.B. sagen: A1 und A2 gehören zur Klasse X, B zur Klasse
Y.
Y kann X modifizieren. Daher wäre dann folgenden Vorgehensweise möglich.
Wir setzen unter Objekte der Klasse Y einfach ein Tag <Modifikatoren>,
alles unter dieses Tag sieht aus, als wäre es ein Objekt der Klasse X,
nur dass die Werte, die beiden Unterelementen angegeben sind, als
relativ zu betrachten sind. Eigentlich können wirs gleich so machen,
dass wir ein <Modifikatoren modify=""> machen, das angibt, für welche
Klasse / Klassen die darunterstehenden Modis gelten. Und für jeden Modi
angeben, ob er absolut oder rel. zu verstehen ist, aber gerade bei dem
Punkt sollten wir nix überstürzen, erst Ideen sammeln.
Zwar kann man das auch mit Skripting machen (wie vorgeschlagen), ich
will aber nur so _wenig_ Skripting wie möglich einführen, da wir da
selber einen Parser schreiben müssen und das auch noch schlechter
pflegen können, als wenn wir uns eine gute XML-Struktuer überlegen, die
das auch mit weniger Skripting ermöglicht (ganz ohne wirds wohl nicht
gehen).


Gruß
Matthias

PS: Noch was: auch wenn ich hier von einer Art Vererbung rede, meine ich
nicht, dass wir das irgendwie realisieren müssen. Ich meine nur, dass
wir uns bei solchen Klassen auf eine einheitliche Struktur einigen, also
beim Begleiter statt Tag <LO> für Loyalität dies besser als
Basis-Attribut nehmen (also in den Topf mit MU, KL, ...). Mehr mein ich
damit nicht