Okay, also... mir ging es erstmal nur allgemein darum, da ich es für mehrere Anwendungsbereiche bräuchte. In der letzten Zeit hatte ich geplant, konzipiert und herumexperimentiert, ein Upgrade-System (also soetwas wie ein TechTree wie man ihn aus anderen, komplexeren Strategiespielen als SuM1 kennt) fraktionsspezifisch zu implementieren. Ich habe viel Zeit mit der genauen Planung dieser Entwicklungen, ihrer Abhängigkeiten und Effekte verbracht. Grundsätzlich ist das Upgradesystem, so wie ich es mir eigentlich gedacht hatte, dezentral und einerseits verzweigt, andererseits auch wieder zusammenfließend. Intention dahinter war vor allem, dem Gameplay mehr Tiefe zu verleihen durch eine wesentlichere Strukturierung des Spielablaufs zwischen EarlyGame, MidGame und EndGame, bzw. der Übergänge dazwischen, um mehr Abwechslung in das Spielgeschehen zu bringen. Außerdem war die fraktionsspezifische Auslegung bereits für Abwechslung ausgelegt und insbesondere zur Betonung des wesentlichen, grundeigenen Charakters jeder Fraktion. Zuletzt kommt noch der Zweck dazu, im späteren Spielverlauf das Spiel auf einem "höheren Niveau" in Bezug auf Wirtschafts- und Militär-Management ablaufen zu lassen.
Eigentlich habe ich damit ja nun nur das selbe Problem (um beim TechTree-Bild zu bleiben) wie bei einem echten Baum auch: Die Äste können sich nur verzweigen, aber nicht wieder zusammenwachsen, was ich aber wollte. Nebenbei, da einige der Upgrades in den Zitadellen gekauft werden sollten, habe ich die Zuweisungen von CommandSets zu Zitadellen-Gebäuden neugeordnet, sodass nicht ein Commandset wie zuvor von mehreren Fraktionen genutzt wird, und dann die Fraktions-Zita-CommandSets um die gewünschten Befehle ergänzt.
Die Wirkungen der Upgrades sind vor allem spezifische Rohstoffproduktionsbesch
leuniger, Freischaltungen bestimmter Einheiten und Gebäude (selten), in der ursprünglichen Auslegung insbesondere auch die Freischaltung von Helden, spezifische Einheitenrekrutierungsbe
schleuniger und die Freischaltung größerer/erweiterter Horden/Bataillone zur direkten Rekrutierung.
Meistens verzweigen sich die Upgrade-Stränge zunächst und haben mehrere Ausgangspunkte, laufen dann aber zu den richtig starken End-Spitzen wieder zusammen.
Nun werde ich konkreter, um das Problem in Einzelfällen zu veranschaulichen:
1) Beispiel Rohan:
Rohan hat im wesentlichen drei Gruppen von Upgrades (zwischen denen jedoch noch Verzweigungen bestehen): Gehöfte-Ups, Zitadellen (Tech)-Ups, Rüstkammer (Einheiten)-Ups, und separat die Militär-Ups von Infanterie (Kaserne/Schießstand, ich verwende Edain, sollte aber keinen großen Unterschied machen) und Kavallerie. In den Stallungen lassen sich nun also drei Ups erforschen (ich kürze die Namen jetzt ab): FastCavalry, AdvancedCavalry und Eilrekrutierung. FastCavalry gibt einen dezenten Bauzeit-Bonus, AdvCav aktualisiert das CommandSet zu Rekrutierungsbefehlen größerer Bataillone, Eilrekrutierung gibt speziell für Kavallerie einen deutlichen Beschleunigungsbonus. Bei der Infanterie ist das auch so aufgebaut, nur die Wirkungen sind dabei schwächer, dafür erfordern die genannten-Kavallerie-Upgrades zuvor die Gehöfte-Verbesserungen. Derer gibt es zwei, Fruchtfolge und Erntesegen (letzteres stärker). Diese Eilrekrutierung wäre also abhängig von a) Rang 3 der Stallungen, b) Erntesegen, c) FastCav + AdvCav und d) einem Zita-Upgrade, Ruf des Königs. Technisch ergibt sich aber diese Schwierigkeit sogar schon an Erntesegen: Es erfordert Gehöft Stufe 3 und Fruchtfolge. Auch die Infanterie-Eilrekrutierung hat ein ähnliches, wenn auch kleineres Problem: Kaserne Rang 3, FastInf, AdvInf und Ruf des Königs. Die jeweilige Abhängigkeit von AdvInf/Cav könnte man terminieren, indem der Upgrade-Befehl einfach nur im aktualisierten CommandSet zur Verfügung steht. Aber das schmälert das Problem nur geringfügig. Und Eilrekrutierung einfach nur von Stallungen Rang 3 oder nur von Ruf des Königs abhängig zu machen, wäre balancingtechnisch undenkbar, dann müsste der Effekt so stark abgemildert werden, dass man es sich gleich sparen kann.
2) Beispiel Gondor
Das Gondor-Upgradesystem ist das komplexeste aller Fraktionen, Gondor kommt damit nur langsam in Fahrt, hat aber später die Möglichkeit, vergleichsweise weniger große aber dafür sehr starke Veteranen-Armeen ins Feld zu führen. Konkret ist da z.B. ein Problem: Merkantilismus. Ein finales Ökonomie-Up, das nochmal auf alle Einnahmen einen deutlichen Bonus errechnet, das aber zunächst recht teuer ist und für dessen Erforschung im Marktplatz zunächst alle anderen Öko-Ups (d.h. Erntesegen, Eisenerz, Belagerungsmaterial und evtl ein Stein-Up falls der Steinbruch ein AutoDeposit erhält) bereits gekauft sein müssen. Auch hier wird das so nicht funktionieren.
Ebenso bei "Militär-Akademie", einem Upgrade der Rang 3 Kaserne, das zur Rekrutierung größerer Armeen(-Bataillone) befähigt, hierzu aber erforschte Kenntnisse aus der Kaserne, dem Schießstand und der Zitadelle benötigt. Paralell dazu der Spezialfall "Kavallerie-Akademie" in den Stallungen Rang 3, er erfordert eine Freischaltung "Haferanbau" ohne sonstigen Effekt in den Gehöften, ebenso dieses Zitadellen-Up, wie gesagt Rang 3 des Gebäudes und die vorangehenden beiden (FastCav und AdvCav ähnlich wie bei Rohan aber mit schwächerer Wirkung). Dadurch sollte die Rekrutierung einer neuen Einheit (Schwanenritter, konnten in Edain sonst nur durch Imrahil beschworen werden) und größerer Ritterheere ermöglicht werden.
Auch für die bösen Fraktionen hätte ich Beispiele, z.B. die nachfolgende extreme Schnellrekrutierung in der Zitadelle von Mordor nach den einzelnen kleineren Beschleunigungen aus den einzelnen Gebäuden; auch das ist ein wichtiger Knotenpunkt, der sich so nicht umsetzen lässt.
Ganz kurz all das gesagt auf deine Nachfrage: Für PlayerUpgrades (im Code-Sinn).
![[ugly]](https://modding-union.com/Smileys/mu/ugly.gif)
Ich möchte auch grundsätzlich nicht auf Abhängigkeiten verzichten und dafür Baukosten und -zeit nach oben ziehen, denn dann hätte ich bei dem Ziel versagt, den Spielablauf zu strukturieren, man könnte ja auch einfach gleich auf die besten sparen.
Und abschließend möchte ich noch anfügen, dass ich mir darüber im klaren bin, dass man einfach den
Effekt des jeweiligen Upgrades von mehreren vorangegangenen Upgrades abhängig machen kann, statt den Erwerb dieses Upgrades
selbst... das stimmt. Wäre mir aber nicht so lieb, weil die Verkettung wegfiele (man könnte die Wirkung ja schneller erreichen) und sich nochmal zusätzlicher Investitionsaufwand an Zeit und Geld bis zum Eintreten des Effektes ergeben sollte. Außerdem hat der Spieler dann ja keine Möglichkeit, im Spiel zu sehen, was das jetzt genau bewirkt und welche Folgen es hat, da das dazwischengeschaltete Upgrade (also der commandbutton mit Beschreibung usw., den man sonst ja i-wann mal drücken müsste) einfach entfällt.
Hättest du soetwas mit Umwegen gemeint?
Also, falls das der einzige Weg ist, dann werde ich diese Upgrade-Systeme wohl noch einmal reformieren, sodass ich eine bestmögliche Mitte finde, wie das Umgehen mehrerer Abhängigkeiten wo notwendig durch direkte Wirkungsauslösung vereinbar ist mit den Prinzipien des Systems, und diese dabei gewahrt bleiben.
Aber falls du doch Vorschläge hättest, wie ich das hinkriege, wäre ich dir überaus dankbar.
Liebe Grüße,
~Mario
PS: Zu Helden, ja das ist auch etwas; die sollen zwar nie von mehreren, aber eigentlich doch von genau einem Upgrade abhängig werden. Die einzige Möglichkeit die ich bisher dafür hatte, war, sie aus den BuildableHeroesMP der Playertemplate.ini zu entfernen, aus den CSs der Keeps die GenericReviveSlots rauszuhauen und durch eigene Command_ConstructXXX Befehle zu ersetzen, diese in der commandbutton.ini entsprechend zu definieren und in der object-ini des Helden im DESIGN Block die Zeile "MaxSimultaneousOfType = 1" (ohne "") hinzuzufügen. (Evtl die Buttons durch eine CommandSetUpgrade-Funktion erst erscheinen zu lassen, ändert daran aber nichts). Der wesentliche Nachteil: Man kann Helden nicht mehr wiederbeleben, sondern nur noch erneut rekrutieren. D.h., sie haben wieder dieselbe BuildTime und Cost (keine besonderen ReviveTime und ReviveCost Werte, was ja ein überaus sinnvoller Balancing-Faktor ist) und sie verlieren unwiderruflich ihren Rang. Ich musste auf diese Technik ausweichen, da diese spieleigene Regelung mit reviveslots usw. keine feste Definition von NeededUpgrade für einen commandbutton der Heldenrekrutierung zulies, und mir außer dieser Technik keine weitere bekannt ist, wie man die mögliche Rekrutierung eines Helden von einem Upgrade abhängig machen kann. Gibt es da noch etwas anderes, direkteres? Danke schön schonmal. Falls es darauf jetzt aber so leicht keine Antwort gibt würde ich einen anderen Thread aufmachen, das hat nämlich nichts mit diesem Thema hier direkt zu tun, sondern ist ein eigenständiges Problem.
Vielen Dank nochmal für die Hilfe.
Thema: Mehrere Abhängigkeiten für CommandButtons (Gelesen 2619 mal)