ChatLog Sophie
Chat mit Sophie (Allanon/Menouthis) zum XML Format:
Zusammenfassung
- Eigenes XML Format bei Allanon/Menouthis vorhanden (Reports und Regeln)
- Wichtige Unterschiede zwischen Menouthis und Eressea bei Marktplatz, Helden, Kulturen, Magie
- Helden sind eigenes Configobject mit Effekten
- Menouthis verwendet Requirements-Konzept für Regeldefinition
- Commandos bei Menouthis sind ebenfalls in Regeldatei konfiguriert
- Die meisten Spielobjekte bestehen aus Name, Beschreibung und einem Satz Effekten
- Effekt ist wahrscheinlich auch, ob jemand eine Region bewacht. --Darcduck
- Referenzierung diskutiert
- Ein immer gleiches Element
- Rolle (und typ) in Attributen speichern
- Referenzelement in Attributen Speichern
- Beispiele:
- <link rel="captain" ref="unit_1234"/>
- <link type="hero" ref="id"/>
- NR Text als Fallback in CDATA bei seltenen/neuen Objekten/Infos
- Einheiten und Items als subobjekt nahezu aller spielobjekte, Schiffe ggf. als subobjekt von Gebäude
- auch Einheiten als subobjekt von Einheiten bedenken, genau wie subregionen von regionen, gleiches für Gebäude
- Möglichkeit Flotten, Inseln, ...
- Regionen können Z Koordinate haben, aber auch zusätzlich eine benannte "plane".
- plane ist dabei eher eine Regeltechnisch oder Spieltechnisch extra Welt.
- Die Z Koordinate soll für richtig 3D Welten reserviert werden, also z.b. Dungons die sich in alle 3 Dimensionen ausdehnen.
- Der Eressea Astralraum ist eine Mischung, da er einen Bezug zu Z=0 hat, aber doch sehr spezifische Regeln. Das lässt sich aber alles auch durch die Terraintypen ausdrücken.
- Messages
- an jedes Spielobjekt hängbar
- Hier gibt es die grössten Unterschiede
- Wenn möglich sollen Messages identifizierbar sein, damit sie nicht doppelt gespeichert werden
- Helfe Stati - keine Bitmasken
Log
Wegen der Langen Zeilen mach ich das mal zu normalem Text -- Darcduck
[20:12] Session Ident: |Sophie| (IRCnet, Enn0) (~sophie@Xc3fa.x.pppool.de)
[20:12] <|Sophie|> hallo
[20:12] <Enn0> hi
[20:13] <|Sophie|> mist, euer Entwurf zu XML-Reports ist natürlich in hunderttausenddetails anders als meine existierenden Reports
[20:14] <Enn0> ja, klar.
[20:14] <|Sophie|> aber das sind im wesentlichen Benennungsdinge und ob Tag oder Attribut verwendet wird, das kann man gut anpassen
[20:15] <|Sophie|> ich hab mir vorhin Gedanken zur Erweiterbarkeit/Unterstützung verschiedener Spiele gemacht, bin aber auf keinen grünen Zweig gekommen
[20:15] <Enn0> das zwei ansaetze mit dem gleichen report rauskommen, ist nicht so warhscheinlich. aber wir wollen was machen, womit man moeglichst mehr als nur eressea beschreiben kann. man kann sich er auch immer eine transformation machen.
[20:15] <Enn0> wir sind 3-4 Leute, die das diskutieren, das aendert sich auch im moment noch gewaltig jeden tag
[20:16] <|Sophie|> ich würde schon gern mitdiskutieren, hab aber zur Zeit nicht gerade besonders viel Zeit
[20:17] <|Sophie|> allerdings die Grundeigenschaften Partei, Region, Einheit, Gegenstand, Talent, Zauber sind ja sowieso relativ klar und einfach zu beschreiben
[20:17] <Enn0> wir schieben die diskussion jetzt in das eressea-wiki, weil die mailingliste kein archiv hat, und auch unuebersichtlich wird. kannst ja einfach mal gelegentlich draufgucken. wenn dir was einfaellt, was man beachten sollte, oder irgendwas, das ihr in menouthis oder allanon habt, das eher ungewoehnlich sit, hoeren wir das natuerlich gern
[20:17] <|Sophie|> die Frage ist eher, wie regelt man soetwas wie Markt oder Helden, wo sich Menouthis und Eressea doch unterscheiden
[20:18] <|Sophie|> insbesondere im Hinblick auf zukünftige Erweiterbarkeit
[20:18] <|Sophie|> bei uns sind Helden z.B. ein eigenes Configobjekt, das Namen, Beschreibung und Effekte besitzt
[20:19] <|Sophie|> hm, vielleicht könnte ich euch für das Requirementkonzept erwärmen
[20:19] <|Sophie|> das ist im Prinzip ähnlich wie die Produktionsvoraussetzungen, nur das man mehrere davon mit oder verknüpft kombinieren kann
[20:19] <|Sophie|> was damit zumindest für den Computer verständlich praktisch alle denkbaren Kombinationen erlaubt
[20:20] <Enn0> mit sowas wie dem markt kann man aber auch nichts anfangen, wenn man die unterstuetzung nicht hat im client - also, die daten darin sind im grunde total opaque. Es gibt ein paar dinge, die kann man spiel-unabhaengig machen, so dass ein spiel sie einsetzen kann und der client was mit angfangen, ohne das man es vorher weiss - benannte links zum beispiel.
[20:21] <Enn0> unsere schiffe haben einen dedizierten kapitaen, da macht man dann ein <link rel="captaon" ref="unit_1234"/> rein, und wenn der client <link/> versteht, ist das fein
[20:21] <Enn0> aeh. captain sollte das heissen
[20:21] <|Sophie|> das Parsersystem von Menouthis ist so, dass ein auf Javabasierender Client jeden Befehl syntaktisch parsen kann, ohne ihn semantisch kennen zu müssen
[20:22] <Enn0> und wenn man andere beziehungen zwischen objekten hat, kann man die aehnlich definieren und der client, wenn er schlau genug ist, kann die zumindest in den properties des schiffes/gebaeudes/etc ordentlich anzeigen
[20:22] <|Sophie|> hm
[20:22] <Enn0> den satz musst du mir nochmal auseinanderklamuesern :-)
[20:22] <|Sophie|> hab ihr Kulturen oder sowas?
[20:22] <Enn0> wir haben rassen.
[20:23] <Enn0> ich weiss nicht, was kulturen sind
[20:24] <|Sophie|> ich hab alle parserrelevantenteile in eine eigene Bibliothek ausgelagert, wenn der Client die entsprechenden Definitionen eines Befehls kennt, kann er sich die nötigen Voraussetzungen, Vervollständigungen etc aus dieser Bibliothek holen
[20:24] <|Sophie|> im Prinzip das gleiche in Grün, bei Spielern sehr beliebt
[20:24] <|Sophie|> allerdings wäre das dann wieder ein generelles Objekt, das in den Konfigurationsteil muss
[20:25] <|Sophie|> und auf das die Partei dann linken muss
[20:25] <|Sophie|> nur das der Client dann keine Ahnung hat, auf was da gelinkt wird, wenn er das Objekt nicht kennt
[20:25] <|Sophie|> allerdings: Die meisten Objekte bestehen aus Name, Beschreibung und einem Satz Effekten
[20:26] <Enn0> aber was kann er denn dann mit so einem unbekannten objekt anfangen?
[20:26] <|Sophie|> damit könnte man auch unbekannte Objekte teilweise lesen
[20:27] <Enn0> die zu lesen macht aber ja nur sinn, wenn man mit ihnen was anfangen kann.
[20:27] <|Sophie|> ein M-Held besitzt darüberhinaus z.B. noch Voraussetzungen, die eine Einheit erfüllen muss um dieser Heldentyp werden zu können
[20:27] <|Sophie|> aber das wäre ja eine eher unwichtige Information
[20:29] <|Sophie|> wenn der Report jetzt sowas in der Richtung <link type="hero" ref="id"> und einen configteil mit <hero><name>...<effects>...</.. hätte, könnte der Client, auch ohne das Heldenkonzept zu kennen bei der Anzeige: Held: Typname (Effekte: ...) schreiben
[20:31] <|Sophie|> genauso bei Kulturen oder Rassen
[20:31] <|Sophie|> bei Gegenständen ists komplizierter, weil da die Einheit noch zusätzliche Informationen, nämlich die Anzahl hat
[20:33] <|Sophie|> hm, wobei man auch solche zusätzlichen Attribute in Form einer Metametacodierung speichern kann
[20:33] <Enn0> ja. und ich will auch nicht alles als relativ fade <link/> elemente modellieren, dann kommt man irgendwann dahin dass das ganze sehr unstrukturiert wird.
[20:33] <Enn0> etwas sehr meta :-)
[20:34] <|Sophie|> der configteil hätte dann also sowas wie: <configobject id="item"><argument type="int"><name>Anzahl</name></argument></configobject>
[20:34] <Enn0> wenn du soviel zeit nicht hast, aber doch interesse teilzunehmen, vielleicht koenenn wir einfach mal mit den stakeholdern (client-entwickler, spiel-entwickler, usw) eine irc-debatte machen, wenn wir etwas weiter gekommen sind.
[20:35] <|Sophie|> das mit dem Gegenstand ist jetzt nur ein Beispiel, nimm irgendwas, was sich irgendwer zusätzlich ausgedacht hat
[20:35] <Enn0> darueber muss ich jetzt z.B. erstmal wieder gruebeln :-)
[20:36] <|Sophie|> sirprize schlägt vor, Daten in XML und daneben gerenderten NR-Text zu haben, als Fallback
[20:36] <|Sophie|> wenn ein Client irgendwas nicht kennt, zeigt er den Text an
[20:37] <Enn0> das blaeht dann gewaltig au.
[20:37] <Enn0> auf
[20:38] <|Sophie|> ich fürchte nur, ohne Redundanz bekommen wir keine gut kompatible Vielfältigkeit
[20:39] <|Sophie|> am wenigsten Platz würde ein Binärformat verbrauchen, das wäre dann aber extrem spielabhängig
[20:41] <Enn0> aber NR reinmachen taete man ja primaer, um clients zu supporten, die nicht aktualisiert werden.
[20:41] <|Sophie|> wir müssen da halt irgendwo einen Kompromiss in der Mitte bekommen
[20:41] <Enn0> andere clients koennen sich genauso gut auf neue daten einstellen.
[20:42] <|Sophie|> es würde einem Spieleentwickler erlauben, neue Features einzubauen, ohne das alle Clients diese zunächst nicht unterstützen
[20:44] <Enn0> ich kuendige sowas eigentlich immer mit genug vorlauf an. aber eine moeglichkeit, einen optionalen CDATA block mit textdarstellung in einzelne elemente zu haengen, kann man mal ueberlegen. ja.
[20:45] <|Sophie|> man muss dort als Spieleentwickler ja nicht gezwungen sein etwas reinzuschreiben
[20:45] <|Sophie|> bzw das Element überhaupt zu setzen
[20:47] <Enn0> ja. gute idee.
[20:49] <|Sophie|> hm, zusammen mit einer Grundstruktur für Spielobjekte (so heißt das Interface bei mir ;) ), sollte da eigentlich was richtig hübsches rauskommen
[20:49] <|Sophie|> sprich alles was über Partei, Region, Einheit, Item, Talent, Zauber hinausgeht wird mit link eingebunden
[20:49] <|Sophie|> Resourcen fehlen noch
[20:50] <Enn0> wir wollen regel-spezifisches in ein separates dokument hauen.
[20:50] <Enn0> genau.
[20:51] <|Sophie|> ich hab das in einem, aber das kann man ja auch über die beliebte "mehrere XML-Dateien in einer zip-Datei"-Format lösen
[20:51] <Enn0> so soll das.
[20:51] <|Sophie|> hm, bei mir können auch Regionen Gegenstände haben, bzw eigentlich haben die Bauern diese Gegenstände
[20:51] <Enn0> acuh um historische infos, oder die reporte von mehr als einer partei miteinander zu verbinden
[20:51] <Enn0> das hab ich mir schon gedacht
[20:51] <|Sophie|> dann sollte jedes Objekt noch ein optionales turn Attribut haben
[20:51] <Enn0> ich glaube, bei mir im prinzip auch. wird nur von eressea nicht benutzt
[20:52] <Enn0> parteien haben auch einheiten bei mir
[20:52] <Enn0> nein, kein optionales turn-attribut
[20:52] <|Sophie|> Parteien haben bei mir zum Beispiel keine
[20:52] <Enn0> da haben wir uns gegen entschieden. das machen wir einmal an das document oben, ein date-feld.
[20:52] <Enn0> ich glaube, gebaeude auch. irgendwann hab ich die mal einfgfach an alles geklemmt :-)
[20:53] <Enn0> safuer hatten bis heute regionen keine unique id. endlich mal gemacht.
[20:53] <|Sophie|> ja, leerstehen lassen kann man den Kram ja immer noch
[20:53] <Enn0> unsere regionen haben auch keine sub-regionen, aber wir planen die trotzdem ein.
[20:53] <Enn0> das "kostet" ja nix.
[20:54] <|Sophie|> was sind denn subregionen?
[20:54] <Enn0> ausser etwas mehr arbeit fuer den client-entwickler, wenn er das supporten will
[20:54] <Enn0> eine region mit staedten drin.
[20:54] <|Sophie|> bei einer Z-Achse wäre ich übrigens eher für eine benannte als eine benummerte Koordinate
[20:54] <Enn0> aus denen man rein und raus in die region kann
[20:54] <|Sophie|> ah
[20:55] <Enn0> da hatten wir schon ein ziemliches hin und her
[20:55] <|Sophie|> ich finde eine Zahl macht nur Sinn, wenn sie eine echte Zahl ist ;)
[20:56] <Enn0> wir machen ein <coordinate/> objekt, und was da reinkommt ist noch nicht ganz klar. z-koordinaten druecken eine ordnung aus, und die kann ja wichtig sein, je nach spiel.
[20:56] <|Sophie|> wie machen wir das mit Regionstypen? Als Link oder als fixes Element
[20:56] <Enn0> wenn ich in Atlatnis:Inferno die 9 level der hoelle habe, zum beispiel :-)
[20:56] <Enn0> terrain ist glaub ich fix.
[20:56] <|Sophie|> ja, aber das ist immer noch so diskret ;)
[20:57] <Enn0> meinetwegen kann da dann in dem coordinate-objekt noch platz fuer optionale <plane name="happyhippoland"/> modifier sein
[20:58] <|Sophie|> ja stimmt eigentlich, wenn jemand Z-Koordinaten will, soll er sie haben
[20:58] <Enn0> und wenn einer garkeine koordinaten will, dann das auch :-)
[20:58] <|Sophie|> solange man noch eine plane definieren kann, stört das zumindest die Spieleentwickler nicht
[20:58] <Enn0> ich wollte das immer schon.
[20:59] <|Sophie|> die Cliententwickler dürfen sich dann über Topologie und Metrik Gedanken machen ;)
[20:59] <|Sophie|> Region (0,0) im Osten, Nordosten, Nordwesten, Westen, Südwesten, Südosten und Osten: Feuerwand
[21:00] <Enn0> ich denke mal, solang ich ein neues spiel erfinden kann, das dann ohne aenderung des DTD voll ausdruecken kann, und an den stellen, wo es spezielle art der darstellung braucht, diese im client nachpflegen kann, dann haben wir gewonnen.
[21:00] <Enn0> achja: osten und westen.
[21:01] <|Sophie|> ja und ich denke mit optionalen CDATA Text und links ist man davon nicht weit entfernt
[21:01] <Enn0> es kann ja sein, dass ein spiel sich fuer nord und sued als hauptrichtungen entscheidet. tut mindestens ein atlantis-klon. spielt das eine rolle?
[21:01] <|Sophie|> im Prinzip taucht das nirgendwo im Report auf
[21:01] <Enn0> nee, eigentlich nicht.
[21:01] <|Sophie|> da stehen ja nur Koordinaten, keine Topologien
[21:02] <Enn0> ein wenig ist ncoh die frage, was man mit messages macht. der erste entwurf den ich da heute zu gesehen habe, war ein echter hammer.
[21:02] <|Sophie|> nur wird der Client vermutlich ganz gerne wissen, welche Topologie denn gerade angesagt ist
[21:02] <Enn0> ja, das beschreibt man irgendwo meta in der spieldefinition
[21:02] <|Sophie|> im Prinzip sind messages ein Fall von CDATA mit optionalen Datenfeldern
[21:03] <Enn0> und alternativen fuer sprache
[21:05] <|Sophie|> hm, wenn sowieso bekannt ist, welche Sprache der Empfänger des Reports haben will, braucht er die ja eigentlich nicht, oder?
[21:06] <|Sophie|> aus dem Grund hatte ich immer auf Mehrsprachigkeit für die Reports selbst verzichtet
[21:06] <Enn0> stimmt, wenn im report drinsteht, welche sprache die messages haben, ist das genug. das ist wie mit dem turn.
[21:07] <Enn0> aber wenn ich einen englsichen und einen deutschen merge, muss ich halt drauf achten, dass ich wenn ich zweimal die gleiche regions-message habe, nur die anzeige, die der leser lieber hat.
[21:07] <Enn0> in unseren reporten kann man das erkennen, die messages haben eine id.
[21:07] <|Sophie|> ja, schließlich will niemand wissen, das Feen auf englisch fairies heißen, wenn er sowieso einen deutschen Report will
[21:08] <|Sophie|> ja, das geht
[21:08] <|Sophie|> die Frage ist halt noch, was die semantischen Infos von Messages angeht
[21:08] <Enn0> und er will nciht, wenn er reporte von 6 parteien hat, viermal "Ein Einhorn erscheint" in der Region stehen sehen, und zweimal "a unicorn appears" :-)
[21:08] <Enn0> das sind sicher viele links
[21:08] <|Sophie|> da werden sich Spiele wahrscheinlich am meisten unterscheiden
[21:09] <Enn0> eigentlich muesste man da richtige hrefs machen, mit vollen URI. Damit man auch daten nachladen kann, die der client nicht hat
[21:10] <Enn0> es gibt in eressea reihenweise items, skills, monster, usw. die nicht in den regeln stehen
[21:11] <|Sophie|> ja, deshalb schicke ich die Regeln beim Report mit
[21:11] <|Sophie|> nachladen zerstört halt den wesentlichen PbEM-Vorteil der Internetlosigkeit
[21:11] <Enn0> dein ajax-client aber auch
[21:11] <|Sophie|> ja, aber der ist fakultativ
[21:12] <Enn0> ich kann immer noch die regeln mitschicken, aber ich will die option drinlassen
[21:12] <|Sophie|> hm, man könnte das ja als Spieleroption machen
[21:13] <|Sophie|> achja, da fällt mir noch was ein, was ich gesehen hab: Helfestati sollten keine numerischen Werte sein
[21:14] <Enn0> sind sie das?
[21:14] <|Sophie|> moment, ich guck nochmal
[21:14] <Enn0> wir hatten da frueher mal ein bitfeld, glaub ich, aber ich glaub nicht mehr
[21:15] <|Sophie|> http://eressea.game-host.org/de/XML_Format#Allianzen_.28HELFE_Stati.29
[21:15] <Enn0> ohja.
[21:15] <Enn0> ich hab noch nicht alles nachgeholt, was seit gestern passiert ist :-) so darf das nicht
[21:16] <Enn0> helpstatus find ich auch einen schietnamen :-)
[21:16] <|Sophie|> ja, ich würde es eher diplomancy nennen
[21:16] <|Sophie|> dann kann man auch Kriegserklärungen reinsetzen
