alzi | 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. |
alzi | Jun 09, 2009 9:21 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Sachen die meiner Meinung nach raus können: -> Is_Controllable es gibt im Code eigentlich nichts, dass bis jetzt auch nur annährend so etwas überprüft. Das ergibt sich eigentlich daraus, ob eine Einheit bauen, fahren, schießen, etc. kann und daraus ergeben sich dann auch die Menüunterpunkte. Um aber die dann richtig hin zu bekommen, bräuchte man z.B. noch so was wie "can_be_self_destroyed". z.b. für die explode-minen. -> Size_Length/Widht ist finde ich nicht nötig. Wir sind weit davon entfernt verschiedene Gebäudegrößen zu unterstützen. Nur eben dieses "is_big" ist dann nötig. -> Is_Target_ ... kann finde ich raus, weil es doppelt mir "Allowed_Targets" in der Waffen Sektion ist. Das macht finde ich kaum einen sinn zu definieren, von welchen Einheiten eine Einheit angegriffen werden kann und dann auch noch welche Einheiten eine Einheit überhaupt Angreifen kann. Also ich finde zumindest kaum ein Beispiel wo sich das mal unterscheiden sollte und außerdem ist unser Code im Moment noch gar nicht auf eine solche Doppelabfrage ausgelegt, daher würde ich es erstmal bei einem einfache "can_attack" Attribut belassen, wie es auch vom Code unterstützt wird. -> Built_Costs(_Max) Ich weiß nicht genau, wie das mit dem maximalen Wert ist, aber mit kommt es so vor, als wenn er immer das Dreifache des normalen Werts ist. Wenn das der Fall ist, dann brauchen wir das ja nicht. Mal drei kann auch das Programm rechnen. Und zum Normalwert: Wenn man aus dem original die Attribute der Einheiten aus der Resdatei extrahiert, dann gibt es da nicht genau die Baukosten. Dafür steht da ein Wert drin, der immer die Hälfte der Baukosten bei Fahrzeugen oder ein drittel der Baukosten bei Gebäuden (oder auch umgekehrt, weiß nicht mehr genau) ist. Dieser Wert wird dann z.b. auch benötigt um zu berechnen wie teuer Reparaturen sind oder wie lange Einheiten außergefecht gesetzt bleiben. Evtl. sollten wir lieber diesen Originalwert reinschreiben als das alles zurückzurechnen?!? -> Is_Produced_by Siehe "can_build" -> Turret_Gfx kann raus finde ich. Noch zu sehr Zukunft und der Code ist weit entfernt von so was. -> Shot_Trajectory selbes wie Turret_Gfx -> Ammo_Type selbes wie Turret_Gfx & Shot_Trajectory -> Allowed_Targets Siehe "Is_Target_ ..." -> Destination_Area/Destination_Type Mit so speziellen Treffertypen kann unser Code noch lange nicht umgehen und das wird er auch lange nicht können. Von daher würde ich sagen das kommt raus und lieber ein einfaches "cluster_attack" für den Raketenwerfer. -> Movement_Allowed Ist auch hier zu speziell. So was kann unser Code nicht. Es gibt hierfür die Regel can_attack_and_fire, die nicht mit einer Anzahl von Bewegungspunkten, die frei sind bis der Schuss verloren geht vereinbar sind. Von daher würde ich sagen auch das kommt raus. -> Gets_Experience, Can_Dive, Landing_Type, Can_Upgrade, Is_Kamikaze, Is_Infrastructure alles raus. -> Self_Repair_Type Gebäude machen dies generell. Evtl. bräuchte man dieses Attribut, da wir ja die Trennung zwischen Gebäuden und Fahrzeugen abschaffen. Aber ich denke die Sache mit dem "mit Material oder ohne" ist unnötig. -> Can_Launch_SRBM, Energy_Shield_Strength, Energy_Shield_Size raus! -> Range_ ... ist im Moment völlig unnötig da zu unterscheiden. Würde ich auf ein einziges "Scan" Attribut zusammenfassen. -> Costs_ ... / Factor_ ... Raus! Das hängt von anderen spielinternen Regeln ab und wird sich vermutlich auch erstmal nicht ändern. -> Capacity_ ... Das ist evtl. ganz gut, das zu differenzieren, aber im Moment im Code nicht vorgesehen und ist glaube ich auch ne menge Arbeit das zu ändern. Hier muss man überlegen ob man sich die Arbeit macht, oder ob wir doch nur die Aufteilung in "cargo" und "can_load" machen, so wie früher. Reicht nämlich eigentlich für alle bestehenden Sachen aus. Besonders Kompliziert wird das ganze mit dem Umbau nämlich wenn es darum geht das Laden der Einheiten auch auf "Can_Use_Unit_As_Garage" anzupassen. So das wars dann erstmal mit meinem Megapost. Bitte Senf dazu abgeben |
Toranaga | Jun 10, 2009 5:10 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Klingt sehr gut! Vor allem der Satz "Sachen für die Zukunft können auch in Zukunft noch ergänzt werden" gefällt mit sehr gut! Natürlich für die Zukunft offen sein, aber nicht schon alles für die Zukunft machen - das macht alles nur unnötig kompliziert. Deine Vorschläge klingen für mich alle plausibel. Ob etwas fehlt oder zuviel ist, kann ich so ad hoc nicht sagen, aber das wird man dann sicher in der Umsetzung sehen. Ein anderer Bereich zum Aufräumen und wo man nochmal sehen kann, was es alles für (zum großen Teil unbenutzte) Attribute gibt, ist sUnitData. Da kann dann auch fast alles raus. Aber das passiert ja durch die neue cUnit sowieso. |
alzi | Jun 11, 2009 4:14 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Habe vergessen, das Hackar im development forum nicht schreiben kann. deswegen hat er mir eine pm mit der antwort geschrieben, die ich jetzt hier poste. Wäre evtl. ganz gut wenn einer der Moderatoren das hier in den normalen M.A.X.R Bereich verschieben könnte Quote: meine gedanken zu xml sachen (da ich auf dein post iwie nicht antworten kann: |
alzi | Jun 11, 2009 6:17 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Und dann gehts auch gleich weiter mit Kommentaren von mir: Ersteinmal habe ich weiter nach Dingen gesucht die noch fehlen und mir dazu mal die draw bzw. render methoden nochmal genau angeschaut. Uns fehlen da noch ein paar Sachen, die wiedermal von "is_road" etc. abhängen. -> sowas wie show_demage_effect. Soll heißen, Straßen, Plattformen, etc. zeigen nicht diesen Raucheffekt, wenn sie beschädigt sind. Das muss der Code ja irgendwo her nehmen. -> has_beton der Zeichencode muss unterscheiden können ob unter ein Gebäude der Betonboden gemalt werden muss. -> has_player_color der Zeichencode muss unterscheiden können ob die Spielerfarbe für diese Einheit geblittet werden muss. so und nun zu Hackars Antwort: Quote: jup das ist durchaus sinnvoll und umzusetzen schlage gleich modifies_speed vor, angabe in % Quote: jo überfahrbar, wäre auch eine möglichkeit. Wäre so ziemlich das gleiche wie mein "is_blocking". Nur würde ich halt wirklich noch die extra unterscheidung über "surface_position" machen, in der festgelegt wird ob die einheit unter, über oder auf gleichem level mit anderen einheiten steht. Das ist wichtig fürs zeichnen! Da fällt mir grade aber auch ein, dass wir noch einen zwischenschritt brauchen. Für Brücken, die sowohl über Fahrzeugen (wenn ein Schiff drunter steht) als auch unter Einheiten gemalt werden müssen können.Zitat: Quote: jo, das ist auch eine Möglichkeit. Bringt etwas mehr Umbauaktionen im Code mit sich, aber die dürften überschaubar sein.Zitat: Quote: Sofern wir irgendwann Einheiten haben, die auch andere Resourcen als Energie verbrauchen, wäre das villt wirklich sinnvoll, aber ich denke das System von MAX ist, dass jede Einheit die andere Resourcen außer Energie verwertet immer dazu auch Energie benötigt. Aber eigentlich weiß man ja wirklich nie was noch so kommt und prinzipiel kann der Code das schon jetzt.can_work Das nach dem bestehenden Modell übrigens Power-Stations auch ein- und ausschaltbar sind, liegt daran, dass nicht nur geprüft wird ob die Einheit Energie verbraucht, sondern auch ob sie welche produziert. Quote: In meinem Text habe ich ja erläutert, wieso das evtl. nicht das Sinnvollste ist. Da muss man jetzt halt abwägen can_build Quote: "is_base" hat momentan eine ganz andere Funktion. Es bedeutet, dass eine Einheit unter anderen Gebäuden ist. Ist z.b. gesetzt bei Straßen, Brücken, Minen, usw. Deswegen habe ich ja geschrieben, dass es durch die "surface_position" ersetzt werden soll.is_base Quote: dieses Attribut, hat nicht einfach zu bedeuten, dass die Einheit sowohl can_attack und auch can_drive hat, sondern dass die Einheit, nachdem sie gefahren ist, immernoch Schießen kann, also nur langsam mit den Bewegungspunkten die Schüsse verliert und nicht sofort nach dem ersten Schritt. Das ersetzt also quasi das Movement_Allowed. Aber nur quasi, denn Movement_allowed will vorgeben, dass eine bestimmte Anzahl von Bewgungspunkten frei ist, bis nicht mehr geschossen werden kann. Diese Anzahl kann aber nicht von Beginn an fest angeben werden. Sie wird vom Code berechnet und ändert sich z.b. auch durch Forschung.can_drive_and_fire Quote: Allien Gebäude würde ich erstmal nur im Hinterkopf behalten. Jetzt für die schon Dinge in die XMLs aufzunehmen würde ich unbedingt vermeiden. Machts nur unnötig kompliziert. Das dauert sowieso noch bis wir sie implementieren.Is_Controllable Quote: Weil es im Moment einfach noch überhaupt keine Funktion hat und in anher Zukunft auch erstmal keine haben wird.Gets_Experience, Can_Dive, Can_Upgrade, Is_Kamikaze Quote: wozu brauchen wir das? Es gibt noch nirgends verschiedene Raten und feste Kosten. Wie Gebäude sich selbst reparieren errechnet sich aus Ihren Baukosten, so wie im Original. Was anderes wird es auch hier in naher Zukunft denke ich nicht geben.Self_Repair_Type Quote: Ich meine ein anderes Factor. z.b. "Factor_Water" oder "Factor_Coast". Das soll dazu dienen um welchen Faktor sich der Wegpunkteverbrauch von Einheiten ändert, je nachdem auf welchem Gelände sie sich bewegen. Macht Ihmo keinen sinn. Eher sollte das Gelände die Eigenschaft besitzen die Kosten zu ändern (wie die straße) als dass es bei der Einheit drin steht. Und wie gesagt, kann unser Code sowas auch noch garnicht.Factor Aber du hast recht, den anderen Faktor Wert brauchen wir auch. Im Moment hängt das glaub einfach davon ob, ob die Fabrik Menschen herstellen kann. Quote: Habe hier ja beschrieben warum das evtl nicht das sinnvollste ist.Capacity MFG alzi |
HackAR | Jun 13, 2009 3:51 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Quote: bei mir: showDamageshow_demage_effect Quote: bei mir: drawUndergroundhas_beton Quote: Soweit ich weiß wird es im Original über Prozente berechnet. Wenn Unit x % der Bewegungspunkte übrig hat, so hat sie auch x % der schüße übrig (abgerundet)Movement_allowed will vorgeben, dass eine bestimmte Anzahl von Bewgungspunkten frei ist, bis nicht mehr geschossen werden kann. Quote: Ich schlage vor die boolean sachen nur dann in die xml reinzuschreiben, wenn sie wahr sind.Jetzt für die schon Dinge in die XMLs aufzunehmen würde ich unbedingt vermeiden. Quote: Wenn wir Einheiten einheitlich behaldeln wollen, brauchen wir sowas...Gets_Experience, Can_Dive, Can_Upgrade, Is_Kamikaze Quote: Komisch. ich dachte die Gebäude reparieren sich immer 2hp/round unabhängig von den Kosten...Wie Gebäude sich selbst reparieren errechnet sich aus Ihren Baukosten, so wie im Original. Quote: dann haben wir noch die sonderfälle scout, geolog, ...Eher sollte das Gelände die Eigenschaft besitzen die Kosten zu ändern (wie die straße) als dass es bei der Einheit drin steht. Quote: wie ist Can_Use_Unit_As_Garage zu verstehen? Capacity |
alzi | Jul 07, 2009 1:19 pm |
---|---|
Subject: Re: Neue Einheiten XMLs So, ich habe dann mal einen Prototyp einer neuen data.xml zusammengestellt um mir das ganze vor Augen führen zu können: DownloadSource code (XML):
|
alzi | Jul 07, 2009 1:51 pm |
---|---|
Subject: Re: Neue Einheiten XMLs Ein paar Dinge möchte ich dazu dann noch erklären: - Waffentechnisch habe ich diese "Mehrere-Waffen-In-Einer-Einheit" Funktion erstmal rausgenommen. Ist noch zu früh für solche Späße ^^ - Bei der Auswahl der baumöglichen Einheiten habe ich mich für eine Produces_Units-Liste entschieden. Es ist zwar nicht die optimalste Lösung aber ich denke es ist denoch der besste Kompromis. Die Entscheidung warum ich Produces_Units und nicht Is_Producted_By_Units genommen habe ist eigenltich ganz simpel: Es ist im code einfach einzubauen. Zuerst dachte ich es wäre anders sinnvoller, da man bei einer is_produced_by-Liste nicht wenn man ein neues Fahrzeug hinzufügt auch die data.xmls der Fabriken ändern muss, aber in diesem Fall müsste man z.b. wenn man eine neue Einheit erstellt, die kleine Fahrzeuge herstellt die xmls aller kleinen Einheiten ändern und von daher schenkt sich beides nicht viel. - Dann habe ich des öfftern sowas wie Kombinationsauswahlen Eingebaut. Ein Beispiel hierfür wäre Can_Move_On. So sparen wir uns extra Abfragen wie früher DRIVE_LANDnSEA. Im code lässt sich das mit einzelnen bits und bitweisen und/oder ganz einfach umsetzten. - is_generating habe ich jetzt erstmal doch nicht für die Resourcen Metal, Öl und Gold so übernommen. Undzwar weil ich glaube, dass hier ein bestimmter Wert keinen Sinn macht. Wieviel resourcen eine Mine letztendlich fördert hängt von den vorkommen unter ihr ab und auch von den Einstellungen. Wenn es hier einen Wert zu setzten gäbe, wäre es denke ich der Maximalwert, der meines Wissens immer bei 16 insgesamt für alle Resourcen liegt. Ob das so stimmt und in wiefern das modifizierbar wäre, muss Eiko beantworten, da er vor kurzem den Resourcen-Förder-Algo neu geschrieben hat. - Die Ladung habe ich nur teilweise Aufgeteilt. Hier habe ich einen Kompromis zwischen Freiheit und Codeänderungsaufwand gewählt. Für die Resourcen kann einzeln jeweils festgelegt werden wieviel von welchem Rohstoff geladen werden kann. Wobei mir gerade einfällt das der Codeänderungsaufwand hierfür auch riesig wäre, weil man alle Statusanzeigen ändern müsste und z.b. die transfermenüs. ich glaub das sollte man doch zusammenfassen. Ansonnsten habe ich noch die Einheitenlademöglichkeit abgetrennt aber nicht komplett auf einheitenids ausgeweitet sondern einfach nur auf gruppen. So das wars erstmal. Senf ist wiedermal erwünscht |
Eiko | Jul 09, 2009 9:05 pm |
---|---|
Subject: Re: Neue Einheiten XMLs So, mein Senf dazu: Erstmal, super Arbeit! Hab auch nur noch ein paar Kleinigkeiten dazu. DownloadSource code (XML): Brauchen wir die ID eigentlich noch? Wenn nein,hätten wir kein Problem mehr mit möglicherweise doppelten IDs.
DownloadSource code (XML):
Rocket_Cluster würde ich raus nehmen, da es das Attribut Cluster_Attack gibt. DownloadSource code (XML): Hier würde ich als zusätzliche Flexibilität einen Num nehmen, der angibt, ab wie viel Bewegung ein Schuss verloren geht. Das is im Code mit einer Zeile behandelt, also sollten wir das einbauen
DownloadSource code (XML): Hier würde ich, wie im IRC erwähnt die Attribute Can_Build und Build_By nehmen. Wenn die beiden von 2 Einheiten zueinander passen, kann die Einheit von der anderen gebaut werden. Vorteil: keine Referenzierung von anderen Einheiten per ID notwendig. Dadurch braucht man beim Hinzufügen von neuen Einheiten nie zusätzlich eine andere XML editieren müssen.
DownloadSource code (XML): Coast wäre dann 8
DownloadSource code (XML): Ich würde vorschlagen, Faktoren für verschiedene Terrains zu benutzen, die angeben, wie schnell sich eine Einheit auf einem bestimmten Terrain bewegen kann. Eine 0 würde bedeuten gar nicht, eine 0.5 halbe Geschwindigkeit, eine 1 normal schnell, usw.
Damit hätten wir festgelegt, auf welchen Terrains sich Einheiten bewegen dürfen und wie das Terrain die Geschwindigkeit Beeinflusst. Das macht die Sache flexibler, als wenn nur "No_water_deceleration" benutzt wird. DownloadSource code (XML):
Das sollte in die Grafik-Sektion. DownloadSource code (XML): Bäume?^^ Ich bin mir ziemlich sicher, dass der Bulldozer das nicht kann
DownloadSource code (XML): Hier würd ich ein Num nehmen, der die maximalanzahl angibt. Der Code kann, seitdem ich ihn überarbeitet hab bereits mit Variablem Maximalwert umgehen.
DownloadSource code (XML): + Coast
DownloadSource code (XML): Hm, ich bin mir gerade nicht sicher, ob das ausreicht. Was ist zum Beispiel mit See-Mine und Brücke auf einem Feld? Das is möglich, wäre aber beides "Beneath" oder?
DownloadSource code (XML): Würde ich erweitern auf "Build_On" und wieder eine Bitkombination für Wasser, Küste, Land, da sonst nicht alle Fälle abgedeckt werden können.
DownloadSource code (XML): Welche Bedeutung hat das?
DownloadSource code (XML): würde ich zusammenfassen, zu "Capacity" und "Type". Ansonsten würde das zu kompiliert, da man ja auswählen können müsste was nun geladen werden soll, also umfangreiche Änderungen am Userinterface nötig wären.
DownloadSource code (XML): Wie werden die Attribute Air, See, Ground, Human einer Einheit bestimmt? Das steht ja nicht explizit in der XML drin. Air, See, Ground könne man anhand "Can_Move_On" bestimmen. Und Human?
DownloadSource code (XML): Ich finde die Abtrennung aller rein grafischen Eigenschaften sehr gut! Ich würde sogar noch einen Schritt weiter gehen und das in eine Extra Datei auslagern. So dass Verhalten und Aussehen der Einheit komplett getrennt sind. Dadurch kann zum Beispiel das freie Grafikset unabhängig von den originalen Grafikeigenschaften gestaltet werden. Der resinstaller kann dann die Grafik-XML einfach ersetzen.
Was ist mit der Eigenschaft "ConnectToBase", woraus wird das abgeleitet, oder muss das noch zusätzlich rein? So, das wars erstmal, da ich gerad nicht allzuviel Zeit hab. |
alzi | Jul 10, 2009 5:51 pm |
---|---|
Subject: Re: Neue Einheiten XMLs So ich geb wiedermal Komentare ab. Zu allem wo ich das nicht tue stimme ich Kommentarlos zu Quote: Ich dachte auch zuerst daran, die ids weg zu lassen, aber das Problem worauf ich keine Lösung finden konnte, war das sich Server und Client dann nicht mehr auf Einheiten einigen könnten. Klar soll der Server später mal die clienten synchronisieren, so dass er theoretisch beim Spielstart einfach seinen Datensatz zu den Clienten schicken könnte, aber das problem wäre dann immernoch die Zuordnung der Grafiken. Mir ist aber auch eingefallen, dass wir theoretisch schon eine kleine Sicherung für doppelte IDs haben. Nämlich die vehicles.xml bzw. buildings.xml wo alle Einheiten mit ihren IDs aufgeführt sind. Wir hatten diese Dateien damals extra behalten um so alle IDs übersichtlich sammeln zu können.Brauchen wir die ID eigentlich noch? Wenn nein,hätten wir kein Problem mehr mit möglicherweise doppelten IDs. Quote: Ich hätte das eher getrennt, da für mich der "Muzzle_Type" eigentlich nur als grafisches Attribut galt und "Cluster_Attack" eben dann tatsächlich bedeutet, dass Flächenschaden entstehen soll.Rocket_Cluster würde ich raus nehmen, da es das Attribut Cluster_Attack gibt. Quote: Das war in den alten XMLs so drinnen und ich habe es absichtlich rausgenommen, da ich denke, das die "ab bestimmten bewegungspunkten sache" nicht wirklich dem tatsächlichen verhalten entspricht. Tatsächlich verliert die Einheit die Schüsse immer proportional zu den Bewgungspunkten, also Hälfte der Bewgungspunkte auch nur Hälfte der Schüsse, bzw. beim Schiesen entsrpechend umgekehrt. Die Bewegungspunkte können aber z.b. durch Forschung veriieren, weshalb ich einen festen Wert in der data.xml nicht für wirklich sinnvoll halten. Evtl ein proportionalitätsfaktor. Das dürfte glaube ich auch ganz gut umzustetzen sein.Hier [,Can_Drive_And_Fire,]würde ich als zusätzliche Flexibilität einen Num nehmen, der angibt, ab wie viel Bewegung ein Schuss verloren geht. Das is im Code mit einer Zeile behandelt, also sollten wir das einbauen Quote: Ok, das wäre auch eine relativ gut umsetzbare Möglichkeit, wenn ich nochmal drüber nachdenke. War in den alten Xmls bereits so vorgesehen, nur waren da eben auch Faktoren für z.b. die Straße drinnen und das macht ihmo keinen sinn. Ich denke hier wäre dann wieder nur WATER, AIR, SEA und COAST nötig. Und durch die Sache würde mann dann auch Can_Move_On unnötig machen.Ich würde vorschlagen, Faktoren für verschiedene Terrains zu benutzen, die angeben, wie schnell sich eine Einheit auf einem bestimmten Terrain bewegen kann. Eine 0 würde bedeuten gar nicht, eine 0.5 halbe Geschwindigkeit, eine 1 normal schnell, usw. Quote: habe ich aus der alten Xml übernommen und vergessen das Kommentar zu ändern. Soll natürlich nur für das räumen von normalem Schutt gelten.Bäume?^^ Ich bin mir ziemlich sicher, dass der Bulldozer das nicht kann Quote: Ok, perfekt. Wenn er das kann, dann kommt das auch rein Hier würd ich ein Num nehmen, der die maximalanzahl angibt. Der Code kann, seitdem ich ihn überarbeitet hab bereits mit Variablem Maximalwert umgehen. Edit: kann er das auch pro Resource extra oder nur für alle gemeinsam? Quote: Jo ich hatte mir vorgestellt, dass das dann beides Beneath wäre. Theoretisch müsste das auch reichen, wenn man "Beneath" Einheiten nicht untereinander blockierbar macht und für z.b. Brücken gibt es dann ja das Attribut "Can_Be_Overbuild". Bin mir grad aber auch nicht sicher ob ich da nicht etwas vergessen habe zu bedenken.Hm, ich bin mir gerade nicht sicher, ob das ausreicht. Was ist zum Beispiel mit See-Mine und Brücke auf einem Feld? Das is möglich, wäre aber beides "Beneath" oder? Quote: Das soll steuern ob man die Einheit starten kann. Bahausungen z.b. produzieren zwar etwas (Menschen) aber sind nicht ein- oder ausschaltbar.Welche Bedeutung hat das? [Is_Activatable] Quote: Stimmt Human habe ich da auch vergessen. Da müsste ein Attribut "Is_Human" rein ^^ oder wir machen das wie beim Bauen mit Stringabgleich.Wie werden die Attribute Air, See, Ground, Human einer Einheit bestimmt? Das steht ja nicht explizit in der XML drin. Air, See, Ground könne man anhand "Can_Move_On" bestimmen. Und Human? Quote: Jup wäre ne idee überall nochmal "graphics.xml" dazu zu packen.Ich finde die Abtrennung aller rein grafischen Eigenschaften sehr gut! Ich würde sogar noch einen Schritt weiter gehen und das in eine Extra Datei auslagern. So dass Verhalten und Aussehen der Einheit komplett getrennt sind. Dadurch kann zum Beispiel das freie Grafikset unabhängig von den originalen Grafikeigenschaften gestaltet werden. Der resinstaller kann dann die Grafik-XML einfach ersetzen. Quote: Jup hab ich vergessen, sollte auch rein.Was ist mit der Eigenschaft "ConnectToBase", woraus wird das abgeleitet, oder muss das noch zusätzlich rein? MFG alzi |