https://wiki.eressea.de/api.php?action=feedcontributions&user=Sophie&feedformat=atomEressea - Benutzerbeiträge [de]2024-03-28T22:04:31ZBenutzerbeiträgeMediaWiki 1.41.0https://wiki.eressea.de/index.php?title=XML_Format/Menouthisbeispiel&diff=2338XML Format/Menouthisbeispiel2008-05-14T21:17:03Z<p>Sophie: </p>
<hr />
<div>Beispiel eines Menouthisreports im [[XML Format]]<br />
&lt;?xml version="1.0" encoding="UTF-8"?&gt;<br />
&lt;atlantis rules="menouthis" lang="de"&gt; &lt;!-- Attribut lang nicht in der DTD bisher! --&gt;<br />
&lt;server&gt;<br />
&lt;uri&gt;mailto:befehle@menouthis.net&lt;/uri&gt;<br />
&lt;subject&gt;menouthis kapiteli check&lt;/subject&gt;<br />
&lt;evaluation&gt;donnerstags 20 Uhr&lt;/evaluation&gt;<br />
&lt;/server&gt;<br />
&lt;turn&gt; &lt;!-- fehlt noch in der Spezifikation! Eventuell überarbeitungsbedürftig, nicht jedes Spiel nimmt unbedingt Jahr, Monat, Jahreszeit, vielleicht einfach alles mögliche als optionales Element --&gt;<br />
&lt;number&gt;17&lt;/number&gt;<br />
&lt;year&gt;2&lt;/year&gt;<br />
&lt;month&gt;Juni&lt;/month&gt;<br />
&lt;season&gt;Sommer&lt;/season&gt;<br />
&lt;/turn&gt;<br />
&lt;faction id="faction_2" key="2"&gt; &lt;!-- hier die Frage: sollte die eigene Partei irgendwie ausgezeichnet sein? Nachteil: Mergen verschiedener Parteien würde infos vernichten, aber ich halte mergen ja sowieso für Doppelspiel :) --&gt;<br />
&lt;message id="message_1"&gt;<br />
&lt;link role="type" ref="goal" /&gt;<br />
&lt;text&gt;Ziel des Spiels:<br />
Kapitel I: Die Aufdämmerung<br />
Von der Inselgruppe entkommen<br />
Baue ein Karavellen&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;message&gt;<br />
&lt;link role="type" ref="syntaxerror" /&gt;<br />
&lt;text&gt;Ein &lt;link role="unit" ref="6"&gt;Händler (6)&lt;/link&gt; hat nicht genug &lt;link role="item" ref="scythe"&gt;Sensen&lt;/link&gt; zu verkaufen.&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;message&gt;<br />
&lt;link role="type" ref="sell" /&gt;<br />
&lt;text&gt;Ein &lt;link role="unit" ref="6"&gt;Händler (6)&lt;/link&gt; verkaufte &lt;link role="soldnumber" ref="100"&gt;100&lt;/link&gt; &lt;link role="solditem" ref="wood"&gt;Holzstämme&lt;/link&gt; für &lt;link role="moneynumber" ref="549"&gt;549&lt;/link&gt; &lt;link role="moneyitem" ref="guilder"&gt;Gulden&lt;/link&gt;.&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;status type="ordergap"&gt;0&lt;/status&gt;<br />
&lt;status type="age"&gt;0&lt;/status&gt;<br />
&lt;diplomacy ref="faction_npc0"&gt;<br />
&lt;state type="move" /&gt;<br />
&lt;state type="stealth" /&gt;<br />
&lt;/diplomacy&gt;<br />
&lt;name lang="en"&gt;faction of report&lt;/name&gt;<br />
&lt;name lang="de"&gt;Partei des Testreports&lt;/name&gt;<br />
&lt;link role="race" ref="fairy" /&gt;<br />
&lt;status type="address"&gt;sophie@menouthis.net&lt;/status&gt;<br />
&lt;status type="lang"&gt;de&lt;/status&gt;<br />
&lt;status type="password"&gt;ue.4Jgs9&lt;/status&gt;<br />
&lt;status type="maxemigrants"&gt;0&lt;/status&gt;<br />
&lt;status type="option"&gt;nr&lt;/status&gt;<br />
&lt;status type="option"&gt;cr&lt;/status&gt; &lt;!-- Darf der gleiche Status mehrfach auftreten? --&gt;<br />
&lt;!-- &lt;heroes&gt; Wie modelliere ich das?<br />
&lt;heronumber&gt;<br />
&lt;id&gt;sorcerer&lt;/id&gt;<br />
&lt;number&gt;1&lt;/number&gt;<br />
&lt;maxnum&gt;4&lt;/maxnum&gt;<br />
&lt;/heronumber&gt;<br />
&lt;/heroes&gt; --&gt;<br />
&lt;effect name="Verrückter Zauber" desc="Alle Einheiten dieser Partei erhalten +1 auf alle Talente" /&gt; &lt;!-- Dieses Element ist noch nicht spezifiziert, ich hätte es gern für jedes gameobject--&gt;<br />
&lt;/faction&gt;<br />
&lt;faction id="faction_npc3" key="npc3"&gt;<br />
&lt;status type="age"&gt;0&lt;/status&gt;<br />
&lt;name lang="en"&gt;undeads&lt;/name&gt;<br />
&lt;name lang="de"&gt;Untote&lt;/name&gt;<br />
&lt;desc lang="en"&gt;The foul unholy souls, driven only by hate of every living creature.&lt;/desc&gt;<br />
&lt;desc lang="de"&gt;Die unheiligen verfluchten Seelen, getrieben von undenkbarem Hass auf alles Lebende&lt;/desc&gt;<br />
&lt;link role="race" ref="skeleton" /&gt;<br />
&lt;status type="language"&gt;en&lt;/status&gt;<br />
&lt;status type="factionsetting"&gt;npc&lt;/status&gt;<br />
&lt;/faction&gt;<br />
&lt;region id="region_1"&gt;<br />
&lt;coordinates x="-1" y="1"/&gt;<br />
&lt;link role="type" ref="ocean" /&gt;<br />
&lt;status type="seen"&gt;old&lt;/status&gt;<br />
&lt;/region&gt;<br />
&lt;region id="region_2"&gt;<br />
&lt;coordinates x="0" y="1"/&gt;<br />
&lt;link role="type" ref="mountain" /&gt;<br />
&lt;name&gt;Dyhu&lt;/name&gt;<br />
&lt;status type="seen"&gt;current&lt;/status&gt;<br />
&lt;/region&gt;<br />
&lt;region id="region_3"&gt;<br />
&lt;coordinates x="0" y="0"/&gt;<br />
&lt;link role="type" ref="savannah" /&gt;<br />
&lt;name&gt;Sirvolfas&lt;/name&gt;<br />
&lt;status type="seen"&gt;full&lt;/status&gt;<br />
&lt;status type="jobs"&gt;305&lt;/status&gt;<br />
&lt;!--&lt;resources&gt; <br />
&lt;resource&gt;<br />
&lt;id&gt;wood&lt;/id&gt;<br />
&lt;manifestation id="tree"&gt;573&lt;/manifestation&gt;<br />
&lt;manifestation id="sapling"&gt;761&lt;/manifestation&gt;<br />
&lt;/resource&gt;<br />
&lt;resource&gt;<br />
&lt;id&gt;peasant&lt;/id&gt;<br />
&lt;manifestation id="peasant"&gt;310&lt;/manifestation&gt;<br />
&lt;/resource&gt;<br />
&lt;resource&gt;<br />
&lt;id&gt;recruit&lt;/id&gt;<br />
&lt;number&gt;9&lt;/number&gt;<br />
&lt;/resource&gt;<br />
&lt;/resources&gt; Zur genaueren Diskussion! --&gt;<br />
&lt;status type="moneytype"&gt;kreuzer&lt;/status&gt;<br />
&lt;status type="entertainmoney"&gt;77042&lt;/status&gt;<br />
&lt;items&gt;<br />
&lt;item type="guilder"&gt;15408&lt;/item&gt;<br />
&lt;item type="kreuzer"&gt;46&lt;/item&gt;<br />
&lt;item type="wood"&gt;300&lt;/item&gt;<br />
&lt;/items&gt;<br />
&lt;!--<br />
Hier fehlt auch eine genauere Spezifikation, eine Art link mit mehr Argumenten wäre gut<br />
&lt;improvements&gt;<br />
&lt;improvement type="stockfarm"&gt;<br />
&lt;number&gt;1&lt;/number&gt;<br />
&lt;/improvement&gt;<br />
&lt;improvement type="village"&gt;<br />
&lt;number&gt;6&lt;/number&gt;<br />
&lt;/improvement&gt;<br />
&lt;/improvements&gt;--&gt;<br />
&lt;!-- Hier das gleiche, ein link mit mehreren Argumenten würde ausreichen<br />
&lt;roads&gt;<br />
&lt;road&gt;<br />
&lt;type&gt;cobblestone&lt;/type&gt;<br />
&lt;size dir="nw"&gt;15&lt;/size&gt;<br />
&lt;/road&gt;<br />
&lt;/roads&gt;--&gt;<br />
&lt;trade&gt;<br />
&lt;offer amount="10"&gt;<br />
&lt;item role="trade_get" ref="wood" amount="1" /&gt;<br />
&lt;item role="trade_give" ref="kreuzer" amount="500" /&gt;<br />
&lt;/offer&gt;<br />
&lt;offer amount="400"&gt;<br />
&lt;item role="trade_get" ref="kreuzer" amount="40" /&gt;<br />
&lt;item role="trade_give" ref="grain" amount="1" /&gt;<br />
&lt;/offer&gt;<br />
&lt;/trade&gt;<br />
&lt;status type="governor"&gt;2&lt;/status&gt;<br />
&lt;!-- und wieder ein Link mit mehreren Argumenten nötig<br />
&lt;rights&gt;<br />
&lt;stayright number="-1" tax="200" taxitem="kreuzer" /&gt;<br />
&lt;stayright number="-1" tax="100" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;entertainright number="-1" tax="500" taxitem="kreuzer" /&gt;<br />
&lt;entertainright number="-1" tax="0" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;productionright item="weapon" number="-1" tax="500" taxitem="kreuzer" /&gt;<br />
&lt;traderight item="weapon" number="0" mode="buy" tax="0" taxitem="kreuzer" /&gt;<br />
&lt;traderight item="weapon" number="-1" mode="buy" tax="0" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;/rights&gt;--&gt;<br />
&lt;unit id="unit_4" key="4"&gt;<br />
&lt;link role="faction" ref="2" /&gt;<br />
&lt;status type="number"&gt;10&lt;/status&gt;<br />
&lt;status type="weight"&gt;250.0&lt;/status&gt;<br />
&lt;status type="hp"&gt;400&lt;/status&gt;<br />
&lt;status type="fightstate"&gt;not&lt;/status&gt;<br />
&lt;name lang="en"&gt;Wachtrupp&lt;/name&gt;<br />
&lt;name lang="de"&gt;Wachtrupp&lt;/name&gt;<br />
&lt;status type="guards"&gt;1&lt;/status&gt;<br />
&lt;skills&gt;<br />
&lt;skill type="pole" level="7" efflevel="5" learningdays="9131" /&gt;<br />
&lt;/skills&gt;<br />
&lt;items&gt;<br />
&lt;item type="fairydust" amount="50" /&gt; &lt;!-- Hier ein Alternativer item Vorschlag, der besser zum trade passt --&gt;<br />
&lt;item type="spear" amount="10" /&gt;<br />
&lt;/items&gt;<br />
&lt;!-- Wieder mehrere Argumente :/<br />
&lt;capacity range="1"&gt;350.0&lt;/capacity&gt;<br />
&lt;capacity range="2"&gt;270.0&lt;/capacity&gt;<br />
&lt;capacity range="3"&gt;270.0&lt;/capacity&gt;--&gt;<br />
&lt;commands&gt; &lt;!-- Das würde ich direkt so lassen --&gt;<br />
&lt;command&gt;bewache&lt;/command&gt;<br />
&lt;/commands&gt;<br />
&lt;/unit&gt;<br />
&lt;ship id="accessable_4" key="4"&gt;<br />
&lt;link role="type" ref="boat" /&gt;<br />
&lt;status type="build"&gt;5&lt;/status&gt;<br />
&lt;name lang="de"&gt;Kleines Schiff&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/ship&gt;<br />
&lt;caravan id="accessable_3" key="3"&gt; &lt;!-- eventuell besser: &lt;gameobject type="caravan" id="accessable_3" key="3"&gt;--&gt;<br />
&lt;name lang="de"&gt;Kleine Karawane&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/caravan&gt;<br />
&lt;building id="accessble_2" key="2"&gt;<br />
&lt;link role="type" ref="outpost" /&gt;<br />
&lt;status type="build"&gt;28&lt;/status&gt;<br />
&lt;name lang="de"&gt;Außenposten des Testreports&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/building&gt;<br />
&lt;/region&gt;<br />
&lt;/atlantis&gt;</div>Sophiehttps://wiki.eressea.de/index.php?title=XML_Format/Menouthisbeispiel&diff=2337XML Format/Menouthisbeispiel2008-05-14T21:16:26Z<p>Sophie: </p>
<hr />
<div> &lt;?xml version="1.0" encoding="UTF-8"?&gt;<br />
&lt;atlantis rules="menouthis" lang="de"&gt; &lt;!-- Attribut lang nicht in der DTD bisher! --&gt;<br />
&lt;server&gt;<br />
&lt;uri&gt;mailto:befehle@menouthis.net&lt;/uri&gt;<br />
&lt;subject&gt;menouthis kapiteli check&lt;/subject&gt;<br />
&lt;evaluation&gt;donnerstags 20 Uhr&lt;/evaluation&gt;<br />
&lt;/server&gt;<br />
&lt;turn&gt; &lt;!-- fehlt noch in der Spezifikation! Eventuell überarbeitungsbedürftig, nicht jedes Spiel nimmt unbedingt Jahr, Monat, Jahreszeit, vielleicht einfach alles mögliche als optionales Element --&gt;<br />
&lt;number&gt;17&lt;/number&gt;<br />
&lt;year&gt;2&lt;/year&gt;<br />
&lt;month&gt;Juni&lt;/month&gt;<br />
&lt;season&gt;Sommer&lt;/season&gt;<br />
&lt;/turn&gt;<br />
&lt;faction id="faction_2" key="2"&gt; &lt;!-- hier die Frage: sollte die eigene Partei irgendwie ausgezeichnet sein? Nachteil: Mergen verschiedener Parteien würde infos vernichten, aber ich halte mergen ja sowieso für Doppelspiel :) --&gt;<br />
&lt;message id="message_1"&gt;<br />
&lt;link role="type" ref="goal" /&gt;<br />
&lt;text&gt;Ziel des Spiels:<br />
Kapitel I: Die Aufdämmerung<br />
Von der Inselgruppe entkommen<br />
Baue ein Karavellen&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;message&gt;<br />
&lt;link role="type" ref="syntaxerror" /&gt;<br />
&lt;text&gt;Ein &lt;link role="unit" ref="6"&gt;Händler (6)&lt;/link&gt; hat nicht genug &lt;link role="item" ref="scythe"&gt;Sensen&lt;/link&gt; zu verkaufen.&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;message&gt;<br />
&lt;link role="type" ref="sell" /&gt;<br />
&lt;text&gt;Ein &lt;link role="unit" ref="6"&gt;Händler (6)&lt;/link&gt; verkaufte &lt;link role="soldnumber" ref="100"&gt;100&lt;/link&gt; &lt;link role="solditem" ref="wood"&gt;Holzstämme&lt;/link&gt; für &lt;link role="moneynumber" ref="549"&gt;549&lt;/link&gt; &lt;link role="moneyitem" ref="guilder"&gt;Gulden&lt;/link&gt;.&lt;/text&gt;<br />
&lt;/message&gt;<br />
&lt;status type="ordergap"&gt;0&lt;/status&gt;<br />
&lt;status type="age"&gt;0&lt;/status&gt;<br />
&lt;diplomacy ref="faction_npc0"&gt;<br />
&lt;state type="move" /&gt;<br />
&lt;state type="stealth" /&gt;<br />
&lt;/diplomacy&gt;<br />
&lt;name lang="en"&gt;faction of report&lt;/name&gt;<br />
&lt;name lang="de"&gt;Partei des Testreports&lt;/name&gt;<br />
&lt;link role="race" ref="fairy" /&gt;<br />
&lt;status type="address"&gt;sophie@menouthis.net&lt;/status&gt;<br />
&lt;status type="lang"&gt;de&lt;/status&gt;<br />
&lt;status type="password"&gt;ue.4Jgs9&lt;/status&gt;<br />
&lt;status type="maxemigrants"&gt;0&lt;/status&gt;<br />
&lt;status type="option"&gt;nr&lt;/status&gt;<br />
&lt;status type="option"&gt;cr&lt;/status&gt; &lt;!-- Darf der gleiche Status mehrfach auftreten? --&gt;<br />
&lt;!-- &lt;heroes&gt; Wie modelliere ich das?<br />
&lt;heronumber&gt;<br />
&lt;id&gt;sorcerer&lt;/id&gt;<br />
&lt;number&gt;1&lt;/number&gt;<br />
&lt;maxnum&gt;4&lt;/maxnum&gt;<br />
&lt;/heronumber&gt;<br />
&lt;/heroes&gt; --&gt;<br />
&lt;effect name="Verrückter Zauber" desc="Alle Einheiten dieser Partei erhalten +1 auf alle Talente" /&gt; &lt;!-- Dieses Element ist noch nicht spezifiziert, ich hätte es gern für jedes gameobject--&gt;<br />
&lt;/faction&gt;<br />
&lt;faction id="faction_npc3" key="npc3"&gt;<br />
&lt;status type="age"&gt;0&lt;/status&gt;<br />
&lt;name lang="en"&gt;undeads&lt;/name&gt;<br />
&lt;name lang="de"&gt;Untote&lt;/name&gt;<br />
&lt;desc lang="en"&gt;The foul unholy souls, driven only by hate of every living creature.&lt;/desc&gt;<br />
&lt;desc lang="de"&gt;Die unheiligen verfluchten Seelen, getrieben von undenkbarem Hass auf alles Lebende&lt;/desc&gt;<br />
&lt;link role="race" ref="skeleton" /&gt;<br />
&lt;status type="language"&gt;en&lt;/status&gt;<br />
&lt;status type="factionsetting"&gt;npc&lt;/status&gt;<br />
&lt;/faction&gt;<br />
&lt;region id="region_1"&gt;<br />
&lt;coordinates x="-1" y="1"/&gt;<br />
&lt;link role="type" ref="ocean" /&gt;<br />
&lt;status type="seen"&gt;old&lt;/status&gt;<br />
&lt;/region&gt;<br />
&lt;region id="region_2"&gt;<br />
&lt;coordinates x="0" y="1"/&gt;<br />
&lt;link role="type" ref="mountain" /&gt;<br />
&lt;name&gt;Dyhu&lt;/name&gt;<br />
&lt;status type="seen"&gt;current&lt;/status&gt;<br />
&lt;/region&gt;<br />
&lt;region id="region_3"&gt;<br />
&lt;coordinates x="0" y="0"/&gt;<br />
&lt;link role="type" ref="savannah" /&gt;<br />
&lt;name&gt;Sirvolfas&lt;/name&gt;<br />
&lt;status type="seen"&gt;full&lt;/status&gt;<br />
&lt;status type="jobs"&gt;305&lt;/status&gt;<br />
&lt;!--&lt;resources&gt; <br />
&lt;resource&gt;<br />
&lt;id&gt;wood&lt;/id&gt;<br />
&lt;manifestation id="tree"&gt;573&lt;/manifestation&gt;<br />
&lt;manifestation id="sapling"&gt;761&lt;/manifestation&gt;<br />
&lt;/resource&gt;<br />
&lt;resource&gt;<br />
&lt;id&gt;peasant&lt;/id&gt;<br />
&lt;manifestation id="peasant"&gt;310&lt;/manifestation&gt;<br />
&lt;/resource&gt;<br />
&lt;resource&gt;<br />
&lt;id&gt;recruit&lt;/id&gt;<br />
&lt;number&gt;9&lt;/number&gt;<br />
&lt;/resource&gt;<br />
&lt;/resources&gt; Zur genaueren Diskussion! --&gt;<br />
&lt;status type="moneytype"&gt;kreuzer&lt;/status&gt;<br />
&lt;status type="entertainmoney"&gt;77042&lt;/status&gt;<br />
&lt;items&gt;<br />
&lt;item type="guilder"&gt;15408&lt;/item&gt;<br />
&lt;item type="kreuzer"&gt;46&lt;/item&gt;<br />
&lt;item type="wood"&gt;300&lt;/item&gt;<br />
&lt;/items&gt;<br />
&lt;!--<br />
Hier fehlt auch eine genauere Spezifikation, eine Art link mit mehr Argumenten wäre gut<br />
&lt;improvements&gt;<br />
&lt;improvement type="stockfarm"&gt;<br />
&lt;number&gt;1&lt;/number&gt;<br />
&lt;/improvement&gt;<br />
&lt;improvement type="village"&gt;<br />
&lt;number&gt;6&lt;/number&gt;<br />
&lt;/improvement&gt;<br />
&lt;/improvements&gt;--&gt;<br />
&lt;!-- Hier das gleiche, ein link mit mehreren Argumenten würde ausreichen<br />
&lt;roads&gt;<br />
&lt;road&gt;<br />
&lt;type&gt;cobblestone&lt;/type&gt;<br />
&lt;size dir="nw"&gt;15&lt;/size&gt;<br />
&lt;/road&gt;<br />
&lt;/roads&gt;--&gt;<br />
&lt;trade&gt;<br />
&lt;offer amount="10"&gt;<br />
&lt;item role="trade_get" ref="wood" amount="1" /&gt;<br />
&lt;item role="trade_give" ref="kreuzer" amount="500" /&gt;<br />
&lt;/offer&gt;<br />
&lt;offer amount="400"&gt;<br />
&lt;item role="trade_get" ref="kreuzer" amount="40" /&gt;<br />
&lt;item role="trade_give" ref="grain" amount="1" /&gt;<br />
&lt;/offer&gt;<br />
&lt;/trade&gt;<br />
&lt;status type="governor"&gt;2&lt;/status&gt;<br />
&lt;!-- und wieder ein Link mit mehreren Argumenten nötig<br />
&lt;rights&gt;<br />
&lt;stayright number="-1" tax="200" taxitem="kreuzer" /&gt;<br />
&lt;stayright number="-1" tax="100" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;entertainright number="-1" tax="500" taxitem="kreuzer" /&gt;<br />
&lt;entertainright number="-1" tax="0" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;productionright item="weapon" number="-1" tax="500" taxitem="kreuzer" /&gt;<br />
&lt;traderight item="weapon" number="0" mode="buy" tax="0" taxitem="kreuzer" /&gt;<br />
&lt;traderight item="weapon" number="-1" mode="buy" tax="0" taxitem="kreuzer" faction="npc2" /&gt;<br />
&lt;/rights&gt;--&gt;<br />
&lt;unit id="unit_4" key="4"&gt;<br />
&lt;link role="faction" ref="2" /&gt;<br />
&lt;status type="number"&gt;10&lt;/status&gt;<br />
&lt;status type="weight"&gt;250.0&lt;/status&gt;<br />
&lt;status type="hp"&gt;400&lt;/status&gt;<br />
&lt;status type="fightstate"&gt;not&lt;/status&gt;<br />
&lt;name lang="en"&gt;Wachtrupp&lt;/name&gt;<br />
&lt;name lang="de"&gt;Wachtrupp&lt;/name&gt;<br />
&lt;status type="guards"&gt;1&lt;/status&gt;<br />
&lt;skills&gt;<br />
&lt;skill type="pole" level="7" efflevel="5" learningdays="9131" /&gt;<br />
&lt;/skills&gt;<br />
&lt;items&gt;<br />
&lt;item type="fairydust" amount="50" /&gt; &lt;!-- Hier ein Alternativer item Vorschlag, der besser zum trade passt --&gt;<br />
&lt;item type="spear" amount="10" /&gt;<br />
&lt;/items&gt;<br />
&lt;!-- Wieder mehrere Argumente :/<br />
&lt;capacity range="1"&gt;350.0&lt;/capacity&gt;<br />
&lt;capacity range="2"&gt;270.0&lt;/capacity&gt;<br />
&lt;capacity range="3"&gt;270.0&lt;/capacity&gt;--&gt;<br />
&lt;commands&gt; &lt;!-- Das würde ich direkt so lassen --&gt;<br />
&lt;command&gt;bewache&lt;/command&gt;<br />
&lt;/commands&gt;<br />
&lt;/unit&gt;<br />
&lt;ship id="accessable_4" key="4"&gt;<br />
&lt;link role="type" ref="boat" /&gt;<br />
&lt;status type="build"&gt;5&lt;/status&gt;<br />
&lt;name lang="de"&gt;Kleines Schiff&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/ship&gt;<br />
&lt;caravan id="accessable_3" key="3"&gt; &lt;!-- eventuell besser: &lt;gameobject type="caravan" id="accessable_3" key="3"&gt;--&gt;<br />
&lt;name lang="de"&gt;Kleine Karawane&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/caravan&gt;<br />
&lt;building id="accessble_2" key="2"&gt;<br />
&lt;link role="type" ref="outpost" /&gt;<br />
&lt;status type="build"&gt;28&lt;/status&gt;<br />
&lt;name lang="de"&gt;Außenposten des Testreports&lt;/name&gt;<br />
&lt;units&gt;<br />
&lt;!-- Weitere Unitobjecte --&gt;<br />
&lt;/units&gt;<br />
&lt;/building&gt;<br />
&lt;/region&gt;<br />
&lt;/atlantis&gt;</div>Sophiehttps://wiki.eressea.de/index.php?title=XML_Format&diff=2336XML Format2008-05-14T21:08:41Z<p>Sophie: /* Beispiel Report */</p>
<hr />
<div>Anstatt sofort einen DTD zu definieren (die Dinger kann eh kaum jemand lesen) arbeiten wir hier ein Beispiel-Dokument aus, und diskutieren darüber.<br />
<br />
== Generelles ==<br />
<br />
Das Format soll es u.a. erlauben, einen Client zu entwickeln der weitestgehend Spiel-agnostisch ist, und trotzdem in der Lage moeglichst viel des Spielstandes fuer den Spieler sichtbar zu machen. Das bedeutet, dass man sich eher auf weniger Elemente festlegt, die ein Client dann jeweils in einer "Default" Implementation behandeln kann.<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. Bei Schiffen kann man eventuell auf allgemeine Transporter verallgemeinern, aber fuer alle Objekte gilt, dass sie sich in ihrere Art und ihrere Darstellung stark genug voneinander unterschieden.<br />
<br />
Einige Beispiele, wo weniger Elemente besser sind:<br />
<region><resource ref="wood"/></region><br />
... ist besser als ...<br />
<region><wood/></region><br />
Weil ein Client, der Ressourcen darstellen kann auch ohne Wissen um die Resource Holz einen Fallback machen kann ("wood" in den Localization-Ressourcen nach Icon + Name durchsuchen) als mit einem <wood/> Element, das er nicht kennt. Mal ganz abgesehen davon, dass jede neue Ressource eine Aenderung am DTD verursacht.<br />
<br />
<ship><link role="captain" ref="unit_546"/></ship><br />
<br />
Hier kann der Regel-agnostische Client immerhin noch das Icon des referenzierten Objektes, seinen Schlüssel und evtl. den Namen, darstellen, selbst wenn er mit dem Begriff "Kapitän" nichts anzufangen weiß. Wenn er es natürlich kennt, kann er spielspezifisch darauf reagieren (und z.B. testen ob der Kapitaen der Schiff-betretenden Einheit ein HELFE setzt, o.ä.<br />
<br />
=== IDs und Referenzen ===<br />
* Elemente die wir mit IDs versehen verwenden das standardisierte [http://www.w3.org/TR/xml-id/ xml:id] Attribut.<br />
<br />
==== Spielobjekte (Regionen, Einheiten, Schiffe, Burgen, ...) ====<br />
<br />
... also Objekte die in Atlantis-ähnlichen Spielen eine id haben. Um diese im Spiel anzusprechen, erhalten sie zusätzlich zur xml:id das Attribut key. Das xml:id Attribut kann, muss aber nicht, den key als Teil der id verwenden.<br />
<br />
Beispiele:<br />
<unit xml:id="unit_raLf" key="raLf">...<br />
<ship xml:id="ship_12f4" key="12f4">...<br />
<unit xml:id="ddff556787u" key="enno">...<br />
<br />
* Wird der XML-Report vom Server erzeugt, werden die xml:id vom Server vorgegeben.<br />
* Wird der XML-Report aus einem anderen Format konvertiert, welches keine global eindeutigen ids hat (CR), dann sollte der client <elementname>_<key> als xml:id generieren.<br />
* Referenzen auf diese Elemente sollten ein einheitliches Attribut verwenden, z.b. ref<br />
<br />
<memberof ref="faction_bgz7"/><br />
<br />
==== Regelobjekte (Gegenstände, Talente, Resourcen, Rassen, Terrain ...) ====<br />
... also mögliche Typen die üblicherweise in den Regeln definiert werden. Im Report wird, wenn überhaupt möglich, nur darauf referenziert.<br />
<br />
Beispiel in der Regeldatei:<br />
<itemtype xml:id="itemtype_wateroflife">...<br />
<skilltype xml:id="skilltype_perception">...<br />
<br />
* Referenzen auf diese "Typ"-Elemente sollten ein einheitliches Attribut verwenden, z.b. type<br />
* Elemente tragen nach Möglichkeit die Bezeichnung ihrer "Rolle". Wobei <item> den Besitz/vorhandensein eines Gegenstandes des Typ <itemtype> meint. Gleiches gilt für <skill>.<br />
<br />
<items><br />
<item type="itemtype_wateroflife">12</item><br />
</items><br />
<skills><br />
<skill type="skilltype_perception"><level>12</level></skill><br />
</skills> <br />
<br />
* ggf. macht es sinn itemtype als item zu bezeichnen und das Halten eines Gegenstandes doch unter einem anderen element abzulegen. (z.b. hasitem) - meinungen gefragt ...<br />
<br />
=== Lokalisierung ===<br />
* Es sollte das Attribut xml:lang verwendet werden. Elemente die dieses Attribut erlauben, sollten generell auch mehrfach auftauchen dürfen. Problematisch ist der Umgang wenn man mehrfach die gleiche sprache angibt.<br />
* Elemente die so etwas unterstützen könnten:<br />
<name ...>...<br />
<descr ...>...<br />
<text ...>...<br />
<keytext ...>... <br />
<pattern ...>...<br />
<br />
=== Datierung ===<br />
Fürs erste haben wir uns gegen eine Datierung von einzelnen Elementen entschieden. Ein Report erhält daher global ein Datum, und gibt den Status zu diesem Datum wieder<br />
<br />
<br />
<br />
== Beispiel Report ==<br />
[[XML Format/Menouthisbeispiel|Komplettbeispiel für Menouthis mit Anmerkungen]]<br />
{|<br />
|colspan="2"|<br />
=== Header und Serverinfos ===<br />
|-<br />
|<pre><br />
<!DOCTYPE atlantis PUBLIC "-//PBEM//DTD Atlantis 1.0//EN" <br />
"http://eressea.de/atlantis-report.dtd"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<atlantis rules="eressea"><br />
<br />
<server><br />
<uri>mailto:eressea-server@eressea.kn-bremen.de</uri><br />
<subject>ERESSEA BEFEHLE</subject><br />
</server><br />
</pre><br />
|<br />
* DTD - machen wir eine DTD für alle Spiele oder gibt es eine Grundlagen-DTD und dann spielspezifische DTD?<br />
* Version und Encoding<br />
* Benutztes Regelset<br />
|-<br />
|colspan="2"|<br />
=== Allianzen ===<br />
|-<br />
|<br />
<alliance id="alliance_1245" key="1245"><br />
???<br />
<helpstatus set="59"/><br />
<helpstatus ref="faction_1234" set="59"/><br />
<helpstatus ref="alliance_badg" set="1"/><br />
</alliance><br />
|<br />
* 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. <br />
|-<br />
|colspan="2"|<br />
<br />
=== Parteien ===<br />
|-<br />
|<br />
<faction id="faction_Lotr" key="Lotr"><br />
<name>xxxxx</name><br />
<descr>dsfsf sdf sdf</descr><br />
<type role="race" ref="race_aquarians"/><br />
<type role="magic" ref="magic_gwyrrd"/><br />
<type role="culture" ref="culture_mechanics"/><br />
<status type="age">60</status><br />
<status type="points">12345</status><br />
<status type="avgpoints">10000</status><br />
<items><br />
<item type="item_birthdaycake">1</item><br />
</items><br />
|<br />
* Kultur und Magiegebiet könnten auch Referenzen sein ... to be discussed.<br />
* Alter, Punkte usw. würde ich gar nicht gesondert erfassen. <br />
* Parteien können items haben. <br />
|-<br />
|colspan="2"|<br />
<br />
=== Allianzen (HELFE Stati) ===<br />
|-<br />
|<br />
<helpstatus ref="faction_1234" set="59"/><br />
<diplomacy ref="faction_1234"><br />
<state type="state_help_silver"/><br />
<state type="state_help_guard"/><br />
<state type="state_help_give"/><br />
<state type="state_help_defend"/><br />
<state type="state_help_attack"/><br />
<state type="state_forbid_trade"/><br />
<state type="state_forbid_recruit"/><br />
<state type="state_warn_nmr"/><br />
<state type="state_send_report"/><br />
</diplomacy> <br />
|<br />
* helpstatus ist denke ich das bessere Element um die aktuelle Eressea Situation für Gruppen und Parteien zu beschreiben.<br />
* diplomacy wurde von während es Chats erwähnt. Ausserdem sollen Solche Beziehungen zu anderen Völkern allgemeingültiger sein. Auch "Krieg" bzw. "Feind" sollte möglich sein.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Gruppen (wie in Eressea verwendet) ===<br />
|-<br />
|<br />
<unitgroup id="unitgroup.1234.Kapitäne"><br />
<helpstatus remove="2"/><br />
<helpstatus ref="faction.gtzu" add="2"/><br />
</unitgroup><br />
<unitgroup id="unitgroup.1234.Matrosen" basegroup="unitgroup.1234.Kapitäne"><br />
<helpstatus remove="1"/><br />
</unitgroup><br />
|<br />
* Vorsicht, hier muss der eindeutige Key auch den Parteikey enthalten, sonst ist die Gruppe möglicherweise nicht eindeutig.<br />
* Neben einer einfach Auflistung der Helfestati sollte der client/server erlauben unterschiede zur Partei oder einer anderen Gruppe zu definieren<br />
* Im angegebenen Beispiel basiert die Gruppe Kapitäne auf der Partei. Allerdings wird der Status 2 für alle entfernt, dann aber wieder für ein Volk gesetzt. Die Matrosen basieren auf den Kapitänen, nur nehmen sie von anderen keine Waren entgegen.<br />
* Naja so ähnlich jedenfalls sollte es laufen, nicht immer überall alles neu definieren, sondern sozusagen deltas definiert werden können. Wenn es der Server nicht unterstützt, soll der Client entsprechend die Helfe Stati automatisch setzen.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Messages ===<br />
|-<br />
|<br />
<message id="message_123456" type="msgtype_23423546"><br />
<text xml:lang="de"><br />
Die Nussschale (1234) segelt von Irgendwo (1,2) nach Nirgendwo<br />
(99,99). Dabei wurden Ozean (1,3), Ozean (1,4) ... und Ozean <br />
(98,99) durchquert.<br />
</text><br />
<attribute name="ship"><shipref ref="ship_1234"/></attribute><br />
<attribute name="from"><regionref ref="region_653456"/></attribute><br />
<attribute name="to"><regionref ref="region_653567"/></attribute><br />
<attribute name="through"><br />
<regionref ref="region_953456"/><br />
<regionref ref="region_68656"/><br />
...<br />
<regionref ref="region_114562"/><br />
</attribute><br />
<message id="message_456346" type="msgtype_456902645"><br />
<text xml:lang="de"><br />
Die Nussschale (1234) wurde in Ozean (77,78) von Stürmen nach<br />
Ozean (78,78) abgetrieben. Sie erlitt dabei 2% Schaden.<br />
</text><br />
<attribute name="ship"><shipref ref="ship_1234"/></attribute><br />
<attribute name="from"><regionref ref="region_673256"/></attribute><br />
<attribute name="to"><regionref ref="region_322167"/></attribute><br />
<attribute name="damage"><int>2</int></attribute><br />
</message><br />
</message><br />
|<br />
* Messages können den Text in fertig gerenderter form enhalten. (Sprachabhängig)<br />
* Attribute sollten nicht nur einfach Werte sondern auch Listen enthalten können.<br />
* Ideal wäre die Attribute typisiert zu speichern, dann muss diese Info nicht aus dem Messagetyp geholt werden.<br />
* Eine Verschachtelung von Messages sollte möglich sein<br />
|-<br />
|colspan="2"|<br />
<br />
=== Messages (Alternative) ===<br />
|-<br />
|<br />
<message id="message_123456" type="msgtype_23423546"><br />
<msgtext xml:lang="de"><br />
Die <link name="ship" role="ship" ref="ship_1234">Nussschale <br />
(1234)</link> segelt von <link name="from" role="region"<br />
ref="region_653456">Irgendwo (1,2)</link> nach <regionref<br />
name="to" ref="region_653567">Nirgendwo (99,99)</regionref>. <br />
Dabei wurden <msgfunc name="through" type="regions"><regionref<br />
ref="region_953456">Ozean (1,3)</regionref>, <regionref <br />
ref="region_68656">Ozean (1,4)</regionref>, ... und <regionref<br />
ref="region_114562">Ozean (98,99)</regionref></msgfunc><br />
durchquert.<br />
</msgtext><br />
</message><br />
|<br />
* Messages enthalten hier Text und ihre Attribute gemischt. d.h. es ist immer klar aus welchem Teil der Pattern welcher Text erzeugt wurde.<br />
* Mithilfe der Pattern lässt er sich auch bei fehlenden Referenzen halbwegs in andere Sprachen übersetzen, da man dann auch den Inhalt der anderen Sprache zurückgreifen kann. Dann steht zwar in der englischen Meldung auch Ozean (1,3) statt ocean (1,3) aber besser so als komplett deutsch ausgeben zu müssen, weil nicht renderbar wegen fehlender Referenzen.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Regionen ===<br />
|-<br />
|<br />
<region id="region_126788"><br />
<coordinate x="14" y="27"/><br />
<name>xxxxx</name><br />
<descr>dsfsf sdf sdf</descr><br />
<type role="terrain" ref="terrain_plain"/><br />
|<br />
* Regionen, hier versehen mit einer Koordinate. <br />
* Wie wir verschiedene Ebenen Kennzeichen müssen wir noch diskutieren. Eine Z-Koordinate ist denkbar. Ein Element <maplevel> wäre aber auch nicht schlecht.<br />
* Für subregionen will man ggf. keinen Terraintyp - deshalb sollte das type Attribut von region optional sein.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Regionsresourcen ===<br />
|-<br />
|<br />
<resources><br />
<resource type="resourcetype.mallorntrees">50</resource><br />
<resource type="resourcetype.mallornsaplings">10</resource><br />
<resource type="resourcetype.laen"><br />
<level depth="33">10</level><br />
<level depth="34">12</level><br />
</resource><br />
<resource type="resourcetype.silver">10000</resource><br />
<resource type="resourcetype.peasant">1000</resource><br />
<resource type="resourcetype.elvendear" quantity="many"/><br />
<resource type="resourcetype.elvendear">many</resource><br />
</resource><br />
</resources><br />
|<br />
* Mal ne dumme Frage am Anfang: Kann man Resourcen nicht vielleicht einfach als Gegenstände der Region auffassen? Vermutlich nicht weil es noch viele Besonderheiten gibt. Im objektorientieren vielleicht schon da könnte man Resourcen als Sonderform von Items definieren.<br />
* type referenziert auf den entsprechenden resourcetype. Wenn der nicht in den Regeln vorhanden ist, sollte der Client natürlich trotzdem den Eintrag verarbeiten, er hat nur keine Infos über den Typ.<br />
* Menge im Element codieren, oder als Attribut? Da es sich um die wichtigste info zur Resource handelt, ist es denke ich sinnvoll das im Element abzulegen.<br />
* Stufenabhängigkeit als Attribut oder als Subelement? Hab es mal als Subelement eingebaut, mit mehreren angezeigten Schichten.<br />
* Weitere Zusätzliche Attribute je nach Resourcentyp? Denke nicht, zumindest nicht solange sich solche werte ausrechnen lassen.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Handel ===<br />
|-<br />
|<br />
<trade><br />
<offer amount="10"><br />
<item role="trade_give" ref="itemtype_silver" amount="5"/><br />
<item role="trade_get" ref="itemtype_balm" amount="1"/><br />
</offer><br />
<offer amount="1"><br />
<item role="trade_give" ref="itemtype_juwel" amount="2500"/><br />
<item role="trade_give" ref="itemtype_wood" amount="200"/><br />
<ship role="trade_get" ref="shiptype_caravel" amount="1"/><br />
</offer><br />
<offer><br />
<item role="trade_give" ref="itemtype_wood" amount="25"/><br />
<ship role="trade_get" ref="ship_1234234324" turns="10"/><br />
</offer><br />
<offer><br />
<link role="trade_start" ref="region_3431245324"><br />
<item role="trade_get" ref="itemtype_wood" amount="25"/><br />
</link><br />
<link role="trade_end" ref="region_132876878798" turns="10"><br />
<item role="trade_give" ref="itemtype_wood" amount="25"/><br />
<item role="trade_get" ref="itemtype_silver" amount="2000"/><br />
</link><br />
</offer><br />
</trade><br />
|<br />
* Wir erlauben Handel prinzipiell bei jedem Spielobjekt, d.h. global, Region, Einheit, Schiff, Gebäude, ...<br />
* Gehandelt werden können Items oder Spielobjekte oder Typen von Spielobjekten<br />
* Ein Verleih kann über eine zeitliche Begrenzung erreicht werden<br />
* Eine Dienstleistung wie Waren von A nach B ist ggf. auch möglich<br />
|-<br />
|colspan="2"|<br />
<br />
=== Einheiten ===<br />
|-<br />
|<br />
<unit id="unit_mag3" key="mag3"><br />
<name ...><br />
<descr xml:lang="de">Er schützt die Region.</descr><br />
<descr xml:lang="en">He protects the region.</descr><br />
<descr type="private"><br />
Botschafter (1234) ist ein parteigetarnter Spion der xxx<br />
</descr><br />
<type role="race" ref="race_daemons"/><br />
<type role="camouflage_race" ref="race_aquarians"/><br />
<size>1</size><br />
<link role="memberof" ref="faction_Lotr"/><br />
<link role="camouflage_faction" ref="faction_3243"/><br />
<status type="guard"/><br />
<status type="fight">front</status><br />
<status type="health">wounded</status><br />
<status type="hungry"/><br />
<effect type="limitCamoflage">14</effect><br />
<spells type="magic_gwyrrd"><br />
<spell type="spell_xxx"/><br />
<spell type="spell_xxy"/><br />
</spells><br />
<items><br />
<item type="item_laen">14</item><br />
<item type="item_wood">44</item><br />
</items><br />
<skills><br />
<skill type="skill_perception" level="17"/><br />
<skill type="skill_camouflage" level="4" amount="300"/><br />
</skill><br />
</skills><br />
<effect><br />
<keytext key="ew34" xml:lang="de"><br />
Die Einheit fühlt sich sehr stark.<br />
</keytext><br />
</effect><br />
<effect><br />
<item type="item_sevenmilestea" amount="7"/><br />
</effect><br />
<message ...><br />
</unit><br />
|<br />
* Hier frage ich mich, ob es besser ist die Rasse als Typ der Einheit im Element unit mitzugeben oder so wie es jetzt ist, im extra Element persons die Rasse und ihre Anzahl angegeben wird. Das eröffnet die Möglichkeit Einheiten mit verschiedenen Rassen zu mischen.<br />
* Bei camouflage bin ich mir auch unsicher. Wichtig ist, Man kann sich sinnigerweise nur als eine Rasse, eine Partei oder mit einer bestimmten Stufe tarnen.<br />
* Ebenso unklar ist, wie man den ganzen Magiebereich flexibel abbildet. Magier haben bei Eressea ein Magiegebiet, bei anderen Spielen ggf. mehrere. Sprüche gehören zu einem Magiegebiet. Vertraute bei Eressea haben eventuell Sprüche, ohne diese aber einem Magiegebiet zuzuordnen. Bei Eressea gibt es Aura und Maximale Aura (prinzipiell ~ permanente Aura). Das kann man als Gegenstände auffassen, diese lassen sich aber in ihrer Menge nicht wie üblich übergeben. Trefferpunkte sind auch in diesem Bereich anzusiedeln. Sie werden aber nur durch einen Gesundheitsstatus grob ausgedrückt. Also modellieren wir das alles einzeln oder lassen wir uns was allgemeines einfallen? <br />
* Thoralf hat recht, ein wenig mehr Struktur als notwendig hilft die übersicht zu wahren. Deshalb stecken wir Talente, Gegenstände usw. lieber in ein container-element. Bei Elementen die oft gar nicht oder nur sehr selten in mehrzahl auftreten, würde ich darauf aber verzichten (z.b. Effekte)<br />
|-<br />
|colspan="2"|<br />
<br />
=== Gebäude ===<br />
|-<br />
|<br />
<building id="building_h0us" key="h0us" type="buildingtype.academy"><br />
<name>xxxxx</name><br />
<descr>dsfsf sdf sdf</descr><br />
<size>25</size><br />
|<br />
Name und Beschreibung sind klar #PCDATA. Typ und Grösse sind zumindest bei<br />
Eressea etwas das jedes Gebäude als Eigenschaft hat. Den Typ würde ich lieber als <br />
Attribut auslegen, da man dann ggf. auf einen Gebäudetyp referenzieren kann. In<br />
dem Fall muss es aber wieder global eindeutig sein. Also doch wieder sowas wie<br />
type="buildingtype.academy". Leider kann man ja nicht klar stellen, dass type<br />
auf einen buildingtype referenziert. <br />
<br />
Die Grösse hingegen würde ich als Element angeben - warum - keine Ahnung.<br />
|-<br />
|colspan="2"|<br />
<br />
=== Schiffe ===<br />
|-<br />
|<br />
<ship id="ship_ttnc" key="ttnc" type="boat"/><br />
<name>...<br />
<descr>...<br />
<status tag="load">2000</status><br />
<status tag="damage">2</status><br />
|<br />
* Schiffstyp als Attribut vom element ship, wegen referenzieren auf Regeln<br />
* Beladung, Schaden, Baustatus, usw. sind m.E. nur simple "Statusinfos" für die es nicht jeweils ein extra Element braucht. Wie sich sowas auf freie Kapazität, Reichweite usw. auswirkt ist eh spielabhängig. Ausserdem heissen diese Attribute überall ein bisschen anders.<br />
<br />
|-<br />
|<br />
</region><br />
|<br />
|-<br />
|colspan="2"|<br />
<br />
=== Messagetypen ===<br />
|-<br />
|<br />
<messagetype id="msgtype_5673456873"><br />
<section>travel</section><br />
<pattern locale="de"><br />
<attribute name="unit"/> segelt von <attribute name="from"/> nach <br />
<attribute name="to"/>. Dabei wurden <br />
<function type="regions"><attribute name="through"></function> durchquert.<br />
</pattern><br />
</messagetype><br />
|So richtig gefällt mir das hier noch nicht. <br />
Man sollte anhand der Pattern bereits den Typ des jeweiligen Attributs erkennen.<br />
Vermutlich müsste jede $xyz() die es derzeit gibt, als extra Elementtyp in der<br />
(Eressea)-DTD definiert werden.<br />
|-<br />
|<br />
</atlantis><br />
|<br />
|}<br />
<br />
== Regelset ==<br />
Mir stellt sich die Frage, ob das Regelset nur die "technischen" Infos enthalten soll, oder ob auch die UI-Infos hier direkt rein sollen. Damit meine ich die Lokalisierung und Icons. Solche Sachen könnten auch in einer zusätzlichen XML Datei definiert sein, die dann z.B. nur Übersetzungen enthält.<br />
<br />
Die Icons sollen sowieso nach Möglichkeit nicht direkt referenziert sein, sondern in einer Grafikset-XML verwaltet werden. D.h. es wird nur auf die im Grafikset eindeutigen IDs referenziert. Natürlich kann man auch das Grafikset spielabhängig gestalten und dort die Bindung der Icons an die Spielobjekte vornehmen.<br />
<br />
Gleiches gilt für die Übersetzungen von Namen. Die können ebenso als "Benennungsset" spielabhängig und in einer Extra Datei gehalten werden und auf Spielobjekte referenzieren.<br />
<br />
Und noch ein Dokument fuer eine Spiel-Definition<br />
<pre><br />
<!DOCTYPE atlantis PUBLIC "-//PBEM//DTD Atlantis 1.0//EN" "http://eressea.de/atlantis-ruleset.dtd"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<atlantis><br />
<itemcategory id="itemcategory_resource"><br />
<name lang="de">Ressource</name><br />
<useicon ref="icon_resource"><br />
</itemcategory><br />
<br />
<itemtype id="itemtype_laen"><br />
<name lang="de">Laen</name><br />
<weight>2</weight><br />
<produce><br />
<skill type="skilltype.bergbau" minlevel="7" productionpoints="7"/><br />
<building type="buildingtype.mine" required="yes"/><br />
<components><br />
<resource type="resourcetype.laen">1</resource><br />
</components><br />
</produce><br />
<useicon ref="icon_laen"/><br />
<category ref="itemcategory_resource"/><br />
</itemtype><br />
<itemtype id="peasantblood"><br />
<produce><br />
<skill type="skilltype.alchemy" minlevel="4" productionpoints="4"/><br />
<components><br />
<resource type="resourcetype.peasant">1</resource><br />
<item type="fjordfungus">1</item><br />
...<br />
</components><br />
<command><cmd_make/> <amount optional="true"/> ...</command><br />
</produce><br />
</itemtype><br />
<br />
<race/><br />
<plane/><br />
<terraintype/><br />
<skilltype/><br />
<buildingtype id="buildingtype_mine"><br />
...<br />
<useicon ref="icon_mine"><br />
<placement role="map" x="0%" y="30%"/><br />
</useicon><br />
</buildingtype><br />
<shiptype/><br />
<command/><br />
<br />
</atlantis><br />
</pre><br />
<br />
== Elemente im Detail ==<br />
Um mal einen Ansatzpunkt für die DTD zu bekommen und auch als Doku werden hier die Elemente mit ihren Eigenschaften gelistet. Beispiel sollen sich auf das nötigste beschränken, also auch nicht mehr als 10 Zeilen beanspruchen.<br />
<br />
=== <gameobject/> ===<br />
* Attribute: <br />
** id = Dokumentweit eindeutiger Schlüssel<br />
** type = Basistyp des Spielobjektes (Flotte, Insel, Kolonie, Karawane, ...)<br />
** key = innerhalb des Typs des Spielobjektes eindeutiger Schlüssel<br />
* Subelemente: <br />
** Beschreibende: [[#<name/>|<name/>]]? [[#<descr/>|<descr/>]]? [[#<plaintext/>|<plaintext/>]]*<br />
** Ausprägung (Rasse, Held(entyp)): [[#<type/>|<type/>]]*<br />
** Daten/Status: [[#<data/>|<data/>]]* [[#<status/>|<status/>]]*<br />
** Verweise auf andere Spielobjekte: [[#<link/>|<link/>]]*<br />
** Gegenstände/Besitz: [[#<items/>|<items/>]]?<br />
** Hierarchiebildung: <gameobject/>* [[#<faction/>|<faction/>]]* [[#<region/>|<region/>]]* [[#<unit/>|<unit/>]]* [[#<ship/>|<ship/>]]* [[#<building/>|<building/>]]*<br />
<br />
Beispiel:<br />
<gameobject id="fleet_471b" type="fleet" key="471b"><br />
<link role="master" ref="ship_45t6"/><br />
<link role="slave" ref="ship_t426"/><br />
<link role="slave" ref="ship_vfr7"/><br />
</gameobject><br />
==== <world/> ====<br />
* Subelemente: wie <gameobject/><br />
<br />
==== <faction/> ====<br />
* Attribute: id und key<br />
* Subelemente: wie <gameobject/><br />
<br />
==== <region/> ====<br />
* Attribute: id und key<br />
* Subelemente: wie <gameobject/><br />
<br />
==== <unit/> ====<br />
* Attribute: id und key<br />
* Subelemente: wie <gameobject/> zusätzlich:<br />
** Erfahrung/Talente: <skills/>?<br />
** Befehle: <commands/>?<br />
<br />
==== <ship/> ====<br />
* Attribute: id und key<br />
* Subelemente: wie <gameobject/><br />
<br />
==== <building/> ====<br />
* Attribute: id und key<br />
* Subelemente: wie <gameobject/><br />
<br />
=== <name/> ===<br />
* Attribute: <br />
** lang = Die Sprache des Elementinhalts. Default ist die Sprache des Reports oder der Konfigurationsdatei. (optional)<br />
** stemming = (singular|plural) gibt an, wie dieses Element in bestimmten Beugungen heisst. Default ist singular. (optional)<br />
* Subelemente:<br />
* #PCDATA<br />
<br />
=== <descr/> ===<br />
* Attribute: <br />
** lang = Die Sprache des Elementinhalts. Default ist die Sprache des Reports oder der Konfigurationsdatei. (optional)<br />
* Subelemente:<br />
* #PCDATA<br />
<br />
=== <link/> ===<br />
* Attribute: <br />
** role = Die Rolle oder Beziehung des Verweises<br />
** ref = Das referenzierte Element, der Typ kann dann über das Element ermittelt werden.<br />
* Subelemente:<br />
* ?<br />
<br />
== Siehe auch ==<br />
* [[CR Format]]<br />
<br />
== External Links ==<br />
* [http://pathfinder-xquery.org/files/xpath-accel.pdf Accelerating XPath Location Steps]<br />
* [http://groups.google.com/group/eressea-client/browse_thread/thread/ddbbcf74febf85f8/7d5f1207b0f296e4?lnk=raot CRXML Format und Tools]</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2256Diskussion:XML Format2008-04-30T07:50:47Z<p>Sophie: /* Requirements */</p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
::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.--[[Benutzer:Sophie|Sophie]] 17:58, 29. Apr 2008 (CEST)<br />
<br />
::: Hm, also auf den ersten Blick hat mir das "Manifestierungkonzept" gefallen. Auf den zweiten Blick aber nicht. In Eressea kann man z.b. Samen machen. Das wäre in das obige Konzept schlecht reinzupressen. Acu bin ich immer noch der Meinung das Man Gegenstände und Resourcen auf ein gemeinsamen Nenner bringen kann. Dann kann man z.b. auch den Verderb von Kräutern im Bitz einer Einheit genauso modellieren, wie das Wachstum von Kräutern in Regionen. Oder bei Allanon können doch Zentauren Pferde vermehren ... wo ist der Unterschied zu Resourcen? Um nun Samen in Schösslinge und diese in Bäume zu verwandeln, "produziert" die Region einfach in bestimmen Jahreszeiten aus Samen Schösslinge. Das ist wieder vergleichbar mit einer Einheit die aus Holz ein Speer herstellt. --[[Benutzer:Darcduck|Darcduck]] 20:16, 29. Apr 2008 (CEST)<br />
<br />
:::Um es also mit den requirements Konzept zu sagen: Ein Samen ist ein Gegenstand und Resource (-> item). Er kann im Besitz von Einheiten und Regionen sein. --[[Benutzer:Darcduck|Darcduck]] 20:16, 29. Apr 2008 (CEST)<br />
* Um einen Samen in der Region zu erzeugen, muss: <br />
** (Jahreszeit richtig UND Bäume in der Region sein UND Zufallswert) ODER <br />
** (Ein Same bei der Einheit sein UND Das Kommando PFLANZE Same gegeben werden UND Zufallswert)<br />
* Um einen Schössling zu erzeugen, muss: <br />
** (ein Samen in der Region sein UND Jahreszeit richtig UND Zufallswert) ODER<br />
** (ein Magier Hainzauber sprechen ... ich spare mir mal die einzelnen details) ODER<br />
** (WdL benutzt werden .. details gespart)<br />
* Um einen Baum zu erzeugen ...<br />
::::Das Problem ist, das zumindest Menouthis Ressourcen und Gegenstände getrennt behandeln muss, allein schon weil eine Ressource nicht einfach so eine Anzahl hat. Ich stelle mir eine Repräsentation als Gegenstand auch beim mehrschichtigen Eisen von Eressea kompliziert vor. Auch gibt es dann Gegenstände, die nicht in den Besitz einer Einheit oder der Bauern gelangen können (Bäume, Bauern, Rekruten, etc). Natürlich kann man Ressourcen im Report auf Gegenstände herunterprojezieren, aber ich fürchte wir machen damit uns mehr Probleme als wir gewinnen. Zum Beispiel kann ein Parser ohne Weltenkenntnis dann nicht erkennen das "Gib bla 5 Rekruten" ein syntaktisch falscher Befehl ist. --[[Benutzer:Sophie|Sophie]] 21:36, 29. Apr 2008 (CEST)<br />
:::::Naja eine Anzahl hat eine Resource schon, nämlich die Anzahl die man abbauen kann. Du hast aber recht das die Mehrschichtigkeit bei Eressea nicht ganz einfach ist. Vermutlich muss es dazu items mit level geben. Wenn man das auch für Gegenstände nutzt, heisst das, ein Spiel könnte auch Schwerter Stufe 10 enthalten, die sich ein wenig besser verhalten als Schwerter Stufe 5. Im Moment versuche ich mir immer vorzustellen was man so alles machen könnte und mit einer (De)generationsrate, einem Level, Gewicht bzw. "Platz" und Anzahl lassen sich meines Erachtens so ziemlich alle Grundeigenschaften von von Gegenständen oder Resourcen abbilden. Selbst solche 25 Eisen/Woche sind recht einfach. 25 Items Eisenquellen erzeugen 25 Items Eisen am Anfang jeder Woche. Die können abgebaut werden. Am Ende der Woche degeneriert Eisen in der Region dann zu 100%.<br />
<br />
Einen wichtigen Unterschied zwischen Resourcen und Gegenständen sehe ich aber auch: Um Resourcen "streitet" man sich üblicherweile, d.h. hier wird unter allen fördernden Einheiten aufgeteilt. Sowas ist mir bei Einheiten nicht bekannt. Diebe z.b. sind nacheinander dran, nicht "gleichzeitig".<br />
<br />
Wenn wir nun einen Unterschied machen, welche Konsequenzen hat das auf die Modellierung? Auch andere Spielobjekte sollen ja Gegenstände haben können. Schiffe z.b. Beiboote, Kanonen. Können Schiffe auch Resourcen "anbieten"? Anders gefragt, macht es Sinn sowohl Resourcen als auch Gegenstände bei einem Spielobjekt zu verwalten? Alles recht philosophische Fragen ... --[[Benutzer:Darcduck|Darcduck]] 01:17, 30. Apr 2008 (CEST)<br />
<br />
= Requirements =<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)<br />
<br />
: So jetzt bin ich fast alle xmls im svn durch und auch die Regeln habe ich mir im vergleich dazu mal angeschaut. Ich bin beeindruckt! Ein paar Startschwierigkeiten wird es wohl geben, aber dann hat das Spiel genug neue Elemente um den Eressea-Spieler über den Tellerrand blicken zu lassen :-) Was die xml-Dateien angeht: Man sieht, dass sich dahinter keine DTD verbirgt. Dafür liesst es sich so recht einfach und bleibt übersichtlich. Für Menouthis würde ich wohl auch kaum etwas daran ändern. Allerdings kann ein XML Parser eines Clients mit den vielen Elementen sicher nichts anfangen (vieles braucht er aber auch nicht). Waffen werden gesondert gelistet, natürlich aufgrund ihrer Kampfeigenschaften, das diese Jedoch auch items sind wird dem Client nur durch Programcode klar. Hierarchieen würde ich auch als solche Abbilden und auf <super...> verzichten. Subtypen brauchen indes kein eigenes element, da sie bereits durch die Struktur als Subelement erkennbar sind.--[[Benutzer:Darcduck|Darcduck]] 03:51, 30. Apr 2008 (CEST)<br />
<br />
: Noch ein kurzer Kommentar zu den Requirements: Meist in der Kontext unklar in dem eine Bedingung erfüllt sein muss. Soll eine Einheit das Silber haben, oder die Partei im Reichsschatz? Bedingung ist nur <item ...> Ein Requirement müsste m.E. entweder immer auf das ausführende spielobjekt bezogen sein, oder der Kontext (unit, ship, building, faction, world, ...) muss mit angegeben werden. Interessant sind auch die Helden in Menouthis. Regeltechnisch gibt es natürlich Rassen und Heldentypen. Als Reportobjekte gibt es aber vermutlich (habs nicht nachgeschaut im Quellcode) nur Einheiten die entsprechend eine Rasse und ggf. einen Heldentyp haben. Sowohl an der Rasse als auch am Heldentyp hängen dann die Effekte die die Grundeigenschaften einer Einheit modifizieren. Die Bedingung <requirement><hero>sourcerer</hero></requirement> wird also von einer Einheit erfüllt die ein Held ist. Für Rasse und Kultur und auch diese Heldenausprägung würde ich wie schon geschrieben verschiedene parallele Typen zulassen. Also z.b:<br />
<br />
<unit id="..."><br />
<type role="race" ref="race_ferry"/> <br />
<type role="hero" ref="hero_witch"/> <br />
...<br />
</unit><br />
<br />
: <maxnum> hingegen ist eine Umgehung von <requirement>. Den eigentlich ist die Bedingung ja die Partei muss weniger als maxnum einheiten vom typ haben. Ich gebe zu das ist schwer im XML zu notieren, weshalb die "Abkürzung" hier ok ist. --[[Benutzer:Darcduck|Darcduck]] 03:51, 30. Apr 2008 (CEST)<br />
::Die XMLs in dem Verzeichnis sind die serverseitigen Konfigurationsdateien, die Reports für die Clients werden getrennt davon generiert. Mein Plan ist es, die Reports an das verallgemeinerte XML-Format anzupassen und die Konfiguration erstmal so zu behalten wie sie ist, die muss ja niemand außer dem Menouthisserver parsen können. Die Gegenstände sind nicht in einem Baum angeordnet, sondern nur in einem gerichteten, zirkelfreien Graphen, so ist ein Rind gleichzeitig Schlachttier und Zugtier und ein Pferd gleichzeitig Zugtier und Reittier, man kann die Zusammenhänge also nicht direkt ins XML abbilden. Die eigenen Elementnamen wollte ich in der Config irgendwann nochmal abschaffen und die zugrundeliegende Vererbung im Quellcode durch Komposition ersetzen, im Report steht das bereits so, das sollte zumindest dort keine Probleme machen.<br />
::Requirements können derzeit auf zwei Objekte angewandt werden: Einheiten und Regionen, wobei der Hauptfokus auf Einheiten liegt. Bei aktivierten Pool kann der Pool zur Erfüllung eines Requirements mitbenutzt werden, ob er das darf legt der Code fest (Bei der Produktion von Gegenständen erlaubt, beim verwenden eines Transporters verboten). Einen Reichschatz in Form von Gegenständen der Partei kennt Menouthis nicht, aber ich würde das in dem Fall eher dem Spiel überlassen, wie es den konkreten Fall handelt.</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2245Diskussion:XML Format2008-04-29T19:36:32Z<p>Sophie: /* Ressourcen */</p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
::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.--[[Benutzer:Sophie|Sophie]] 17:58, 29. Apr 2008 (CEST)<br />
<br />
::: Hm, also auf den ersten Blick hat mir das "Manifestierungkonzept" gefallen. Auf den zweiten Blick aber nicht. In Eressea kann man z.b. Samen machen. Das wäre in das obige Konzept schlecht reinzupressen. Acu bin ich immer noch der Meinung das Man Gegenstände und Resourcen auf ein gemeinsamen Nenner bringen kann. Dann kann man z.b. auch den Verderb von Kräutern im Bitz einer Einheit genauso modellieren, wie das Wachstum von Kräutern in Regionen. Oder bei Allanon können doch Zentauren Pferde vermehren ... wo ist der Unterschied zu Resourcen? Um nun Samen in Schösslinge und diese in Bäume zu verwandeln, "produziert" die Region einfach in bestimmen Jahreszeiten aus Samen Schösslinge. Das ist wieder vergleichbar mit einer Einheit die aus Holz ein Speer herstellt. --[[Benutzer:Darcduck|Darcduck]] 20:16, 29. Apr 2008 (CEST)<br />
<br />
:::Um es also mit den requirements Konzept zu sagen: Ein Samen ist ein Gegenstand und Resource (-> item). Er kann im Besitz von Einheiten und Regionen sein. --[[Benutzer:Darcduck|Darcduck]] 20:16, 29. Apr 2008 (CEST)<br />
* Um einen Samen in der Region zu erzeugen, muss: <br />
** (Jahreszeit richtig UND Bäume in der Region sein UND Zufallswert) ODER <br />
** (Ein Same bei der Einheit sein UND Das Kommando PFLANZE Same gegeben werden UND Zufallswert)<br />
* Um einen Schössling zu erzeugen, muss: <br />
** (ein Samen in der Region sein UND Jahreszeit richtig UND Zufallswert) ODER<br />
** (ein Magier Hainzauber sprechen ... ich spare mir mal die einzelnen details) ODER<br />
** (WdL benutzt werden .. details gespart)<br />
* Um einen Baum zu erzeugen ...<br />
::::Das Problem ist, das zumindest Menouthis Ressourcen und Gegenstände getrennt behandeln muss, allein schon weil eine Ressource nicht einfach so eine Anzahl hat. Ich stelle mir eine Repräsentation als Gegenstand auch beim mehrschichtigen Eisen von Eressea kompliziert vor. Auch gibt es dann Gegenstände, die nicht in den Besitz einer Einheit oder der Bauern gelangen können (Bäume, Bauern, Rekruten, etc). Natürlich kann man Ressourcen im Report auf Gegenstände herunterprojezieren, aber ich fürchte wir machen damit uns mehr Probleme als wir gewinnen. Zum Beispiel kann ein Parser ohne Weltenkenntnis dann nicht erkennen das "Gib bla 5 Rekruten" ein syntaktisch falscher Befehl ist. --[[Benutzer:Sophie|Sophie]] 21:36, 29. Apr 2008 (CEST)<br />
<br />
= Requirements =<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2237Diskussion:XML Format2008-04-29T15:59:25Z<p>Sophie: </p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
::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.--[[Benutzer:Sophie|Sophie]] 17:58, 29. Apr 2008 (CEST)<br />
<br />
= Requirements =<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2236Diskussion:XML Format2008-04-29T15:58:17Z<p>Sophie: /* Ressourcen */</p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
::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.--[[Benutzer:Sophie|Sophie]] 17:58, 29. Apr 2008 (CEST)<br />
<br />
== Requirements ==<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2235Diskussion:XML Format2008-04-29T15:57:56Z<p>Sophie: /* Ressourcen */</p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
::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.<br />
<br />
== Requirements ==<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2226Diskussion:XML Format2008-04-29T14:35:46Z<p>Sophie: Requirements</p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)<br />
<br />
: 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:<br />
RESOURCE 1355696724<br />
"Schößlinge";type<br />
130;number<br />
RESOURCE 1923739441<br />
"Bäume";type<br />
520;number<br />
--[[Benutzer:Enno|Enno]]<br />
<br />
== Requirements ==<br />
<br />
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:<br />
<br />
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. <br />
<br />
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.<br />
Ein Beispiel (Produktion von Korallen):<br />
<producerequirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>2</level><br />
</skill><br />
<race>aquan</race><br />
<resource consume="false"><br />
<id>coral</id><br />
<number>10</number><br />
</resource><br />
</requirement><br />
<requirement><br />
<skill><br />
<id>mining</id><br />
<level>3</level><br />
</skill><br />
<not><br />
<requirement><br />
<race>aquan</race><br />
</requirement><br />
</not><br />
<resource consume="true"><br />
<id>coral</id><br />
<number>1</number><br />
</resource><br />
</requirement><br />
</producerequirement><br />
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 [https://sodge.org/svn/menouthis/unstable/config/ svn] (Benutzername svn, kein Passwort)<br />
<br />
Die Elemente die wir so haben in Kurzvorstellung:<br />
*<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<br />
*<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.<br />
*<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.<br />
*<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<br />
*<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.<br />
*<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)<br />
*<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.<br />
*<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<br />
*<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)<br />
<br />
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). <br />
<br />
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.<br />
--[[Benutzer:Sophie|Sophie]] 16:35, 29. Apr 2008 (CEST)</div>Sophiehttps://wiki.eressea.de/index.php?title=Diskussion:XML_Format&diff=2217Diskussion:XML Format2008-04-29T12:15:46Z<p>Sophie: </p>
<hr />
<div>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. [[Benutzer:Enno|Enno]] 10:58, 22. Apr 2008 (CEST)<br />
<br />
= Allgemeines =<br />
<br />
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). -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Hierarchie von "echten" Objekten, item, unit, region, alliance, faction, building, ship, usw. wuerde ich trotzdem gern als <item/>, <unit/>, usw. modellieren. -- [[Benutzer:Enno|Enno]] in Generelles<br />
: 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.<br />
: 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:<br />
<br />
<gameobject id="hero_34535" type="hero"><br />
<br />
== Historische Daten ==<br />
<br />
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).<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: 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 ..." ;-)<br />
:: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
== id vs. key ==<br />
<br />
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.<br />
-- [[Benutzer:Enno|Enno]] 16:47, 22. Apr 2008 (CEST)<br />
: Ist xml_id und id eigentlich das gleiche? Ich glaube nicht. -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Ich denke schon - aus [http://webservices.xml.com/pub/a/ws/2005/02/23/salz.html The xml:id Conundrum] zitiert: "Perhaps unfortunately, the basic c14n specification says that all attributes in the XML namespace must be imported" -- [[Benutzer:Enno|Enno]]<br />
<br />
: 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 -- [[Benutzer:Darcduck|Darcduck]]<br />
:: Die wird es fuer Eressea hoechstwahrscheinlich geben, ich will sie aber nicht im Format festschreiben. -- [[Benutzer:Enno|Enno]]<br />
<br />
Die Elemente zum referenzieren tragen sinnvollerweise ebenfalls die endung ref -- [[Benutzer:Darcduck|Darcduck]]<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
:: 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). -- [[Benutzer:Darcduck|Darcduck]]<br />
::: 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: [http://eressea.upb.de/~enno/eressea/cr/test-zv.crxml Wichtig: View Source]. -- [[Benutzer:Enno|Enno]]<br />
:::: 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? -- [[Benutzer:Darcduck|Darcduck]]<br />
<br />
: 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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <group/> =<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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.<br />
<br />
=<alliance/>=<br />
<br />
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. -- [[Benutzer:Darcduck|Darcduck]]<br />
: Genau dafuer war es gedacht. -- [[Benutzer:Enno|Enno]]<br />
<br />
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. -- [[Benutzer:Enno|Enno]]<br />
<br />
= <link/> =<br />
<br />
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.<br />
<link role="salesgood" type="item" ref="itemtype_wood"/><br />
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. -- [[Benutzer:Enno|Enno]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
: 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" .../> --[[Benutzer:Darcduck|Darcduck]]<br />
: 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. --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<itemtype id="itemtype_Bauernblut"><br />
<name>Bauernblut</name><br />
<descr>Man nehme ...</descr><br />
<commands><br />
<command role="make"><br />
<components><br />
<item parent="unit" role="inventory" ref="itemtype_herbX">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbY">1</item><br />
<item parent="unit" role="inventory" ref="itemtype_herbZ">1</item><br />
<item parent="region" role="resource" ref="itemtype_peasant">1</item><br />
</components><br />
<skill ref="skilltype_alchemy">4</skill><br />
<calc var="amount" function="make_potion_max">...???</calc><br />
<syntax>MACHE <int role="amount" default="max" required="false"/> Bauernblut</syntax><br />
</command><br />
<command role="use"><br />
<syntax>BENUTZEN <int role="amount" default="1" required="false"/> Bauernblut</syntax><br />
</command><br />
</commands> <br />
</itemtype><br />
</pre><br />
<br />
: Und hier wie eine Region aussehen könnte: --[[Benutzer:Darcduck|Darcduck]]<br />
<br />
<pre><br />
<region id="region_yyyyyy"><br />
<name/><br />
...<br />
<link role="seen_from_astral" ref="region_xxxxxx"/><br />
...<br />
<items><br />
<item role="resource" ref="itemtype_peasant" amount="1000"><br />
<item role="recruit" ref="itemtype_peasant" amount="50"/><br />
</item><br />
<item role="resource" ref="itemtype_silver" amount="100000"><br />
<item role="entertain_max" ref="itemtype_silver" amount="10000"/><br />
<item role="work_loan" ref="itemtype_silver" amount="12"/><br />
</item><br />
<item role="resource" ref="itemtype_wood" amount="1"/><br />
<item role="resource" ref="itemtype_iron" amount="17" level="14"/><br />
<item role="herb" ref="itemtype_flatroot" amount="many"/><br />
<item role="sell" ref="itemtype_juwel" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="7"><br />
</item><br />
<item role="buy" ref="itemtype_balm" amount="10"><br />
<item role="price" ref="itemtype_silver" amount="32"><br />
</item><br />
</items><br />
</region><br />
</pre><br />
<br />
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.<br />
<br />
== Ressourcen ==<br />
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).<br />
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):<br />
<resource><br />
<id>wood</id><br />
<name lang="en">wood of the region</name><br />
<name lang="de">Holz der Region</name><br />
<singularname lang="en">wood of the region</singularname><br />
<singularname lang="de">Holz der Region</singularname><br />
<type>plant</type><br />
<manifestation><br />
<id>tree</id><br />
<name lang="en">trees</name><br />
<name lang="de">Bäume</name><br />
<singularname lang="en">tree</singularname><br />
<singularname lang="de">Baum</singularname><br />
<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) --<br />
<requirement> !-- Das wäre ein schönes Beispiel für ziemlich spielspezifisches Verhalten von Ressourcen --<br />
<coproduct><br />
<id>coal</id><br />
<number>1/100</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>1</weight> !-- D.h. ein Baum entspricht einem Holz --<br />
<reproductionchance>0.0004</reproductionchance><br />
<reproductsto>seed</reproductsto><br />
<spaceusage>0.01</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>sapling</id><br />
<name lang="en">saplings</name><br />
<name lang="de">Schößlinge</name><br />
<singularname lang="en">sapling</singularname><br />
<singularname lang="de">Schößling</singularname><br />
<uproot><br />
<requirement><br />
<coproduct><br />
<id>coal</id><br />
<number>1/1000</number><br />
</coproduct><br />
</requirement><br />
</uproot><br />
<weight>0.5</weight> !-- Schößlinge zählen nur zur Hälfte zum Holz--<br />
<growchance>0.002</growchance><br />
<growsto>tree</growsto><br />
<spaceusage>0.005</spaceusage><br />
</manifestation><br />
<manifestation><br />
<id>seed</id><br />
<name lang="en">seeds</name><br />
<name lang="de">Samen</name><br />
<singularname lang="en">seed</singularname><br />
<singularname lang="de">Samen</singularname><br />
<weight>0</weight><br />
<growchance>0.002</growchance><br />
<growsto>sapling</growsto><br />
<spaceusage>0</spaceusage><br />
<display><br />
<requirement><br />
<divine /><br />
</requirement><br />
</display><br />
</manifestation><br />
</resource><br />
<br />
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<br />
--[[Benutzer:Sophie|Sophie]] 14:15, 29. Apr 2008 (CEST)</div>Sophie