Lass schnelles Ding langsam aussehen (Box2D)

Ich arbeite an einem Spiel, bei dem du ein Trebuchet kontrollierst, um Bälle zum Gegner zu werfen.

Es ist wie ein Spiel namens "Medieval Siege". Wenn das Trebuchet seinen Arm schwingt, muss der Spieler den besten Moment nutzen, um den Knopf zu drücken und den Ball loszulassen. Dann fliegt der Ball im Tangentenwinkel. Mein aktuelles Problem ist, dass der Trebuchet-Arm zu schnell schwingt, als dass der Spieler den richtigen Moment nutzen könnte. In der Zwischenzeit muss es so schnell sein, sonst kann es nicht weit genug werfen. Und es gibt eine winzige Schnur, die den Ball und den Trebuchet-Arm verbindet. Wenn der Arm zu langsam schwingt, hängt der Ball nur an der Schnur, wenn sich der Arm bewegt.

Ich löse das Problem, indem ich die Schrittgröße umschalte. Wenn der Arm schwingt, ändere ich die Schrittgröße von 1/60 auf 1/200. Und sobald der Spieler den Ball loslässt, ist er wieder bei 1/60.

Dies funktioniert ziemlich gut, außer dass mein Spiel für Multiplayer mit Networking ist. Das Ändern des Schritts kann daher zu Problemen führen.

Eine andere Lösung, die ich mir vorstellen kann, besteht darin, ihn langsam schwingen zu lassen, aber wenn der Spieler den Ball loslässt, füge ich dem Ball manuell Geschwindigkeit hinzu, während ich seine Richtung behalte. Ich mag diese Lösung nicht wirklich, weil sie falsch aussieht und ich immer noch das Problem habe, dass der Ball nur an der Schnur hängt, es sei denn, ich mache die Schnur sehr, sehr kurz.

Bitte werfen Sie etwas Licht darauf, danke!

BEARBEITEN

Vielen Dank für die Eingabe aller, ich löse das Problem, indem ich den Arm langsam schwingen lasse und wenn der Spieler den Ball loslässt, die Geschwindigkeit des Balls greife und zweimal. Es sieht genauso aus wie das Ändern der Schrittgröße. Es gibt nur eine zusätzliche Sache, die ich tun muss. Da der Arm sehr langsam schwingt, hängt der Ball nur am Armende, anstatt zu schwingen. Ich habe dies gelöst, indem ich während und nur während der Schwungperiode eine Kraft auf den Ball ausgeübt habe, die der Gravitationskraft entspricht. Dann hängt es nicht mehr dort, sondern schwingt mit dem Arm zusammen.

Die Antwort von @MrCranky ist detailliert und sieht machbar aus, also würde ich sie akzeptieren. :) :)

Instinktiv würde ich sagen, dass uns ein wesentlicher Teil des Kontexts fehlt, der für die Beantwortung benötigt wird. "Warum hindert Sie der Multiplayer-Aspekt daran, den Zeitschritt zu ändern?"

Wenn Sie versuchen, eine Physiksimulation über eine Netzwerkverbindung zu teilen, ist dies normalerweise eine ziemlich schwierige Aufgabe. Die Simulationen gehen sehr leicht auseinander, und insbesondere bei Netzwerkverbindungen, bei denen Pakete verloren gehen können, ist es sehr schwierig, die Dinge zusammenzuhalten.

Die einfachste und robusteste Antwort auf Ihre Frage ist die Verwendung eines variablen Zeitschritts. Wenn Sie sich dem Moment der Entscheidung nähern, aktualisieren Sie Ihre Physiksimulation nicht um eine Sekunde für jede verstrichene reale Sekunde, sondern um eine halbe Sekunde oder eine andere geeignete Zahl. Da es sich um einen Integrationseffekt handelt, können Sie wahrscheinlich davonkommen, indem Sie die Aktualisierungsrate während des Entscheidungsfensters einfach auf die niedrigere Rate reduzieren, aber Sie können auch schnell nach unten auf die niedrigere Rate interpolieren. In beiden Fällen spielen Sie die Physiksimulation im Wesentlichen in Zeitlupe ab. Es sollte sich perfekt genau verhalten, nur langsam genug, dass der Spieler seine Entscheidung treffen kann. Ich würde keine andere Möglichkeit in Betracht ziehen, die Physik zu verfälschen, damit sie funktioniert. Sie werden höchstwahrscheinlich alle schrecklich funktionieren und sich nicht „richtig“ fühlen.

Wir kehren also zur Netzwerkimplementierung zurück. Ohne weitere Informationen hätten Sie vermutlich zwei Möglichkeiten. Erstens, wenn Sie im Gleichschritt mit der anderen vernetzten Partei arbeiten. Wenn also ein Spieler langsamer werden muss, um seine Entscheidung zu treffen, verlangsamen Sie beide Spieler gleichermaßen. Dies wird sich für den Spieler, der nicht schießt, wahrscheinlich nervig und seltsam anfühlen, da dies seine eigenen Reaktionszeiten verwirrt.

Stellen Sie sich zum zweiten zwei Trebuchets vor, die aufeinander schießen. Das Trebuchet braucht 10 Sekunden, um zu werfen, und das Schussfenster beginnt bei T + 5s. P1 startet den Zündzyklus bei T + 0s und verlangsamt bei T + 5s die lokale Physiksimulation um 50%. Sie brauchen 15 Sekunden, um den gesamten Zyklus durchzuspielen. Bei T + 5s weist P1 P2 an, den 10s-Startzyklus mit voller Geschwindigkeit abzuspielen. P1 sieht also, dass der Trebuchet-Zyklus 15 Sekunden dauert, P2 sieht 10 Sekunden, aber beide Spieler sehen, dass der Zyklus bei T + 15 Sekunden endet. Wenn P1 tatsächlich loslässt, teilen sie P2 mit, wann sie sich im fiktiven Zyklus befinden. Wenn also P1 bei T + 10s veröffentlicht wird, ist dies tatsächlich bei 7,5s während des Startzyklus von 10s. P2 kann dann die Freigabe bei T + 12,5 s (7,5 s in der lokalen Wiedergabe des Zyklus) anzeigen, und beide Spielersimulationen sollten das Projektil an demselben physischen Punkt im Zyklus abgefeuert haben.

Bei diesem zweiten Ansatz simulieren Sie also nicht mehr im Gleichschritt. Sie führen zwei unabhängige Simulationen durch, verfolgen jedoch stattdessen die Spielereingaben. Wenn beiden mitgeteilt wird, dass der Spieler um 7.5 Uhr in den Startzyklus entlassen wurde, sollten sie sich beide darauf einigen, wo das Projektil landen wird. In der Praxis geht das wahrscheinlich sehr schnell auseinander, und Sie müssen die Simulationszustände irgendwie synchronisieren.

Warum nicht einfach kopieren / anpassen, was bereits vorhanden ist und in ähnlichen Fällen funktioniert?

Wenn sich Ihr Trebuchet zu schnell bewegt, besteht die offensichtliche Lösung darin, die Zeit zu skalieren, um sie langsamer zu machen. Das heißt, für jede Sekunde in Echtzeit vergehen in Ihrer Physiksimulation nur z. B. 0,1 Sekunden. Aus Sicht des Spielers bewegt sich der Ball nun zehnmal langsamer.

Tatsächlich gibt es eine andere Möglichkeit, den gleichen Effekt zu erzielen: Anstatt die Zeit zu skalieren, skalieren Sie einfach alle Ihre Physikkonstanten, die in Einheiten einschließlich der Zeit angegeben sind. Zum Beispiel hat die Gravitationsbeschleunigung Einheiten von Geschwindigkeit / Zeit = Entfernung / Zeit². Wenn also die Schwerkraft die einzige Konstante in Ihrem Spiel ist, erzielt eine Verkleinerung um den Faktor 100 = 10² den gleichen Effekt wie eine Verlangsamung der Zeit um den Faktor 10 .

Wenn Ihr Physikmodell andere Konstanten mit Zeiteinheiten enthält (oder Geschwindigkeit = Entfernung / Zeit oder Beschleunigung = Entfernung / Zeit² usw.), müssen Sie diese natürlich auch skalieren, wenn Sie die Trajektorien gleich halten möchten .

Beachten Sie, dass es eine Grenze gibt, wie weit Sie damit praktisch gehen können: Wenn Sie die Zeit beispielsweise um den Faktor 100 verlangsamen, ist Ihr Trebuchet sehr einfach zu kontrollieren, aber Ihre Spieler werden sich wahrscheinlich auch langweilen, wenn sie auf das warten Bälle, die nach dem Abfeuern langsam nach unten schweben. Wenn dies ein Problem ist, müssen Sie möglicherweise auf fortgeschrittenere Tricks zurückgreifen, wie sie in anderen Antworten vorgeschlagen wurden, z. B. die Verwendung einer sehr langsamen Zeitskalierung, während das Trebuchet feuert, aber nach dem Start des Balls zu einer schnelleren Zeitskala wechseln.