[TAC] Spielgeschwindigkeit, Rundenzahl, Siegbedingungen

[raystuttgart]

Und so sind auch viele andere Diplomatiewerte (z.B. iRefuseToTalkWarThreshold) betroffen, nur das ich die nie angepasst habe. Elwood überarbeit zur Zeit ja die XML-Werte für die Staatsoberhäupter. Er orientiert sich dabei an den Vanilla-Werten und weiß gar nicht, daß das in TAC zu anderen Ergebnissen als in Vanilla führt...

Eigentlich wollte ich meine Klappe halten, aber dazu muss ich doch ein paar Worte verlieren.

Ich habe hier Elwood darauf hingewiesen, dass es bei den Ureinwohnern auch eine Abhängigkeit zum Spielfortschritt gibt.
(Punkt 6.)

Ich betone nochmal:
Spielfortschritt

Das ist nicht die reine Rundenzahleinstellung eines Spiels.

Ausserdem habe ich bewusst darauf hingewiesen, dass das an der Stelle nicht so ausschlaggebend ist.

@koma:

In folgendem Punkt gebe ich dir Recht:
Es gibt Einflüsse der Rundeneinstellung auf diverse KI Entscheidungen (natürlich auch im Bereich Diplomatie).
Das ist aber durch vernünftige Wahl der Einstellungen durchaus in den Griff zu bekommen.
Deshalb schaut man sich ja am Besten den Code an, lässt Erfahrungserte einfließen und bestimmt dann, wie die Werte zu setzen seien.

Meine Meinung dazu:

Die Diplomatie-Einstellungen sind definitiv kein Grund, die Rundenzahl runterzusetzen.
Da bin ich absolut dagegen.
Die hohe Rundenzahl ist meiner Meinung nach eine der wichtigsten Verbesserungen, die es in TAC gibt !

Anmerkung:

1. Ich verstehe leider nicht, wo dir die Rundenzahl Probleme bereitet, Sorry.
2. Hardcodiert ist da - soweit ich es gesehen habe nichts- das geht als Faktor entsprechend der Einstellung im XML in die Formeln ein.
3. Wie du die Rundenzahl senken willst, ohne dass das dann Auswirkungen auf das Spielende hat, ist mir auch nicht verständlich.

[koma13]

koma, sei aber bitte so lieb und erkläre noch mal gaaanz langsam, was du beim Rundenlimit ändern würdest. Und welche konkreten Auswirkungen das hat auf das Erfüllen der Siegvarianten, auf den Kalender, auf die Einstellungen in der CIV4GameSpeedInfo.xml. Ich fürchte, ich habe noch nicht ganz kapiert, was dir da im Detail vorschwebt.

Ok.

In der DLL werden die Diplomatiewerte auf die Spielgeschwindigkeit (=SG) angepasst. Ein Teil der Werte wird dazu mit dem Rundenlimit multipliziert. Ein anderer Teil der Werte wird über andere Civ4GameSpeedInfo-Einträge berechnet.

Wir haben in TAC nun das Rundenlimit erhöht, ohne allerdings die anderen SG-Werte (iGrowthPercent, iStoragePercent usw) um den selben Faktor zu erhöhen. Dadurch fallen Diplomatiewerte, die über das Rundenlimit angepasst werden, deutlich höher aus als Diplomatiewerte, die über die anderen Einträge der SG berechnet werden.

Nach meinem Wissensstand entscheidet nicht das Rundenlimit über das Spielende, sondern die Siegbedingungen. Würde man in Vanilla bei einer Partie sämtliche Siegbedingungen deaktivieren, sollte also auch dort ein Endlosspiel möglich sein.
Das Zeitlimit der Siegbedingungen selber orientiert sich allerdings wieder an dem Rundenlimit. Dadurch wird der Punktespiele-Sieg und auch das Revolutionslimit in Vanilla auf 300 Runden (SG Normal) und in TAC auf 900 Runden gesetzt.

Um das obenbeschriebene Problem bezüglich der Diplomatiewerte zu lösen, sollte es also ausreichen, die Siegbedingungen vom Rundenlimit abzukoppeln. Damit könnten wir die SG auf Vanilla-Niveau zurückführen und könnten das Zeitlimit für die Siegbedingungen individuell einstellen, z.B auf die jetzt in TAC üblichen 900 Runden.

Dazu würde es sich anbieten in Civ4GameSpeedInfo einen neuen Eintrag "iVictoryTurnLimit" einzuführen, mit dem das Zeitlimit der Siegbedingungen dann festgelegt werden kann.

[raystuttgart]

Hi koma,

schau dir doch bitte die Formeln nochmal an.

Da geht es fast immer um den Spielfortschritt.

Da wird die aktuelle Rundenzahl mit dem voraussichtlichen Spielende zusammen in die Berechnung mit eingebracht.

Das ist nicht alleine das Rundenlimit.
Ich erkenne da echt kein Problem.

[koma13]

Da wird die aktuelle Rundenzahl mit dem voraussichtlichen Spielende zusammen in die Berechnung mit eingebracht.

Und das voraussichtliche Spielende wird über das Rundenlimit berechnet.

[raystuttgart]

Und das voraussichtliche Spielende wird über das Rundenlimit berechnet.

Richtig, aber dennoch geht es da um den Spielfortschritt.
Die aktuelle Runde ist dann ja aber auch in einem ganz andere Spielbereich.

Du bekommst da absoluten Krampf in den Formeln, wenn deine aktuelle Runde = 700 ist, du aber in der Spielende-Einstellung = 300 drin hast.

Du erzeugst da ein ganz neues Problem wo es aktuell gar keines gibt !

Sieh dir das bitte nochmal ganz in Ruhe an.

[koma13]

Sieh dir das bitte nochmal ganz in Ruhe an.

Mach ich seit gestern nachmittag.

Schau dir an, wie CvGameAI::AI_adjustedTurn(int iTurn) und CvGame::getEstimateEndTurn() berechnet werden.

Wenn es kein Problem für dich ist, daß die KI in der normalen Spielgeschwindigkeit sich so verhält, als ob sie auf Marathon spielen würde, ist das schön für dich. Für TAC ist das mMn keine Lösung.

[raystuttgart]

Wenn es kein Problem für dich ist, daß die KI in der normalen Spielgeschwindigkeit sich so verhält, als ob sie auf Marathon spielen würde, ist das schön für dich. Für TAC ist das mMn keine Lösung.

Das ist doch dann aber ein "Problem", das durch "falsch gewählte" XML-Einstellungen entsteht !

Ausserdem wollen es die Spieler ja vielleicht auch so und wählen ja bewußt nach ihren Erfahrungen die Spielstarteinstellungen.

Das machst du nicht dadurch besser indem du dafür sorgst, dass in anderen Formeln absoluter Quatsch rauskommt.

Sorry koma, ich widerspreche dir ja wirklich selten, weil du fast immer Recht hast, aber diesmal bist du - meiner Meinung nach - auf dem falschen Weg.

Spielfortschritt bleibt Spielfortschritt !

10 gespielte Runden aus 300 verfügbaren Runden.
30 gespielte Runden aus 900 verfügbaren Runden.

[koma13]

Das ist doch dann aber ein "Problem", das durch "falsch gewählte" XML-Einstellungen entsteht !

Die XML-Werte in der Civ4GameSpeedInfo sind falsch gesetzt. Diese Datei dient nicht dazu, die Siegbedingungen nach hinten zu verschieben, sondern die Spielgeschwindigkeiten anzupassen. Dazu müssen die einzelnen Einträge dort in einem vernünftigen Verhältniss stehen, was bei TAC derzeit nicht der Fall ist.

Spielfortschritt bleibt Spielfortschritt !

10 gespielte Runden aus 300 verfügbaren Runden.
30 gespielte Runden aus 900 verfügbaren Runden.

1. Was ist Spielfortschritt?
2. Wie passt das denn damit zusammen, daß die KI um Runde 300 die Unabhängigkeit erklären soll. Du bringst Spielgeschwindigkeit und Rundenlimit durcheinander.

[raystuttgart]

Die XML-Werte in der Civ4GameSpeedInfo sind falsch gesetzt. Diese Datei dient nicht dazu, die Siegbedingungen nach hinten zu verschieben, sondern die Spielgeschwindigkeiten anzupassen. Dazu müssen die einzelnen Einträge dort in einem vernünftigen Verhältniss stehen, was bei TAC derzeit nicht der Fall ist.

Und deswegen willst du Berechnungsformeln in der DLL zerschießen ?

Wie gesagt, ich kann dein Problem beim besten Willen nicht erkennen.
Die Formeln in der DLL sind stimmig.
Da geht es nämlich um den Spielfortschritt (das sag ich jetzt glaub ich zum X-ten mal.).

Wenn gespielte Runden > Spielende, dann kommt mit deinem Vorschlag (wenn ich ihn richtig verstehe) da nämlich echt ganz seltsames Zeug raus.

[koma13]

Ray, die KI hat aber keine 900 Runden Zeit. Die Unabhängigkeit findet nachwievor um Runde 300 statt.

Nochmal (zum Letzten mal): wir haben in TAC nicht die Spielgeschwindigkeit geändert, sondern nur das Rundenlimit erhöht. Das führt bei den Diplomatiewerten, je nach dem, ob diese Werte über das Rundenlimit (getEstimateEndturn) oder anderen Einträgen der Spielgeschwindigkeit (z.B. AI_adjustedTurn) berechnet werden zu Unterschieden um den Faktor 3.

Nach deiner Logik wäre es dann egal, ob Elwood bei einem Leaderhead-Eintrag nun eine 4 oder eine 12 setzt.

[raystuttgart]

Ray, die KI hat aber keine 900 Runden Zeit. Die Unabhängigkeit findet nachwievor um Runde 300 statt.

Das ist doch aber ein anderes Problem.

Dann müsste dieser Wert mittels Berücksichtigung der XML-Einstellungen (getEstimateEndturn) angepasst werden.
(Da bin ich noch vollkommen bei dir. )

[koma13]

Dann müsste dieser Wert mittels Berücksichtigung der XML-Einstellungen angepasst werden.
(Da bin ich noch vollkommen bei dir. )

Und wie willst du das machen? Alle Diplomatiewerte in der DLL dahingehend überprüfen, ob sie über das Rundenlimit oder über iGrowthPercent+iTrainPercent+iConstructPercent berechnet werden?

Viel Spass dabei.

[raystuttgart]

Nochmal auseinanderklamüsert:

1. Bei den Berechnungen die GC.getGameINLINE().getEstimateEndTurn() verwenden, geht es nur darum, dass die KI bestimmte Entscheidungen eher oder seltener trifft, je nachdem, wie weit das Spiel zeitlich fortgeschritten ist.

Das sie dabei nicht berücksichtigt, welche Fortschritte der Spieler dabei tatsächlich erzielt haben mag, ist Schade, aber nicht tragisch.
(iGrowthPercent+iTrainPercent+iConstructPercent)

Ausserdem sind das gar nicht soviele Codestellen.

2. Das bei der Berechnung, ob eine KI die Revolution beginnt, nicht einfließt, wieviel Zeit sie eigentlich noch hätte (Rundenlimit) ist auch Schade, aber auch das ist nicht tragisch.

3. Es muss sichergestellt bleiben, dass bei den Formeln, die den zeitlichen /relativen Spielfortschritt einbeziehen kein Quatsch rauskommt.

Deshalb keine Trennung von Spielrundenlimit und Limit für Siegbedingungen.

4. Ich gebe dir Recht, dass es nicht optimal gelöst ist, dass einige Stellen nur den zeitlichen Fortschritt betrachten und andere auch den Fortschritt, den ein Spieler im Wachstum erreicht haben kann.

Schnellschüße, die aber in einigen Formeln zu abstrusen Werten führen, helfen nicht.

5. Optimum wäre wahrscheinlich wenn bei den Codestellen immer beides mit einfließen würde.

Fazit:

Ich bin dagegen, das Rundenlimit vom Limit der Siegesbedingungen zu entkoppeln, weil ich in einigen Formeln dann eine hohe Fehlergefahr sehe.

Du und das Team bestimmt aber was ihr macht.
(Ich denke, ich habe meine Meinung dazu gesagt.)

P.S.:
Nimm es mir bitte nicht übel, wenn ich hier so lange rumlamentiert habe ...
Ich sehe einfach nur eine hohe Gefahr bei deinem Vorschlag, dass die Dinge nicht besser, sondern schlimmer werden.

Eine Anpassung der XML-Werte wäre vielleicht sinnvoller.

[koma13]

Ausserdem sind das gar nicht soviele Codestellen.

Also dein Vorschlag geht so:

1. Wie erhöhen die Rundenlimits für die einzelnen Spielgeschwindigkeiten über XML um den Faktor 3 (das wurde ja bereits gemacht).
2. Dann reduzieren wir in der DLL das Rundenlimit wieder um den Faktor 3 für alle Werte an dutzenden Stellen bis auf eine Ausnahme (die Siegbedingungen).

Das ist doch viel zu umständlich. Einfacher wäre es da das Rundenlimit auf Vanilla-Niveau zu lassen und die eine Ausnahme (das Zeitlimit für die Siegbedingungen) zu erhöhen.

Als Boni würden auch die Jahreszahlen wieder stimmen. Es wirkt nicht sehr authentisch, wenn der Spieler ein Kolonialreich aus dem nichts aufbaut und schon nach 100 Jahren in der Lage ist, eine europäische Großmacht zu besiegen.

EDIT:
Die Problematik mit den Jahreszahlen sollten wir nicht unterschätzen.

Derzeit haben Spieler, die TAC nicht gut kennen, keine Möglichkeit einzuschätzen, wie lange sie noch Zeit haben das Spiel zu gewinnen. Die niedrigen Jahrenzahlen suggerieren, das man sich die gesamte Zeit über in der Anfangsphase des Spiels befindet.
Die KI erklärt dann aus heiterem Himmel um 1600 die Unabhängigkeit und der Spieler wird sich vermutlich fragen, wo die versprochenen 900 Runden abgeblieben sind.

[raystuttgart]

Mein "Vorschlag" ist folgender:

1. Es muss sichergestellt bleiben, dass bei Formeln, die den relativen zeitlichen Fortschritt des Spiels berücksichtigen, kein Unsinn rauskommt.
(z.B. wenn aktuelle Rundenzahl = 500 und Spielende = 300 eingestellt wäre.)

2. Wir prüfen den Code auf alle Stellen, in denen nur zeitlicher Spielfortschritt oder nur Wachstum / potentiellen Fortschritt des Spielers zu dieser Zeit einbezogen wurden,
ob es an diesen Stellen sinnvoll ist auch den jeweils anderen Faktor einzubeziehen.

Beispiel 1:
KI bestimmt den Moment, an dem sie die Unabhängigkeit beginnt.
-> Hier wäre es gut, wenn die KI nicht gleich um Runde 300 immer den Unabhängigkeitskrieg versucht, wenn sie bis Runde 900 die Möglichkeit hätte.
(Spieler wählen die längere Spieldauer ja nicht umsonst ...)

Beispiel 2:
KI bestimmt ihr Diplomatie-Verhalten bezüglich Krieg.
-> Hier wäre es gut, wenn die KI nicht nur den Faktor relativer zeitlicher Spielfortschritt, sondern auch ein wenig den Faktor Wachstum / Fortschritt des Spielers mit einbezieht.

3. Die XML-Einstellungen an den Gamespeeds werden nochmal auf ihre Stimmigkeit überprüft.

Warum:

1. Wir bekommen keine unvorhersehbaren Werte der Formeln im frühen oder im späten Spielverlauf.
2. Der Spieler hätte auch bei hohen Spielrundenzahlen einigermaßen die Möglichkeit diese auszuschöpfen.
3. Das Balancing und das KI-Verhalten wären zum Schluß wahrscheinlich deutlich besser.
(Würde mit unterschiedlichsten Einstellungen im XML klar kommen.)

Mir ist vollkommen klar, dass das viel Aufwand ist.
(Ich würde dich da unterstützen. )

Aber das ist mir um ein vielfaches lieber, als dein bisheriger Vorschlag.
Der ist nämlich:

1. Für andere Modder später mal extrem schwer nachzuvollziehen.
2. Er schafft Probleme in den Formeln, die nur den zeitlichen Aspekt berücksichtigen.
3. Es ist eine ziemlich unsaubere Geschichte.

Was willst du also machen ?

Eine "schmutzige" Lösung, die vielleicht ein Problem löst, aber gleichzeitig ein anderes schafft, oder eine "saubere" Lösung, die zwar aufwendiger ist, aber letzlich ein deutlich besseres Resultat verspricht ?

Wenn dir die "saubere" Lösung zuviel Arbeit ist, dann sollte man eventuell einfach die XML-Werte passend abstimmen.
(Was die 3. Möglichkeit wäre ...)

Wenn auch das nicht gemacht werden soll, wäre es mir am liebsten, wenn man dann gar nicht in die DLL fast und alles so lässt, wie es ist.
(Was die 4. Möglichkeit wäre ...)