¿Cómo diseñas un sistema de grabación / repetición para un juego que cambia con frecuencia?

Estoy trabajando en un MMORPG gratuito y tengo un problema.

Estoy (con otras personas) desarrollando un sistema de grabación de video para el juego. La idea es básicamente: registramos todos los paquetes enviados y recibidos con marcas de tiempo, más algunos datos locales del cliente, y luego los volcamos en un archivo. Para reproducir el video, simplemente emulamos todo lo que está en el archivo. También tenemos una opción para exportar el video a avi con ffmpeg.

El problema es: cuando cambiamos entre versiones del juego, es difícil mantener la compatibilidad con versiones anteriores del video (comandos agregados / eliminados, cambios de funciones, etc.). ¿Hay una buena manera de manejar este problema? en lugar de tener un montón de jugadores diferentes y elegir el correcto para cada versión del archivo de video?

Sería útil saber cómo manejan otros juegos esta situación.

Gracias por la ayuda, perdón por mi inglés.

— Marco
fuente

Solo como un poco más de comida para buscar en Google / investigar: la forma en que lo haces es exactamente cómo los Juegos de Quake de id registraron Demos, al capturar Paquetes de Servidor. Hasta donde sé, simplemente nunca resolvieron los problemas de compatibilidad.

— Michael Stum

He cambiado el título de esta pregunta: no se trata realmente de MMO, excepto que los MMO son los juegos que cambian con más frecuencia.

Respuestas:

Nuestra regla básica es nunca cambiar un tipo de paquete existente. Todo se agrega al final de uno existente o un nuevo comando. Esto también hace que sea mucho menos probable que dos personas pisoteen el trabajo del otro.

— coderanger
fuente

En este juego sucede. Se agregan, eliminan, mueven paquetes (por ejemplo, hace algún tiempo, hemos decidido mover todos los paquetes relacionados con los Comandos GM a un "paquete extendido", esto probablemente sucedería nuevamente cuando reescribamos el sistema de gremios ... Editar comandos / funciones (cambiar su funcionalidad) es menos probable, pero ese no es el punto. Dices que de ahora en adelante, no deberíamos eliminar ningún paquete, ¿eliminar comandos simplemente dejarlos inaccesibles del lado del servidor? Gracias por tu respuesta!

— Marco

Sí, despreciar y dejarlos allí. Eventualmente, las cosas viejas se pueden eliminar, pero eso es generalmente después de un año o dos.

— coderanger

Además, un poco de planificación adicional ayudaría. Cuanto mejor planifique sus paquetes ahora, menos cambios tendrá que hacer en el futuro.

— Kylotan

El problema es que el juego siempre está cambiando. Agregamos un nuevo paquete casi todos los meses (agregamos nuevas funciones). Y, sin embargo, tenemos que hacer muchos cambios en las funciones de reescritura de paquetes antiguos y así ... Pero supongo que podemos dejar los métodos allí y esperar un año para eliminarlos.

— Marco

Usar más tipos de paquetes genéricos te ayudaría mucho aquí. No debería necesitar agregar nuevos mensajes para cada nueva característica que implemente.

— Kylotan

No es inconcebible, especialmente en una PC, que solo versionen el código de juego y cambien la versión cuando hacen un cambio que afecta el sistema de reproducción. Si el archivo de reproducción está etiquetado con la versión del código de juego con el que fue creado y el cliente todavía tiene acceso a esa versión, debería funcionar bien.

— U62
fuente

Así es como he visto esto en la práctica, almacenar el número de versión con el registro del juego. Entonces, por supuesto, también debe mantener las versiones de software anteriores para reproducir registros anteriores, por ejemplo, en un repositorio de código fuente, pero probablemente debería hacerlo de todos modos.

— Ian Schreiber

Gracias por su respuesta, el juego es gratuito (licencia GPL), por lo que cualquiera puede acceder a versiones antiguas del juego e incluso compilar el cliente para que no sea un problema tener todas las versiones diferentes. Esto es muy utilizado, no todos los servidores alternativos utilizan las últimas versiones, hay servidores que ejecutan versiones de 2004 ..

— Marco

@Marco: Sospecho que el funcionamiento de SC2 es que pone casi todo el código en una DLL. Cuando carga una repetición, verifica la versión, carga la DLL para esa versión y se ejecuta. Es un poco más complicado, pero el usuario solo necesita una instalación, y un exe puede ejecutar todas las repeticiones anteriores.

— Mooing Duck

Una forma de abordar esto es a lo largo de las líneas de un juego llamado "Heroes of Newerth". (que cambia cada +/- 2 semanas) Por lo que puedo decir, ellos:

Use parches diff para el juego y las repeticiones.
Todas las repeticiones se almacenan en la nube. Finalmente expiran.
Si el usuario quiere ver una repetición descargada antigua, primero debe usar el botón "Compatizar".
Parece que este control remoto difiere de la última versión; o en caso de que la reproducción ya no esté almacenada, la carga y luego hace la diferencia remota.

Como no trabajo en S2, claramente no puedo decir que definitivamente así es como funciona. Sin embargo, he notado una marcada tendencia de tamaño de descarga asociada con la edad de la repetición.

O eso, o agregan parches de entidad a la repetición (por ejemplo, el hechizo X tiene efecto Y en lugar de efecto Z). Si la información relacionada con los paquetes también se almacena en la configuración de la entidad, esta revisión en caliente de la entidad también le permitirá comprender los paquetes más antiguos.

Definitivamente no almacenaría el comportamiento histórico en el cliente porque eso puede volverse enorme muy rápidamente. Especialmente cuando el cliente está actualizando, por ejemplo, 10.1.0 a 10.2.0 (ya que necesitan descargar cada parche entre las dos versiones, en lugar del parche final).

Google Protobuf es una buena idea como capa de serialización porque admite cosas como esta por diseño.

— Jonathan Dickinson
fuente