ATB -> CTB

[Caledoriv]

Die Formel "Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)" verstehe ich aber offen gesagt auch nicht so recht. Kann es sein, dass da ein falsches Zeichen drin ist?

btw: Irgendwelche Tipps, wie man bei sowas besser den Überblick behält? Ich hab das Gefühl, das ist einfach zu viel für mein gehirn. xD

...

Für den Code ist es mir jetzt zu spät...

Zur Formel:
Die Idee dazu ist folgende: Wende die Formel an, soabld der Ready-Wert überschritten ist. Hier mal zwei Beispiele (das erste ohne Tempowert, um es einfach zu halten):

Ready-Wert = Ready-Wert - Ready-Limit - Aktionsdauer
Ready-Limit = 300
Ready-Wert nach dem neuen Update: 320
Tempo des Helden: 40

Schritt 1: Ziehe Ready-Limit ab, damit ganz normal die Reihenfolge berechnet werden kann.
Neuer Ready-Wert: 320 - 300 = 20

Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 100. Ziehe diesen Wert ebenfalls vom Ready-Wert ab:
Neuer Ready-Wert: 20 - 100 = -80

Berechne jetzt ganz normal die Reihenfolge, indem in jeder Iteration der Tempowert auf den Ready-Wert draufgerechnet wird. Der Held braucht ca. 3 Runden, bis er diesen zusätzlichen Malus aufgeholt hat, sodass der Gegner früher wieder dran kommt.

...

Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)
Das hier macht genau das Gleiche wie oben, allerdings ist die Aktionsdauer (und damit der Malus) jetzt nicht immer konstant, sondern hängt vom Tempowert des Helden ab. D.h. wenn der Held ein höheres Tempo hat, hat er auch einen niedrigeren Malus. (Allerdings muss hier die Aktionsdauer wesentlich höher sein als oben!)

Ready-Limit = 300
Ready-Wert nach dem neuen Update: 320
Tempo des Helden: 40

Schritt 1: Ziehe Ready-Limit ab, damit ganz normal die Reihenfolge berechnet werden kann.
Neuer Ready-Wert: 320 - 300 = 20

Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 4000, d.h. der Bruch (Aktionsdauer / Tempowert) hat einen Wert von 4000/40 = 100. Ziehe diesen Wert vom Ready-Wert ab.
Neuer Ready-Wert: 20 - 100 = -80

-----
Der Held levelt auf und hat jetzt Tempo 50 (statt 40). In Schritt 2 ändert sich damit die Rechnung:
Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 4000, d.h. der Bruch (Aktionsdauer / Tempowert) hat einen Wert von 4000/50 = 80. Ziehe diesen Wert vom Ready-Wert ab.
Neuer Ready-Wert: 20 - 80 = -60

...

Die Idee dahinter ist quasi, dass der Malus sich mit der Zeit verringert, d.h. der Held kann die Aktion über die Zeit schneller ausführen. Da müsste aber wohl noch etwas bei der Berechnung nachjustiert werden, weil der Effekt marginal ist...


Tipps:
Du kannst dir das ggf. mit einem Diagramm bzw. Automaten veranschaulichen:
https://de.wikipedia.org/wiki/Zustandsdiagramm_(UML)
https://de.wikipedia.org/wiki/Determ...licher_Automat
Der ganze mathematische Hintergrund kann ignoriert werden... Scroll einfach zu den Bildern und lies die Überschiften dazu . Diese Dinger sind zwar nicht genau das, was du möchtest, gehen aber in die richtige Richtung.

Genau geht es mit einem Aktivitäsdiagramm, weil du damit den Code quasi "grafisch" vor dir hast:
https://de.wikipedia.org/wiki/Aktivit%C3%A4tsdiagramm
Ich fand es aber am Anfang relativ schwer, mir sowas aufzumalen. Ggf. reichen ein paar einfache Kreise mit ein paar Pfeilen wie oben ja auch schon aus, um den Überblick nicht zu verlieren.

[IndependentArt]

Ready-Wert = Ready-Wert - Ready-Limit - Aktionsdauer
Ready-Limit = 300
Ready-Wert nach dem neuen Update: 320
Tempo des Helden: 40

Schritt 1: Ziehe Ready-Limit ab, damit ganz normal die Reihenfolge berechnet werden kann.
Neuer Ready-Wert: 320 - 300 = 20

Schritt 2: Aktion wählen. Die Aktion hat eine Dauer von 100. Ziehe diesen Wert ebenfalls vom Ready-Wert ab:
Neuer Ready-Wert: 20 - 100 = -80

Berechne jetzt ganz normal die Reihenfolge, indem in jeder Iteration der Tempowert auf den Ready-Wert draufgerechnet wird. Der Held braucht ca. 3 Runden, bis er diesen zusätzlichen Malus aufgeholt hat, sodass der Gegner früher wieder dran kommt.

...

Ich denke, das ist im großen und ganzen das, was ich versucht habe einzubauen. Wir müssen nur ein bisschen aufpassen, dass wir mit den Namen für die Werte nicht durcheinander kommen.
Deine Bezeichnungen dürften bei mir so heißen:
Ready-Limit = CTB Ready
Ready-Wert = R-CTB Order (Preview)
Ich bin nicht sicher, ob du das bedacht hast: Wenn erst im Schritt 2 die Aktionsdauer abgezogen wird, wurde ja vorher mit Erreichen des Ready-Limits schon ein Zug berechnet. Vielleicht hängt das aber auch von der Reihenfolge des ganzen Ablaufs ab.
Außerdem: Bei mir wird die Aktionsdauer prozentual auf das Ready-Limit bezogen. Bei Ready-Limit 300 und Aktionsdauer von 100 (%) wäre das also -300. Eine feste Aktionsdauer von 100 wäre ja bei sich veränderndem Ready-Limit etwas schwierig, aber das hast du vmtl. Auch nicht so vorgesehen.
Außerdem muss man da auch wieder unterscheiden zwischen Preview und eigentlicher Berechnung (wie ich es oben getan habe):
Preview:
Hier kann natürlich bequem einfach die komplette Aktionsdauer abgezogen werden. Ich setze wie oben beschrieben anach die Aktionsdauer 0, damit das nur 1 Mal geschieht. Damit also die nächsten Züge wieder mit normaler Dauer berechnet werden.

Eigentliche Berechnung:
Angenommen nach dem Zug des Charakters hat der Gegner 3 Züge, weil die Aktion so lang dauert. Für den ersten Zug ist die Rechnung im Prinzip genau so wie beim Preview: die volle Aktionsdauer wird abgezogen. Nach dem ersten Zug des Gegners wird alles wieder neu berechnet. Die Aktionsdauer muss also sozusagen um 1 Zug verringert werden, so wie oben beschrieben.

Ich hoffe, wir verstehen uns irgendwie. ^^
Danke auch für die Links, mal sehen, ob ich damit was anfanen kann.

[Ken der Kot]

Puh, langsam wird das schwierig zu durchschauen. Ich meld mich, sobald ich der Meinung bin, dass ich da noch halbwegs gut genug durchblicke, um dazu was sagen zu können. Aber wär's nicht Stand Jetzt deutlich einfacher, wenn du jemanden bittest, dir ein C-Programm zu schreiben, das sich so verhält wie du es gerne hättest? Ich meine, es ist sehr löblich, dass du das komplette KS über Events realisieren willst, aber bei einem so großen Projekt ist das vom Arbeitsaufwand doch unverhältnismäßig? Frag mal Brei -- der Kerl, der zur Zeit die Spielanalysen streamt. Der scheint von Dyn-Programmen sehr viel Ahnung zu haben. Vielleicht sind das mit C nur ein paar Zeilen Code, während das bei Events echt ausufernd wird. Nur mal so als kleinen Gedankenanstoß, falls du partout nicht weiterkommen solltest.

[IndependentArt]

Ich denke, ich hab jetzt ne relativ genaue Vorstellung, wo das Problem liegt. Ich versuche das mal in aller kürze darzulegen:
Das Preview fängt ja immer beim gleichen Wert an und rechnet dann alle Slots bis zum Schluss aus.

Angenommen, es werden nach dem Zug des Charakters 3 Züge für den Gegner berechnet, siehe hier:

Die fixe Berechnung (also nicht das Preview) findet nach den Zügen statt. Direkt nachdem der Charakter seinen Zug beendet hat, ist die Berechnung noch synchron mit dem Preview.
Der 2. Durchgang der fixen Berechnung findet nach dem Gegnerzug statt und es wird ein Zug des Charakters weiter vorn berechnet oder anders gesagt: ein Zug des Gegners fällt weg. Warum?

Ganz einfach: Beim 2. Durchgang sind die Ausgangswerte anders. Nachdem die Berechnung 1 Mal durchgeführt wurde (und alle Slots bis nach hinten gefüllt wurden), bleibt der aktuelle Wert ja irgendwo stehen. Und dieses irgendwo unterscheidet sich vom Startpunkt der Preview-Berechnung, so dass bei der nächsten fixen Berechnung etwas anderes rauskommen muss. edit: Außerdem könnte es auch problematisch sein, dass zwischendrin die Abfragepriorität der Teilnehmer irgendwie wechselt (ich fürchte, das hat sogar noch nen größeren Einfluss als die veränderte Startposition).

Eigentlich relativ logisch, ich bin nur noch nicht sicher, wie ich das löse.

@Ken

Das einzige, was hier zu beschränkt ist, ist die Rechenleistung meines Gehirns. ^^
Eigentlich ist der Code ja nicht besonders lang, nur etwas komplex/kompliziert.
Davon abgesehen benutze ich kein DynRPG mehr, sondern easyrpg (mit interierten DynPlugins). Sicher könnte man da auch irgendwas eigenes schreiben, aber ich sehe da nicht wirklich einen Grund dazu bzw. muss ich es ggf. Ja auch selbst noch modifizieren können.
Aber trotzdem danke, dass du noch versuchst mitzudenken.

[Cornix]

Ein paar Fragen zum Verständnis:

1. Wie genau sieht deine Formel im Moment aus? Bitte einmal die genaue Rechnung mit allen beteiligten Variablen, deren Bedeutung und Beispielwerten beschreiben.
2. Hast du einmal alles von Hand nachgerechnet? Bekommst du ein anderes Ergebnis wenn du von Hand rechnest?
3. Verstehe ich es richtig, dass du die Werte zweimal ausrechnest; einmal für die Zugberechnung und einmal nur für das UI? Wenn ja: warum?
4. Hast du schon versucht dir einmal alle Werte nacheinander als Textausgabe anzeigen zu lassen? Schreib doch einmal was du dabei ausgegeben bekommst in Reihenfolge.

[maniglo93]

Ok, ich bin nun, glaube ich, durch dein Code durchgestiegen und... Naja er ist halt individuell meine codes sind vermutlich genauso kompliziert, deswegen nimm mein Rat mit etwas Salz

Du solltest den Code mehr nach Funktion trennen um einen besseren Überblick zu bekommen. Aktuell ist, so wie es für mich aussieht, jede Funktion in einander vermischt, wodurch es schwer ist Fehler / Bugs unabhängig zu betrachten.

Letztendlich brauchst du 3 Funktionen (mal Graphische Implementation ausgeschlossen) :
-Sortierung
-Berechnung Reihenfolge
-Berechnung Individueller Aktionsdauer

Eine Preview Rechnung brauchst du nicht zwangsläufig (kommt drauf an wie genau du diese später haben möchtest, führe ich unten weiter aus). Denn letztendlich ist die Preview-Rechnung = Aktuelle Rechnung. Dies zu splitten, wie du es gemacht hast, führt zu zwei Funktionen und somit zwei potentielle Fehlerquellen. Als erstes würde ich dir empfehlen, schon bei der Auswahl der Aktion die normal Rechnung auszuführen und diese anzeigen zu lassen. Vielleicht behebt sich da schon dein Fehler. Dann würde ich ein Check machen, wann die Reihenfolge neu berechnet werden soll. Also wenn die Reihen folge ist R - G - G - G - R, dann ist ja schon klar, dass der G 3x an der Reihe ist, weshalb dann neu die Reihenfolge berechnen?

Wenn dein Ziel ist, dass die Gegner auch schnellere bzw langsamere Aktionen durchführen kann, dann wirst es kompliziert für dich und du solltest jetzt schon dein System darum planen, denn aus dem Standpunkt des Designs bringt mir die Info, dass der Gegner 3x dran ist nur dann was, wenn er wirklich 3x dran ist und nicht nur 2x weil er bei der 2ten Aktion ein sehr langen Zauber macht. Dann muss das Preview schon die Auswirkung von Tempo Veränderung der zukünftigen Zauber einbrechnen und das wird mit den Events knifflig. Besonders wenn es Buffs gibt, die das Tempo erhöhen. Und lass uns gar nicht über Chancen reden (50% Chance den Gegner zu verlangsamen). Ein Preview ist nur dann sinnvoll, wenn es so genau wie möglich ist.

Deswegen mein Rat: Glieder deinen Code mehr um vielleicht überflüssige Funktionen herausziehen und Probleme genauer zu identifiziert.

Ich hoffe ich konnte dir helfen

Cheers
Maniglo

[IndependentArt]

Danke für die Antworten. Ich muss mir das nochmal in Ruhe durch den Kopf gehen lassen und melde mich dann die Tage wieder.

@Cornix: Nur zur Sicherheit: Ist meine letzte Mail angekommen? ^^ Ist jetzt erstmal kurz aufgeschoben, aber es erscheint mir am sinnvollsten, wenn man das mal per Bildschirmübertragung durchgeht, im Gegensatz dazu, dass man es immer versucht zu verschriftlichen.