Re: [DSA Manager] DSAdmin Datenstruktur
Status: Planning
Brought to you by:
alexnofftz
From: Alexander N. <lists@AlexNofftz.de> - 2001-11-13 22:10:01
|
Hi Oliver! Bin gerade aus Scary Movie II gekommen (<bg>) und habe jetzt Zeit hierfür... > Die Struktur ist komplett internationalisiert (bis auf > zwei oder drei Dinge), um den Gerüchten um ein englisches > Myranor und Aventurien Rechnung zu tragen. Da besteht > sicherlich Diskussionsbedarf. Ja, da hatten wir ja auch schon über Telefon drüber geredet, an den anderen Reaktionen hier siehst du ja, wie die anderen darüber denken. BTW du weißt, wofür die letzen beiden Buchstaben beim DOCTYPE stehen? Mal zur Verdeutlichung mein DOCTYPE für die Charaktere: -//FANPRO//DTD DSA Charakter 1.0//DE und als Gegenbeispiel mal der von XHTML: -//W3C//DTD XHTML 1.1//EN Fällt dir was auf? ;-) > Einige Übersetzungen (einfach erstmal so gewählt): > AV = Attribute Value > SkV = Skill Value (TaW) Wie gesagt, so etwas ist riskant. Entweder bekommen wir von FanPro die englischen Bezeichnungen, oder wir lassen es lieber, bevor das in totales Chaos ausartet. > Kurze Erläuterung zum Skipting: > > talent('swords').SkV.base spricht z.B. den Basiswert des > Schwerter-TaW an, Da widersprichst du dir aber, eigentlich müsste die Funktion jetzt skill() heißen <g> > Das Skripting ist recht heftig geworden. Ich denke, so in der Art > können wir tatsächlich auch die wildesten Regeln umsetzen. Die > Implementierung wird allerdings nicht unaufwendig. Vielleicht sollte > man aber auch für einfache Modifikatoren neben <action> noch ein > simpler gestaltetes <mod> vorsehen. Allerdings. > <dsa xmlns="http://dsaman.sf.net/dsa-4.0"> Ist zwar nur kosmetisch, aber evtl. wäre hier ein URN besser. Die URLs als Namespaces waren nur eine Notlösung, weil bei der Namespace-Spezifikation die URN-Definition noch nicht fertig war. > <attributes> > <base-attributes> > <attribute id="MU"> > <name xml:lang="de">Mut</name> > <short-name xml:lang="de">MU</short-name> Der short-name sollte der ID sein, daher ist diese Zeile eigentlich unnötig. > <AV base="0" base-min="8" base-max="gen ? 14 : 21"/> Diese Anweisung ist mir nicht so ganz klar. Was soll dieses "gen" bedeuten? Dass der Wert bei der Generierung nicht höher als 14, danach bis max. 21 gehen kann? Das ist so nicht richtig. Das mit der Generierung stimmt, aber danach ist der Maximalwert das anderthalbfache des Startwertes. Dadurch ergibt sich durch den Startwert 14 die 21, aber wenn ich den Vorteil Herausragende Eigenschaft nehme, kann ich durchaus auch höher kommen. > <derived-attributes> > <attribute id="LE"> > <name xml:lang="de">Lebensenergie</name> > <short-name xml:lang="de">LE</short-name> > <AV base="0" base-max="floor(KO/2)" add="ceil((KO+KO+KK)/2)" cost="..."/> Gute Definition, aber cost ist ganz einfach: cost="SKT(H)" ;-) > <level-attributes> Ein unglücklicher Name, da gefiel mir mein <Variablen> besser, außerdem gehört hier der SO nicht rein. > <attribute id="ST"> > <name xml:lang="de">Stufe</name> > <short-name xml:lang="de">ST</short-name> > <AV base="1" cost="100*(ST+1)"/> NEIN, denn damit wäre laut deiner Syntax die Stufe dann ein steigerbarer Wert, der mich immer genau so viele AP kostet, wie mir zur nächsten Stufe fehlen. Besser direkt berechnen über: <AV base="0" add="round(floor((5+sqrt(25+2*AP))/10))"/> > <attribute id="SO"> > <name xml:lang="de">Sozialstatus</name> > <short-name xml:lang="de">SO</short-name> > <AV base="0" base-min="1"/> > </attribute> Gehört nicht hierein! SO ist eine (nicht steigerungsfähige) Eigenschaft und sollte auch da hin. > <advantages> > <advantage id="lucky" cost="15"> > <name xml:lang="de">Glück</name> > <description xml:lang="de"> > <p> Ein Held, an dem sprichwörtlich das Glück klebt, > bla, bla, ... </p> > </description> > <short-description xml:lang="de"> > <p> Bis 3-mal am Tag eine Probe <emph>einmal</emph> > wiederholen und günstigeres Ergebnis wählen.</p> > </short-description> > </advantage> Im Prinzip einverstanden, bis darauf, dass es in HTML <em> statt <emph> heißt ;-) > <advantage id="gifted-skill" specialisation="required" cost="oh shit!"> Wieso "oh shit!"? Was spricht dagegen, diesen Vorteil für jede Talentgruppe einzeln zu definieren? Allzu viele sind's ja nicht. > <name xml:lang="de">Begabung für Talent</name> > <prerequisite expr="not Advantage('gifted-skill-group')"/> Außerdem darf "gifted-skill" nicht doppelt gewählt werden, es sei denn, es ist durch die RaKuPro vorgegeben. > <advantage id="gifted-skill-group" specialisation="required" cost="ohshit!"> > <name xml:lang="de">Begabung für Talentgruppe</name> > <prerequisite expr="not Advantage('gifted-skill')"/> > <action on="once" do="this will be complicated ..."/> Wird es nicht, wenn man einfach einer Talentgruppe einen ID zuweist, kann man sich darauf beziehen. > <advantage id="special-possession" specialisation="required" cost="12"> > <name xml:lang="de">Besonderer Besitz</name> > </advantage> Dieser Vorteil sollte bei den Professionen stehen und direkt aufzählen, was man dann bekommt. > <races> > <race id="human"> > <action on="calc" do="..."/> > ... > <culture id="mittelreich"/> > <culture id="..."/> > </race> Die Kulturen in der Rasse speichern? Und wenn ich jetzt einen Thorwaler spielen will, der im Bornland aufgewachsen ist? Das geht sogar schon bei den Basisregeln! > <skills> > <skill-category id="combat-skills"> > <name xml:lang="de">Kampftalente</name> > <skill-category id="armed-combat"> > <name xml:lang="de">Bewaffneter Nahkampf</name> > <skill id="swords"> > <name xml:lang="de">Schwerter</name> > <SkV base="0" cost-table="5"/> > <eBE base="BE-2"/> > <similar to="sabers"/> > <similar to="fencing"/> > <similar to="blunt-weapons"/> > </skill> > </skill-category> > </skill-category> Hmm, ob diese Mehrfachverschachtelung überhaupt nötig ist? Außerdem merke ich langsam schon, wie viel meine Drei-Buchstaben-Prefixe bei den IDs ausmachen ;-) > <skill-category id="special-skills"> > <name xml:lang="de">Sonderfertigkeiten</name> > <skill > id="armor-tolerance-1" cost="150" > specialisation="required" spec-type="armor" > > > <name xml:lang="de">Rüstungsgewöhnung I</name> > <action > on="calc" > do="! skill(armor-tolerance-2) ? armor(spec).BE -= 1" > /> > </skill> Sonderfertigkeiten sind keine Talente, daher sind sie hier etwas unglücklich eingeordnet. Ansonsten einverstanden. > <professions> > <profession id="mercenary" cost="10"> > <name xml:lang="de">Söldner</name> > <action on="once" do="talent('athletics').SkV.base += 2"/> > <action on="once" do="talent('climbing').SkV.base += 1"/> > ... > <action on="once" do="skills.add('armor-tolerance-1')"/> > </profession> > </professions> Wäre es nicht viel übersichtlicher, die ID statt talent(ID).SkV.base - Schreibweise auch hier zuzulassen? > > Ein Charakter (skizzenhaft): > ---------------------------- > > <?xml-stylesheet type="text/xsl" href="character2xhtml.xsl"?> StyleSheet vorgeben? Warum? > <charakter > xmlns="http://www.lowangen.de/dsa-4.0" hehe > age="21" > size="90" > weight="80" Ungünstig. Ich hatte diese Werte extra als eigene Tags definiert, damit man die Einheit angeben kann. Viele geben die Größe in "Halbfingern" an, andere in Schritt. Einige geben die Größe in Stein an, andere in Unzen etc. > <name xml:lang="de">Alrik</name> > <race id="human"/> > <culture id="mittelreich"/> Besser hier auch Inhalte zulassen, einige wollen bestimmt einen "Dalmatier" spielen, obwohl sie die Werte eines "Garethers" nehmen ;-) > <description> > Alrik ist ... bla, bla > </description> ...was? :-) > <base-attributes> > <attribute id="MU"><AV base="9" effective="9"/></attribute> > ... > </base-attributes> Warum einen Effektiv-Wert angeben? Da wären die Modifikatoren besser. Was bringt mir der Effektivwert, wenn ich nicht weiß, wie der sich berechnet. > <derived-attributes> > ... > </derived-attributes> > <level-attributes> > <attribute id="ST"><AV base="1"/></attribute> > ... > </level-attributes> > <combat-attributes> [..] Wenn ich dich richtig verstehe, willst du die Berechnungsvorschiften aus der o.a. Datei lesen, dann brauche ich aber all dies nicht zu speichern weil klar ist, wie ich diese Werte erhalte. > <professions> > <profession id="mercenary" veteran="false" cost="10"/> > </professions> Mehrere Professionen? Veteran? Ähh... ?! > <advantages> > <advantage id="USER-ADVANTAGE-2f394e7a829" cost="10"> Wieso so ein merkwürdiger ID? Warum nicht einfach den Namen dafür verwenden, wie wir es hier schon besprochen hatten? > <name xml:lang>Schwertmeister</name> > <action on="calc" do="skill('swords').AT += 1"/> > <action on="calc" do="skill('swords').PA += 2"/> > </advantage> > <advantage id="lucky"/> Wenn man einen Vorteil nicht modifiziert, wird er nur als Referenz übernommen? OK, leuchtet ein und spart Platz. > <skills> > <skill id="swords"> > <SkV base="4" effective="4"/> Wenn effektive==base ist, brauchen wir's nicht anzugeben, oder? ;-) > <AT base="13" effective="14"/> > <PA base="11" effective="13"/> Schlecht, lieber: <AT base="3" add="AT_BASE"/> <PA base="2" add="PA_BASE"/> genau genommen ist die PA überflüssig, da PA=TaW-AT > </skill> > <skill > id="armor-tolerance-1" spec="plate-armor" > > > </skill> Dazu habe ich mir schon Gedanken gemacht. Wir sollten alle Ausrüstungsgegenstände in Klassen einteilen, wobei ein Gegenstand auch gleichzeitig mehreren Klassen angehören kann. Die Klassen wiederrum sind hierarchisch geordnet, damit lässt sich die Rüstungsgewohnung wunderbar beschreibung, aber auch die Begabung für ein Talent oder eine Talentgruppe etc. Bis dann, Alex -- Alexander Nofftz, Leverkusen, Germany http://www.AlexNofftz.de Ale...@em... |