Ich stoße gerade (unabhängig von RaR 2.2) auf folgendes Problem:
Typischerweise werden entweder Feature-relevante Modifikatoren oder Terrain-relevante Modifikatoren in die Kampfwertberechnung einbezogen.
Also, wenn ein Geländefeld mit Wald bewachsen ist, gelten die Modifikatoren für den Wald, und nicht die für das darunterliegende Terrain (gilt für Verteidiger wie für Angreifer). Das ist in aller Regel auch sinnvoll.
Es gibt allerdings den Sonderfall des dschungelbewachsenen Sumpffeldes.
Ich bin der Meinung, dass sich in diesem Spezialfall die Modifikatoren summieren sollten (wie im Falle der Hügel ebenfalls). Gibt man z.B. Sumpf einen Verteidigungsmodifikator von +20% und Dschungel einen Verteidigungsmodifikator von +50%, dann sollte der Verteidiger m.E. insgesamt +70% erhalten, und nicht nur +50%.
Für den Angreifer sollte die Summierung ebenso gelten.
Mal gucken, was ich da mache...
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
So, der Compiler hat alles geschluckt und RaR startet normal! Soll heißen das ich wohl nichts vergessen habe mit rüber zu nehmen. Ich habe es jetzt nicht im Spiel getestet aber es müsste ganz normal funktionieren und das tun was es halt tun soll!
Ich habe fYieldPriceNormalizingMultiplier jetzt in fPriceNormalizingMultiplier umbenannt um den Multipler nominell nicht nur Auf Yields zu beschränken. Ich kann die Price-Normalizing dann noch auch noch auf die Units ausweiten. Muss man dan gucken wie du das gerne hättest? Aber vorab schon mal zum reingucken!
Die Berechnungen um "YieldBoughtTotal" sind in RaR etwas umfangreicher. Da muss ich mir noch ein paar Gedanken ob ich das noch was raus-nehme (Stichwort "iEuropeVolumeAttrition").
In einer PN konnte ich die Datei nicht anhängen also hab ich das hier gemacht.
Gruß
Kermit
Geändert von Kermit87 (25. September 2014 um 00:13 Uhr)
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
Das hatte ich mir vor geraumer Zeit schon mal (allerdings nur sehr flüchtig) angesehen. Ich bin mir aus der Erinnerung heraus gar nicht sicher, ob das überhaupt genutzt wird.
Bei nochmaligem Nachdenken könnte es wohl doch genutzt werden, aber ich war mir beim damaligen Betrachten zumindest nicht sicher, ob es messbare Auswirkungen haben würde.
Ein weiterer Blick darauf könnte sich jedenfalls lohnen.
Achtung Spoiler:
Es gibt ja verschiedene Spieleinstellungen die den PriceNormalizingMultiplier beeinflussen können:
bei der Spielgeschwindigkeit ist zB. zu beachten das sich bei einer Höheren Spielgeschwindigkeit jedoch nicht die Menge der in einer Runde erwirtschafteten Yields erhöht. Kannst Du mit deinem analytischen Schafsinn überlegen woran Du die Höhe des PriceNormalizingMultiplier anknüpfen würdest?
- Spielgeschwindigkeit
- Schwierigkeitsgrad
- oder erstmal statisch
- oder vielleicht die PriceNormalizingMultiplier aus: "(Spielgeschwindigkeit + Schwierigkeitsgrad) / 2" mitteln
Ich arbeite auch gerade an einem Prototyp von/um: CvTeam::normalizeEuropeUnitsPrices()
Geändert von Kermit87 (26. September 2014 um 16:12 Uhr) Grund: Schreibfehler
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
(Die Nummerierungen stammen von mir)
Puh. Das sind "spielphilosophische" Fragen.
1) Spielgeschwindigkeit
Bei TAC-normal haben wir 300 Runden, bei Marathon 900 Runden.
Da gibt es eigentlich zwei Ansatzpunkte: Entweder, man führt die Routine nur jede x-te Runde aus, wobei sich das x aus dem Verhältnis der Runden aus der gewählten und aus der als "normal" angesehenen Rundenzahl ergibt. Oder man führt die Berechnung jede Runde aus, dann aber mit einem angepassten Prozentsatz. Letzteres wäre "unauffälliger", ersteres vermutlich minimalst weniger rechenintensiv (über die gesamte Spieldauer gesehen).
2) Schwierigkeitsgrad
Da geht's dann in die Philosophie, ähnlich wie bei Kämpfen, die (für den menschlichen Spieler) ja auch schwierigkeitsgradunabhängig sind (für den KI-Spieler nicht, sobald es um Kämpfe gegen Eingeborene geht).
Da gibt es m.E. keine ja/nein-Antwort, das ist persönliches Ermessen. Es gibt für beide Ansichten gute Gründe.
Persönlich tendiere ich dazu, den Korrekturfaktor unabhängig vom Schwierigkeitsgrad zu lassen, das ist aber lediglich ein persönliches Bauchgefühl und kann nicht weiter begründet werden.
3) Statisch
Das verstehe ich als das Verwenden des gleichen Prozentsatzes, unabhängig von Spielgeschwindigkeit oder Schwierigkeitsgrad.
Da die Spielgeschwindigkeit die mögliche Ausbringungsmenge während des jeweiligen Gesamtspiels beeinflusst, sollte man tatsächlich diesbezüglich korrigieren wie unter 1)
Statisch würde ich es also nicht lassen
4) Mittelung aus Spielgeschwindigkeit + Schwierigkeitsgrad
Wenn man auf 1) und 2) guckt, ergibt sich schon die Antwort.
Davon unabhängig muss man sich überlegen, was von beiden Faktoren in welchem Maße den größeren Einfluss hat; oder anders ausgedrückt, ich halte die Formel (Spielgeschwindigkeit + Schwierigkeitsgrad) / 2 für ungeeignet.
Je höher Spielgeschwindigkeit und Schwierigkeitsgrad, desto niedriger die Korrekturfaktoren. Diese dann noch zu halbieren, würde den Effekt ja nur verstärken und die Korrektur nachher vermutlich bis in den nicht mehr messbaren Bereich minimieren.
Kurz und knapp: ich würde empfehlen, im Moment das Augenmerk nur auf Punkt 1) zu richten.
Gut dann werde ich mich auf Punkt 1) konzentrieren. Danke!
Frage zu Syntax:
Verstehe ich das richtig das iVar_A der Wert von iVar_D zugewiesen wird wenn Die (iVar_B == iVar_C) "true" ergibt. Sollte dies nicht der Fall sein so wird iVar_A der Wert iVar_E zugewiesen. Ist das so korrekt?Code:int iVar_A = (iVar_B == iVar_C) ? iVar_D : iVar_E;
Frage:
Gibt es eigentlich eine Funktion oder möglichkeit die mir die Nachkommastellen einer float fVar zurückgibt?
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
Genau.
"?" ist ein sogenannter "ternärer Operator", der genau so wirkt, wie du das beschrieben hast. Eignet sich hervorragend, um überflüssige und unübersichtliche if-Statements zu umgehen.
Vermutlich hilft dir modf() weiter.
Geändert von Kermit87 (27. September 2014 um 13:29 Uhr)
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
Es mag sein, dass ich gerade etwas wesentliches übersehe, aber CvTeam::changeEuropeUnitsPurchased und CvTeam::getEuropeUnitsPurchased ändern doch nur die Anzahl "gekaufter" Einheiten. Warum die Multiplikation/Division mit 10000?
Das habe ich so gemacht wegen dem Runden. Unterstellen wir dem Computer mal das er immer aufrundet (was er glaube ich auch tut), dann wäre bei einem PriceNormalizingMultiplier von 0,95 unter einem m_aiEuropeUnitsPurchased[eUnitClass] Wert von 20 Schluss!
Beispiel (jede Runde):
Deswegen habe ich das Komma um vier Stellen verschoben.Code:0,95 * 30 = 28.50 ≈ 29 sinkend 0,95 * 29 = 27,55 ≈ 28 sinkend 0,95 * 28 = 26,60 ≈ 27 sinkend 0,95 * 27 = 25,65 ≈ 26 sinkend 0,95 * 26 = 24,70 ≈ 25 sinkend 0,95 * 25 = 23,75 ≈ 24 sinkend 0,95 * 24 = 22,80 ≈ 23 sinkend 0,95 * 23 = 21,85 ≈ 22 sinkend 0,95 * 22 = 20,90 ≈ 21 sinkend 0,95 * 21 = 19,95 ≈ 20 sinkend 0,95 * 20 = 19,00 ≈ 19 Stagnation 0,95 * 19 = 18,05 ≈ 19 Stagnation 0,95 * 19 = 18,05 ≈ 19 Stagnation 0,95 * 19 = 18,05 ≈ 19 Stagnation usw. …
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!
Nein, tut er nicht.
Integerwerte sind immer der Ganzzahl-Anteil. Also 28,34 wird zu 28 und 28,84 wird auch zu 28.
Außerdem überrascht mich gerade, dass du die Anzahl der Einheiten mit dem PriceNormalizingMultiplier multiplizieren willst? Ich wäre ja vom jeweiligen Preis ausgegangen...
Allerdings komme ich auch grade vom Radfahren zurück und bin einigermaßen erschossen... Ich gucke mir das morgen noch mal an.
OK, dann Rundet er sozusagen immer ab!
Das künstliche erhöhen Zahlen erhöht die sogesehen die Auflösung der Berechnung. Sonst würde die Preisentwicklung teilweise stark verfälscht!
So habe ich das auch mit den Yields gemacht. Ausschlaggebend für den steigenden Preis sind ja die gekauften Einheiten. Vielleicht habe ich deinen Einwand aber auch nicht richtig verstanden?Außerdem überrascht mich gerade, dass du die Anzahl der Einheiten mit dem PriceNormalizingMultiplier multiplizieren willst? Ich wäre ja vom jeweiligen Preis ausgegangen...
Allerdings komme ich auch grade vom Radfahren zurück und bin einigermaßen erschossen... Ich gucke mir das morgen noch mal an.
Geändert von Kermit87 (30. September 2014 um 00:37 Uhr)
Wer Rechtschreibfehler findet darf sie behalten, ich habe genug davon!