[TAC] Spielgeschwindigkeit, Rundenzahl, Siegbedingungen

[Ronnar]

Ich kann diese Entscheidung nur begrüßen.
Sowas gehört einfach in die DLL und nirgendwo sonst.

Das ist deine ganz persönliche Meinung und keine allgemein gültige Aussage wie du es hier darstellst. Selbst mit CIV BTS wurden offizielle Szenarien ausgliefert, die Siegbedingungen in Python umsetzen. Du willst nur einfach immer alles in der DLL umsetzen, egal was es ist.

Es spricht eigentlich rein gar nichts dagegen, außer dass man den Code an einer Stelle zusammenhalten will. Anonsten hat Python da keinerlei Nachteile, Performance spielt keine Rolle bei Siegbedingungen, die nur einmal pro Runde geprüft werden.

[raystuttgart]

Will nicht streiten, sag ja nur dass ich die Entscheidung gut finde.

[Elwood]

Finde ich persönlich sehr schade, gerade wenn man jetzt hier liest, dass dem nicht mal "harte technische Fakten" im Weg stehen . Ich hatte mich auf diese überarbeitete Variante gefreut.

[Commander Bello]

Ich muss jetzt mal eine Frage stellen, die ich immer schon stellen wollte, aber auch immer vergessen habe:
Ich habe mich in der Tat gewundert, wie genau der Industrialisierungssieg errechnet wird (habe den Zielwert in meiner Modmod für meine Kartengrößen ja geändert).

Ich hatte es für die Fanatiker letzte Woche ausprobiert. Beim Industriesieg werden alle Produkte, Kreuze und Glocken gezählt, die in der Runde nicht verarbeitet bzw. verbraucht werden. Wenn dieser Ausstoß 5000 beträgt hat man gewonnen.

Da hilft ein Blick in die (inzwischen hoffnungslos veraltete) TAC-DLL-Dokumention. Da ist unter PatchMod: Victorys
der Industrialisierungssieg aufgeführt.

Mit TAC 2.00 hatten wir damals einen Neuanfang gemacht. Die DLL wurde komplett neu erstellt. Die Quelldateien aus TAC dienten dabei nur als Richtlinie, der Quellcode selber wurde aus AOD2 und der NBMod entnommen. Die XML-Dateien wurden anschließend angepasst.
Das führte dann zu den von dir nun entdeckten Unterschieden. Den Produktionssieg wollten wir immer mal ausbauen, wozu es allerdings bis heute nicht gekommen ist.

Vielen Dank für die Aufklärung!

Was wollen wir damit machen? Es gibt 3 Möglichkeiten:

1. Wir arbeiten den Industrialisierungssieg für die finale Version richtig heraus
2. Wir nehmen diese Siegvariante wieder raus
3. Wir lassen es so, wie es ist

Den Industrialisierungs- / Wirtschaftssieg wird es in Python umgesetzt für TAC nicht mehr geben. Koma ist genau wie Ray dafür diese Logik in der DLL zu lassen und nicht in Python zu verlagern.

Da ich keine Lust habe mich in DLL erstellen einzuarbeiten und sich kein anderer gefunden hat, der es in der DLL umsetzen will, bleibt diese Siegvariante wie sie ist.

Frech, wie ich bin, greife ich das Thema noch einmal kurz auf.

Wie Akropolis richtig schreibt, werden alle Erträge aller Yields gezählt - aber nach einem sehr merkwürdigen System.
Pro Stadt wird die Nettosumme der Yields gezählt, falls sie nicht negativ ist.

Klingt kompliziert? Ist es auch.

Also:
In Stadt A werden 6 Eisenerz erzeugt und in der Schmiede in 3 Eisen umgewandelt. Unten steht: +3 Erz und +3 Eisen. Gezählt werden insgesamt 6 Yields (und immer daran denken: es gelten alle Yields, also Futter, Holz, Rohstoffe, Fertigerzeugnisse, Produktion, Glocken, Kreuze und Bücher!).

Nun sind in der Stadt auch noch 100 Holz vorhanden, die pro Runde in der Schreinerei in +6 umgewandelt werden. Es wird aber kein Holz selbst erzeugt.
Unten steht nun - 6 Holz und +6 . Gezählt werden +6 Yields - der Verbrauch des Holzes wird nicht gezählt, obwohl im Detailbild des F1-Ratgebers eine -6 für das Holz ausgewiesen wird (das war vermutlich der Grund, warum ich früher nie auf den F8-Wert gekommen bin, wenn ich mal an den Fingern abgezählt habe).

Auf diese Weise kann man "zu Fuß" alle Yields zusammenrechnen und kommt auf den Wert, der unter F8 beim menschlichen Spieler für den Industriesieg ausgewiesen wird.
Für alle anderen Spieler gilt folgende Formel:
Die Gesamtproduktion (GP) errechnet sich wie oben, wird mit dem Wert für AIAdvancedStart (in der HandicapInfo) in Abhängigkeit vom Schwierigkeitsgrad multipliziert, durch 100 geteilt und mit 3 multipliziert.
Bei Patriot ist der Wert für AIAdvancedStart = 135, also lautet die Formel:
GP * 135 / 100 * 3 = GP * 4,05
oder umgekehrt, die AI muss auf Stufe Patriot 5000/4,05= 1.235 Yields erreichen.

Die Berechnung findet sich in der CvTeam.cpp:

Achtung Spoiler:

// PatchMod: Victorys START
int CvTeam::getTotalProductionRate() const
{
    int iProductionRate = 0;
    int iPlayerProduction = 0;
    for (int i = 0; i < MAX_PLAYERS; ++i)
    {
        CvPlayer& kPlayer = GET_PLAYER((PlayerTypes) i);
        if (kPlayer.isAlive() && kPlayer.getTeam() == getID() && !kPlayer.isEurope())
        {
            iPlayerProduction = 0;
            for (int iK = 0; iK < NUM_YIELD_TYPES; iK++)
            {
                iPlayerProduction += kPlayer.getYieldRate((YieldTypes)iK);
            }
            if (!kPlayer.isHuman())
            {
                iPlayerProduction *= GC.getHandicapInfo(getHandicapType()).getAIAdvancedStartPercent();
                iPlayerProduction /= 100;
                iPlayerProduction *= 3;
            }
            iProductionRate += iPlayerProduction;
        }
    }

Eine maximal schmutzige Lösung wäre wohl folgende:
iPlayerProduction = 0;
iPlayerProduction += kPlayer.getYieldRate(YIELD_BELLS) * x (x = Bewertung der Glocken)
iPlayerProduction += kPlayer.getYieldRate(YIELD_HAMMERS) * y (y = Bewertung der Hämmer)
usw.

Schöner wäre es sicherlich, z.B. in der GlobalAltDefines neue Bewertungstags einzufügen, und dann in der obigen Funktion eine Schleife einzufügen, die diese Tags ausliest und die Yields entsprechend bewertet.
Viel mehr müsste meines Erachtens nicht gemacht werden.

[raystuttgart]

Viel mehr müsste meines Erachtens nicht gemacht werden.

Hallo C.B.,

wenn du das programmieren willst, dann mach die Gewichtung bitte nicht über die GlobalDefines.xml.
Viel sauberer wäre es in der Civ4YieldInfos.xml einen neuen XML-Tag einzuführen, der dann über eine Methode in CvInfos.cpp abgefragt wird.
Dafür gibt es zig Beispiele in der DLL, wie man sowas macht.

Und bitte kein Hardcoding der Yields.
Ein Loop über die Yields ist furchtbar einfach und auch hierfür gibt es zig Beispiele dafür in der DLL.

Eine maximal schmutzige Lösung wäre wohl folgende:

Von einer "maximal schmutzigen" Umsetzung wie du es nennst, hat doch niemand was.

Ansonsten viel Erfolg beim Programmieren.
Finde ich echt super, dass du dich am DLL-Programmieren versuchst, wirst sehen, dass das gar nicht so schwer ist.
(Als Einstieg in die DLL-Programmierung sind solche Kleinigkeiten perfekt geeignet.)

[Commander Bello]

Hallo C.B.,

wenn du das programmieren willst, dann mach die Gewichtung bitte nicht über die GlobalDefines.xml.
Viel sauberer wäre es in der Civ4YieldInfos.xml einen neuen XML-Tag einzuführen, der dann über eine Methode in CvInfos.cpp abgefragt wird.
Dafür gibt es zig Beispiele in der DLL, wie man sowas macht.

Das ist ein guter Hinweise, danke schön.

Und bitte kein Hardcoding der Yields.
Ein Loop über die Yields ist furchtbar einfach und auch hierfür gibt es zig Beispiele dafür in der DLL.

Von einer "maximal schmutzigen" Umsetzung wie du es nennst, hat doch niemand was.

Das war auch nicht wirklich ernst gemeint.

Ansonsten viel Erfolg beim Programmieren.
Finde ich echt super, dass du dich am DLL-Programmieren versuchst, wirst sehen, dass das gar nicht so schwer ist.
(Als Einstieg in die DLL-Programmierung sind solche Kleinigkeiten perfekt geeignet.)

Das wird leider noch etwas dauern, ich muss erst einmal meine Baustellen hier schließen, da bin ich ja schon ordentlich in Verzug und mich dann nach meiner Krankheit wieder erst ins Mergen und Kompilieren einarbeiten - das ist ja leider auch liegengeblieben.

Aber dafür habe ich ja im allgemeinen Verzeichnis schon meinen "Kummerthread" aufgemacht....

[Writing Bull]

Dass die Punktewertung in der Praxis so massiv von den Gründervätern abhängt, finde ich auch komisch. Wenn niemand protestiert, kann ich das gerne für das anstehende Release von TAC 2.01 noch ändern.

Achtung Spoiler:

<Define>
<DefineName>SCORE_LAND_FACTOR</DefineName>
<!--Score you get if you have all the land on the current map-->
<iDefineIntVal>4000</iDefineIntVal>
</Define>
<Define>
<DefineName>SCORE_FATHER_FACTOR</DefineName>
<!--Score you get if you have all the fathers-->
<iDefineIntVal>4000</iDefineIntVal>
</Define>

Land hat zwar theoretisch das gleiche Gewicht wie GV, aber 100% Landbesitz ist in Colonization utopisch (100% Gründerväter sehr schwer, aber zumindest hohe Anteile sind gängig).Ich würde daher für den Anfang eine Halbierung auf 2000 vorschlagen.

Teste das doch mal mit diesen Werten, die du vorschlägst!

Es funktioniert wie beabsichtigt (technisch hab ich die geänderten Tags einfach ans Ende der GlobalDefinesALT.xml angehängt); die Halbierung des GV-Wertes ist auch keinesfalls zu stark, es ist immernoch der dominierende Wert - aber eben nicht mehr so übermäßig.

Bereits vor mehr als zwei Jahren haben wir das Problem gesehen, dass bei der Punktewertung die Gründerväter viel zu sehr ins Gewicht fallen. Pfeffersack hat seinerzeit den Vorschlag gemacht, die GVer noch halb so viele Siegpunkte erzeugen zu lassen. Ich habe das jetzt in der Arbeitsversion umgesetzt. Konkret heißt das jetzt, dass es für jeden erreichten Gründervater nur halb so viele Siegpunkte gibt. Die anderen Faktoren bleiben unverändert.

[xXstrikerXx]

Danke.

Das würde also bedeuten, das 300 Rundenlimit hat nur Einfluss auf das Spiel, wenn der Europasieg (bzw. der Punktesieg) aktiviert ist.

Sollte das zutreffen, macht es wenig Sinn das Rundenlimit oder Siegrundenlimit anheben zu wollen. Da würde ich folgendes vorschlagen:

1. Wir kehren wie geplant zu den Vanilla-Geschwindigkeiten zurück.
2. Der Europa-Sieg wird auf abgewählt gesetzt (bDefault in CIV4VictoryInfo.xml), so daß er bei Spielstart nicht ausgewählt ist.
3. Wir fügen einen Hinweis in der Beschreibung des Europasieges hinzu, daß das Spiel damit auf 300 Runden begrenzt wird.
4. Wir erhöhen die Spielzeitverlängerung durch Auslösen der Revolution von 100 auf z.B 200 Runden (iRevolutionTurns in Civ4GameSpeedInfos.xml?).

Damit sollten die teilnehmenden Spieler genügend Zeit haben, die ausgewählten Siegbedingungen zu erfüllen, ohne daß ich in der DLL etwas ändern müsste. Auch die Berechnung der Diplomatiewerte würde so wieder korrekt funktionieren und wir könnten uns beim Leaderheads-Balancing an den Vanilla-Werten orientieren.


Gute Frage. Der Vorherrschaftssieg ist eh ein wenig problematisch. Wenn man z.B. die Anzahl der Ureinwohner auf eine Nation begrenzt, wird diese Nation bei Spielbeginn zum Sieger gekürt, vermutlich da sie alle Bedingungen für den Vorherrschaftssieg erfüllt hat.

Ein paar Sachen noch:
1. Ich finde 300 Runden für den Punktesieg zu kurz. Ich würde 400-500 Runden vorschlagen. Noch besser, aber wahrscheinlich nicht mehr umsetzbar: der Spieler darf selbstbestimmen, nach wievielen Runden der Punktesieg gelten soll. Zumindest mir reichen 300 Runden bei weitem nicht aus um mich vollends zu entwickeln. Zu lange sollte das Spiel aber auch nicht dauern, damit die Siegbedingung Punktesieg nicht mit der Bedingung "Vorherrschaft" zusammenfällt. Ich wäre also für ein neues Limit bei 400 Runden.
2. Brauchen wir wirklich ein Rundenlimit für die Unabhängigkeit? Müsste nicht gerade dort gelten "bis zum bitteren Ende"? Dies könnte man auch so umsetzen, dass man das Limit auf z.B. 1000 setzt - das wäre wohl eine nach unseren Maßstäben unendliche Zeit. Normal ist eine Revolution immer erst vorbei wenn sie erfolgreich war oder niedergeschlagen wurde.
3.Wenn ich das richtig verstanden habe gilt für die KI eine "Richtlinie", wann sie den Unabhängigkeitskrieg beginnen soll. Hier wäre ich für eine Anpassung an den Schwierigkeitsgrad. Neue Spieler sollen die Möglichkeit haben, TAC erstmal kennenzulernen. Hier wäre es wenig hilfreich, wenn sie das erste Spiel gleich gegen die KI verlieren, weil diese die Unabhängigkeit beginnt. Neue Spieler beginnen halt häufig zunächst ein Spiel mit Standardeinstellungen. Der leichteste Schwierigkeitsgrad sollte meiner Meinung nach dann auch wirklich "leicht" zu gewinnen sein. Ich schlage 500 Runden für den einfachsten Schwierigkeitsgrad vor, 400 für den darüber. Ab dann 300 Runden, und für die Hardcores gibt's 200 Runden auf dem härtesten SG. Das ist dann für die, die eine besondere Herausforderung suchen.
4. Etwas ähnliches wie 3. stelle ich mir auch für den Punktesieg vor, es wäre eine Erweiterung des unter 1. genannten festen Limits von 400 Runden.

Was ist davon umsetzbar und was nicht? Um die Umsetzung kümmere ich mich mit etwas Hilfe auch gern selbst, sofern es XML betrifft.

so long and greetz

[Writing Bull]

1. Ich finde 300 Runden für den Punktesieg zu kurz. Ich wäre also für ein neues Limit bei 400 Runden.
2. Brauchen wir wirklich ein Rundenlimit für die Unabhängigkeit? Müsste nicht gerade dort gelten "bis zum bitteren Ende"? Dies könnte man auch so umsetzen, dass man das Limit auf z.B. 1000 setzt.
3.Wenn ich das richtig verstanden habe gilt für die KI eine "Richtlinie", wann sie den Unabhängigkeitskrieg beginnen soll. Hier wäre ich für eine Anpassung an den Schwierigkeitsgrad
4. Etwas ähnliches wie 3. stelle ich mir auch für den Punktesieg vor, es wäre eine Erweiterung des unter 1. genannten festen Limits von 400 Runden.

Ohne auf diese Ideen im Detail einzugehen: Diese umfassenden Änderungswünsche kommen natürlich sehr, sehr spät - nämlich fast ein Jahr, nachdem wir die Siegbedingungen umfassend diskutiert und neu gestaltet haben, und zwei Wochen vor dem Redaktionsschluss der inhaltlich letzten Version. Bei keinem dieser Punkte kann ich erkennen, dass er zwingend realisiert werden müsste. Deshalb sollten wir meines Erachtens die Finger davon lassen.

[raystuttgart]

Das Problem an den Rundenlimits ist folgendes:

Auch wenn die im XML angegebene Zahl bei bestimmten Siegbedingungen für das tatsächliche Ende der Partie gar keine Rolle spielt,
so wird sie an mehreren Stellen in der Logik (Vorallem KI-Verhalten bezüglich Kriegsführung/-planung und Diplomatie) verwendet.

Es ist also nicht möglich einfach im XML Werte zu ändern, ohne dass das Auswirkungen auf die KI hat.
Ihr würdet sprichwörtlich an einem Faden in einem komplizierten Geflecht ziehen, ohne zu wissen, was ihr dabei alles auslöst.

Ohne DLL-Unterstützung ist das äußerst riskant.
(Rundenlimits vs. KI-Balancing)

Wollt ihr das wirklich nochmal so kurz vor Ende eures letzten Release wagen ?

[Stöpsel]

Testanfrage Rev.# 458 Änderung der Rundeninformation


Änderung der Rundenanzeige, so dass ein Zeitlimit nicht angezeigt wird, wenn die Punktesieg-Option nicht angewählt ist und keine Revolution gestartet worden ist. Details gibt's hier

Testen:

Ist die Anzeige korrekt (Mouseover über Jahreszahl) je nachdem ob die Option Punktesieg aktiviert ist oder nicht

Die Anzeige (Mouseover Jahreszahl oben rechts, Geldvermögen oben links) ist korrekt: mit Punktsieg = aktuelle Runde | 300 (Limit); ohne = aktuelle Runde | kein Rundenlimit

Sowohl bei aktiviertem als auch abgeschalteten Punktesieg muss nach Start der Revolution wieder ein Rundenlimit angezeigt werden

Ohne Punktsieg = aktuelle Runde | Runde Revolutionsstart+200

Mit Punktsieg konnte ich noch nicht testen, außer dass das 300 Runden-Limit bestehen bleibt, wenn vor Runde 100 revoltiert wird.
Ich würde zum Testen gern das Rundenlimit für den Punktsieg senken, kann aber nicht finden, wo das festgelegt wird. Kann mir bitte jemand sagen, wo das steht?

Es sollte auf jeden Fall auch getestet werden, ob die Anzeige nach Start der Revolution durch eine KI noch korrekt ist

Die Anzeige funktioniert genau wie beim Revolutionsstart durch den menschlichen Spieler (aktuelle Runde | Runde Revolutionsstart+200).

[Ronnar]

Mit Punktsieg konnte ich noch nicht testen, außer dass das 300 Runden-Limit bestehen bleibt, wenn vor Runde 100 revoltiert wird.
Ich würde zum Testen gern das Rundenlimit für den Punktsieg senken, kann aber nicht finden, wo das festgelegt wird. Kann mir bitte jemand sagen, wo das steht?

Danke, Stöpsel.
Das sollte eigentlich ausreichen als Test. Wenn die anderen Anzeigen korrekt sind, sollte es diese auch sein. Die Ausgabevariable ist bei eingeschaltetem Punktesieg vor und nach der Revolution dieselbe, die Zahlenwerte werden in der DLL ermittelt (und daran habe ich nichts gedreht). Die Mühe musst du dir also nicht mehr machen (sollte da ein Fehler sein, dann gab es den seit Vanilla schon).

[Stöpsel]

Die Ausgabevariable ist bei eingeschaltetem Punktesieg vor und nach der Revolution dieselbe, die Zahlenwerte werden in der DLL ermittelt.

D.h. also, es gibt keine XML-Datei, in der konkrekt diese 300 Runden für den Punktsieg festgelegt ist, und kann daher auch nicht mal eben so geändert werden. Der Hintergrund meiner Überlegung ist die Frage, ob das Rundenlimit des Punktsieges Vorrang vor dem Rundenlimit der Revolution hat. Wird bspw. der Punktsieg und die Unabhängigkeit als Siegoption gewählt, dabei die Revolution in Runde 280 gestartet, erhöht sich dann das Rundenlimit für alle Siegoptionen auf 480 Runden, oder ist wegen der Option Punktsieg das Spiel trotzdem in Runde 300 vorbei? Das wollte ich auf die Schnelle wissen.

Edit1: Sind diese 300 Runden vielleicht in der CIV4GameSpeedInfo im Eintrag <iTurnsPerIncrement> festgelegt, der jetzt wegen der im Spielverlauf sich verändernden Zeitschritte der Rundenzahlen auf 4 Werte aufgeteilt ist? Wenn man die 4 Werte (bei TAC Normal) addiert, kommt man auf 300. Wenn ich das Zeitlimit auf 20 Runden senken wollte, dann müsste ich die Werte z.B. auf 20/0/0/0 ändern können.

Edit2: So ist es. Jetzt habe ich auch hierauf eine Antwort:

Sowohl bei aktiviertem als auch abgeschalteten Punktesieg muss nach Start der Revolution wieder ein Rundenlimit angezeigt werden

Ohne Punktsieg = aktuelle Runde | Runde Revolutionsstart+200

Mit Punktsieg konnte ich noch nicht testen, außer dass das 300 Runden-Limit bestehen bleibt, wenn vor Runde 100 revoltiert wird.

Mit Punktsieg = aktuelle Runde | Runde Revolutionsstart+200

Dabei gilt das Limit der Siegoption Unabhängigkeit, d.h. das Spiel läuft über das ursprüngliche Rundenlimit des Punktsieges hinaus.

Achtung Spoiler:

Danke für's Selbstgespräch, Stöpsel