und was wäre dieser bestimmte Wert?Zitat
das wäre vmtl. genau das was ich bereits ausprobiert hab, nur umgekehrt.
1130 und 1016 sind die Tempo-Stats von Charakter und Gegner.
Ich vergleiche am Ende nur, ob "Current CTB Slot" größer als 1837 ist, weil auf der Variablen ID 1836 der letzte zu befüllende Slot liegt.
Den bestimmst du selbst. Vielleicht 255? Weil das Max Wert ist?
Und hat es dann so funtioniert? Müsste ja logischerweise,
Da Bsp. Char hat Wert 50 und Gegner 60 -> 255-50= 205 und 255-60 ist 195. Wenn du dann runterzählst sollte Der Gegner Schneller sein, weil er den höheren Wert hat.
OK macht Sinn.
Der Überschuss ist kinderleicht in den Griff zu bekommen, in dem man Abfragt, ob der Zähler > 255 ist und im Ja-Fall dieselbe Variable auf 255 setzt.
Leider wird IndependentArt diese Antwort nicht lesen, da er mir vor Wochen mitgeteilt hat, mich ohne Angabe von Gründen und ohne eine mir bekannte Vorgeschichte auf seine Ignore-Liste zu setzen.
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
Nochmal folgende Erklärung wie es momentan funktioniert:
Charakter 1 Tempowert = 20
Gegner Tempowert = 10
Ich setze 2 andere Variablen gleich diese Tempovariablen (damit mir die Originalwerte erhalten bleiben).
Von diesen ziehe ich -1 ab, bis eine davon 0 ist. Der Gegner-Wert wäre als erstes 0, weil er kleiner ist. Wenn das passiert, wird der erste Slot mit der Zahl die für den Gegner steht bestückt (Gegner 1 = 4) und der Wert von dem abstrahiert wird, wird resettet (also wieder 10). Fällt der Charakterwert auf 0, passiert das gleiche (für Charakter 1 wird der Slot = 1 gesetzt). Da der Gegnerwert genau halb so groß ist, werden die Werte jetzt gleichzeitig auf 0 fallen. Der Charakter erhält allerdings Vorzug, weil die Abfrage im Skript über dem Gegner steht.
Hierdurch ergibt sich für die ersten 10 Slots ca. Folgendes Pattern: 4 1 4 4 1 4 4 1 44
Gibt auch schon eine Visualisierung dazu:
Was würde es mir nun nützen, eine Variable +1 zu rechnen, bis sie 255 ist? ^^ Vlt meintest du aber auch +Tempowert, wie ich es bereits gemacht habe und ich hab das falsch verstanden.
Auf jeden Fall kommt es ja auf das gleiche raus, ob ich +Tempowert rechne, bis die Variable 255 überschreitet oder -Tempowert von 255 an runter zähle.
@Ken
Ich glaube, es wurde noch nicht so recht verstanden, warum ich mir Sorgen um den Überschuss mache und ich bin auch nicht sicher, wie ich das artikulieren kann.
Mir ist klar, dass ich fragen kann ob der Zähler > 255 ist. Mir gehts aber gar nicht darum, irgendeinen Wert auf 255 runter zu bügeln. Wäre der Tempowert 50, würden die 255 ja mit 300 überschritten werden und ich könnte die Aktion einleiten.
Die Differenz von 45 würde allerdings völlig unberücksichtigt bleiben, was mich zu der Befürchtung führt, dass hier nicht genau gerechnet wird, im Gegensatz zu der Variante wo 1 subtrahiert wird und man genau auf 0 kommt.
Es müsste vielleicht irgendeine Möglichkeit geben, wie man die Statuswerte in ihr Gegenteil vekehrt. So dass die hohen Werte niedrig werden und die niedrigen Werte hoch. Aber mir ist noch nichts brauchbares dazu eingefallen.
Ich hoffe, man versteht das irgendwie.
btw: Ich hab dich mal entblockt.
Also kein Plan, ob ich das jetzt richtig verstehe, aber wenn die 6 einfach bedeutet, dass das Tempo sechs Mal aufaddiert wird, bis sie einen Wert größer oder gleich 255 erreicht, hast du bei Tempo = 50 mit der Rechnung 50+50+50+50+50+50=300 zwar als Ergebnis 300, du kannst den Wert aber in eine neue Variable speichern und davon 255 abziehen und erhälst damit den Überschuss. Die eigentliche Zielvariable, die somit ja immer noch > 255 ist, setzt du trotzdem wieder auf 255. Im ersten Additionsschritt addierst du diesen Überschuss (45) zusätzlich auf den ersten Step der Tempovariable, sodass sich ergibt: (50+45)+50+50+50+50+50=345. (Einfach zwei Variablen addieren sollte deinem Code nichts tun, denn wenn du mal genau auf 255 landest enthält die Überschussvariable dementsprechend den Wert 0). Der nächste Wert, der in die Überschussvariable eingespeichert wird, wäre 345-255 und würde im nächsten 6er-Schritt wieder auf den ersten Wert aufaddiert werden usw.
Du speicherst die Tempowerte doch in Variablen. Die multiplizierst du jeweils mit -1 und dann müsste das passen.
--Ein sehr symphatischer und überaus aktiver RPG Maker Benutzer
Geändert von Ken der Kot (02.04.2019 um 19:35 Uhr)
Ich nehme an, dass das eine Antwort auf dein Problem war:
Aus der Erklärung wird mir jetzt so langsam das Problem klar. Der Gegner hat weniger Tempowert als der Held, kommt aber öfter dran. Und jetzt möchtest du, dass das genau andersrum ist.Nochmal folgende Erklärung wie es momentan funktioniert:
Charakter 1 Tempowert = 20
Gegner Tempowert = 10
Ich setze 2 andere Variablen gleich diese Tempovariablen (damit mir die Originalwerte erhalten bleiben).
Von diesen ziehe ich -1 ab, bis eine davon 0 ist. Der Gegner-Wert wäre als erstes 0, weil er kleiner ist. Wenn das passiert, wird der erste Slot mit der Zahl die für den Gegner steht bestückt (Gegner 1 = 4) und der Wert von dem abstrahiert wird, wird resettet (also wieder 10). Fällt der Charakterwert auf 0, passiert das gleiche (für Charakter 1 wird der Slot = 1 gesetzt). Da der Gegnerwert genau halb so groß ist, werden die Werte jetzt gleichzeitig auf 0 fallen. Der Charakter erhält allerdings Vorzug, weil die Abfrage im Skript über dem Gegner steht.
Hierdurch ergibt sich für die ersten 10 Slots ca. Folgendes Pattern: 4 1 4 4 1 4 4 1 44
Gibt auch schon eine Visualisierung dazu:
Die Lösung von Hasenmann zielt genau darauf ab. Nehmen wir dein Beispiel:
Held: Tempo 20
Gegner: Tempo 10
neuer Maximalwert: 30
Jetzt addierst du die ganze Zeit 1 auf die Tempowerte, bis einer den Maximalwert erreicht.
- Das ist jetzt nach 10 Schritten der Held => Held erhält Slot in der Reihenfolge und setzt seinen Wert wieder auf 20.
- Nach 10 weiteren Schritten stehen beide auf 30 => Beide erhalten einen Slot, Held wird wieder auf 20 gesetzt, Gegner wieder auf 10
- Das Ganze beginnt von vorne
Damit bedeutet ein höherer Wert, dass man öfter dran kommt.
-------
Es gibt dabei aber ein paar Sachen, die du beachten musst:
- Kein Charakter kann einen höheren Tempowert als das festgelegte Maximum haben. Außerdem sollte niemand sehr nahe daran kommen können, sonst kann es sein, dass einer sehr, sehr oft hintereinader dran ist.
Beispiel: Maximalwert ist 300, dein Held hat Tempo 299. Jetzt kommt er in jedem +1 Schritt dran, d.h. selbst wenn der Gegner Tempo 290 hat, ist der Held 10 Mal so oft dran.
- Das Beispiel macht schon den Effekt deutlich: Der Zusammenhang zwischen unterschiedlichen Tempowerten ist nicht mehr konstant, d.h. wenn der Held den doppelten Tempowert eines Gegners hat, kommt er nicht zwangsläufig doppelt so häufig dran.
Mit dieser Methode kommt es auf den Unterschied zur Maximalgrenze an: Wenn die Differenz (Maximalwert - Heldentempo) halb so groß ist wie die Differenz (Maximalwert - Gegnertempo), dann ist der Held doppelt so oft dran.
------
Und noch eine kleine Anmerkung:
Ich behaupte, du musst dein Skript mit -1 nicht umbauen, wenn du stattdessen als Grundwerte "Maximalwert - Tempo" als Input lieferst. Probier einfach mal, deine temporäre Variable (die du ja momentan nur setzt, um den "richtigen" Tempowert nicht zu überschreiben), auf "Maximalwert - Tempo" zu setzen. Das Sollte den gewünschten Effekt erzielen.
Bei der Wahl des Maximalwertes musst du dir dann Gedanken machen, wie groß diese Spanne werden soll und wie schnell der Held seinen Tempowert steigern kann bzw. welche Items / Ausrüstung das in welchem Ausmaß tun können.
--
Geändert von Caledoriv (02.04.2019 um 19:49 Uhr)
@Caledoriv
Jop so hab ich das gemeint.
@Ken
Das mit dem "Aufgeben" ist gar kein schlechter Gedanke. Ich könnte auch einfach -255 rechnen, sobald 255 überschritten wird. Damit würde ich quasi beim "Überschuss" wieder anfangen aufzuaddieren für den nächsten Slot.
Das scheint mir im Moment am praktikabelsten zu sein. Habs auch grad schon getestet.
Caledoriv
Ich glaube, die Variante ist für stark variierende Tempowerte nicht praktikabel. Für die Tempowerte 10 u. 20 und Max. 30 funktioniert es natürlich genau so wie vorher. Ich denke aber, mein Maximalwert wird schon irgendwo um 255 liegen. So kehren sich die Tempowerte im Verhältnis zum Max. Um, damit hätte ich quasi Werte von 245 und 235, was ein 1 4 1 4 1 4 Pattern ergeben würde, weil der Unterschied zwischen den Werten quasi aufgehoben wird. ^^
Ich habe in meinem Spiel auch ein CBS, wie du es suchst. Dabei bin ich über 3 verschiedene Designs / Techniken gegangen:
Das erste ist, wie beschrieben, ein fixer Maximalwert. Dies fand ich zuerst sehr gut, aber später sind mir paar Probleme klar geworden: Relationen gab es nicht. Dies ist ein Design Problem, so ist ein sehr schneller Charakter gefühlt nicht wirklich schneller. Es fühlte sich eher an, als wären alle gleich schnell und erst in Runde 5 oder 6 agierte der schnelle Charakter bemerkbar öfters. Also müsste ein Kampf über 15 Runden mind. gehen um einen schnellen Charakter auch schnell wirken zu lassen, was ich vermeiden wollte.
Die zweite ist, ein variabler Maximalwert. Der Maximalwert ist die Summe aller Tempo-Werte. Dies funktionierte und fühlte sich schon viel besser an, doch gab dies mir kaum Kontrolle über das Balanzing, so dass schnell einige Probleme geschahen.
Die nun dritte Möglichkeit ist ein Slot / Turn - Max. Dies ist etwas schwieriger technisch. Es wird ganz normal vom Tempo -1 gerechnet, bis einer bei 0 ist, der übernimmt Slot 1 und bekommt dann wieder sein Tempo wert (addiert). Dies wird dann Bsp. 10 mal wiederholt. Nun ist es aber nicht so, dass Slot 1 anfängt, sondern der letzte Slot. Dabei hat jede Aktion seinen fixen Tempo-Wert (Verteidigen hat z.B. Tempo 300, während Angriff Tempo 100 hat) und der Abzug (also -1) ist abhängig vom Agi Wert. Ein schneller Charakter (also mit hohen Agi) ist somit schneller wieder dran.
Ich hoffe das konnte dir etwas helfen / inspirieren
Ich habe einmal ein Kampfsystem mit einem ähnlichen System entwickelt. Ich hatte damals viele detaillierte Tests durchgeführt, bis ich ein System gefunden habe, mit dem ich zufrieden war.
Mein System hat folgende Eigenschaften:
* Es ist relativ simpel zu implementieren. (das ist sehr gut)
* Ein Character mit doppelter Geschwindigkeit erhält ca. doppelt so viele Züge. (das ist eher gut)
* Die Anzahl der Züge für einen Character entspricht ca. der Prozentzahl von dessen Geschwindigkeitswerts in Bezug zu der Summe aller Geschwindigkeitswerte. (das ist eher gut)
* Es verhält sich zyklisch für genügend viele Züge. Das heist es bilden sich Muster für der Abfolge der Charactere. (kann gut oder schlecht sein, je nach Geschmack)
* Sehr langsame Charaktere kommen erst sehr sehr spät zum Zug (das ist eher schlecht)
Hier ist eine Beispielausgabe:
Hier ist ein zweites Beispiel mit Zahlen die näher bei einander liegen:
Zuletzt ein extremes Beispiel mit einhundert Zügen und sehr geringen Geschwindigkeitsunterschieden:
Hier ist der Ablauf des Algorithmus:
- Jeder Charakter hat einen Geschwindigkeitswert (ich nenne diesen Agi). Hohe Werte sind besser als niedrige.
- Im Kampf gibt es für jeden Charakter einen Ready-Wert. Also wie bereit der Charakter ist am Zug zu sein.
- Zu Beginn des Kampfes wird das Ready-Limit auf das (Maximum aller Agi-Werte) + 1 gesetzt. <- Die +1 in dieser Berechnung ist wichtig! Sie verbessert das Ergebnis erheblich!
- Der folgende Pseudo-Code bestimmt, welcher Charakter im Moment am Zug ist:
Es ist hierbei wichtig, dass entweder der Ready-Wert von allen Charakteren oder von keinem erhöht wird.
Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - Ready-Limit.
Der Ready-Wert für den aktiven Charakter wird also um das Ready-Limit reduziert.
Ich hoffe das war ausführlich genug, um das Prinzip zu verstehen.
Geändert von Cornix (04.04.2019 um 00:20 Uhr)
Danke für die weiteren Antworten.
@Cornix
Soweit ich das verstehe, ist das ziemlich genau das System wie ich es jetzt implementiert habe.
Interessant finde ich, dass du den Ready-Wert aus allen Agi-Werten errechnest. Das ist vermutlich ökonomischer und letztlich wohl auch gerechter. Deshalb werd ich es wohl übernehmen.
Apropos gerecht, ich frage mich gerade noch, was die Reihenfolge der Abfragen für einen Einfluss auf die Züge hat.
Momentan sieht meine Abfragen-Struktur für 6 Teilnehmer so aus:
Charakter 1
Gegner 1
Charakter 2
Gegner 2
Charakter 3
Gegner 3
Damit haben die oberen evtl in einigen Situationen eine starke Priorität, weil sie immer als erstes abgefragt werden. Zumindest sieht es mir danach aus, ich kann die Konsquenzen nicht völlig abschätzen.
Zum Gegensteuern schwebt mir vor, jeder Abfrage ein Label vorzuschieben. Eine Variable zählt dann immer von 1-6 und lässt das Skript damit zum jeweiligen Label springen, was das ganz wohl etwas ausgeglichener machen dürfte.
Ich würde das konsistent halten und nicht Helden und Gegner abwechseln. D.h. entweder alle Helden zuerst oder alle Gegner zuerst. Im Extremfall wirkt es dann für den Spieler zufällig, wer in welcher Reihenfolge dran kommt.
Aber die Reihenfolge der Abfrage sollte sowieso nur dann etwas ändern, wenn zwei Kämpfer den gleichen Tempowert angesammelt haben. Soll heißen, die Abfrage ist im Idealfall noch etwas komplexer:
Beispiel 1:
Grenzwert ist 300
Tempo Held: 20
Tempo Gegner: 15
Momentaner Wert Held: 290
Momentaner Wert Gegner: 295
Nach dem nächsten Schritt hätten beide einen Wert von 310. Nur in diesem Fall sollte die Reihenfolge der Abfrage einen Unterschied machen.
Beispiel 2:
Grenzwert ist 300
Tempo Held: 20
Tempo Gegner: 15
Momentaner Wert Held: 290
Momentaner Wert Gegner: 290
Nach dem nächsten Schritt überschreiten beide den Grenzwert: Der Held hat 310 und der Gegner hat 305. In dem Fall wäre es in meinen Augen ideal, wenn der Held den ersten Slot bekommt und der Gegner den zweiten, obwohl beide in derselben Iteration den Grenzwert überschritten haben.
--
@Caledoriv
Ich hab mal mit verschiedenen Abfragemethoden herumprobiert und alle haben mir zumindest für meine Werte die exakt gleichen Ergebnisse gebracht. Es scheint also, als macht das nur einen marginalen Unterschied.
---
Ich habe indessen die Basisvariante implementiert, welchen sehr zuverlässig die Reihenfolge ermittelt.
Jetzt hantiere ich gerade mit Dingen herum, die doch etwas komplizierter sind als erwartet: Flexible "Zugzeit" und Preview. Damit meine ich einfach, dass natürlich unterschiedliche Aktionen unterschiedlich lang dauern sollen. Ich will jetzt nicht auf die spefizischen Probleme eingehen, auf die ich dabei gerade stoße, weil ich im Moment schon noch davon ausgehe, die selbst lösen zu können.
Ich bin dabei jedoch auf eine Design-Frage gestoßen: Angenommen ich wähle für meinen gegenwärtigen Zug eine Aktion, welche die doppelte Zeit benötigt. Sollte der gleiche Zug auch für alle folgenden berechneten Züge angenommen werden oder wird für die ein Zug mit normaler Geschwindigkeit angenommen?
Angenommen die Basisdauer ist 100 und eine spezielle Aktion dauert 200.
Dann würde für die Folgezüge eins dieser Muster herauskommen:
200 100 100 100 100 100 100 (für den 2. Zug zurück zur Basisberechnung)
200 200 200 200 200 200 200 (spezielle Berechnung beibehalten)
Aus meiner Sicht ist es ziemlich naheliegend, die erste Variante zu wählen, so baue ich es auch gerade. Aber vielleicht habt ihr ja noch andere Gedanken dazu.
Berechtigungen
Zitieren
