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.
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.
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.
Ja, die Reihenfolge der Abfrage macht nur einen Unterschied, wenn mehrere Kämpfer gleichzeitig die Grenze überschreiten.
@ Zugdauer:
Mehr Infos bitte^^. Im Moment habe ich den Eindruck, dass sich beim Wählen dieser "langen" Aktion die Zugreihenfolge ändern kann und dementsprechend an dieser Stelle neu berechnet werden müsste? Ist das so oder habe ich das falsch verstanden?
Generell hatte ich eine Zugdauer bisher nicht auf dem Schirm; ich bin bisher davon ausgegangen, dass Aktionen keine Dauer haben und dementsprechend nur der Tempowert die Reihenfolge bestimmt. Falls dem nicht so ist, würde ich die Aktionsdauer für den Standardangriff als Referenzwert nehmen.
-----
Ich bin gerade so überrascht, weil eine sich ändernde Reihenfolge für mich als Spieler ersteinmal komisch wirkt und mir im schlechtesten Fall meine Strategie versaut, weil mein Held auf einmal nicht mehr wie angezeigt an die Reihe kommt. Wenn man die Reihenfolge nicht so hunderprozentig genau sieht (wie z.B. in Mondschein), sind solche Änderungen kein Problem.
Aber wenn ich als Spieler alles schon mehrere Züge vorausplanen kann und für mich die neue Zugreihenfolge nicht ersichtlich ist, macht das u.U. keinen guten Eindruck.
Daher würde ich in dem Fall unbedingt eine Anzeige einbauen, wie sich die Zugreihenfolge mit dieser Aktion verändert! Dann kann ich als Spieler immer noch genau so vorausplanen und erlebe keine "bösen" Überraschungen. Außerdem ist das ein cooler Effekt für Dinge, welche das Tempo erhöhen / erniedrigen.
Hi,
sorry für die späte Antwort, war etwas beschäftigt.
Ich hab nun festgestellt, dass ich die Abfragereihenfolge doch durchzählen muss. Ich hatte einen Fall mit 2 Kampfteilnehmern und es kam immer nur der Charaktere an die Reihe. Das Durchzählen der Abfragen konnte das fixen.
Zitat
@ Zugdauer:
Mehr Infos bitte^^. Im Moment habe ich den Eindruck, dass sich beim Wählen dieser "langen" Aktion die Zugreihenfolge ändern kann und dementsprechend an dieser Stelle neu berechnet werden müsste? Ist das so oder habe ich das falsch verstanden?
...
Exakt.
Ich kenne ehrlich gesagt nur 2 Spiele mit diesem System und beide haben unterschiedliche Zugdauer für bestimmte Aktionen.
Zitat
Daher würde ich in dem Fall unbedingt eine Anzeige einbauen, wie sich die Zugreihenfolge mit dieser Aktion verändert! Dann kann ich als Spieler immer noch genau so vorausplanen und erlebe keine "bösen" Überraschungen. Außerdem ist das ein cooler Effekt für Dinge, welche das Tempo erhöhen / erniedrigen.
...
Ich denke, das ist ja auch genau das, was ich mit dem Preview bezwecken will, sofern wir da nicht aneinander vorbei reden.
Ich hab mal ein Beispiel:
Ich experimentiere gerade mit Prozentwerten herum:
Die Aktion Angriff läuft bei diesem Beispiel auf 100% des Tempowerts.
Zauber hingegen läuft auf 500%.
Die Tempowerte beider Teilnehmer sind 11. Damit ergibt sich ein Ready-Wert von 22+1.
Ich hätte bei 500% glaube ich mit einem etwas größeren Unterschied gerechnet, sprich, dass Ramirez noch mehr Züge bekommt. Aber ich denke, das liegt am Wechsel der Abfragenreihenfolge und an der Formel des Ready-Werts.
Gleich mal ausprobieren ... YO, frage ich eine feste Größe wie 255 als ab, sieht die Verteilung für "Zauber" schon anders aus:
edit: stimmt nicht, war mein Fehler. auch mit einem festen ready Wert von 255 kommt genau das gleiche raus.
Die 500% sind natürlich ein unrealistisches Beispiel. Ich denke nicht, dass die Zuglänge großartig über Unterschiede zwischen 50-200% hinaus geht, aber es verdeutlicht, worauf man achten muss, je nachdem, in welche Richtung man das Syteam tweaken will. Das muss ich mir jetzt eben genau überlegen.
Moment; das mit den Prozentwerten erscheint mir nicht schlüssig... sofern ich das richtig verstehe.
Beispiel:
Mein Startheld lernt auf Level 5 gerade seinen ersten Zauber. Der Zauber dauert 200% des Tempos. Der Tempowert auf dem niedrigen Level ist 15. Ergo: Die Aktion dauert 30 Einheiten.
Jetzt spiele ich weiter. Mein Held wird Level 35 und hat jetzt Tempowert 50. Derselbe Zauber dauert jetzt nach dieser Logik 100 Einheiten (anstatt wie auf dem niedrigen Level nur 30).
=> Habe ich das so richtig verstanden? Das erscheint mir nicht sinnvoll zu sein, wenn dem wirklich so ist. Als Alternative werfe ich mal das hier ein:
(Dauer des Standardangriffs) * (Modifikator der Aktion)
------------------------------------------------------------------------------ = Dauer der Aktion
...................... Tempowert des Charakters
@ Reihenfolgeanzeige:
In den Bildern wird also die Reihenfolge bei Ausführen dieser Aktion angezeigt? D.h. wenn ich Pfeil hoch / runter drücke, wird sofort die Reihenfolge geupdated? Wenn das so ist, finde ich das top .
=> Habe ich das so richtig verstanden? Das erscheint mir nicht sinnvoll zu sein, wenn dem wirklich so ist.
...
Nein. Die Prozent beziehen sich auf das, was hinzugefügt wird.
Beispiel für einen Durchlauf des Skripts bei Tempowert 10:
100%: aktueller Zeitwert + 10
500%: aktueller Zeitwert + 50
Der "aktuelle Zeitwert" ist quasi der Wert, der den Ready-Wert überschreiten muss, damit ein Slot in der Aktionsreihenfolge belegt wird.
Zitat
In den Bildern wird also die Reihenfolge bei Ausführen dieser Aktion angezeigt? D.h. wenn ich Pfeil hoch / runter drücke, wird sofort die Reihenfolge geupdated? Wenn das so ist, finde ich das top .
...
So wahr mir Gott helfe:
Das ist ein Test mit 1000% für Zauber. Ich verstehe es noch nicht ganz.
Danke für die Bilder^^.
Sieht auf jeden Fall richtig gut aus!
Die 3D-Perspektive macht richtig was her .
Bzgl. Dauer einer Aktion:
Anscheinend haben wir wirklich aneinander vorbeigeredet. Bisher bin ich davon ausgegangen, dass die Aktion sofort ausgeführt wird, aber die Aktionsdauer dann negativ für den folgenden Zug berechnet wird (d.h. mache ich jetzt eine Aktion mit hoher Dauer, dauert es länger, bis ich wieder dran komme).
Jetzt habe ich den Eindruck, dass die Aktion erst ausgeführt wird, wenn diese Dauer vergangen ist. So ähnlich wie in Grandia.
Also so ganz blicke ich noch nicht, wie genau du das umsetzt. Ist aber auch nicht so wichtig^^.
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
Sobald ein Charakter seinen Zug durchgeführt hat gilt: Ready-Wert = Ready-Wert - Ready-Limit
...
Neu:
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:
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.
Zitieren
.
