¿En qué se basa el tiempo del juego? ¿Tiempo real o marcos?

Estoy diseñando un juego por primera vez, pero me pregunto en qué momento del juego se basa. ¿Está basado en el reloj o depende de marcos? (Nota: No estoy seguro de si 'tiempo de juego' es la palabra aquí, corríjanme si no lo es)¿En qué se basa el tiempo del juego? ¿Tiempo real o marcos?

Para ser más claro, imaginar estos escenarios:

ordenador 1 es rápido, hasta 60 fps
ordenador 2 es lento, no más de 30 fps

en ambos equipos el mismo juego se juega, en el que un personaje camina a la misma velocidad.

Si el tiempo del juego se basa en cuadros, el personaje se movería dos veces más rápido en la computadora 1. Por otro lado, si el tiempo del juego se basara en tiempo real, la computadora 1 mostraría el doble de marcos, pero el personaje mover tan rápido como en la computadora 2.

Mi pregunta es, ¿cuál es la mejor manera de lidiar con el tiempo de juego y cuáles son las ventajas y desventajas?

Fuente

2010-06-28 Harmen

+1, recuerda la vez que comencé a programar en QBASIC :). – MAK

Depende de si su computadora tiene un botón turbo o no ... –

Ha ... Recuerdo tener que apagar el turbo porque un juego era demasiado rápido para jugar. –

Los juegos realmente antiguos usaban un conteo de cuadros. Se hizo bastante obvio rápidamente que esta era una idea pobre, ya que las máquinas se vuelven más nuevas, y por lo tanto los juegos funcionan más rápido.

Por lo tanto, basarlo en el reloj del sistema. En general, esto se hace conociendo cuánto tiempo tomó el último fotograma y usando ese número para saber cuánto tiempo real pasará por este fotograma.

Fuente

2010-06-28 18:35:04 zebediah49

+1: Heh. Alguien recuerda * Wing Commander * ... Una de las peores series para ese problema. El hardware actualizado los hizo no reproducibles. Ahora los juegos interpretan el tiempo según la hora del sistema, y el sistema gráfico consulta el estado de los objetos del juego y dibuja una imagen. – Satanicpuppy

Juegos muy antiguos usados * marcas de temporizador * no cuenta de cuadros. Un reloj más rápido (8 MHz vs 4.77 MHz) significaba que había más tics en un segundo, y dado que algo sucedía, digamos, cada 10 tics, el juego corría más rápido y dibujaba en la pantalla más a menudo. El aumento de las velocidades de cuadros fue una * consecuencia * de los tics más rápidos, pero no fueron la base del movimiento en sí mismos. –

@Stephen P: Creo que te refieres a ciclos de CPU, en lugar de tics de temporizador. Los videojuegos realmente antiguos (por ejemplo, Odyssey I) usaban la carga que fluía dentro y fuera de los condensadores a velocidades variables. Los juegos ligeramente nuevos (por ejemplo, Pong original) usaron cuadros de video, aunque la velocidad de cuadros es un estricto submúltiplo de la frecuencia del reloj de entrada. El primer sistema de juego controlado por procesador realmente popular (Atari 2600) tiene que renderizar cada cuadro mientras se escanea, ya que el sistema no tiene suficiente hardware para sostener toda una pantalla a la vez. – supercat

Debe confiar en el reloj del sistema, no en el número de cuadros. Has hecho tu propio caso para esto.

Fuente

2010-06-28 18:32:38 Will

Para que los usuarios de cada uno tengan la misma experiencia, querrán usar el tiempo real, de lo contrario, diferentes usuarios tendrán ventajas/desventajas dependiendo de su hardware.

Fuente

2010-06-28 18:32:47

El FPS es simplemente cuánto marco puede procesar la computadora por segundo.

El tiempo de juego es SU tiempo de juego. Usted lo define. A menudo se llama "Game Loop". La representación de marcos es una parte del bucle del juego. También verifique si el FSM está relacionado con la programación del juego.

Le sugiero que lea un par de libros sobre programación de juegos. La pregunta que hace es qué explica ese libro en los primeros capítulos.

Fuente

2010-06-28 18:35:54

Los juegos deben usar el reloj, no los marcos, para proporcionar el mismo juego sea cual sea la plataforma. Es obvio cuando observas MMO o juegos de disparos en línea: ningún jugador debe ser más rápido que otros.

Fuente

2010-06-28 18:37:46

Depende de lo que está procesando, qué parte del juego está en cuestión.

Por ejemplo, las animaciones, la física y la IA deben ser independientes de la frecuencia de cuadro para funcionar correctamente. Si tienes una animación dependiente de FPS o un hilo de física, entonces el sistema de física se ralentizará o el personaje se moverá más lento en sistemas más lentos y avanzará increíblemente rápido en sistemas muy rápidos. No está bien.

Para algunos otros elementos, como la creación de scripts y el renderizado, obviamente necesita que sea por fotograma y, por lo tanto, depende del framerate. Le recomendamos que procese cada script y represente cada objeto una vez por cuadro, independientemente de la diferencia de tiempo entre cuadros.

Fuente

2010-06-28 18:39:41 ssube

El juego debe confiar en el reloj del sistema. ¡Ya que no quieres que tu juego se juegue en computadoras decentes en el momento!

Fuente

2010-06-28 18:42:57

En general, los juegos comerciales tienen dos cosas en ejecución: un ciclo de "simulación" y un ciclo de "renderización". Estos deben estar desacoplados tanto como sea posible.

Quiere corregir su paso de tiempo de simulación a algún valor (mayor o igual a su velocidad de fotogramas máxima). A la física compleja no le gustan los pasos de tiempo variables. Me sorprende que nadie haya mencionado esto, pero los pasos de tiempo fijo frente a los pasos de tiempo variables son una gran cosa si tienes algún tipo de física interesante. Aquí hay un buen enlace: http://gafferongames.com/game-physics/fix-your-timestep/

Luego, su ciclo de representación puede ejecutarse lo más rápido posible y representar la salida del paso de simulación actual.

Así, refiriéndose a su ejemplo:

Se podría ejecutar la simulación a 60 fps, es decir 16.67ms paso de tiempo. La computadora A rendiría a 60 fps, es decir, representaría cada cuadro de simulación. La computadora B representaría cada segundo marco de simulación. Por lo tanto, el personaje se movería la misma distancia en el mismo tiempo, pero no tan suavemente.

Fuente

2010-06-28 18:53:12 Justicle

Eso es interesante; Nunca antes había tenido problemas con la física de paso variable. Supongo que he hecho cosas relativamente simples, o he bloqueado el tamaño de paso (para cosas científicas) sin embargo. Pensaría que usar pasos de tiempo más finos en una máquina más rápida lo haría aún más suave y mejor. Sí, ciertas cosas físicas no funcionarían bien a un ritmo demasiado bajo, pero arreglarlo más alto y hacer que la computadora falle no parece mucho mejor. – zebediah49

Supongo que "multijugador" podría ser la definición de "interesante". Probablemente exagerado para este caso en particular, pero vale la pena señalar desde el punto de vista que los pasos del tiempo son un tema complicado. – Justicle

Tiempos diferentes hacen las cosas más suaves pero también pueden cambiar el juego. P.ej. en algunos (la mayoría) de los juegos que no integran correctamente el movimiento, si tu paso de tiempo cambia debido a un análisis de virus, puedes obtener resultados de simulación muy diferentes (por ejemplo, creo en Quake si disparaste una carga tan alta como lo hiciste saltar, ¿podrías saltar a cualquier parte del nivel?). –

Los juegos suelen utilizar el temporizador de mayor resolución disponible, como QueryPerformanceCounter en Windows para sincronizar las cosas. Los viejos juegos solían usar marcos, pero después de que literalmente podías correr más rápido en Quake cambiando tu FPS, aprendimos a no hacer eso nunca más.

Fuente

2010-06-28 18:54:39 Puppy

¿En qué se basa el tiempo del juego? ¿Tiempo real o marcos?

Respuesta

Cuestiones relacionadas