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.
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.
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:
Neu:Zitat
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:
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.
@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 21:36 Uhr)
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.
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.
--
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.
Wo genau siehst du da den Fehler ...?
Das dürfte ungefähr auf das gleiche hinauslaufen, was Cornix mit "Ready-Wert = Ready-Wert - (Ready-Limit * Aktions-Dauer) / 100" vorgeschlagen hat, oder?
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?
Das geht alles irgendwo in die gleiche Richtung
Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)
--
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.
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^^.
--
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.
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?
--
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 16:31 Uhr)
Für den Code ist es mir jetzt zu spät...Die Formel "Ready-Wert = Ready-Wert - Ready-Limit - (Aktionsdauer / Tempowert)" verstehe ich aber offen gesagt auch nicht so recht.
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
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):
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.
--
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.
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.
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
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 18:02 Uhr)
Ein paar Fragen zum Verständnis:
- Wie genau sieht deine Formel im Moment aus? Bitte einmal die genaue Rechnung mit allen beteiligten Variablen, deren Bedeutung und Beispielwerten beschreiben.
- Hast du einmal alles von Hand nachgerechnet? Bekommst du ein anderes Ergebnis wenn du von Hand rechnest?
- 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?
- Hast du schon versucht dir einmal alle Werte nacheinander als Textausgabe anzeigen zu lassen? Schreib doch einmal was du dabei ausgegeben bekommst in Reihenfolge.
Ok, ich bin nun, glaube ich, durch dein Code durchgestiegen und... Naja er ist halt individuell
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
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.
Geändert von IndependentArt (26.04.2019 um 19:59 Uhr)
Berechtigungen
Zitieren
