¿Cuál es el beneficio de rendimiento de guardar todos los personajes conectados en MMO a intervalos regulares?

La mayoría de los MMORPGS tienen un sistema Worldsave que salvará a todos los personajes una vez cada X horas. Supongo que la razón es el rendimiento. Entonces, ¿por qué es esto mejor, en cuanto al rendimiento, que guardar un personaje en la desconexión?

networking mmo databases

— Bunden
fuente

No es por desempeño; está sacrificando un poco de rendimiento por la corrección , lo cual es más importante.

— Mason Wheeler

¿El tiempo realmente juega algún papel aquí? AFAIK, cada acción en un mmo se guarda de inmediato. Obtiene un elemento y ese elemento se agrega al servidor sin demora a su cuenta; de lo contrario, el servidor tendría que recordar que lo hizo y luego hacerlo 5 minutos después, lo que no tiene ningún beneficio. O el cliente tendría que recordarlo y enviarlo 5 minutos después, lo que ahora lo abre a la piratería, porque en esos 5 minutos cualquiera puede alterar / agregar datos para enviar.

— HopefullyHelpful

@HopefullyHelpful No, eso no es cierto. Cada acción en un MMO está en la memoria de inmediato, pero eso es transitorio. Guardar todo directamente en el almacenamiento persistente sigue siendo demasiado costoso, incluso con SSD. Incluso con juegos que se guardan directamente en una base de datos, la base de datos en sí misma no guarda esos datos en el disco de inmediato (o al menos guarda solo un registro de transacciones, no los datos consistentes; esto debe reconstruirse en un bloqueo, y toma bastante tiempo) poco tiempo). Pero ahorrar en la desconexión es una mala idea por otra razón: consistencia.

— Luaan

Pensé que esta pregunta iba a estar más en la línea de cuál es el beneficio de rendimiento de guardar caracteres en intervalos frente a en tiempo real.

— Anthony

@Luaan: es perfectamente posible guardar cada cambio de estado en un almacenamiento persistente, incluso en discos duros mecánicos. (Es posible que necesite algunos en servidores ocupados). El truco es no actualizar objetos individuales. En su lugar, guarda un registro de transacciones "Jugador (A). Inventario + = Objeto (B)`. Periódicamente vacia el estado completo. Para recuperarse, vuelve a cargar el último guardado completo y aplica las transacciones más recientes del registro de transacciones. . 'está escribiendo un archivo secuencial, se llega a un rendimiento máximo para la mecánica de disco duro pero para mantener el registro de transacciones de tamaño razonable, es necesario el periódico completo guarda.

— MSalters

Respuestas:

Esto no es por rendimiento. Esto es a prueba de fallos. Si el mundo ahorra cada pocos minutos, si algo le sucede al servidor y se apaga, todos solo perderán el progreso de unos minutos.

Al guardar en la desconexión, si el servidor tiene un problema, todos perderán todo lo que han hecho desde que iniciaron sesión. Para aquellos en sesiones de juego particularmente largas (como es común en los MMO), perderán una cantidad significativa de datos.

Sacrifican un poco de rendimiento para eliminar el riesgo de pérdida masiva de datos.

Por supuesto, puede almacenar fácilmente los datos del reproductor en las máquinas del cliente, reduciendo el tráfico de red. El problema aquí es que está abierto a la piratería. Una vez que una persona descubre cómo hacer trampa, la comparte y todos lo hacen.

EDITAR: como señaló @Philipp , esto también elimina la capacidad de duplicar elementos. Con un sistema de guardar en desconexión si se realiza una transacción antes de un bloqueo del servidor y una persona cierra sesión antes del bloqueo, ambos jugadores vuelven a la última vez que cerraron la sesión, ya sea eliminando los elementos o duplicándolos.

— Aric
fuente

Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .

— Josh

Los primeros sistemas que guardaban solo en desconexión tendían a guardar también periódicamente mientras el jugador estaba activo. En esos sistemas, típicamente MUD (mazmorras multiusuario), el personaje se mantuvo en la memoria hasta que se volcaron periódicamente a un archivo.

Esto significaba que si un usuario se desconectaba sin "acampar", generalmente se encontraban a varias habitaciones de distancia y faltaban un montón de botín, XP, etc., desde la última vez que guardaron. En ese sentido, se parecía mucho a cómo juegan los juegos de rol de la consola hoy en día (tienes que guardar tu juego sin apagar la consola, o pierdes todo desde la última vez que guardaste).

El sistema funcionó para su propósito previsto, porque los personajes no podían interactuar entre sí, excepto posiblemente a través de un sistema de "correo" donde podían enviarse mensajes y elementos entre ellos. La posibilidad de perder elementos y progresar tiende a ser bastante significativa, pero solo afecta a un personaje a la vez en la mayoría de los casos.

La función de ahorro de mundo surgió porque los personajes eventualmente pudieron interactuar directamente entre sí, por lo que todos los personajes que jugaban tenían que estar en un estado consistente, o podría ocurrir la duplicación y eliminación de elementos. Esto no fue un problema en el escenario MUD, porque era difícil abusar del sistema de una manera que resultó en la duplicación de artículos o divisas, pero fue increíblemente fácil de hacer en los primeros MUD MUD. El jugador A le da al jugador B un elemento, el jugador B guarda y el jugador A se desconecta sin guardar. Duplicación instantánea

Worldsave no es un beneficio de rendimiento, sino que está diseñado para evitar trampas. Recuerdo haber jugado en sistemas en los que el evento WorldSave se anunciaba literalmente por adelantado y, a menudo, colgaba todo el sistema durante un minuto mientras el servidor actualizaba todos sus archivos. Si bien esto evitó las trampas, no fue muy conveniente para los usuarios de estos sistemas.

Eso nos lleva a la situación actual. Hoy, no usamos funciones de tipo salvavidas. Usamos bases de datos. Esto nos permite asegurarnos de que la duplicación y eliminación se minimicen tanto como sea posible. Los personajes existen como registros en una base de datos, y cada transacción entre jugadores es una transacción de base de datos literal; o la acción está totalmente comprometida o se revertirá.

Salvo errores inusuales en el sistema, obtienes los beneficios de guardar archivos de personajes individuales (tiempos de guardado rápidos) y los beneficios de los salvavidas (sin trampas), sin los inconvenientes de ninguno de ellos (pérdida de progreso significativo y duplicación de elementos).

Al diseñar un MMO moderno, querrá crear procedimientos almacenados en una base de datos y usar esos procedimientos para realizar transacciones. Por ejemplo, al hacer un intercambio entre dos jugadores, podría verse así:

start transaction;
insert into inventory (playerid, itemid) values (111, 222);
delete from inventory where playerid=111 and itemid=444;
insert into inventory (playerid, itemid) values (333, 444);
delete from inventory where playerid=333 and itemid=222;
commit;

(Nota: este SQL no está escrito de manera práctica y solo pretende ser un ejemplo).

De esta manera, si hay un bloqueo antes de la confirmación, el sistema regresa a un estado en el que el jugador 111 y el jugador 333 todavía tienen los elementos originales, mientras que después de la confirmación, el intercambio se completa. No hay oportunidad para la duplicación, porque los caracteres se guardan al mismo tiempo, como lo garantiza la base de datos.

— phyrfox
fuente