Plataformas 2D: ¿por qué hacer que la física dependa de la velocidad de cuadros?

Question

"Super Meat Boy" es un difícil juego de plataformas que recientemente salió para PC, que requiere un control excepcional y saltos perfectos en píxeles. El código de física en el juego depende de la velocidad de fotogramas, que está bloqueada a 60 fps; esto significa que si tu computadora no puede ejecutar el juego a toda velocidad, la física se volverá loca, causando (entre otras cosas) que tu personaje corra más despacio y caiga por el suelo. Además, si vsync está desactivado, el juego corre extremadamente rápido.

¿Podrían aquellos con experiencia en la programación de juegos 2D ayudar a explicar por qué el juego fue codificado de esta manera? ¿No sería una mejor solución un ciclo de física funcionando a una velocidad constante? (En realidad, creo que se usa un bucle de física para partes del juego, ya que algunas de las entidades continúan moviéndose normalmente independientemente de la velocidad de fotogramas. Por otro lado, tu personaje corre exactamente [fps/60] tan rápido)

Lo que me molesta de esta implementación es la pérdida de abstracción entre el motor del juego y la representación gráfica, que depende de elementos específicos del sistema como el monitor, la tarjeta gráfica y la CPU. Si, por alguna razón, su computadora no puede manejar vsync, o no puede ejecutar el juego a exactamente 60 fps, se romperá espectacularmente. ¿Por qué el paso de renderizado debería influir en los cálculos de física? (La mayoría de los juegos hoy en día ralentizarían el juego u omitirán marcos). Por otro lado, entiendo que los juegos de plataformas de la vieja escuela en el NES y SNES dependían de un framerate fijo para gran parte de su control y física. ¿Por qué es esto, y sería posible crear un patform en esa línea sin tener la dependencia de framerate? ¿Hay necesariamente una pérdida de precisión si separa la representación gráfica del resto del motor?

Gracias, y lo siento si la pregunta fue confusa.

Answer 1

Probablemente necesitaron hacer el juego lo suficientemente rápido y decidieron cubrir suficiente base de usuarios con la implementación actual.

Ahora bien, realmente no es que es difícil actualizar la independencia, si lo piensas durante el desarrollo, pero supongo que podrían ir por algunos agujeros empinados.

Creo que es innecesario, y lo he visto antes (algunos primeros juegos de 3d-hw usaban lo mismo, donde el juego era más rápido si miras al cielo, y más lento si miras al suelo).

Simplemente apesta. Compártelo con los desarrolladores y espera que lo parcheen, si pueden.

Answer 2

No hay razones por las que la física dependa de la velocidad de fotogramas y este es claramente un mal diseño.

Una vez intenté entender por qué las personas hacen esto. Hice una revisión de código para un juego escrito por otro equipo de la empresa, y no lo vi desde el principio, pero utilizaron un gran valor de 17 codificados en su código. Cuando ejecuté el juego en modo de depuración con el FPS mostrado, ¡lo vi, el FPS tenía exactamente 17! Miro el código nuevamente y ahora está claro: los programadores supusieron que el juego siempre tendrá una tasa de cuadros constante de 17 FPS. Si el FPS era mayor que 17, hicieron un sueño para hacer que el FPS fuera exactamente 17. Por supuesto, no hicieron nada si el FPS era menor que 17 el juego se volvió loco (como cuando se jugó a 2 FPS y manejando un auto en el juego, el sistema de juego me alertó: "¡Demasiado rápido! ¡Demasiado rápido!").

Así que escribo un correo electrónico preguntándome por qué codificaron este valor y lo utilizan su motor de física y respondieron que de esta manera mantienen el motor más simple. Y respondí de nuevo, está bien, pero si ejecutamos el juego en un dispositivo que no tiene capacidad para 17 FPS, el motor de tu juego funciona de forma muy divertida pero no como se esperaba. Y dijeron que solucionará el problema hasta la próxima revisión del código.

Después de 3 o 4 semanas recibo una nueva versión del código fuente, así que tenía curiosidad por saber qué hacían con la constante FPS, así que lo primero que hago es buscar el código después de 17 y solo hay un par coincidencias, pero una de ellas no era algo que quisiera ver:

final static int FPS = 17;

Así que eliminaron todos los 17 valores codificados de todo el código y usaron la constante FPS en su lugar. Y su motivación: ahora si tengo que poner el juego en un dispositivo que solo puede hacer 10 FPS, todo lo que tengo que hacer es establecer esa constante FPS en 10 y el juego funcionará sin problemas.

En conclusión, disculpe por escribir un mensaje tan largo, pero quería enfatizar que la única razón por la que alguien hará tal cosa es por el mal diseño.

Answer 3

Aquí hay una buena explicación de por qué el paso de tiempo debe mantenerse constante: http://gafferongames.com/game-physics/fix-your-timestep/

Además, dependiendo del motor de la física, el sistema puede obtener inestable cuando los cambios timestep. Esto se debe a que algunos de los datos que se almacenan en la memoria caché entre marcos dependen del paso de tiempo. Por ejemplo, la suposición inicial para un solucionador iterativo (que es cómo se resuelven las restricciones) puede estar lejos de la respuesta. Sé que esto es cierto para Havok (el motor de física utilizado por muchos juegos comerciales), pero no estoy seguro de qué motor utiliza SMB.

Hubo también un artículo en Game Developer Magazine hace unos meses, que ilustra cómo se logró un salto con la misma velocidad inicial pero diferentes tiempos diferentes diferentes alturas máximas con diferentes velocidades de cuadro. Hubo una anécdota de apoyo de un juego (¿Tony Hawk?) Donde se podía hacer un cierto salto cuando se ejecutaba en la versión NTSC del juego, pero no en la versión PAL (ya que las velocidades de fotogramas son diferentes). Lamento que no pueda encontrar el problema por el momento, pero puedo intentar desenterrarlo más tarde si lo desea.