Es kam ja früher öfters die Frage auf, wie die Prozedur ChangeConfident in X-Skript eigentlich genau funktioniert. Außerdem wird sie ja auch benutzt, um die automatischen Vertrauensänderungen im Spiel zu berechnen. Ich bin jetzt gerade mal darüber gestolpert, und kann sie daher jetzt mal etwas genauer erklären. Zuerst die Funktion, wie sie in Delphi umgesetzt ist:

procedure TOrganisationList.ChangeZufriedenheit(Index: Integer;Wert: Integer);
var
  OldState: TOrganisationStatus;
  NewState: TOrganisationStatus;
begin
  {$IFDEF MAXCONFIDENT}
  exit;
  {$ENDIF}
  if (Index<0) or (Index>Count-1) then exit;
  with fOrganisations[Index] do
  begin
    OldState:=OrganStatus(Friendly);
    inc(Zufriedenheit,Wert);
    while abs(Zufriedenheit)>Friendly do
    begin
      if Zufriedenheit>Friendly then
      begin
        dec(Zufriedenheit,Friendly);
        if Friendly>0 then
          Friendly:=min(100,Friendly+min(5,max(1,round(100/Friendly))))
        else
          Friendly:=1;
      end
      else if Zufriedenheit<-Friendly then
      begin
        inc(Zufriedenheit,Friendly);
        Assert(101-Friendly<>0,'Friendly hat einen Wert von 101');
        Friendly:=max(0,Friendly-min(5,max(1,round(100/(101-Friendly)))));
      end;
      if Friendly=0 then
        Zufriedenheit:=0;
    end;
    NewState:=OrganStatus(Friendly);
    if OldState<>NewState then
    begin
      ChangeStat(OldState,NewState,Name);
      fNotifyList.CallEvents(EVENT_SPECIAL_ONCOUNTRYFRIENDLYCHANGED,TObject( Index));
    end;
  end;
end;

Und was bewirkt nun der 2. Parameter 'Wert' der Prozedur? Dazu muss man zuerst folgendes wissen. Das aktuelle Vertrauen eines Landes wird in dem Wert friendly gespeichert. Zusätzlich hat jedes Land noch den (nur intern verwendeten) Wert Zufriedenheit. Der Parameter Wert erhöht jetzt lediglich den Wert Zufriedenheit. Von hier an beschränke ich mich mal auf positive Zufriedenheitswerte - bei nagativen verhält es sich aber analog. Sobald der Wert Zufriedenheit größer wird, als der aktuelle friendly-Wert des Landes(also größer als das Vertrauen), wird er um friendly verringert, und der friendly-Wert selbst erhöht. Entscheidend für das 'um wie viel erhöht' ist dabei folgende Zeile:

Friendly:=min(100,Friendly+min(5,max(1,round(100/Friendly))))

Ich bin mir nicht ganz sicher, ob Jim_Raynor sich ganz bewusst war, was er damit erreicht, als er das programmiert hat. Kurz gesagt läuft es auf folgendes hinaus:

Ist der friendly-Wert <= 22, so wird er um 5 erhöht,
ist der friendly-Wert <= 28, so wird er um 4 erhöht,
ist der friendly-Wert <= 40, so wird er um 3 erhöht,
ist der friendly-Wert <= 66, so wird er um 2 erhöht,
ist er größer, wird er nur um 1 erhöht (Maximum ist 100).

Sollte anschließend die Zufriedenheit immernoch größer sein, als der friendly-Wert, wird der Vorgang wiederhohlt.



Abschließend stellt sich mir die Frage, ob man das so lassen will, oder ob es nicht sinnvollere Varianten gibt...

Also übersetzt:
- Der im Spiel angezeigte und benutzte Vertrauenswert-Wert ist "friendly"
- Ein Ereignis (und der scriptbefehl) verändern "zufriedenheit"
- Wenn der Zufreidenheitswert größer ist als friendly, wird friendly verändert - das Vertrauen steigt (und analog andersrum?)
- Die Veränderung ist geringer, wenn "friendly" größer ist.


Durch diese Abstufung wird das Maximum nicht so schnell erreicht.
Aber wie ist das mit dem Vertrauensminimum? Gespiegelt? Also auch langsamer nach unten? (ich habe eher den Eindruck gehabt, das ist nicht so)

Von daher ist das eigentlich eine sinnvolle Variante - und erklärt, warum es so schwer ist, "sehr gut" zu erreichen ;)
Für direkten Einfluss aber eher ungeeignet, da man dann weniger genau steuern kann, welche Auswirkungen ein Ereignis hat.

Deshalb gibt es ja noch den zweiten Skriptbefehl um friendly direkt zu ändern.

Gespiegelt ist nur das man eine negative Zufriedenheit braucht um friendly zu verlieren.
Und wie Natter nachträglich merkte (im Chat), verliert man bei hohem Vertrauen mehr Punkte als bei niedrigem, d.h. die Abzugsskala ist ungefähr gedreht.

country_api_ChangeConfidenceAbs ?
Der macht dann direkt friendly?
country_api_ChangeConfidence macht Zufriedenheit?

genau - da war doch eine große Diskussion als der eingeführt wurde. abs steht für absolut

Das Problem was ich sehe ist aber, das ein Spielsatzautor nicht abschätzen kann, wie viel sich das Vertrauen nun ändert, wenn der Spieler 20 UFOs abschießt und dadurch z.B. 160 Punkte Zufriedenheit erhält.

Das Verhalten, dass Vertrauen bei höheren Friendlywerten immer langsamer steigt, könnte man auch einfach durch eine Wurzel erreichen. Schwierig wird es erst, wenn man einen Unterschied in der Richtung der Änderung will (also z.B. das ein hoher Friendlywert nur langsam steigt, aber schnell fällt und umgekehrt).

Die jetzige Variante hat zumindest in Ansätzen ein solches Verhalten. Das ganze ist nämlich nicht symetrisch (leider aber auch nicht antisymetrisch). Bei steigendem Vertrauen sorgen sowohl die immer größeren nötigen Zufriedenheitswerte als auch die kleineren Friendlysprünge für einen langsamer werdenden Anstieg.

Bei fallenden Werten ist das etwas anders. Zwar sorgen auch hier die bei hohem Friendlywert nötigen hohen negativen Zufriedenheitswerte dafür, dass das Vertrauen auch nur langsam wieder sinkt, und bei niedrigerem Vertrauen immer schneller. Die größe der Sprünge ist hier aber genau andersherum (bei hohem Friendly große Sprünge nach unten und umgekehrt). Dadurch fällt man also schneller von einem hohen Friendlywert runter, als man aufsteigt.

Die Frage ist natürlich, ob man das wirklich so will. (Selbst wenn, dann sollte man eine einfachere und möglichst antisymetrische Variante wählen.)

;)


Dann stimmte mein Gefühl also mit der Realität überein.

An sich ist das logisch: Eine Enttäuschung ist umso größer, je besser es vorher lief. Wenn die Bahn jedes dritte Mal ausfällt, wunderts dich nicht mehr sonderlich.

Eine einfache Wurzellösung würde z.B. aus folgendem Code

    inc(Zufriedenheit,Wert);
    while abs(Zufriedenheit)>Friendly do
    begin
      if Zufriedenheit>Friendly then
      begin
        dec(Zufriedenheit,Friendly);
        if Friendly>0 then
          Friendly:=min(100,Friendly+min(5,max(1,round(100/Friendly))))
        else
          Friendly:=1;
      end
      else if Zufriedenheit<-Friendly then
      begin
        inc(Zufriedenheit,Friendly);
        Assert(101-Friendly<>0,'Friendly hat einen Wert von 101');
        Friendly:=max(0,Friendly-min(5,max(1,round(100/(101-Friendly)))));
      end;
      if Friendly=0 then
        Zufriedenheit:=0;
    end;

etwa sowas werden lassen:

inc(Zufriedenheit,Wert);
  if Zufriedenheit > 10000 then Zufriedenheit:=10000;
  if Zufriedenheit < 0 then Zufriedenheit:=0;
  friendly:=round(sqrt(Zufriedenheit));

Die Begrenzung von Zufriedenheit auf 0-10000 könnte man sich sogar sparen, wenn man will, dass der Spieler einen friendly-Wert von 100 festigen kann (bzw. im negativen einen friendly-Wert von 0).

Das Ganze hat eventuell 2 Nachteile: Einerseits verhalten sich Vertrauensgewinn und -verlust identisch (also bei hohem Vertrauen, dauert eine Änderung lange und umgekehrt). Andererseits fehlt ein Puffer zwischen den Friendlywerten. Es kann also passieren, dass friendly ständig zwischen 50 und 51 hin- und herschwankt. Wirklich störend wird das allerdings höchstens, wenn das gerade an einem Übergang zwischen z.B. freundlich und neutral passiert.

Beides kann man abfangen - dann wird die Sache aber wieder etwas komplizierter - vor allem wenn man einen Unterschied zwischen Auf- und Abstieg macht, geht ein Teil der transparenz wieder verloren.

Sorum mag das stimmen - andersherum ergibt es aber keinen Sinn. Wenn ich der Bahn nix zutraue, dann wird sich daran auch nichts ändern, wenn mal ein Zug pünktlich fährt (vielmehr ärgert man sich dann über den Schaffner, oder was man sonst gerade findet). Wenn schon, dann ist es so, dass man Vertrauen schneller verliert, als man es gewinnt. Das ließe sich wiederum sehr einfach und halbwegs transparent realisieren.

Es gab wie schon erwähnt eine längere Diskussion darüber ob man dieses Verhalten der Funktion ändern soll oder nicht.

Wie Natter sehe ich auch ein Problem in der schweren Abschätzbarkeit dieses doch eher komplexen Ablaufes, aber die Formeln bewirken ein paar Sachen die die von Natter vorgeschlagenen direkteren Zuordnungen bisher nicht leisten können:

1.) Bei hohem Vertrauen schneller Fallen als Ansteigen und bei niedrigerem Vertrauen schneller Ansteigen als Fallen.
2.) Einen "Buffer/Dämpfer" - wenn man auf dem "Ansteigenden Ast" bei einem Land ist (d.h. Zufriedenheit hoch und immer mal wieder in ein paar Friendly-Plus umgewandelt), dann muss man eine Menge Minuspunkte kassieren bevor der erste Abzug beim Friendly einsetzt (man muss ja von Zufriedenheit>Friendly (z.B. 50) auf eine Zufriedenheit<-Friendly (dann -50) wechseln, bevor der Abzug auf den Friendly-Wert einsetzen kann.
Natürlich gilt dasselbe auch umgekehrt wenn man einmal auf schlechtem Fuß stand (was die langen Durststrecken nach dem Verlust des Vertrauens erklärt, bis das Vertrauen wieder steigt).

Gerade diese "Nachhaltigkeit", d.h. das ein vorübergehender Wechsel des Kriegsglücks weitestgehend ignoriert wird, halte ich für sehr gut - aber sie bewirkt natürlich einen großen Teil der schweren Abschätzbarkeit.

Es wäre also nett wenn hier ein paar Leute ihre Meinung posten würden, was ihnen lieber wäre. Wobei zu beachten wäre das jede Änderung natürlich immer ausgewogen bleiben muss, d.h. Vorschläge wie "Friendly muss immer stärker zunehmen als abnehmen" sind automatisch gescheitert ;-)

Naja, gerade das lässt sich aber auch problemlos mit der Wurzel realisieren. Zwar wird der Code dadurch etwas komplizierter, aber an dem Grundzusammenhang ändert sich nichts -der Spielsatzersteller kann immernoch genauso leicht abschätzen, wie vorher.

Statt friendly:=round(sqrt(Zufriedenheit));
bräuchte man dann etwas in der Art:

if friendly <= sqrt(Zufriedenheit) then
begin
  if (sqrt(Zufriedenheit)-trunc(sqrt(Zufriedenheit)) > 0.8) then
    friendly:= round(sqrt(Zufriedenheit))
  else
    friendly:= trunc(sqrt(Zufriedenheit));
end
else
  friendly:=round(sqrt(Zufriedenheit));

Dadurch wird der Aufstieg etwas verzögert (aufrunden nicht bei .5 sondern bei .8) und man hat ebenfalls einen Puffer.


Das passiert nicht, denn dann würde ja friendly erhöht, und Zuversicht verringert.

Es geht mir nicht um eine Verzögerung des Aufstieges, sondern um einen Buffer beim Wechsel von Plus- und Minuspunkten.

Wenn man weit im Anstieg ist (>66), dann bräuchte man bei den angenommenen 8 Zufriedenheit pro UFO z.B. 9 UFOs für eine +1 bei Friendly. Wenn man jetzt aufgrund stärkerer UFOs anfängt zu verlieren, dann dauert es 16 UFOs mit -8 bevor man die Zufriedenheit von den ca. +60 herunter hat auf die -67, die nötig sind um den ersten Abzug auf friendly zu erreichen.
Wenn man aber tatsächlich soviele Minuspunkte kassiert hat, dann braucht es auch eine entsprechende Menge von UFOs um wieder auf die Pluspunkte zu kommen, die den friendly-Wert nach oben verschieben.

Der Rundungsdämpfer oben reagiert aber viel schneller auf eine entsprechende Anzahl von Abschüssen oder entkommenen UFOs. Die Rundungsdifferenz in dem Beispiel oben liegt aber selbst bei den höchsten Werten in einem eher niedrigeren Bereich (bei Friendly=66 sind das etwa 40 Zufriedenheitspunkte oder 5 UFOs)

So groß ist der Buffer aber nicht. Nachdem friendly um 1 erhöht wurde, bleibt maximal eine Zufriedenheit von 7 übrig. Man braucht also maximal 1 UFO mehr für den Abstieg, als für den Aufstieg (also in deinem Beispiel 10 UFOs).

Und im Gegensatz zu der jetzigen Variante kann man meinen Code problemlos so ändern, dass der Puffer beliebig groß wird (z.B. Änderung erst, wenn sich friendly um mindestens 5 Punkte ändern würde - wäre sogar einfacher einen größeren Puffer einzubauen, da man dann auf den Umweg mit trunc verzichten könnte). Wie groß ein sinnvoller Puffer ist, darüber müsste man extra nachdenken.

Man könnte sogar einfach einen Fixen wert verwenden - also Zufriedenheit muss sich mindestens um 80 Ändern, eh was passiert (dann hätte man für jeden Wert die gleiche Pufferwirkung von 10 UFOs)

Da ja demnächst eine neue Version ansteht, und ich der Auffassung bin, dass geplante Änderungen an der Spielmechanik eigentlich so früh wie möglich umgesetzt werden sollten, will ich dieses Thema hier nochmal aufwärmen.

Es geht um die Änderung des Vertrauens der Länder. Derzeit ist das mit einer recht undurchsichtigen Funktion gelöst (siehe erster Post), wodurch ein Spielsatzersteller nicht abschätzen kann, was denn eigentlich mit dem Vertrauen passiert, wenn der Spieler z.B. 10 UFOs abschießt. Daher sollte eine einfachere Formel eingesetzt werden. Diese muss bewirken, dass das Vertrauen eines landes immer langsamer steigt, je höher das aktuelle Vertrauen bereits ist (z.B. durch eine Wurzelfunktion).

Davor gibt es aber noch einige Fragen zu klären.

1.) Sollen sich Anstieg und Fallen des Vertrauens gleich verhalten, oder unterschiedlich? Dazu ein paar kurze Erläuterungen.
a) gleiches Verhalten:
Nehmen wir an, das Vertrauen ist schon sehr hoch. Unstrittig ist, dass es in diesem Fall nur noch langsam höher steigen sollte. Gleiches Verhalten bedeutet dann, dass ein hohes Vertrauen auch nur langsam wieder sinken kann - ein hohes Vertrauen wäre also recht stabil, ein niedriges Vertrauen ließe sich dafür sehr leicht ändern.
b)unterschiedliches Verhalten:
Die erste Variante besteht in einem asymmetrischen Verhalten von Vertrauensgewinn und Vertrauensverlust. Ein hohes Vertrauen wirde also nur langsam ansteigen, aber dafür sehr schnell fallen - bei niedrigem Vertrauen wäre es genau andersherum. Asymetrisches Verhalten hat immer die Tendenz das Vertrauen in Richtung eines mittleren Wertes zu bringen (wenn der Spieler eine Zeitlang genauso viele Pluspunkte wie Minuspunkte erhält, wird sich das Vertrauen bei neutral einpendeln, egal ob es am Anfang sehr hoch, oder sehr niedrig war).
Die zweite Variante wäre, einfach zu sagen, dass man Vertrauen immer schneller verliert, als man es gewinnt. Wenn der Spieler also im Durchschnitt genauso viele Pluspunkte wie Minuspunkte erhält, wird das Vertrauen immer weiter sinken.

2.) Wie sollte der Puffer für Vertrauensänderungen beschaffen sein? Ohne Puffer könnte jede kleine Punktevergabe zu Vertrauensänderungen führen (im schlimmsten Fall mit einer entsprechenden Meldung im Spiel). Für die Umsetzung sehe ich 2 Varianten:
a)Mindestpunktzahl: Die Punkte werden sollange gesammelt bis ihr Betrag größer als eine fixe Zahl ist (z.B. 100). Wenn ein UFO-Abschuss z.B. 20 Punkte bringt, dann wären mindestens fünf Abschüsse nötig, um das Vertrauen zu erhöhen.
b) friendly-Wert: Der friendly-Wert eines Landes muss sich mindestens um einen Wert x ändern (z.B. 3). Das führt dann in der Praxis dazu, dass die benötigte Punktzahl für das überschreiten des Puffers vom aktuellen Vertrauenswert abhängt (gehen wir mal von Pluspunkten aus - dann wäre der Punkte-Buffer für niedriges Vertrauen kleiner als für hohes Vertrauen).

So, nun seid ihr gefragt ;)

1)
Der Anstieg sollte gerade bei hohen Vertrauenswerten immer nur langsam erfolgen. Alles andere führt wahrscheinlich schnell zu Balance-Problemen.
Es bleibt also nur die Frage, ob der Abstieg genauso langsam oder asymetrisch schneller geschehen sollte.

Und da ich für beides je nach Spielsatz durchaus Anwendungsgebiete sehen kann, würde ich eher vorschlagen das man das per globaler Variable umschaltbar macht. Der Default wird dann das, wofür ich mich beim GalWar entscheide.

2) globale Variable mit irgendeinem Default, das geht wohl am einfachsten (zumal wir einen festwert auch erstmal ausprobieren müssten).
Dann kann auch jeder Skripter der vom Default abweichen will das über events (Vertrauensstufe geändert) selber steuern...

Man könnte auch beide Einstellungen in einer Variablen kombinieren - der Wert gibt die Grenze an, plus oder minus schaltet das Absinken entsprechend um.

1) asymmetrisch mit geringer linearer Abweichung.
Heißt, bei 100% fällt das Vertrauen doppelt so schnell wie bei 50%, bei 0% steigt es doppelt so schnell wie bei 50%

Hätte ich jetzt gesagt, und dürfte relativ einfach zu überschauen sein.

2.) Eine Änderung findet nur einmal am Tag statt - das ist ein zeitlicher Puffer. Die einfachste Variante, die mir einfällt. (Nicht alle Änderungen einzeln, sondern in einem Nachrichtenfenster. Dann kanns einem auch nicht entgehen, wenn es im geoscape "wegflutscht", weil z.B. viele Herstellungsnachrichten kommen.)


-----

Wobei auch erst mal klar sein müsste, was das Vertrauen wie stark beeinflusst. Ein UFO-Überflug verringert, aber wie??

- procedure TOrganisationList.UFOLebt(UFO: TObject); (wird stündlich aufgerufen von TUFOList.NextHour(Sender: TObject);)
bewirkt:
# UFO älter als 900 Minuten: Zufriedenheit -3
# UFO länger als 240 Stunden über Land: Zufriedenheit -6

- procedure TOrganisationList.Abschuss(Pos: TFloatPoint; Minuten: Integer);
# je nach Zeit über Land und Zeit überhaupt Zufriedenheit+0...10 (falls Abschuss in diesem Land) bzw. Zufriedenheit+0...5 (alle anderen Länder)

- procedure TOrganisationList.PayForschMoney(const Project: TForschProject); Forschung beendet (kein Upgrade, kein AlienItem)
# Zufriedenheit +3

Hab jetzt erstmal eine Wurzelabhängigkeit umgesetzt. Dadurch ändert sich das Vertrauen im allgemeinen etwas langsamer. Die globalen Variablen kommen dann später mal, wenn das ganze etwas getestet wurde.

This is such a great resource that you are providing and you give it away for free. I love seeing blog that understand the value of providing a quality resource for free. medicare spokane

Прод256.7вовнCHAPMikhOverУглоротнPrelNatuкнопSideFighВолжкандСкипКузни�тоWinsWaltКузьфарфKING
FredDeanМиллPhilCorcShyaСтраКартум�тСилквозгHenrThomиздаDecoВороИллюСодеXVIIСмелмодеCarlпуте
ТютчКотеHPBlДор�ДанкPoulPoulSaufModoBookModoГончRobeSelaMariМард(187МезеLionКочеТарачитаИльч
СодеБро�NikiVentмолнRoxySelaVictотдеVent��ыли�тоMODOZonePhilGeorMariрегеобучКамеTraiShirЧжуа
ZoneХанзZoneZoneZoneZoneавтоZoneErleZoneZoneZoneZoneZoneZoneВдовОтечZoneZoneZoneуча�ZoneZone
ВлСоПролтлеюCMOSорнагардElecHotpMistStevрезиШомеКозл7800Этце90608902тап