Hacer que lo rápido parezca lento (Box2D)

Estoy trabajando en un juego en el que controlas un trebuchet para lanzarle bolas al oponente.

Es como un juego llamado 'Asedio medieval'. Cuando el trebuchet balancea su brazo, el jugador debe aprovechar el mejor momento para presionar el botón y soltar la pelota. Entonces la pelota volará en el ángulo tangente. Mi problema ahora es que el brazo del trebuchet se balancea demasiado rápido para que el jugador aproveche el momento correcto. Mientras tanto, tiene que ser así de rápido, de lo contrario no puede lanzar lo suficientemente lejos. Y hay una pequeña cuerda que conecta la bola y el brazo de trebuchet, si el brazo se balancea demasiado lento, la bola simplemente cuelga de la cuerda cuando el brazo se mueve.

Resuelvo el problema alternando el tamaño del paso, cada vez que el brazo se balancea, cambio el tamaño del paso de 1/60 a 1/200. Y una vez que el jugador suelta la pelota, vuelve a 1/60.

Esto funciona bastante bien, excepto que mi juego es para multijugador con redes. Por lo tanto, cambiar el paso puede causar problemas.

Otra solución que se me ocurre es permitir que oscile lentamente, pero cuando el jugador suelta la pelota, agrego velocidad manualmente a la pelota mientras mantengo su dirección. Realmente no me gusta esta solución porque parece falsa y todavía tengo el problema de que la pelota está colgando de la cuerda, a menos que la haga muy corta.

Por favor, arroja algo de luz sobre esto, ¡gracias!

EDITAR

Gracias por el aporte de todos, resuelvo el problema haciendo que el brazo se balancee lentamente y cuando el jugador suelta la pelota, agarra la velocidad de la pelota y multiplicada por dos. Se ve exactamente igual que cambiar el tamaño del paso. Solo hay una cosa extra que necesito hacer. Debido a que el brazo oscila muy lentamente, la pelota simplemente cuelga del extremo del brazo en lugar de balancearse. Resolví esto aplicando una fuerza igual a la fuerza gravitacional sobre la pelota durante y solo durante el período de swing. Entonces ya no cuelga allí, sino que se balancea con el brazo.

La respuesta de @MrCranky es detallada y parece factible, así que la aceptaría. :)

Instintivamente, diría que nos falta una parte sustancial del contexto necesario para responder, que es "¿por qué el aspecto multijugador te impide cambiar el paso del tiempo?"

Si está tratando de compartir una simulación física a través de una conexión de red, bueno, eso suele ser algo bastante difícil de hacer. Las simulaciones divergen muy fácilmente, y especialmente con conexiones de red que pueden perder paquetes, es muy difícil mantener las cosas juntas.

La respuesta simple y más robusta a su pregunta es usar un paso de tiempo variable. Cuando se acerque al momento de la decisión, en lugar de actualizar su simulación física en un segundo por cada segundo que pasa en el mundo real, actualícela en medio segundo u otro número adecuado. Como se trata de un efecto de integración, es probable que puedas salirte con solo bajar la velocidad de actualización a la velocidad más baja durante la ventana de decisión, pero también puedes interpolar rápidamente a la velocidad más baja. De cualquier manera, esencialmente está reproduciendo la simulación física en cámara lenta. Debe comportarse de manera perfectamente precisa, lo suficientemente lenta como para que el jugador pueda tomar su decisión. No consideraría ningún otro medio para eludir la física para que funcione, lo más probable es que todos funcionen horriblemente y no se sientan 'bien'.

Entonces volvemos a la implementación de la red. Sin más información, supongo que tienes dos opciones. En primer lugar, si está operando en sintonía con la otra parte en red. Entonces, cuando un jugador tiene que reducir la velocidad para tomar su decisión, reduzca la velocidad de ambos jugadores por igual. Esto probablemente se sentirá molesto y extraño para el jugador que no está disparando, porque confundirá sus propios tiempos de reacción.

Para el segundo, imagine dos trebuchets disparándose el uno al otro. El trebuchet tarda 10 segundos en lanzarse, y la ventana de disparo comienza en T + 5s. P1 comienza el ciclo de disparo en T + 0s, y en T + 5s ralentiza su simulación física local en un 50%. Les llevará 15 segundos jugar todo el ciclo. Entonces, en T + 5s, P1 le dice a P2 que comience a reproducir el ciclo de lanzamiento de 10s a toda velocidad. Entonces P1 ve que el ciclo de trebuchet toma 15 segundos, P2 ve que toma 10 segundos, pero ambos jugadores ven que el ciclo termina en T + 15 segundos. Cuando P1 realmente se libera, le dicen a P2 cuándo se lanzaron en el ciclo nocional. Entonces, si P1 se lanza en T + 10s, en realidad es de 7.5s a través del ciclo de lanzamiento de 10s. P2 puede mostrar el lanzamiento en T + 12.5s (7.5s en su reproducción local del ciclo), y las simulaciones de ambos jugadores deberían haber lanzado el proyectil en el mismo punto físico del ciclo.

Entonces, en este segundo enfoque, ya no estás simulando al mismo tiempo. Está ejecutando dos simulaciones independientes, pero en su lugar está rastreando las entradas de los jugadores. Si a ambos se les dice que el jugador lanzó a las 7.5 s en el ciclo de lanzamiento, ambos deberían acordar dónde aterrizará el proyectil. Sin embargo, en la práctica, es probable que diverja muy rápido, y necesitará sincronizar los estados de simulación de alguna manera.

¿Por qué no simplemente copiar / adaptar lo que ya existe y funciona en casos similares?

Si su trebuchet se mueve demasiado rápido, la solución obvia sería escalar el tiempo para hacerlo más lento. Es decir, por cada segundo de tiempo real, haga pasar solo, por ejemplo, 0.1 segundos en su simulación física. Ahora, desde el punto de vista del jugador, la pelota se moverá 10 veces más despacio.

En realidad, hay otra forma de lograr el mismo efecto: en lugar de escalar el tiempo, simplemente escale todas sus constantes físicas que están en unidades, incluido el tiempo. Por ejemplo, la aceleración gravitacional tiene unidades de velocidad / tiempo = distancia / tiempo², por lo que si la gravedad es la única constante en tu juego, reducirla en un factor de 100 = 10² logra el mismo efecto que reducir el tiempo en un factor de 10 .

Por supuesto, si su modelo de física incluye otras constantes con unidades de tiempo (o velocidad = distancia / tiempo, o aceleración = distancia / tiempo², etc.), también tendrá que escalarlas si desea mantener las trayectorias iguales .

Tenga en cuenta que hay un límite en cuanto a qué tan lejos puede llegar prácticamente con esto: si reduce el tiempo en, digamos, un factor de 100, su trebuchet será realmente fácil de controlar, pero es probable que sus jugadores también se aburran mientras esperan Bolas para flotar lentamente después de dispararlas. Si ese es un problema, es posible que deba recurrir a trucos más avanzados como los sugeridos en otras respuestas, como usar una escala de tiempo realmente lenta mientras el trebuchet está disparando, pero cambiar a una escala de tiempo más rápida una vez que se ha lanzado la pelota.