Diskussion:XML Format

Zur Zeit findet die Diskussion auf der Magellan-Beta Mailingliste statt. Gib uns deine Email-Adresse hier als Kommentar, und wir fuegen dich dazu. Oder verlagern die Diskussion. Enno 10:58, 22. Apr 2008 (CEST)

Allgemeines

Nach dem Chat mit Sophie bin ich immer mehr der Auffassung, dass es gut ist, wenn ein Spiel einem Client "neue" Attribute senden kann, die er lesen kann ohne dass er dafuer neu geschrieben werden muss. Ich habe das mal unter Generelles näher ausgeführt. Zu Mechanismen, wie das geschehen kann, sollten wir noch ein paar Strategien entwickeln - SirPrize schlug vor, das gewisse Elemente auch mal ein CDATA enthalten koennen, dass man dem Client sozusagen als Fallback fuer's rendern komplexer Objekte mitgeben kann (optional). -- Enno

Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- Enno in Generelles

Bei item kann man sich schon wieder streiten. Im Unterschied zu allen anderen genannten hat es keinen key mit dem man den Silberhaufen von Objekt vom Silberhaufen von Objekt b unterscheiden kann. Nichtsdestotroz sind Item und Skill elementare Bestandteile eines Atlantis Pbem.

Um über diese Liste hinausgehende Spielobjekte mit unterschiedlichem key aber gleichem typ einzuführen sollten wir ein entsprechend allgemeines element formulieren, das prinzipiell auch die rolle jedes der aufgeführten elemente übernehmen könnte. Einfach um sicherzustellen, dass das Format flexibel bleibt. Spricht etwas gegen:

<gameobject id="hero_34535" type="hero">

Historische Daten

Jedes XML-Dokument beschreibt den Spielstand zu einem Zeitpunkt (eine Runde), nicht mehrere. Es gibt kein @turn Attribut. Um historische Daten zu verwenden, liest der Client mehrere XML-Dokuemnte (die z.b. als ZIP-Datei kompiliert sein koennen). -- Enno 16:47, 22. Apr 2008 (CEST)

Beschreiben wir nun mit einem Dokument einen Zeitpunkt oder beschreiben wir mit einem Dokument eine (sprachliche) Sichtweise zu einem Zeitpunkt? Ersteres würde heissen wir vereinigen Dokumente vom gleichen Zeitpunkt (turn) zum einem Dokument. Dabei gehen jedoch bereits Informationen verloren die man sonst "zwischen den Zeilen" lesen kann. Man denke hier an Unterschiede durch unterschiedliche Wahrnehmung. "Ich sehe was, das du nicht siehst ..." ;-)

Das Dokument so auszulegen, dass es mehr als eine Sprache und/oder Sichtweise gleichzeitig beschreiben kann, finde ich Overkill. Der Server braucht das jedenfalls nicht. Ein Client kann das tun, indem er mehrere Dokumente benutzt. Das werden mit der Zeit allerdings eine ganze Menge, und er sollte sich ueberlegen die historischen Dten, die er versteht, in einem kompakteren Format zwischenzuspeichern, das dann client-spezifisch sein wuerde. -- Enno

id vs. key

Wir benutzen das xml:id-Attribut, um die wichtigsten Spiel-Objekte eindeutig identifizieren zu können. Diese IDs werden vom Server vergeben, und der Client darf keinerlei Angaben ueber ihren Aufbau machen. Sie sind nicht identisch mit den Einheiten-Nummern, welche in einem key-Attribut gespeichert werden, welches keine eindeutige ID innerhalb des Dokuemntes ist (weil Parteien, Gebaeude, usw. den gleichen key haben koennen). Das key-Attribut ist ein alphanumerischer Wert, dessen Format fuer jedes Spiel anders aussehen kann. -- Enno 16:47, 22. Apr 2008 (CEST)

Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- Darcduck

Ich denke schon - aus The xml:id Conundrum zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- Enno

Davon abgesehen sollte es eine Logik geben nach der der Client diese IDs aus den key erzeugen kann, damit auch alte CRs in XML umgewandelt werden können -- Darcduck

Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- Enno

Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- Darcduck

Dann bekommt man aber Elemente, die in ihrem Namen keine Rolle haben. Und was ist denn die "shipref" einer Einheit? Das Schiff an dem sie gerade baut? Das auf dem sie steht? Das, welches sie verfolgt? Ich finde es besser, da nicht die Tatsache, dass das Element ein ref-Attribut hat, nochmal in den Namen reinzutun, und dafuer sonst kaum info zu haben. -- Enno

Ok, sehe ich ein, denken wir uns lieber Rollen aus. Ich habe halt im Hinterkopf nicht eine Inflation von Elementen auszulösen. die Rolle der Beziehung kann man theoretisch auch über ein Attribut mitgeben (Daten über Daten). -- Darcduck

Ja, das macht eventuell auch Sinn. Irgendwo muss man da einen halbwegs sauberen Bruch machen, sonst endet man bei der Form von XML-Report, die ich mal als 1:1 Umsetzung des CR-Formates entwichelt hatte: Wichtig: View Source. -- Enno

Jupp, das ist das andere Extrem. Das Problem ist halt, die Rolle in der eine Objektreferenz auftauchen kann, kann sehr vielfältig sein - und - wir kennen sie vielleicht noch gar nicht. Das gleiche Problem haben wir bei vielen kleinen Tags. Irgendwer kommt mal auf die Idee das eine Einheit eine Farbe haben kann ... was dann? -- Darcduck

Ich habe vorhin mal alle ids mit Punkten und Doppelpunkten im Namen ersetzt. Das aktuelle Format "unit_enn0", ist nicht garantiert, der Server bestimmt, was er da benutzt. Wer Lookups in der XML-Datei machen will, um eine spezielle Einheit zu finden, soll te das mit //unit[@key='enn0'] machen, nicht ueber die ID. -- Enno

<group/>

Es ist einfacher, die Gruppen nicht hierarchisch von der Partei abzuleiten. Erstens tut es der Eressea-Server auch nicht. Zweitens ist es hierarchsich viel aufwaendiger, festzustellen ob man eine Permission hat oder nicht. Und drittens wird das Format einfacher, wenn man es flach haelt. -- Enno

Dem Server will ich auch keine zusätzliche Last aufbürden. Zur Verwaltung der Helfe Stati wären Hierarchien aber hilfreich. Jeder der mehr als 2-3 Gruppen hat die auch "Frontnah" genutzt werden, kennt das Spiel. Neu verfeindetes Bündnis - HELFE Stati in allen Gruppen abändern. Ich habe einige Gruppen, die sich sehr ähnlich sind, und nur durch "ohne Helfe Silber" oder "ohne Helfe Kämpfe" von meinen Parteistati unterscheiden.

<alliance/>

Ich würde alliance nicht als Element für die Helfe Stati verwenden sondern für richtige "Parteigruppen" reservieren. Auch sowas soll es ja in Vinyambar schon gegeben haben. d.h. Ein Volk ist dann Teil genau einer (oder mehrerer Allianzen). Möglicherweise ist Allianz auch ein Konstrukt des Clients zur einfacheren Verwaltung der Helfe-Stati. -- Darcduck

Genau dafuer war es gedacht. -- Enno

Ich habe eben mit Sophie (Allnon/Menouthis) gesprochen. Da kam einiges brauchbares bei herum. Habe das mal unter ChatLog_Sophie abgelegt. Am wichtigsten finde ich dabei den Teil, der scih um die Implementation spielspezifischer Dinge kuemmert, die der Client unter Umstaenden nicht kennt, man ihn aber trotzdem anzeigen lassen kann, wenn man das Format schlau genug waehlt. -- Enno

<link/>

Ich frage mich, ob es sinnvoll ist, den verlinkten Typ mit zu spezifizieren, oder ob es reicht, dass der Client das herausfindet. Also z.B.

<link role="salesgood" type="item" ref="itemtype_wood"/>

Eigentlich sollte es ein leichtes sein, das rauszufinden. Und bei aehnlichen Objekten, z.B. <param/> oder sowas, tut man das ja auch nicht. Also Tendenz eher dagegen. -- Enno

Solange unsere Referenzen immer den Typ der Referenz am Anfang tragen ist es einfach, aber selbst ohne sollte es spätestens klar sein, wenn man auf das referenzierte Objekt zugreift. --Darcduck

Ich bin aber dagegen alle Referenzen nur über <link/> zu spezifizieren. Zumindest sollte man zwischen Reportobjekten und Regelobjekten unterscheiden. d.h. der Verweis auf die Faction zu der eine Unit gehört sollte anders aussehen als der Verweis auf einen Itemtyp von dem die Unit 10 Stück im Inventory hat. Wobei ich die Grundlegenden Dinge wie Gegenstände eines Reportobjekts nicht allgemein als <link/> sondern wirklich als <item/> verwenden würde. <item/> ist sozusagen die Abkürzung für <link type="item" .../> --Darcduck

Vielleicht hilft ein kompliziertes Beispiel um verschiedenste Notwendigkeiten der Struktur aufzudecken. Nehmen wir die Definition des Trankes Bauernblut. Der wird als Regel mit dem Report geschickt, wenn man ZEIGE Bauernblut macht. --Darcduck

<itemtype id="itemtype_Bauernblut">
  <name>Bauernblut</name>
  <descr>Man nehme ...</descr>
  <commands>
    <command role="make">
      <components>
        <item parent="unit" role="inventory" ref="itemtype_herbX">1</item>
        <item parent="unit" role="inventory" ref="itemtype_herbY">1</item>
        <item parent="unit" role="inventory" ref="itemtype_herbZ">1</item>
        <item parent="region" role="resource" ref="itemtype_peasant">1</item>
      </components>
      <skill ref="skilltype_alchemy">4</skill>
      <calc var="amount" function="make_potion_max">...???</calc>
      <syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax>
    </command>
    <command role="use">
      <syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax>
    </command>
  </commands>   
</itemtype>

Und hier wie eine Region aussehen könnte: --Darcduck

<region id="region_yyyyyy">
  <name/>
  ...
  <link role="seen_from_astral" ref="region_xxxxxx"/>
  ...
  <items>
    <item role="resource" ref="itemtype_peasant" amount="1000">
      <item role="recruit" ref="itemtype_peasant" amount="50"/>
    </item>
    <item role="resource" ref="itemtype_silver" amount="100000">
      <item role="entertain_max" ref="itemtype_silver" amount="10000"/>
      <item role="work_loan" ref="itemtype_silver" amount="12"/>
    </item>
    <item role="resource" ref="itemtype_wood" amount="1"/>
    <item role="resource" ref="itemtype_iron" amount="17" level="14"/>
    <item role="herb" ref="itemtype_flatroot" amount="many"/>
    <item role="sell" ref="itemtype_juwel" amount="10">
      <item role="price" ref="itemtype_silver" amount="7">
    </item>
    <item role="buy" ref="itemtype_balm" amount="10">
      <item role="price" ref="itemtype_silver" amount="32">
    </item>
  </items>
</region>

Hier ist also nur der doch recht Spielspezifische "Link" in den Astralraum als <link/> angegeben. Die Resourcen, Luxuswaren und andere Gegenstandbezogene Werte sind per <item/> verlinkt. Ob es allerdings Spass macht sich aus dem Kaudawelsch die handelbaren Güter, die Resourcen usw. rauszusuchen ist fraglich. Jede Art "item" das die Region uns bietet, ob mit Gegenleistung oder ohne lässt sich so auflisten. Unschön wird es aber schon bei den Handelswaren. Wie wir eine Art Handelsliste modellieren wollen, müssen wir anderswo noch diskutieren.

Ressourcen

Ich würde Ressourcen nicht als Gegenstände der Regionen betrachten, sondern eher als eigenes Objekt. Am deutlichsten sieht man das bei den Bauern, die sonst nie als Gegenstand auftreten Auch hat eine Region Bäume und kein Holz. Aber auch für die restlichen Ressourcen gelten andere Regeln, beim Eisen in Eressea etwa die talentabhängige Mengenbeschränkung, in Menouthis und Allanon gibt es Ressourcen in der Form Anzahl/Runde (50 Eisen pro Runde) und in allen Spielen gruppierte Ressourcen (Anzahl Holz ist Bäume + Schößlinge / 2). Für die gruppierten Ressourcen benutzt Menouthis sog. Manifestations (Der Ausschnitt ist aus der Konfigurationsdatei und nicht aus einem Report, daher auch ein paar eher interne Informationen):

<resource>
   <id>wood</id>
   <name lang="en">wood of the region</name>
   <name lang="de">Holz der Region</name>
   <singularname lang="en">wood of the region</singularname>
   <singularname lang="de">Holz der Region</singularname>
   <type>plant</type>
   <manifestation>
     <id>tree</id>
     <name lang="en">trees</name>
     <name lang="de">Bäume</name>
     <singularname lang="en">tree</singularname>
     <singularname lang="de">Baum</singularname>
     <uproot> !-- Bauern können die Ressource kaputt machen, wenn sie ihnen den Platz wegnimmt und sie die Voraussetzungen dafür haben (in dem Fall Kohle geschenkt bekommen) --
       <requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --
         <coproduct>
           <id>coal</id>
           <number>1/100</number>
         </coproduct>
       </requirement>
     </uproot>
     <weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --
     <reproductionchance>0.0004</reproductionchance>
     <reproductsto>seed</reproductsto>
     <spaceusage>0.01</spaceusage>
   </manifestation>
   <manifestation>
     <id>sapling</id>
     <name lang="en">saplings</name>
     <name lang="de">Schößlinge</name>
     <singularname lang="en">sapling</singularname>
     <singularname lang="de">Schößling</singularname>
     <uproot>
       <requirement>
         <coproduct>
           <id>coal</id>
           <number>1/1000</number>
         </coproduct>
       </requirement>
     </uproot>
     <weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--
     <growchance>0.002</growchance>
     <growsto>tree</growsto>
     <spaceusage>0.005</spaceusage>
   </manifestation>
   <manifestation>
     <id>seed</id>
     <name lang="en">seeds</name>
     <name lang="de">Samen</name>
     <singularname lang="en">seed</singularname>
     <singularname lang="de">Samen</singularname>
     <weight>0</weight>
     <growchance>0.002</growchance>
     <growsto>sapling</growsto>
     <spaceusage>0</spaceusage>
     <display>
       <requirement>
         <divine />
       </requirement>
     </display>
   </manifestation>
 </resource>

Im Report sollte an der entsprechenden Stelle also je nach Typ der Ressource und ihrer Manifestations (bislang: wegnehmen und weg, pro Runde, verschiedene Mengen für verschiedene Talentwerte) also ganz andere Repräsentationen der jeweilige Anzahl stehen --Sophie 14:15, 29. Apr 2008 (CEST)

Stimmt, das ist im Eressea-CR auch zwei verschiedene Sachen. Allerdings habe ich die Bauern nicht in den Ressourcen aufgeführt, auch wenn ich sie theoretisch so behandle. Aber Bäume zum Beispiel sind ja zwei verschiedene Ressource-typen, die beide Holz produzieren:

RESOURCE 1355696724
"Schößlinge";type
130;number
RESOURCE 1923739441
"Bäume";type
520;number

--Enno

Das kommt natürlich auf die Sichtweise an, ich sehe im Holzfall ein Item namens wood, das aus einer Resource namens wood hergestellt wird, welche aus zwei Manifestations namens tree und saplings besteht. Für die Werte im Regionsabschnitt kann man die Menouthissichtweise leicht in die Eresseasichtweise überführen, ein Problem könnte es bei der Beschreibung der Produktion des Itemtypes wood geben, denn ich stelle Holz ja nicht entweder aus Bäumen oder aus Schößlingen her, sondern durchaus aus beidem zusammengenommen.

Requirements

Wie Enno schon erwähnt hat, hat Menouthis ein relativ ausgefeiltes Requirementsystem, um Voraussetzungen aller Art zu beschreiben. Ursprünglich wurde es entwickelt um die Gegenstandsproduktion schön definieren zu können ist uns später aufgefallen, dass das Konzept eigentlich auch sonst an vielen Stellen vorkommt, es an den entsprechenden anderen Stellen auch zu verwenden macht einiges leichter. Daher stell ich jetzt einfach mal das grundlegende Konzept und die bisher so entwickelten Elemente vor:

Voraussetzungen werden logisch normalisiert, d.h. Es gibt <requirement /> Objekte deren Einzelbeschränkungen gleichzeitig erfüllt sein müssen. Eine Voraussetzung besteht dann aus mehreren dieser <requirement /> Objekte, von denen nur eines erfüllt werden muss. Der Server sucht automatisch nach der besten Alternative und verwendet diese.

Ein Requirement bekommt neben einer Einheit oder Region immer eine Zahl übergeben, die angibt, wie oft die Voraussetzung erfüllt werden soll (z.B. produzieren von mehr als einem Gegenstand), wobei "maximal viel" auch erlaubt ist. Wenn eine binäre Entscheidung benötigt wird, setzt man diese Zahl einfach auf 1. Ein Beispiel (Produktion von Korallen):

   <producerequirement>
     <requirement>
       <skill>
         <id>mining</id>
         <level>2</level>
       </skill>
       <race>aquan</race>
       <resource consume="false">
         <id>coral</id>
         <number>10</number>
       </resource>
     </requirement>
     <requirement>
       <skill>
         <id>mining</id>
         <level>3</level>
       </skill>
       <not>
         <requirement>
           <race>aquan</race>
         </requirement>
       </not>
       <resource consume="true">
         <id>coral</id>
         <number>1</number>
       </resource>
     </requirement>
   </producerequirement>

Korallen können also entweder schonend durch Aquaner abgebaut werden oder aber von allen anderen Rassen im Raubbau, wobei Aquaner pro 10 Regionskorallen einen Korallengegenstand bekommen, alle anderen für jede Koralle in der Region eine Koralle als Gegenstand. Weitere Beispiele gibt es in unserem svn (Benutzername svn, kein Passwort)

Die Elemente die wir so haben in Kurzvorstellung:

• <skill/>, <item consume="true/false"/>, <resource consume="true/false"/> sollten klar sein. <skill> zählt dabei als "Level der Einheit - benötigtes Level + 1"-mal erfüllt, hier sollte man allgemeinere Formeln zulassen können
• <race/>,<hero/>,<culture/>,<regiontype/>,<improvements/>,<ship/>,<regionship/>,<building/>,<regionbuilding/> Hier haben wir teilweise eine Ausnahme erlaubt: wenn diese Elemente mehrfach auftreten, zählen sie trotzdem als mit "oder" zu verknüpfen, wenn eine Einheit sowieso nicht mehrere dieser Typen auf einmal erfüllen kann. Außerdem handelt es sich bei allen diesen Typen um spielabhängige Dinge, die man im allgemeinen XML-Report als <link/> einfügen könnte.
• <not>,<accessablereq> Hierbei handelt es sich um geschachtelte Requirements, <not/> dürfte klar sein, <accessablereq/> ist ein Requirement, dass vom den Einsassen des Schiffs oder Gebäudes erfüllt werden müssen. Also zum Beispiel die Voraussetzungen um ein Schiff fahren zu dürfen.
• <divine/>,</regiononly/>,<unitonly/> Wichtige Steuerungsbefehle: <divine/> ist nie erfüllt, <unit/regiononly/> nur wenn eine Einheit/Region versucht das Requirement zu erfüllen. So kann man exklusive Bauernprodukte definieren
• <unit/> verbraucht oder reserviert Personen der Einheit, verbrauchen ist nur für eventuelle Steingolems oder ähnliches gedacht, das reservieren von Personen aus der Einheit dagegen hat viele Anwendungen, z.B. unabhängig vom Talentwert nur ein Gegenstand pro Person produzierbar, nur ein Wagen nutzbar etc.
• <fly/>,<swim/> die Einheit muss die Fähigkeit zu fliegen/schwimmen haben und eventuelle Kosten dafür zahlen. (Einmal auffliegen kostet eine Fee 1 Feenstaub)
• <money/> Geld wird hier nicht als Gegenstand betrachtet (Wenn man es trotzdem tut, mault Menouthis und hält einen Vortrag über VWL). Der Grund ist der, dass das Geld den Bauern übertragen wird und das Requirement fehlschlägt, wenn es keine Bauern hat. Ich würde dieses Element verallgemeinern (allgemeine Übergabe eines Items an die Bauern) oder nur für menouthisähnliche Wirtschaftssysteme benutzen, atlantisähnliche Systeme sehen das Vernichten von Geld ja standardmäßig vor.
• <random/>,<space/> Die beiden Elemente habe ich bisher nur für Regionsproduktionen benutzt: random enthält eine Wahrscheinlichkeit, mit der dann eine Bernoullikette ausgewertet wird, space reserviert Regionsplatz
• <multiplicator/>,<coproduct/> Diese Elemente sind keine Voraussetzungen im engeren Sinn: der Multiplikator multipliziert einfach am Ende das Ergebnis (z.B. ein Schreiner kann 10 Pfeile pro Level und Rohstoffsatz herstellen) die Coprodukte sind Nebenprodukte, die bei der Herstellung anfallen und beim Auswerten des Requirements der Einheit gutgeschrieben werden (zum Beispiel beim Schlachten von Kühen Leder, oder im Beispiel bei den Resourcen, beim Brandroden der Bauern Kohle)

So ist das System zur Zeit und es ist ganz sicher nicht perfekt (Allein die viel zu taglastige Darstellung sollte für eine mehr auf Attributen basierende Darstellung überarbeitet werden). Ich würde das Grundprinzip gern beibehalten, weil es ein sehr mächtiges und an vielen Stellen verwendbares Werkzeug ist (Im Ressourcenbeispiel oben sieht man z.B. das es auch regelt, wann eine Ressourcendefinition dem Spieler übermittelt wird, aber auch Unterhalt, Rekrutierung, Zauber, Heldwerdung, Transporterbedienung etc. benutzen alle genau diesen immergleichen Syntax).

Um das ganze für den XML-Report fit zu machen, sollten wir die Elemente einzeln überarbeiten (mehr Attribute, weniger Tags, was löst man wie mit einem link, in der Liste oben stehn noch mehr Sachen die mir nicht gefallen etc.) und eventuell verallgemeinern (<money/>) oder zusätzliche einbauen. --Sophie 16:35, 29. Apr 2008 (CEST)