Show whole topic
Jun 09, 2009 9:20 pm
Jun 09, 2009 9:20 pm
Subject: Neue Einheiten XMLs
Ich habe gestern mit Eiko ein wenig darüber geredet, wie wir das mit der cUnit Sache neu umsetzten können, wo Hackar ja schon eine ganze weile dran ist. Wir sind zu dem Entschluss gekommen, dass dieser Monsterumbau auf einen Schlag wohl nicht durchzuführen sein wird. Unsere Idee war es erstmal langsam ein paar einzelne Dinge schon mal auf eine gemeinsame Unit Klasse vorzubereiten. Als erster Punkt standen dafür neue, mehr an das tatsächliche Spielverhalten angepasste Einheiten XMLs auf dem Plan. Wenn wir diese kompakt und passend hinbekommen, kann das die Arbeit für Hackar deutlich vereinfachen, da er dann genauer ablesen kann, was wir den exakt brauchen. Meine Meinung dazu ist, dass wir die XMLs dann so gestallten, dass man aus Ihnen möglichst alle Informationen so raus bekommt, wie man sie dann im Spiel braucht und nicht noch Unmengen zusätzlichen Schnickschnack für die Zukunft einplant. Sachen für die Zukunft können auch in Zukunft noch ergänzt werden. Das soll aber nicht heißen, dass die XMLs genau so aufgebaut werden sollen wie ganz früher die INIs! Besonders so Sachen wie "is_connector", "is_bridge" etc. sollten unbedingt nicht drin stehen, doch man muss die entsprechenden Fähigkeiten halt irgendwie anders verpacken und das möglichst ohne den halben Quellcode der damit arbeitet wieder umzuschreiben.
Ich bin mal durch eine momentane data.xml, und die temporäre Konverter Funktion im Code durchgegangen und habe raus geschrieben, welche Informationen im Spiel noch über die IDs der Einheiten dazugedichtet werden und welche Informationen meines Erachtens unnötig in der XML stehen.
Die Transporter data.xml habe ich als refernez genommen. Ich geh dann jetzt mal alle Punkte nacheinander Durch:
Sachen die noch Fehlen:
-> is_stealth_land - Der Infiltrator ist die einzige Einheit, die dieses Attribut besitzt. Bis jetzt wird dadurch konvertiert. Das sollte aber als extra Punkt in die XML
-> us_stealth_sea - für die Einheiten APC und Submarine. Bis jetzt gehts nach ID, sollte aber auch in die XML.
-> is_connector - hier brauchen wir Ersatz. So was sollte kein Attribut sein. Nur was gibts als Ersatz?! Ich denke wir bräuchten einmal ein Attribut "is_blocking" bzw. eher das Gegenteil, um sicherzustellen, dass Fahrzeuge auf das Feld Fahren können. Evtl. auch eher so etwas wie "surface_position" und da dann die Auswahl unter Einheiten ( für Straßen, Plattform, Brücke. Das würde heißen diese Einheit kann von anderen Einheiten überfahren werden), dann normal (für all das, was ein Feld blockiert) und dann eben noch über Einheiten (für den Connector). Das ganze wäre denke ich mittlerweile relativ gut umsetzbar, da Eiko ja mal die meisten Abfragen, die diese Sache verwenden in cMap::possiblePlace zusammengebracht hat.
-> is_road - selbe wie Connector. Zusätzlich bräuchten wir dann aber noch so was wie "makes_driving_faster".
-> is_bridge - müsste eigentlich nur über dieses position Attribut ersetzbar sein.
-> is_platform - hier bräuchten wir auch noch ein Attribut wie "can_be_overbuild". Ist evtl. auch interessant für die Connectoren. da müsste man da aber noch mal differenzieren ob die Einheit nach dem überbauen bestehen bleibt oder ersetzt wird.
-> is_pad - "can_be_landed_on" oder ähnlich...
->is_mine - hier sollte so was wie "can_mine_resources" her.
-> is_annimated - verwendet nur das Radar. Sollte auch in die XML. Am besten in das letzte Abteil "Graphics" zu dem zeug mit Overlay usw.
-> build_allien - ich würde sagen Aliens nehmen wir erstmal komplett aus dem Spiel und auch aus den XMLs. Wenn es soweit ist. ist das ganz schnell wieder drinnen. Außerdem würde ich das dann sowieso mit dem "can_build" Attribut zusammen nehmen. mehr dazu später.
-> build_on_water - so was brauchen wir auf jeden fall auch. Man muss ja wissen welche Einheiten auf Wasser gebaut werden müssen.
-> is_alien - würde ich vorerst raus nehmen.
-> can_work - hier ist die Frage ob wir dieses Attribut wirklich in der XMl brauchen. Im Moment holt sich das der Data Konverter dadurch, dass er schaut ob die Einheit Energie verbraucht oder produziert. Das deckt alle Einheiten ab, die einschaltbar sind. Evtl. ist das auch sinnvoll, das so zu lassen.
-> can_build - bis jetzt gibt es hier die Auswahl "BIG", "SMALL", "SEA", "AIR", "MAN", "NONE". In den XMLs ist es so drinnen, dass jede Einheit ein Attribut "Is_Produced_by" besitzt. Das wird aber vom Konverter nicht genutzt, da hier Konflikte entstehen könnten, wenn sowohl Flugzeuge als auch Schiffe die selbe Einheit bei Produced_by drin stehen hätten und außerdem könnte man die liste dann ja nur am Ende wenn alle Einheiten fertig geladen wurden erstellen und das war mir damals zu kompliziert, da ich dachte die Konverter Funktion wird sowieso nur sehr kurz bestehen (wie man sich doch irren kann ^^). Ansonnsten müsste Produced_by das ganz gut ersetzten können, aber ich fände dies Listen würden auch Nachteile mit sich bringen. Zum Beispiel wenn jemand eine neue Einheit entwickelt, die auch kleine Gebäude bauen kann. Dann müsste an diese Einheit wieder in ALLEN kleinen Gebäuden in die Produced_by Liste aufnehmen. Evtl wäre es also durchaus sinnvoll Einheiten in Gruppen wie LIGHT_TANK, HEAVY_TANK, PLANE, SHIP, LIGHT_BUILDING, etc. aufzuteilen und dannach die Baumöglichkeiten aufteilen. Man könnte zwar die Standardeinheiten nicht mehr so expliziet nur in einzelnen fabriken bauen lassen, aber die Frage ist ob das überhaupt wirklich wichtig ist. Für später könnten hier ja jederzeit vom Einheiten ersteller neue Gruppen hinzugefügt werden. Im code dann einfach ein string vergleich, was gebaut werden kann, und zu welcher Gruppe die zu bauende Einheit gehört.
-> build_by_big würde durch die obige Änderung wegfallen.
-> is_base würde durch diese "surface_position" Sache ersetzt werden.
-> can_drive_and_fire muss auch rein.
Ich habe gestern mit Eiko ein wenig darüber geredet, wie wir das mit der cUnit Sache neu umsetzten können, wo Hackar ja schon eine ganze weile dran ist. Wir sind zu dem Entschluss gekommen, dass dieser Monsterumbau auf einen Schlag wohl nicht durchzuführen sein wird. Unsere Idee war es erstmal langsam ein paar einzelne Dinge schon mal auf eine gemeinsame Unit Klasse vorzubereiten. Als erster Punkt standen dafür neue, mehr an das tatsächliche Spielverhalten angepasste Einheiten XMLs auf dem Plan. Wenn wir diese kompakt und passend hinbekommen, kann das die Arbeit für Hackar deutlich vereinfachen, da er dann genauer ablesen kann, was wir den exakt brauchen. Meine Meinung dazu ist, dass wir die XMLs dann so gestallten, dass man aus Ihnen möglichst alle Informationen so raus bekommt, wie man sie dann im Spiel braucht und nicht noch Unmengen zusätzlichen Schnickschnack für die Zukunft einplant. Sachen für die Zukunft können auch in Zukunft noch ergänzt werden. Das soll aber nicht heißen, dass die XMLs genau so aufgebaut werden sollen wie ganz früher die INIs! Besonders so Sachen wie "is_connector", "is_bridge" etc. sollten unbedingt nicht drin stehen, doch man muss die entsprechenden Fähigkeiten halt irgendwie anders verpacken und das möglichst ohne den halben Quellcode der damit arbeitet wieder umzuschreiben.
Ich bin mal durch eine momentane data.xml, und die temporäre Konverter Funktion im Code durchgegangen und habe raus geschrieben, welche Informationen im Spiel noch über die IDs der Einheiten dazugedichtet werden und welche Informationen meines Erachtens unnötig in der XML stehen.
Die Transporter data.xml habe ich als refernez genommen. Ich geh dann jetzt mal alle Punkte nacheinander Durch:
Sachen die noch Fehlen:
-> is_stealth_land - Der Infiltrator ist die einzige Einheit, die dieses Attribut besitzt. Bis jetzt wird dadurch konvertiert. Das sollte aber als extra Punkt in die XML
-> us_stealth_sea - für die Einheiten APC und Submarine. Bis jetzt gehts nach ID, sollte aber auch in die XML.
-> is_connector - hier brauchen wir Ersatz. So was sollte kein Attribut sein. Nur was gibts als Ersatz?! Ich denke wir bräuchten einmal ein Attribut "is_blocking" bzw. eher das Gegenteil, um sicherzustellen, dass Fahrzeuge auf das Feld Fahren können. Evtl. auch eher so etwas wie "surface_position" und da dann die Auswahl unter Einheiten ( für Straßen, Plattform, Brücke. Das würde heißen diese Einheit kann von anderen Einheiten überfahren werden), dann normal (für all das, was ein Feld blockiert) und dann eben noch über Einheiten (für den Connector). Das ganze wäre denke ich mittlerweile relativ gut umsetzbar, da Eiko ja mal die meisten Abfragen, die diese Sache verwenden in cMap::possiblePlace zusammengebracht hat.
-> is_road - selbe wie Connector. Zusätzlich bräuchten wir dann aber noch so was wie "makes_driving_faster".
-> is_bridge - müsste eigentlich nur über dieses position Attribut ersetzbar sein.
-> is_platform - hier bräuchten wir auch noch ein Attribut wie "can_be_overbuild". Ist evtl. auch interessant für die Connectoren. da müsste man da aber noch mal differenzieren ob die Einheit nach dem überbauen bestehen bleibt oder ersetzt wird.
-> is_pad - "can_be_landed_on" oder ähnlich...
->is_mine - hier sollte so was wie "can_mine_resources" her.
-> is_annimated - verwendet nur das Radar. Sollte auch in die XML. Am besten in das letzte Abteil "Graphics" zu dem zeug mit Overlay usw.
-> build_allien - ich würde sagen Aliens nehmen wir erstmal komplett aus dem Spiel und auch aus den XMLs. Wenn es soweit ist. ist das ganz schnell wieder drinnen. Außerdem würde ich das dann sowieso mit dem "can_build" Attribut zusammen nehmen. mehr dazu später.
-> build_on_water - so was brauchen wir auf jeden fall auch. Man muss ja wissen welche Einheiten auf Wasser gebaut werden müssen.
-> is_alien - würde ich vorerst raus nehmen.
-> can_work - hier ist die Frage ob wir dieses Attribut wirklich in der XMl brauchen. Im Moment holt sich das der Data Konverter dadurch, dass er schaut ob die Einheit Energie verbraucht oder produziert. Das deckt alle Einheiten ab, die einschaltbar sind. Evtl. ist das auch sinnvoll, das so zu lassen.
-> can_build - bis jetzt gibt es hier die Auswahl "BIG", "SMALL", "SEA", "AIR", "MAN", "NONE". In den XMLs ist es so drinnen, dass jede Einheit ein Attribut "Is_Produced_by" besitzt. Das wird aber vom Konverter nicht genutzt, da hier Konflikte entstehen könnten, wenn sowohl Flugzeuge als auch Schiffe die selbe Einheit bei Produced_by drin stehen hätten und außerdem könnte man die liste dann ja nur am Ende wenn alle Einheiten fertig geladen wurden erstellen und das war mir damals zu kompliziert, da ich dachte die Konverter Funktion wird sowieso nur sehr kurz bestehen (wie man sich doch irren kann ^^). Ansonnsten müsste Produced_by das ganz gut ersetzten können, aber ich fände dies Listen würden auch Nachteile mit sich bringen. Zum Beispiel wenn jemand eine neue Einheit entwickelt, die auch kleine Gebäude bauen kann. Dann müsste an diese Einheit wieder in ALLEN kleinen Gebäuden in die Produced_by Liste aufnehmen. Evtl wäre es also durchaus sinnvoll Einheiten in Gruppen wie LIGHT_TANK, HEAVY_TANK, PLANE, SHIP, LIGHT_BUILDING, etc. aufzuteilen und dannach die Baumöglichkeiten aufteilen. Man könnte zwar die Standardeinheiten nicht mehr so expliziet nur in einzelnen fabriken bauen lassen, aber die Frage ist ob das überhaupt wirklich wichtig ist. Für später könnten hier ja jederzeit vom Einheiten ersteller neue Gruppen hinzugefügt werden. Im code dann einfach ein string vergleich, was gebaut werden kann, und zu welcher Gruppe die zu bauende Einheit gehört.
-> build_by_big würde durch die obige Änderung wegfallen.
-> is_base würde durch diese "surface_position" Sache ersetzt werden.
-> can_drive_and_fire muss auch rein.
Albert Ziegenhagel