Yo no respondo de GexTech porque ni sé cómo funcionan ni es asunto mío, pero como llevo 19 años dejándome los cojones en esto de los videojuegos, diré lo que se me pasa por la cabeza: si hay algo que esta ridícula campaña de desprestigio contra esa empresa me deja totalmente claro, es la calaña de los autores. Y me entristece profundamente el ver que tenéis público para esta payasada.

 El C++ es como la liebre del cuento, siempre estás mas cerca de "saberlo", pero nunca llegas a aprenderlo del todo. Da igual lo que hagas, como si es una aventura en modo texto, pero no te quedes quieto. :) Coge la SDL, pilla los ejemplos, basate en ellos para hacer un matamarcianos, y a partir de ahi ve mejorando el código y haciendo cosas más gordas. Sobre todo, lo más importante, NO empieces intentando hacer un online masivo como parece que hace la mitad de la gente (y que luego se queda en nada).

Cuanto más leas en Inglés, menos te costará y tendrás acceso a leer cosas más interesantes, asi que hale, "my taylor is rich and my mother is in the kitchen."

 Ah vale, para las repeticiones de momentos puntuales sin duda el segundo método, guardar el estado visual de los objetos en cada frame (or cada X frames),  e interpolar. Como sugerían, un buffer circular es perfecto para eso. Es exactamente lo que hicimos en el NBA Inside Drive (que para todo lo demás usaba ticks fijos y motor determinista). Allí además teníamos otros buffers en donde copiabamos ese buffer circular y así contar con una selección de "las mejores jugadas" al final del partido.

 Alguien me ha mentado? :)

Las dos formas habituales de guardar replays son:

- guardando pares (tiempo, evento del jugador), y teniendo un motor de juego completamente determinista, que si recibe esa misma serie, generará unos resultados IDENTICOS a cada paso. Este método es típico de los RTS (aunque el Total Annihilation usaba el segundo sistema).

- guardando las posiciones de los bichos, y los eventos que se producen en el juego (disparo, daño, muerte). Esto es lo que suelen hacer los FPS (aunque el Doom original usaba el método anterior).

El método elegido suele tener mucho que ver con el sistema de red. Ya que todos los jugadores de una partida en red tienen que ver la misma partida, el problema es similar al de reproducir la partida posteriormente.

El segundo método es en principio más sencillo y flexible, pero potencialmente genera más tráfico, todo depende de la cantidad de entidades móviles. El primero genera unos problemas del carajo, porque conseguir que el motor sea 100% determinista es un horror. 99.999% no sirve, en el momento en que la reproducción se desvíe del original, el juego empezará a tomar decisiones diferentes, y la reproducción se degenera rápidamente, el conocido "efecto mariposa".

- Hay que tener muy controladitos los generadores de números aleatorios. Se suelen usar dos: uno para la lógica y cualquier cosa que pueda afectar al estado del juego, y uno para los efectos visuales y cosas que jamás afecten a la lógica. De esa forma, los rand() que hagas para las partículas (que pueden estar desactivadas o con niveles de detalle) no afectan a las decisiones de la IA.

- Hay que tener cuidado con las operaciones en coma flotante, si reproduces la partida en una máquina con una CPU diferente (Mac vs. PC por ejemplo) los decimales de las operaciones pueden diferir, y lo harán. Al carajo la reproducción!

- Hay que cuantizar el tiempo de ejecución de la lógica a intervalos de tiempo fijos, o al menos almacenar los tiempos entre ticks de lógica, y asegurarse de que la reproducción los sigue fielmente. No puedes hacer ninguna virguería para ajustar el tiempo de cálculo de la lógica en función del framerate, y por supuesto esparcir la lógica en varios thread es imposible excepto en operaciones muy concretas (para las que no suele merecer la pena sacar un thread aparte).

- Cualquier chorrada, cualquier bug, cualquier valor no inicializado, cualquier cambio en los valores o algoritmos (típico al sacar parches), cambiará los resultados de la lógica y destruirá la reproducción. Necesitas incluir trazas para depurar estos problemas, normalmente grabas el valor de la semilla de rand() de la lógica y lo compruebas constantemente para detectar si se ha producido una desincronización.

- La reproducción tiene que realizarse en orden y desde el principio: no puedes arrancar a mitad, saltarte unos minutos, o ir hacia atrás. Aunque quieras dar esas capacidades al juego, por dentro tendrás que reproducir cada tick hasta el punto que quieres mostrar.

Muchos muchos problemas, pero las ventajas también son potentes:

- Tienes la herramienta perfecta para depurar un crash: saca el replay para reproducir exactamente la situación que provocó el casque, mucho mejor que el tester te cuente "pues llevé a la tropa cerca del pueblo y luego lancé un ataque contra uno de los defensores".

- El tamaño de las replays es muy pequeño.

- Cuando se usa este sistema para implementar la red, resulta casi imposible hacer muchas trampas en red, como las que hacen los trainers típicos, de darte vida o pasta o matar a un enemigo porque sí. Lo más que puedes hacer es mostrar

El tema da para un libro entero, pero como decía al principio, lo mejor es leer artículos sobre sistemas de red - una vez que tienes el juego corriendo en red, incluir un sistema de replay es casi trivial.

http://www.gamasutra.com/features/20010322.../terrano_01.htm

http://www.gamasutra.com/features/20050823...itkine_02.shtml