Image für Satellitenkauf

[lonk0123]

In all meinen Spielen erreiche ich relativ schnell den Sweet-Spot dadurch, daß ich alle 3 Satellitenankopplungen innerhalb der 1. Woche (spätestens am Anfang der 2. Spielwoche) erreiche, da man am 1. Tag des Spiels mehr als 20% Image für die Anbindung benötigt, diese aber innerhalb der nächsten Tage drastisch sinkt und nach wenigen Tagen 0 erreicht.

Man hat dadurch relativ viele Zuseher, bei m.E. zu geringen Kosten (im Vergleich zum Anschluß anderer Bundesländerlizenzen bzw. Kabelnetze).

Ist es ein Bug oder ein Feature, warum das benötigte Image für Sat-Verbindungen sinkt und für andere Anschlußarten nicht?

[GWRon]

Das ist Absicht und vielleicht kann Nittka das passende Issue/PR raussuchen in dem er die dazugehoerige Aenderung begruendet.

[lonk0123]

Ich war mir sicher darüber schon mal etwas gelesen zu haben, finde aber in den closed Issues nichts Relevantes. Für mich macht genau dieses Problem das Spiel momentan "unspielbar", da die Schwierigkeit nach spätestens 1 Woche dramatisch den Berg runter geht. Mal sehen, wie nittka das begründet hat...

[nittka]

Eine (gewollte) Anpassung hier gab es nur für die Kabelverträge. Die Image-Einschränkung wird aufgehoben sobald 2 Spieler einen Kabelvertrag haben (um einen sowieso schon hinterherhinkenden Spieler nicht zu blockieren).

Bei Satelliten hatte ich das Thema gar nicht betrachtet. Klingt nach einem Bug.

[GWRon]

Was es gibt, ist eine Anforderungsreduktion mit jeder neuen "Satellitenrevision". Satelliten werden ja nach ein paar Jahren vom Nachfolger abgeloest. Nachfolger erfordern weniger Senderimage. Neue Technik: Kosten sinken und es wird mehr Platz fuer "viele Sender". Entsprechend wird auch "Muell" von Satelliten verteilt. So zumindest der Gedanke.

Jeder "Satellit" ruft dazu bei seiner Erstellung auf:

        If revision <= 1
            satellite.minimumChannelImage = RandRange(20,30)
        ElseIf revision <= 3
            satellite.minimumChannelImage = RandRange(15,25)
        Else
            satellite.minimumChannelImage = RandRange(10,15)
        EndIf

Wenn ein Satellit zum "Sterben" festgelegt wird, erzeugt es den Nachfolger mit "satellite.revision + 1"

[GWRon]

Type TStationMap_Satellite Extends TStationMap_BroadcastProvider {_exposeToLua="selected"}
...
    Method Update:Int()
...
            If minimumChannelImage > 0.1 And nextImageReductionTime < GetWorldTime().GetTimeGone()
                If nextImageReductionTime > 0
                    Local oldMinimumChannelImage:Float = minimumChannelImage
                    minimumChannelImage :* nextImageReductionValue
                    'avoid reducing very small values for ever and ever
                    If minimumChannelImage <= 0.1 Then minimumChannelImage = 0
                    'inform others (eg. for news)
                    TriggerBaseEvent(GameEventKeys.Satellite_OnReduceMinimumChannelImage, New TData.AddFloat("minimumChannelImage", minimumChannelImage).AddFloat("oldMinimumChannelImage", oldMinimumChannelImage), Self )
                EndIf

                nextImageReductionTime = GetWorldTime().ModifyTime(-1, 0, 0, Int(RandRange(20,30)))
                nextImageReductionValue = nextImageReductionValue^2
            EndIf

Da sinkt die Anforderung.

[lonk0123]

Sie kann von mir aus ruhig langsam sinken, wenn das so gewollt ist. Momentan erscheint es aber viel zu schnell zu sinken. Man soll ja eigentlich beim Ausbau mit den Antennen starten und sich dann langsam vorarbeiten. Im Moment ist es in den Spielen so, daß man evtl. 1 oder 2 Antennen gesetzt hat, dann ist es meist schon streng rational sich den Satelliten zuzuwenden (weil deren Imageverlangen 0 ist).

[GWRon]

https://github.com/TVTower/TVTower/commit/24652dc36efde6f188ba6b47109054c0e8ab1d5f

War wohl doch von mir eingefuehrter Code :)

[GWRon]

Derzeitiger Verlauf fuer Satellit "Dig", reductionValue ist der Wert, mit dem der angeforderte Imagewert multipliziert wird um den von da an angeforderten Imagewert zu berechnen. (Anforderung = Anforderung * reductionValue)

Dig:  now=1/20:00 (26.04.1985)  next=2/19:00 (24.05.1985)   reductionValue=0.940900028     next change: 21.0000000 => 19.7588997
Dig:  now=5/19:06 (24.05.1985)  next=7/01:06 (02.07.1985)   reductionValue=0.885292888     next change: 19.7588997 => 17.4924126
Dig:  now=7/01:20 (02.07.1985)  next=7/22:20 (28.07.1985)   reductionValue=0.783743501     next change: 17.4924126 => 13.7095642
Dig:  now=7/22:26 (29.07.1985)  next=8/19:26 (25.08.1985)   reductionValue=0.614253879     next change: 13.7095642 => 8.42115307
Dig:  now=8/19:33 (25.08.1985)  next=10/01:33 (02.10.1985)   reductionValue=0.377307832     next change: 8.42115307 => 3.17736697
Dig:  now=10/01:46 (03.10.1985)  next=11/01:46 (03.11.1985)   reductionValue=0.142361194     next change: 3.17736697 => 0.452333748
Dig:  now=11/02:00 (03.11.1985)  next=12/05:00 (07.12.1985)   reductionValue=0.0202667098     next change: 0.452333748 => 0.00916731637
Dig:  now=12/05:06 (07.12.1985)  next=13/05:06 (07.01.1986)   reductionValue=0.000410739536     next change: 0.00000000 => 0.00000000

Wie im obig verlinkten Beitrag erwaehnt gibt es bei der Formel derzeit zwei Stellschrauben:

• die Haeufigkeit der Anforderungsverringerung
• die Veraenderung des Reduktionsfaktors

                nextImageReductionTime = GetWorldTime().ModifyTime(-1, 0, 0, Int(RandRange(20,30)))
                nextImageReductionValue = nextImageReductionValue^2

nextImageReductionValue startet mit 0.97, wir haben mit der Formel also nach 6 "Reduzierungen" eine nahezu "0"-Anforderung. Die Reduzierungen finden aller 20-30 Stunden statt.

Moeglich ist hier ein langsameres Absenken und gleichzeitig verringertes Intervall (also seltenere Reduktion).

mit 0.98 und 35-45 Stunden landen wir bei:

Dig:  now=1/20:00 (26.04.1985)  next=3/10:00 (13.06.1985)   reductionValue=0.960400045     next change: 21.0000000 => 20.1684017
Dig:  now=6/10:13 (13.06.1985)  next=8/07:13 (10.08.1985)   reductionValue=0.922368228     next change: 20.1684017 => 18.6026936
Dig:  now=8/07:20 (10.08.1985)  next=9/19:20 (25.09.1985)   reductionValue=0.850763142     next change: 18.6026936 => 15.8264856
Dig:  now=9/19:33 (25.09.1985)  next=11/07:33 (10.11.1985)   reductionValue=0.723797917     next change: 15.8264856 => 11.4551773
Dig:  now=11/07:46 (10.11.1985)  next=13/04:46 (06.01.1986)   reductionValue=0.523883402     next change: 11.4551773 => 6.00117731
Dig:  now=13/04:53 (07.01.1986)  next=14/19:53 (25.02.1986)   reductionValue=0.274453819     next change: 6.00117731 => 1.64704609
Dig:  now=14/20:00 (26.02.1986)  next=16/16:00 (21.04.1986)   reductionValue=0.0753249004     next change: 1.64704609 => 0.124063581
Dig:  now=16/16:13 (21.04.1986)  next=18/08:13 (11.06.1986)   reductionValue=0.00567384064     next change: 0.124063581 => 0.000703917001
Dig:  now=18/08:26 (11.06.1986)  next=19/20:26 (26.07.1986)   reductionValue=3.21924672e-05     next change: 0.00000000 => 0.00000000

Wenn wir nun noch mit "Schoenen Zahlen" arbeiten (und kompatibel mit alten Speicherstaenden sein wollen - ergo bestehende Felder beibehalten):

Dig:  now=6/10:13 (13.06.1985)  reductionValue=0.955561578     next change: 20.2500000 => 19.25
Dig:  now=8/07:20 (10.08.1985)  reductionValue=0.934088469     next change: 19.2500000 => 17.75
Dig:  now=9/19:33 (25.09.1985)  reductionValue=0.902780175     next change: 17.7500000 => 16.00
Dig:  now=11/07:46 (10.11.1985)  reductionValue=0.857774258     next change: 16.0000000 => 13.50
Dig:  now=13/04:53 (07.01.1986)  reductionValue=0.794437110     next change: 13.5000000 => 10.50
Dig:  now=14/20:00 (26.02.1986)  reductionValue=0.708091319     next change: 10.5000000 => 7.25
Dig:  now=16/16:13 (21.04.1986)  reductionValue=0.595845819     next change: 7.25000000 => 4.25
Dig:  now=18/08:26 (11.06.1986)  reductionValue=0.459939629     next change: 4.25000000 => 1.75
Dig:  now=19/20:40 (26.07.1986)  reductionValue=0.311925769     next change: 1.75000000 => 0.0
Dig:  now=21/12:53 (17.09.1986)  reductionValue=0.174211532

Also Verlaengerung um 9-10 Spieltage bei gleichzeitiger Verlangsamung.

Noch die Verringerung anpassen (auf ^1.3):

Dig:  now=6/10:13 (13.06.1985)  reductionValue=0.966433764     next change: 20.2500000 => 19.50
Dig:  now=8/07:20 (10.08.1985)  reductionValue=0.956585348     next change: 19.5000000 => 18.50
Dig:  now=9/19:33 (25.09.1985)  reductionValue=0.943932295     next change: 18.5000000 => 17.25
Dig:  now=11/07:46 (10.11.1985)  reductionValue=0.927733183     next change: 17.2500000 => 16.00
Dig:  now=13/04:53 (07.01.1986)  reductionValue=0.907089233     next change: 16.0000000 => 14.50
Dig:  now=14/20:00 (26.02.1986)  reductionValue=0.880937338     next change: 14.5000000 => 12.75
Dig:  now=16/16:13 (21.04.1986)  reductionValue=0.848063767     next change: 12.7500000 => 10.75
Dig:  now=18/08:26 (11.06.1986)  reductionValue=0.807155252     next change: 10.7500000 => 8.50
Dig:  now=19/20:40 (26.07.1986)  reductionValue=0.756909907     next change: 8.50000000 => 6.25
Dig:  now=21/12:53 (17.09.1986)  reductionValue=0.696237564     next change: 6.25000000 => 5.00
Dig:  now=23/08:00 (11.11.1986)  reductionValue=0.624575138     -> Minimum 5.0 reached

Da nittka sich dem Issue schon angenommen hat hier mal meine theoretischen Anpassungen:

Field nextImageReductionTime:Float = 0.98
...

    Method Update:Int()

...
            'when to stop reducing
            Local channelImageBottomLimit:Float = 5.0

            If minimumChannelImage > channelImageBottomLimit And nextImageReductionTime < GetWorldTime().GetTimeGone()
                If nextImageReductionTime > 0
                    Local oldMinimumChannelImage:Float = minimumChannelImage
                    'we want to reduce to "nice values" (eg 0.5-steps)
                    minimumChannelImage :* nextImageReductionValue
                    minimumChannelImage = floor(minimumChannelImage * 4)/4.0
                    'avoid reducing very small values for ever and ever
                    If minimumChannelImage <= 0.1 Then minimumChannelImage = 0
                    minimumChannelImage = Max(channelImageBottomLimit, minimumChannelImage)
                    'inform others (eg. for news)
                    TriggerBaseEvent(GameEventKeys.Satellite_OnReduceMinimumChannelImage, New TData.AddFloat("minimumChannelImage", minimumChannelImage).AddFloat("oldMinimumChannelImage", oldMinimumChannelImage), Self )
                EndIf

                nextImageReductionTime = GetWorldTime().ModifyTime(-1, 0, 0, Int(RandRange(35,45)))
                nextImageReductionValue = nextImageReductionValue^1.3
            EndIf

[lonk0123]

11 Schritte in 35-45h-Intervallen fände ich zu wenig, da man ja auch eigenes Image aufbaut und mit 2 oder 3 Sammys schnell auf über 10% Image kommt.

Die anfänglichen Imagewerte der Satelliten liegen ja so um die 25%. Momentan fallen sie glaube ich so ungefähr 2-3% pro Spieltag (das stimmt auch mit den Dig-Werten von oben überein.

Wenn die pro Spieltag um 0.5% - 1% fielen, fände ich das schon ok, da sich beide Imagewerte ja anähhern (das geforderte Image der Satelliten, als auch das eigene Image). Es sollten schon 2 Spielwochen mind. vergehen, ehe man an die Satellitenverträge rankommt. Dann hätte die vorherige terrestrische Phase auch mal eine ganz andere Bedeutung im Spiel.

Evtl. kann man hier auch später mal einen Multiplikator für die einzelnen Schwierigkeitsstufen unterbringen, so daß es für Leute (wie mich, die es gerne etwas schwieriger lieben) ein klein bißchen herausfordernder wird.

[nittka]

Ggf. kommt man auch ganz ohne die schrittweise Reduktion aus. Mit Antennen und Kabelverträgen (und der dort wegfallenden Imagegrenze) sollte man eine genügend große Zuschauerbasis schaffen können. Wenn man damit nicht in der Lage ist 25% Image zu erreichen, hat man es vielleicht auch nicht verdient über Satellit übertragen zu werden. Also konkreter Vorschlag: vereinfachen und reduction komplett entfernen.

Stattdessen könnte man langfristig darüber nachdenken, ob die Kosten am Image hängen könnten (z.B. je besser das Image, desto geringer die Abschlusskosten oder auch laufende Kosten für den Vertragszeitraum). Dann wird es nämlich eine wirtschaftlich interessante Entscheidung, wann man die Verträge abschließt.

[nittka]

Erster PR ist gestellt (gar keine Reduktion). Falls das auf keine Gegenliebe stößt, habe ich auch kein Problem mit Ronnys Variante. Ein unterer Wert von 5% ist meiner Meinung nach aber zu niedrig. 10% sollten es schon sein. Und den Zeitraum würde ich eher auf 38-48 Stunden erhöhen.