La mejor manera de poner en práctica la reproducción de juego?

Question

Estoy creando un juego basado en Java rejilla y quiero poner en práctica juego de grabación y reproducción. No estoy seguro de cómo hacer esto, aunque yo he considerado las ideas 2:

1. Varias veces cada segundo, me gustaría grabar todo el estado del juego. Para jugar de nuevo, escribo un procesador para leer los estados y tratar de crear una representación visual. Con esto, sin embargo, me gustaría probable es que tenga un gran archivo de salvar, y cualquier intento de reproducción probablemente habría retraso notable.

2. También podría escribir cada pulsación de tecla y ratón haga clic en el archivo de salvar. Esto me daría un archivo más pequeño, y podría reproducir con menos retraso. Sin embargo, el más mínimo error en el inicio del juego (por ejemplo, disparar 1 milisegundo más tarde) se traduciría en un estado muy diferentes de juegos varios en el minuto.

Entonces, ¿cuál es la mejor manera de poner en práctica la reproducción de juego?

Editar- No estoy seguro exactamente cómo determinista es mi juego, así que no estoy seguro de todo el juego puede ser reconstruido exactamente registrando sólo las pulsaciones de teclado y los clics del ratón.

Answer 1

Un buen mecanismo de la reproducción no es algo que puede ser simplemente añadido a un juego sin mayores difiiculties. Lo mejor sería hacer el diseño de la infraestructura de juego con ella en mente. El patrón de comando se puede utilizar para lograr una infraestructura de esos juegos.

Por ejemplo:

public interface Command{
    void execute();
}
public class MoveRightCommand implements Command {
   private Grid theGrid;
   private Player thePlayer;

   public MoveRightCommand(Player player, Grid grid){
        this.theGrid = grid;
        this.thePlayer = player;
       }

   public void execute(){
     player.modifyPosition(0, 1, 0, 0);
   } 
}

Y a continuación, el comando puede ser empujado en una cola de ejecución ambos cuando el usuario presiona un botón del teclado, el ratón se mueve o sin un disparador con el mecanismo de reproducción. El objeto de comando puede tener un valor de sello de tiempo (en relación con el inicio de la reproducción) para la reproducción precisa ...

Answer 2

Shawn Hargreaves tuvo un reciente post en su blog acerca de cómo se implementan repetición en MotoGP. Balón por encima de varios enfoques diferentes y sus ventajas y desventajas.

http://blogs.msdn.com /shawnhar/archive/2009/03/20/motogp-replays.aspx

Answer 3

Si se asume que su juego es determinista, podría ser suficiente si ha grabado las entradas de los usuarios (opción 2). Sin embargo, lo que se necesita para asegurarse de que usted está reconociendo los tiempos correctos y coherentes para estos eventos, como cuando fue reconocido por el servidor. No estoy seguro de cómo manejar eventos en la red.

Mi preocupación es que si usted no tiene un mecanismo que puede hacer referencia de manera uniforme eventos cronometrados, puede haber un problema con la manera en que su código controla usuarios distribuidos.

Considere un juego como Halo 3 en Xbox 360, por ejemplo, - cada cliente registra su visión del juego, incluyendo las correcciones basadas en servidor.

Answer 4

¿Por qué no grabar varias veces por segundo y luego comprimir la salida, o tal vez hacer esto:

recordInitialState();
...
runs 30 times a second:
recordChangeInState(previousState, currentState);
...

Si sólo grabar el cambio de estado con una marca de tiempo (y cada cambio es pequeño, y si no hay ningún cambio, luego grabar nada), que debe terminar con tamaños de archivo razonables.

Answer 5

No hay necesidad de guardar todo en la escena para cada cuadro. Guardar los cambios de forma incremental y utilizar algunas buenas técnicas de interpolación. Realmente no lo utilice un enfoque basado en el patrón de comando, sino más bien hacer los cheques a una tasa fija para todos los objetos del juego y ver si ha cambiado cualquier atributo. Si hay un cambio que el cambio se registra en una buena codificación y la repetición ni siquiera llegará a ser tan grande.

Answer 6

¿Cómo se acerque a esto dependerá en gran medida del idioma que está utilizando para su juego, pero en términos generales hay muchos enfoques, dependiendo de si se desea utilizar una gran cantidad de almacenamiento o desea algo de retraso. Sería de gran ayuda si usted podría dar algunas ideas en cuanto a qué sacrificios que está dispuesto a hacer.

Sin embargo, parece el mejor enfoque puede ser simplemente guardar la entrada del usuario, como se ha mencionado, y, o bien almacenar las posiciones de todos los actores / sprites en el juego, al mismo tiempo, que es tan simple como acaba de ahorro de dirección, velocidad y teja x, y, o, si todo puede ser determinista y luego ignorar los actores / sprites que se puede obtener su información.

¿Cómo no determinista su juego está también sería útil para dar una idea mejor.

Si hay una gran cantidad de movimiento dinámico, como un derby accidente, entonces es posible que desee guardar información de cada cuadro, como debe ser la actualización de los jugadores / actores a una cierta velocidad de fotogramas.

Answer 7

Simplemente diría que la mejor manera de registrar una repetición de un juego depende totalmente de la naturaleza del juego. rejilla estar basada no es el problema; la cuestión es cómo predecible el comportamiento está siguiendo un cambio de estado, con qué frecuencia hay nuevas entradas al sistema, si hay datos aleatorios que se inyectan en cualquier punto, etc, puede almacenar todo un juego de ajedrez simplemente mediante el registro de cada movimiento, a su vez, pero eso no quiere trabajar para un shooter en primera persona donde no hay vueltas claras. Se podía almacenar un shooter en primera persona observando el tiempo exacto de cada entrada, pero eso no va a funcionar para un juego de rol en el que el resultado de una entrada puede ser modificado por el resultado de una tirada de dados al azar. Incluso la idea aparentemente infalible para tomar una instantánea tan a menudo como sea posible, no es lo suficientemente bueno si la información importante aparece instantáneamente y no persiste en cualquier forma capturable.

Es interesante que esto es muy similar al problema que se obtiene con la creación de redes. ¿Cómo se asegura un ordenador que otro equipo se pondrá en conocimiento del estado del juego, sin tener que enviar todo ese estado del juego en una frecuencia alta poco práctica? El enfoque típico termina siendo una mezcla a medida de las notificaciones de eventos y actualizaciones de estado, que es probablemente lo que necesita aquí.

Answer 8

Lo hice una vez pidiendo prestado una idea de la compresión de vídeo: los fotogramas clave y fotogramas intermedios. Básicamente, cada pocos segundos se guarda el estado completo del mundo. Luego, una vez por actualización del juego, se ahorra todos los cambios en el estado del mundo que han ocurrido desde la última actualización del juego. Los detalles (¿con qué frecuencia se guarda fotogramas clave? Lo que cuenta exactamente como un 'cambio en el estado del mundo'?) Dependerá de qué tipo de información sobre el juego necesita conservar.

En nuestro caso, el mundo consistía en muchos, muchos objetos del juego, la mayoría de los cuales estaban sosteniendo aún en un momento dado, por lo que este enfoque nos ha ahorrado mucho tiempo y la memoria en el registro de las posiciones de los objetos que no se movían . En el suyo las compensaciones podrían ser diferentes.