Seite 2 von 2 ErsteErste 12
Ergebnis 21 bis 36 von 36

Thema: ATB -> CTB

  1. #21
    Danke. ^^ Der Gegner ist nur nicht für den HG gedacht, deswegen kollidiert er ein wenig mit dem Haus.

    Vielleicht kann ich hier auch ne kleine Techdemo von dem System reinstellen. Ich hab auf jeden Fall jetzt mehr Zeit, daran zu arbeiten.

  2. #22
    Falls du immernoch mit deinem Algorithmus etwas ähnliches implementierst, wie das was ich beschrieben hatte, dann müsstest du eine "Aktions-Dauer" beim abziehen des Ready-Werts implementieren. Also diese Zeile von meinem Algorithmus würde sie ändern:

    Alt:
    Zitat Zitat
    Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - Ready-Limit
    Neu:
    Zitat Zitat
    Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer)
    Eine Aktion könnte also eine Dauer von 2,0 haben und würde dann doppelt so lange dauern wie eine Aktion mit einer Dauer von 1,0.

    Falls du keine Kommazahlen zur Verfügung hast kannst du eine simple Prozentrechnung durch eine Teilung durch 100 nach der Multiplikation erreichen. Also:
    Zitat Zitat
    Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100
    Hierbei wäre die Aktions-Dauer ein Prozentwert, also 100 für 100%, 175 für 175%, etc.

    Vielleicht hilft dir das ja in irgendeiner Weise weiter.

  3. #23
    @Cornix

    Von der Seite könnte man das natürlich auch angehen. Muss ich mal ausprobieren. u.U. droppt der Wert dann halt zeitweise ins Minus.
    Bis jetzt hab ich quasi versucht, die Prozentrechnung auf den Wert, der immer hinzugefügt wird (quasi den Tempowert) anzuwenden. Bin mir nicht sicher, was das für nen Unterschied macht.
    edit: das scheint mir zum genau gleichen Ergebnis zu führen. ich schreib morgen nochmal, womit ich momentan etwas hadere.

    Geändert von IndependentArt (10.04.2019 um 22:36 Uhr)

  4. #24
    Ich habe das Gefühl, es wird langsam. Trotzdem gehen dem Skript noch nicht die Ideen für neue Bugs aus.
    Ich versuche mal mein gegenwärtiges Problem mit Hilfe dieses Videos zu erörtern:



    Ich verlange nicht, dass da jemand durchsieht. Vielleicht hilft es mir ja auch schon, das einfach aufzuschreiben.
    Die Aktion Zauber hat in diesem Beispiel eine Geschwindigkeit von 20% (vom Tempowert, bei Tempowert 10 also 2). Man könnte auch sagen, sie ist 80% langsamer als der normale Angriff. Dementsprechend viele Züge bekommt der Gegner, wenn ich sie auswähle. (ich benutze dann nur Abwehr, weil das als Aktion keine wirkliche Dauer hat)
    Verfolgt man das Video weiter, sieht man, dass der Hase 2 Mal dran ist. Nach dem 2. Zug, verändert sich jedoch die Reihenfolge (etwa bei Sekunde 9, Tipp: mit , und . kann man Frames springen ). Das hat damit zu tun, dass die "Aktionsdauer" zurückgesetzt wird. Das heißt, ab da werden die nächsten Züge nicht mehr mit 20%, spondern wieder mit 100% berechnet und der Charakter ist schneller dran als ursprünglich gedacht. Das hat damit zu tun, was ich weiter oben beschrieben habe, dass die veränderte Aktionsdauer nur für den nächsten Zug angenommen wird und die Züge danach wieder mit 100% berechnet werden.

    Nun könnte man auf die Idee kommen zu sagen: "Na dann lass die Zugdauer halt bis zum nächsten Zug des Charakters gleich".
    Das war auch mein erster Impuls, aber ich habe den Eindruck, wenn ich mit 20% NEU berechne, funktioniert das auch nicht wirklich. Vielleicht hab ich da aber auch nur irgendnen Fehler drin, den ich grad noch nicht checke.

  5. #25
    Was wäre denn das gewünschte Verhalten? Irgendwie stehe ich hier öfter auf dem Schlauch...
    Soll der Hase bei dem niedrigen Tempowert des Helden 4x hintereinander dran kommen? In dem Fall sollte der Tempo-Modifikator erst mit dem nächsten Zug des Charakters geändert werden.

    Als kleine Anmerkung: Die Berechnung zeigt hier teilweise falsche Prognosen an; es wird angezeigt: Hase Hase Hase Hase Hase Ramirez Hase Hase Hase Hase Hase Ramirez ....
    Der unterstrichene Teil ist da ja noch korrekt, aber danach stimmt es nicht mehr.

    ----
    Was hälst du davon, jedem Zauber einfach einen (ggf. vom Tempowert abhängigen) Malus zu geben, der einmalig abgezogen wird? Dann sollte die Berechnung immer korrekt angezeigt werden.

  6. #26
    Zitat Zitat
    Soll der Hase bei dem niedrigen Tempowert des Helden 4x hintereinander dran kommen? In dem Fall sollte der Tempo-Modifikator erst mit dem nächsten Zug des Charakters geändert werden.
    Ja, so soll das eigentlich laufen. Den Tempo-Modifikator erst mit dem nächsten Zug zu ändern hab ich wie gesagt versucht, aber vlt hab ich da auch nen Fehler reingebaut.

    Zitat Zitat
    Hase Hase Hase Hase Hase Ramirez Hase Hase Hase Hase Hase Ramirez ....
    Der unterstrichene Teil ist da ja noch korrekt, aber danach stimmt es nicht mehr.
    Wo genau siehst du da den Fehler ...?

    Zitat Zitat
    Was hälst du davon, jedem Zauber einfach einen (ggf. vom Tempowert abhängigen) Malus zu geben, der einmalig abgezogen wird? Dann sollte die Berechnung immer korrekt angezeigt werden.
    Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?

  7. #27
    Zitat Zitat von IndependentArt Beitrag anzeigen
    Wo genau siehst du da den Fehler ...?
    Angezeigt wird: 4x Gegner, Held, 4x Gegner
    Aber die tatsächliche Reihenfolge ist doch eher: 4x Gegner, Held, 1x Gegner, Held
    Weil der Held ja erstmal wieder sein "normales Tempo" zurückbekommt, wenn er das erste Mal wieder dran ist, oder?

    Zitat Zitat von IndependentArt Beitrag anzeigen
    Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?
    Das geht alles irgendwo in die gleiche Richtung . Ich dachte eher an:
    Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)

  8. #28
    Puh, dieses Skript fuckt mich mehr ab, als ich gedacht hätte. Deswegen will ich mein Hauptproblem nochmal mit Hilfe eines Videos illustrieren.

    Bedingungen:
    Charakter Tempo: 20
    Gegner Tempo: 20
    ReadyWert: 41

    Ich habe im Video das jeweilige Durchzählen beim Charakter mit einer Message Box visualisiert (nicht für das Preview allerdings).
    Außerdem läuft die Formel jetzt wieder mit einem "Malus", wie es Caledoriv nannte. Die Aktion Zauber hat eine Aktionsdauer von 500. Es wird also der ReadyWert*5 abgezogen. Bei 00:27 sieht man dann, dass das erfolgreich erledigt wurde und der aktuelle Wert des Charakters bei -194 liegt.
    In der Folge bekommt der Gegner ganze 6 Slots, bevor der Charakter wieder einen bekommt.

    Jetzt kommt allerdings das Problem: Der Charakter-Wert hat schon in dieser ersten Runde wieder aus dem Minus "herausgefunden" und einen normalen Wert erreicht. Deshalb wird er in der Berechnung, die ab ca. 00:50 stattfindet, wieder weiter vorn eingegliedert.
    Vielleicht hab ich ja mal wieder ein Brett vorm Kopf und die Lösung dafür ist relativ offensichtlich.


  9. #29
    Kann es sein, dass du irgendwo den Wert auf 0 setzt? Weil im Video nach dem Hasenangriff bei 0:47 wieder 0 eingeblendet wird.

    Alternativ kann es auch sein, dass es einen Bug gibt, wenn der Wert genau 0 erreicht, sobald das Ready-Limit abgezogen wird. Wenn ich mich nicht irre, passiert das an genau der Stelle nämlich auch. Das kann Zufall sein oder auch nicht^^.

  10. #30
    Dass der Wert dort auf 0 droppt ist Zufall. Der letzte Wert davor, der für den Charakter errechnet wurde, war 21. als nächstes wird also 21+20-41 gerechnet und es kommt genau auf 0.
    Das Problem ist halt, dass die Aktionsdauer angewendet wird, aber für den nächsten Rechendurchgang schon wieder aufgehoben ist.
    Ich hab zwar ein paar Ideen, wie man das lösen könnte, aber die erscheinen mir im Moment furchtbar kompliziert.
    zB könnte man versuchen, dass von der Aktionsdauer bei jedem Rechendurchgang maximal 100%=1 Zug=ReadyWert abgezogen wird. Das heißt, bei der ersten Berechnung nachdem man den 500% Zug ausgeführt hat, werden auch die 500% abgezogen. Gleichzeitig wird allerdings die Aktionsdauer selbst um 100% erleichtert. Danach werden also dann 400% abgezogen, dann 300% usw., bis der Charakter wieder dran ist und eine neue Aktionsdauer festlegen kann.

  11. #31
    Zitat Zitat von IndependentArt Beitrag anzeigen
    Das Problem ist halt, dass die Aktionsdauer angewendet wird, aber für den nächsten Rechendurchgang schon wieder aufgehoben ist.
    Ganz doofe Frage von meiner Seite: Warum wird da überhaupt etwas aufgehoben?

    Das sollte eigentlich auch so funktionieren. Genau das ist ja das Elegante an der Idee, einfach die Dauer als zusätzlichen Malus draufzurechnen .
    Beim Erreichen des Ready-Limits wird neben dem Ready-Limit zusätzlich noch die Dauer der Aktion abgezogen. Mehr muss dann eigentlich nicht gemacht werden, weil die Berechnung der Züge wie gehabt weitergehen kann... Die Verzögerung entsteht dann durch diesen Malus, d.h. es dauert länger, bis der Ready-Wert erreicht ist, weil zuerst dieser Malus "abgearbeitet"

    Oder übersehe ich da etwas?

  12. #32
    Ich bin zwar glaub ich einen Schritt weiter, aber es spackt immer noch rum. Wenigstens mit einem bestimmten Wert für die Aktionsdauer hat es funktioniert.
    Noch ein Video mit einer Aktionsdauer von 200 (Rechnung siehe unten) für Zauber:


    Man sieht, dass ein Zug des Gegners zwischendrin geschluckt wird.

    Evtl übersiehst du bei dem Malus tatsächlich etwas. Ich versuche mal zu erklären warum:
    Ich habe das momentan so geregelt, dass ich die Aktionsdauer auf 2 Variablen festlege (1848, 1849). 2 Variablen, weil ich eine davon für das Preview brauche.
    Preview Codeblock:


    Der erste Teil ist quasi die Malus-Rechnung. Wenn eine Aktionsdauer festgelegt wurde, diese also größer als 0 ist, wird die Rechnung durchgeführt. Für eine StandardAktion nehme ich aus gewissen Gründen eine Aktionsdauer von 0 an. Die Rechnung wird also nur ausgeführt, wenn die Dauer drüber liegt.
    Der Malus wird errechnet und vom Preview-Wert abgezogen. Außerdem wird die Aktionsdauer 0 gesetzt, weil das ganze nur 1 Mal durchgeführt werden soll. Ich glaube, das funktioniert auch soweit ganz gut. Wenn ich zB einen Aktionswert von 100 festlege, bekommt der Gegner genau einen Zug mehr.
    Ich bin nicht sicher, in wie weit das mit eurem Ansatz überein stimmt. Ich fand es wichtig, dass der Malus vor der sonstigen Rechnung abgezogen wird. Passiert das erst danach, könnte ja zwischendrin schon ein Zug berechnet und ein Slot gefüllt worden sein.

    Code der eigentlichen Berechnung des Malus nach dem Zug:
    Der Block befindet sich direkt am Anfang des Gesamtcodes. Dadurch war es einfacher, ihn nur 1 mal durchlaufen zu lassen. Eigentlich ist fast alles gleich wie bei dem für das Preview. Der Hauptunterschied ist, dass V1848 nicht 0 gesetzt wird, sondern 100 abgezogen wird, weil die Variable ja mehrere Züge, jeweils unter Abzug eines Zuges (-100%) in Benutzung ist.

    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

    Gesamtcode:

    Geändert von IndependentArt (17.04.2019 um 17:31 Uhr)

  13. #33
    Zitat Zitat von IndependentArt Beitrag anzeigen
    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):
    Zitat Zitat von Beispiel 1: Ohne Tempowert
    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.
    Zitat Zitat von Beispiel 2: Mit Tempowert
    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.

  14. #34
    Zitat Zitat
    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.

  15. #35
    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.

  16. #36
    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

    Geändert von IndependentArt (17.04.2019 um 19:02 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •