Stellaris Entwicklungstagebuch #232 - 3.2 Balanceänderungen und Leistungsverbesserungen

    • Offizieller Beitrag

    Hallo zusammen, heute möchten wir Euch einige der bevorstehenden Änderungen vorstellen, die mit dem Patch 3.2 "Herbert" , benannt nach dem Sci-Fi-Autor Frank Herbert, kommend und wir zusammen mit dem Aquatic Species Pack veröffentlichen werden.

    Bei den Balance-Änderungen haben wir die folgenden Änderungen für Euch auf Lager.

    • Funktionale Architektur und Konstruktionsroboter: Die Anzahl der gewährten freien Gebäudeslots wurde von 2 auf 1 reduziert.
    • Agrarische Idylle-Imperien erhalten nun einen Planetenbau-Slot pro vier errichtete Agrardistrikte.
    • Der Modifikator für die Unterhaltskosten von Schiffen für Admiräle der Klonarmee wurde auf 5/10/20% reduziert, basierend auf ihren Entscheidungen.
    • Die Ruinen des Shallash-Bogens geben nicht mehr so viel Einheit wie das Besiegen einer Endgame-Krise.
    • Man kann keine Planetenkillerwaffen mehr auf Primitive innerhalb der eigenen Grenzen einsetzen, wenn man nicht über die entsprechenden Richtlinien zur Einmischung von Primitiven verfügt.
    • Pops, die den Job "Viehzucht" ausüben, haben jetzt 10% weniger politische Macht.
    • Viele Anomalien belohnten 3 Gesellschaftsforschungsvorkommen, jetzt gibt es mehr Abwechslung.
    • Erwachte gefallene Reiche können nun Traditionen verwenden (aber keine Aufstiegs-Vorteile).
    • Erwachte gefallene Reiche können nun Traditionen verwenden (aber keine Aufstiegs-Perks).
    • Mehrere produktivitätssteigernde Technologien sind jetzt nicht mehr von zweifelhaftem Nutzen, da ihre Unterhalts- (und Produktions-) Effekte jetzt nur noch für Berufe gelten, die tatsächlich hauptsächlich Ressourcen produzieren.
    • Die Anzahl der von Freizeit-Arkologie-Distrikten hinzugefügten Jobs wurde reduziert, um sie mit anderen Ökumenopolis-Distrikten in Einklang zu bringen.
    • Der Unterhalt von Ionenkanonen ist nicht mehr kostenlos, sondern kostet 8 Energie
    • Nekro-Hives:
      • Senkung des Nekrophagen-Pop-Montage-Malus auf 50% von 75%.
      • Die Modifikatoren für den Pop-Output (positiv und negativ) gelten nicht mehr für Hive-Minds.
      • Die -50% für organischen Unterhalt gelten nun auch für Energie, für Photosynthese.
      • Nekrophagen des Verschlingenden Schwarms spawnen jetzt mit zusätzlicher Infrastruktur, um das Fehlen von Aufstiegskammern auszugleichen.

    Wir sind uns bewusst, dass der zusätzliche Gebäudeslot der Hauptanziehungspunkt für das Staatselement war, aber er war auch nach dem anfänglichen Veröffentlichungshype weit überrepräsentiert.


    Auch wenn es sich nicht um einen vorgeplanten Balance-Durchgang handelt, wie wir ihn für den Lem-Patch durchgeführt haben, haben wir dennoch einige Stellen gefunden, an denen wir nachbessern und anpassen können, und wir werden dies auch in zukünftigen Patches tun.

    ...und nun übergebe ich an Caligula Caesar für einen Blick auf einige Leistungsverbesserungen und Moddability-Themen.


    Ein Blick auf die Skript-Performance


    Hallo! Ihr seid wahrscheinlich daran gewöhnt, dass ich langatmige Prosa über neue Moddability- und Skriptsprachen-Features schreibe. Diesmal haben wir in dieser Hinsicht nur ein paar Dinge zu zeigen, aber es gibt trotzdem einige coole, technische Dinge, über die ich sprechen kann.


    Ich kannte die Skriptsprache zwar recht gut, aber die Auswirkungen unserer Skripte auf die Leistung waren für mich immer eine große Unbekannte. Würde das, was ich hinzufügte, die Leistung beeinträchtigen? Nun, ich konnte viele Vermutungen anstellen, wie man am effizientesten skriptet, und allgemeine Konzepte der Programmierung, wie z. B. Early Outs, sind durchaus anwendbar. Aber wie groß war der Unterschied? Und wie viel können wir einsparen, wenn wir ineffiziente Skripte erkennen und sie verbessern?


    Moah hatte vor einiger Zeit, als ein Lieblingsprojekt, einige Fortschritte bei der Portierung des EU4-Skript-Profilers nach Stellaris gemacht. Das einzige Problem war, dass die Informationen ziemlich unvollständig waren (da viele Tags an vielen Stellen des Codes hinzugefügt werden mussten, im Grunde überall, wo ein Effekt oder Auslöser aufgerufen wurde). Es war auch ziemlich schwer, die Informationen zu lesen. Aber jetzt, mit der Custodians-Initiative, war die Zeit gekommen, um zu sehen, was wir damit machen können.


    Nach ein wenig (sehr mühsamer) Arbeit, um die Informationen allumfassend, systematisch und lesbar zu machen, ließ ich das Spiel auf einer riesigen Galaxie mit ein paar Extra-Boosts für die KI laufen - 0,75 Forschungskosten, 1,25 bewohnbare Planeten - und ließ es ein Jahr lang mit aktiviertem Skript-Profiler laufen. Dann konnten die Probleme gefunden werden. Ich habe zwei Versionen dieser Ausgabe angehängt: eine, wie sie in einem der ersten Durchläufe war - also, bevor die Abdeckung umfassend war (insbesondere fehlen ausgelöste Modifikatoren und Wirtschaftstabellen), aber auch bevor irgendeine Optimierungsarbeit geleistet wurde - und eine, wie sie jetzt ist, in der 3.2 Beta. (Man beachte, dass die Zahlen, wie lange es für jedes Objekt gebraucht hat, massiv aufgebläht sind, da ich das Spiel im nicht optimierten Debug-Modus mit eingeschaltetem Profiler laufen ließ.


    Ich muss vorausschicken, dass wir den Skript-Profiler aus technischen Gründen nicht zusammen mit dem Update 3.2 veröffentlichen können: Wenn das Spiel mit ihm läuft, wird es um etwa 50% langsamer, also müssen wir einen Weg finden, ihn - und seine volle Auswirkung auf die Leistung - nach Belieben ein- und ausschalten zu können. (Im Moment ist es hinter Compiler-Flags versteckt, die der Öffentlichkeit nicht zugänglich sind). Aber wir hoffen natürlich, dass wir es in Zukunft für Modder freigeben können.


    Frühe Fortschritte


    Die erste große Erkenntnis war, dass das Spiel bestimmte Spielregeln jeden Tag eine große Anzahl von Malen pro Pop neu berechnet, was einen unverhältnismäßigen Einfluss auf die Leistung hatte. Der größte Übeltäter war "can_vote_in_democratic_election", die, wie sich herausstellte, für jeden Pop im Land jeden Tag für jede Popfraktion überprüft wurde, während sie ihren Unterstützungswert berechnete. Ja, Ihr lest richtig: die imperialistische Fraktion überprüfte, ob jeder Pop im ganzen Land wählen durfte, dann tat die Wohlstandsfraktion dasselbe, und die imperialistische, und so weiter... Diese Fälle wurden behoben, indem die tägliche Zwischenspeicherung genutzt wurde: die Pops berechnen nun das Ergebnis einmal pro Tag (oder, im Fall von species_has_happiness, einmal pro Spezies in einem Land pro Tag), und andere Stellen im Code können einfach auf dieses Ergebnis zurückgreifen. Außerdem wurde die Berechnung der Unterstützung der Pop-Fraktionen optimiert, so dass die Summe, durch die sie ihre Unterstützung teilen, einmal pro Land und nicht einmal pro Fraktion berechnet werden kann.


    Auf der Skriptseite konnten wir beim Parsen verschiedener Top-Treffer einige leicht zu optimierende Skriptteile feststellen. Zunächst einmal versuchte graygoo.555 überraschend oft, ein Ereignis auszulösen, das nur dann zum Tragen kommen sollte, wenn die Gray Goo aktiv sind (was nicht der Fall war). Es stellte sich heraus, dass dies daran lag, dass "is_triggered_only" fehlte, so dass es versuchte, jeden Tag auf allen Planeten zu feuern! Eine Reihe von Test-Ereignissen wurde auf ähnliche Weise geskriptet, aber mit "always = no" als Auslöser, so dass sie nie ausgelöst wurden. Sie wirkten sich zwar nur geringfügig, aber dennoch spürbar auf die Leistung aus, so dass sie entfernt werden mussten.


    Der Meinungsmodifikator triggered_opinion_galactic_community_in_breach beanspruchte mit Abstand mehr Leistung als alle anderen Meinungsmodifikatoren, was ein wenig seltsam erschien. Es stellte sich heraus, dass dies durch eine geringfügige Änderung der Reihenfolge der Auslöser behoben werden konnte: Es wurde "is_in_breach_of_any" geprüft, bevor die Mitgliedschaft in der Galcom überprüft wurde - was sich anhört, als wäre es kein großes Problem, aber dieser Auslöser prüft dann die Auslöser für die Verstoßbedingungen aller verabschiedeten Resolutionen, so dass es sich in der Tat um eine Menge Auslöser in einem handelt. Eine einfache Umstellung der Reihenfolge hatte hier sehr positive Ergebnisse.


    Schließlich war das Ereignis crime.1 (in der frühen Version das zweitteuerste Ereignis) ein ähnlicher Fall, aber viel komplizierter. Das Hauptproblem war hier das folgende Stück Skript:



    Das ist ziemlich ineffizient, und es könnte große Vorteile bringen, wenn man das Prinzip der Early Outs anwendet. "Count_owned_pop" ist eine relativ teure Berechnungsmethode, da viel Effizienz bei der Umwandlung des Skripts in Code und der Berechnung der Ergebnisse verloren geht. Auf einem Planeten mit 80 Pops wird also eine Schleife durch alle Pops durchlaufen und eine Reihe von Triggern für jeden dieser Pops überprüft. Unglücklicherweise würde es dies aufgrund der Reihenfolge zweimal pro Tag auf jedem Planeten tun, der nicht 3 arbeitslose Pops auf sich hat:

    • Das Ereignis ist die tägliche Überprüfung der Auslöser auf jedem bewohnten Planeten. Oder zumindest oft. 44.000-mal in einem Jahr, um genau zu sein.
    • Es wird nicht überprüft, ob es arbeitslose Pops auf dem Planeten gibt, bevor es herausfindet, welche Arten von arbeitslosen Pops es gibt. Das bedeutet, dass das ODER für beide count_owned_pop-Abschnitte false zurückgibt, was folglich bedeutet, dass es beide überprüft. Das Hinzufügen von "num_unemployed > 3" in der Nähe des Starts hatte große Vorteile.
    • Es würde die Anzahl der arbeitslosen Pops prüfen, die für Nicht-Gestalten relevant sind, und erst danach prüfen, ob das Land nicht Gestalt hat. Indem die Prüfung der Gestalt an den Anfang verlegt wird, bedeutet dies, dass immer nur eine der count_owned_pop-Schleifen versucht wird.

    Eine neue, effizientere Version des Auslösers war daher diese:



    Gewinne durch weitere Analysen


    Das war eine coole Sache, aber darüber hinaus wurde es etwas schwieriger, einfach nur die Liste zu betrachten, um signifikante Einsparungen zu erzielen. Jetzt kommt die Tabellenkalkulation ins Spiel! Wir fügten die Ergebnisse in eine Tabellenkalkulation ein, und ein paar Formeln und eine nette Pivot-Tabelle später erhielten wir einige Aufschlüsselungen in der Art von "was ist die Gesamtauswirkung aller Arbeitsplätze" oder "was ist die Auswirkung des potenziellen Auslösers der Pop-Fraktionen".



    Dadurch konnten wir einige weitere Dinge feststellen. Erstens verursachte ai_resource_production absurd hohe Leistungskosten bei einer relativ geringen Anzahl von Treffern. Es stellte sich heraus, dass der Trigger "planet_resource_compare" (der hauptsächlich hier verwendet wird) unglaublich teuer war. Das Problem bestand darin, dass er den Ressourcenausstoß aller Ressourcen auf dem Planeten im Grunde neu berechnete (auch indem er sah, was jeder Pop produzierte!). Es stellte sich heraus, dass es möglich war, dies etwas abzumildern (auf etwa 75%), indem man die Produktion der relevanten Ressource selektiv neu berechnen ließ, aber das war immer noch ziemlich teuer für einen Auslöser, also haben wir seine Verwendung auch ein wenig eingeschränkt. Ich schlage vor, dass Modder ihn auch nicht übermäßig nutzen.


    Außerdem stellten wir fest, dass die Aufträge - nicht unerwartet - recht teuer waren. Vor allem ihre Gewichte und ihre "möglichen" Prüfungen. Wir haben einige Ideen, um bei den Gewichten Zeit zu sparen, über die wir aber noch nicht sprechen können (sie sind in der Entwicklung von 3.2 zu spät aufgetaucht, um für den Patch in Betracht gezogen zu werden, da sie relativ wahrscheinlich einige Iterationen benötigen), aber wir haben einen Weg gefunden, die "möglichen" Auslöser billiger zu machen. Im Grunde genommen würde ein Pop alle sieben Tage seinen Job-Cache neu berechnen.


    Zu diesem Zeitpunkt wird geprüft, ob er jeden Job bearbeiten darf, und wenn ja, wird dessen Gewicht berechnet. Die meisten Jobs haben jedoch ziemlich standardmäßige "mögliche" Auslöser, die den ersten Teil überprüfen - insbesondere gibt es einen gemeinsamen Satz von Auslösern für Arbeiter-, Spezialisten-, Herrscher- und Drohnen-Jobs. Es stellte sich heraus, dass erhebliche Verbesserungen (in einem Umfang von fast zwei Dritteln) möglich waren, indem der Pop zuerst diese vier Auslöser berechnete, dann eine Schleife durch die Aufträge zog und das Ergebnis einfach dem richtigen Auftrag zuordnete.


    Schließlich gab es, obwohl die Optimierungen der Spielregeln bereits mehrere Leistungsprobleme mit Pop-Fraktionen behoben hatten, noch einige Punkte, die verbessert werden konnten. Der erste war, ob eine Fraktion überhaupt existieren sollte: Es stellte sich heraus, dass sowohl das Skript als auch der Code überprüften, ob es 5 Pops gab, die der Fraktion beitreten konnten, nur dass der Code dies nicht mehr überprüfte, nachdem die Fraktion gebildet war. Das war natürlich nicht ideal, also wurde die Skriptüberprüfung (die langsamer war) entfernt und die Codeüberprüfung geändert, um zu berücksichtigen, dass schrumpfende Pop-Fraktionen ungültig werden.


    Die zweite war die Entscheidung, ob ein Pop einer Fraktion angehören sollte: Obwohl fast alle Fraktionen nur Pops zulassen, die ihrem Ethos entsprechen, kommt der Filter nach Ethos ziemlich spät. Indem wir ihn viel früher einbauen - im Code, bevor das Skript überhaupt geprüft wird (mit einer Überschreibung für den Fall, dass dies nicht erwünscht ist, z. B. bei Technologen-Robotern) - konnten wir die Kosten für diese spezielle Berechnung massiv senken.

    Schließlich waren einige Forderungen - die jeden Tag pro Fraktion geprüft wurden - ziemlich exorbitant. Durch Änderung der Reihenfolge und Verwendung gleichwertiger, aber billigerer Prüfungen (z.B. any_owned_species statt any_owned_pop). Auch dies hatte eine erhebliche Auswirkung, so dass der Skript-Fußabdruck der Pop-Fraktionen (ohne die von ihnen verwendeten Spielregeln) um etwa zwei Drittel reduziert wurde.


    Zusätzliche Performance-Themen

    Ich hoffe, dass sich diese Arbeit in Form einer etwas geringeren Verlangsamung im späten Spiel bemerkbar machen wird. Meine Tests deuten darauf hin, dass dies ein Erfolg war, obwohl es sehr schwer ist, das Ausmaß zu quantifizieren. Es war jedoch eine Arbeit, die sich ausschließlich auf die Skriptleistung konzentrierte, es gibt also noch viele andere Dinge, die wir im Auge behalten müssen! Die Arbeit ist nie zu Ende, wenn es um die Leistung geht, und wir werden hoffentlich Zeit haben, für 3.3 weitere Verbesserungen vorzunehmen.


    Ich habe zum Beispiel ein paar Beschwerden über die Verzögerung der Benutzeroberfläche im späten Spiel gehört, die durch die Leistungsverbesserung bei einigen Benutzeroberflächen leicht verbessert werden könnte, aber diese Arbeit konzentrierte sich nicht auf die Benutzeroberfläche. Es ist sicherlich richtig, dass einige von ihnen nicht so schnell sind, wie wir sie gerne hätten. Dies gilt insbesondere für die Planetenansicht, die Spezies-Ansicht und das Auswahlmenü für die Kolonisierung, und wir suchen nach Optionen, um sie zu beschleunigen. (Und falls jemandem noch andere einfallen, wäre es hilfreich, wenn Ihr uns darauf hinweisen würdet).


    Verbesserungen der Moddbarkeit


    Ich kann nicht wirklich ein Entwicklertagebuch führen, ohne über ein paar Verbesserungen der Moddbarkeit zu sprechen, also hier sind sie. Wie ich schon sagte, haben wir dieses Mal nicht so viel, aber es gibt ein paar Dinge, die die Leute gerne ausprobieren könnten:

    • Es gibt jetzt einen create_nebula-Effekt. Obwohl es am besten während der Galaxiengenerierung verwendet wird, da die visuellen Effekte auf der Galaxiekarte während des Spiels nicht aktualisiert werden.
    • Entscheidungen können jetzt on_queued- und on_unqueued-Effekte haben.
    • Terraforming verwendet jetzt das Megacorp-Wirtschaftssystem. Das heißt, die Kosten sind konfigurierbare Ressourcentabellen, und Ihr könnt die Modifikatoren Economic_unit auf sie anwenden.
    • Es gibt einen Spezies_Gender-Trigger, der überprüft, welches Geschlecht die Anführer der Spezies sein kann
    • Ihr könnt jetzt benutzerdefinierte Tooltips für Systeme definieren, die Ihr seht, wenn Ihr mit der Maus darüber auf der galaktischen Karte fahrt.
    • Es gibt jetzt on_actions für on_capital_changed und on_planet_class_changed
    • Für Traditionen wird der „mögliche“ Auslöser der Übernahme der Tradition jetzt im Tooltip für die Übernahme angezeigt, wenn dies fehlschlägt. Mir wurde gesagt, dass Ihr jetzt auch die Traditionskategorien mit einem Container versehen könnt, in dem Ihr eine Gridbox hinzufügt.

    Es gibt auch ein paar Dinge, die Modder aktualisieren müssen (abgesehen vom Terraforming, wie erwähnt):

    • any/count/every/random_planet_army bezieht sich jetzt auf alle Armeen auf dem Planeten, nicht nur auf alle, die dem Besitzer des Planeten gehören)
    • Set_starbase_building/module und die Remove-Varianten beginnen jetzt konsistent bei Steckplatz 1, statt „set“ bei 0 und „remove“ bei 1.
    • In component_templates ist valid_for_country jetzt ein Trigger und kein Gewichtungsfeld
    • Fire_on_action hatte einige Probleme, bei denen Ihr Bereiche mit "prev" und "from" definiert habt, diese existieren nicht mehr.

    Als letzte Anmerkung zur Modifizierbarkeit, für alle, die die reichhaltigen Entwicklertagebücher mit weitreichenden Änderungen der Modifizierbarkeit vermissen, Ihr braucht Euch keine Sorgen machen! Jeder, der mit dem Skript unserer neueren Spiele herumgespielt hat, wird wissen, dass in unserer Skriptsprache noch viel mehr Potenzial steckt. Es sind einige coole Sachen in Arbeit, aber ich kann zu diesem Zeitpunkt noch nicht sagen, was genau oder in welchem Patch es sein wird.


    Außerdem hänge ich, wie beim letzten Mal, die Skriptdokumentation an das Entwicklertagebuch an, damit Ihr alle Änderungen, die ich vergessen habe zu erwähnen, sehen könnt. Außerdem können sich Modder, die an einem frühen Zugriff auf das 3.2-Update interessiert sind, um Ihre Mods auf den neuesten Stand zu bringen, hier anmelden: https://pdxint.at/3bZbVJN


    Quelle: https://forum.paradoxplaza.com…nce-improvements.1497227/