¿Cómo almacenan/recuperan los videojuegos de manera eficiente grandes cantidades de datos?

Question

Por ejemplo, en Fallout 3, un juego de salvar almacena el estado y la ubicación de cada objeto y NPC en el juego, y solo ocupa unos pocos MB. ¿¡¿¡Cómo lo hacen!?!?

Y luego, durante el juego, ¿cómo se agregan/recuperan estos datos en/desde la memoria para que se puedan mostrar al jugador en tiempo real?

ACTUALIZADO: (Voy a hacer que trabajar por sus respuestas: P)

Sobre la base de la respuesta de Kevin Crowell ... Así que supongo que tendría una distancia de renderizado que se aplicarían a objetos y NPC, y usted "SELECCIONARÍA" los objetos y NPC dentro del rango dado. Sin embargo, ¿qué tipo de almacén de datos usarías para obtener estos objetos?

En otras palabras, ¿tendría usted una matriz gigantesca de cada objeto en el juego y actualiza constantemente una lista más pequeña que contiene los objetos visibles para representar?

Además, por la respuesta de Chaos ... ¿Sucedería si finalmente tocara cada objeto en el juego? ¿Su juego de salvar se haría cada vez más grande? En el caso de Fallout 3, estoy bastante seguro de que no hay "etapas", donde los datos pasados ​​simplemente podrían descartarse. Todo se conserva cuando sales/regresas a una ubicación. Entonces, ¿cómo crees que se implementa este caso específico?

Answer 1

Con todos los grandes daños actuales, incluso los desarrolladores parecen olvidar cuántos bytes hay en un megabyte. Entonces, para responder a la pregunta en el título: los juegos almacenan grandes cantidades de datos mediante la creación de partidas guardadas de varios megabytes de tamaño.

Para ilustrar qué tan grande es un megabyte, son 8 millones de bits. Eso es suficiente para codificar 2^8000000 = 10^2666666 estados. En comparación, solo hay 10^80 átomos en el universo. Ahora en un juego (guardar) hay múltiples subsistemas con estados distintos; p.ej. en un RPG, cada NPC tiene su propio estado. Pero ¿cuánto de un estado hay realmente? Su posición en una ciudad podría guardarse como 16 bits (¿recuerda la posición exacta si están caminando de todos modos?). Su estado de ánimo/disposición/etc. como otros 8 bits, y que permite más emociones que algunas personas tienen.

Cuando se trata de almacenar este tipo de datos en el juego, la estructura de datos típica es un QuadTree. Esta es una estructura de datos que le permite determinar objetos en una cierta región X-Y en O (log N). En algunos casos, los desarrolladores de juegos les resulta más fácil realizar una partición previa del mundo en zonas. Esto reduce la cantidad de cálculos de tiempo de ejecución. Un buen ejemplo fue Doom. Sus mapas tenían visibilidad precalculada; para cada punto uno podría determinar rápidamente a qué zona pertenecía, y para cada zona, la cantidad de objetos visibles se precalculó. Esto redujo la cantidad de objetos que necesitaban verificaciones de visibilidad en tiempo de ejecución.

Answer 2

Simplemente puede estar asignando objetos, o NPC, a un plano de coordenadas X, Y, Z. Esa información que se almacena a bajo precio.

Durante el juego, todos esos objetos siguen asignados a un sistema de coordenadas en todo momento. Solo necesitan leer en la información de guardado y comenzar desde allí.

Answer 3

Si piensa en la información que necesita guardar, realmente no es mucho;

E.g.

• Posición
• Orientación
• Inventario
• Salud
• estado Objetivo

Hay mucho más por supuesto, muchas de las cuales las dependencias por tanto en el tipo de juego y cómo la estructura de salvar está organizada.

Algunos juegos como Resident Evil solo permiten guardar cuando ingresas a una nueva zona lo que significa que no tienes que almacenar toda la información para las entidades en ambas zonas. Cuando "carga" un guardar sus atributos provienen del disco.

En cuanto a cómo se recuperan/modifican estos datos, no estoy muy seguro de entender. Solo son datos en la memoria de la consola. Cuando el jugador guarda está escrito en el dispositivo de guardar, y cuando lo carga se restaura.

Answer 4

Una técnica principal es el ahorro diferencial: solo el estado de ahorro es diferente de su valor predeterminado. Compara y contrasta "guardar el estado y la ubicación de cada objeto en el mundo del juego" con "guardar el estado y la ubicación de cada objeto en el mundo del juego que el jugador movió o modificó".

Answer 5

Creo que está sobreestimando la complejidad de lo que se almacena/recupera. No es necesario almacenar los modelos 3D para los objetos, ni sus texturas, ni ninguna de las cosas que componen grandes partes del tamaño del disco de un juego.

Antes que nada, como se menciona en el caos, solo es necesario almacenar información sobre las cosas que se han movido. Incluso entonces, probablemente solo necesite almacenar, para cada uno de ellos, la nueva posición y orientación (suponiendo que no haya otras variables involucradas, como "dañado"). Entonces eso son dos vectores para cada objeto, que estará alrededor de un gran total de 24 bytes por objeto. Eso significa que puede almacenar la información de 40,000 objetos por megabyte. Es un montón de objetos que se han movido.

Restaurar estos datos no es más complejo que colocar los objetos en primer lugar. Cada objeto debe tener una posición/orientación predeterminada definida para que el juego lo ubique en algún lugar, por lo que lo único que está haciendo es reemplazar el valor predeterminado con el valor almacenado en el archivo guardado. Esto no es complejo y no requiere ningún procesamiento adicional significativo.

Answer 6

Haciendo eco de las otras respuestas, el mayor ahorro proviene de la eliminación de todos los datos de estado innecesarios.

Si observa los juegos de desplazamiento lateral de 8 bits, comenzarán a descartar el estado tan pronto como las cosas estén fuera de la pantalla, y muchas veces no retienen nada, porque sus recursos son demasiado ajustados para mantener más que el mínimo de instancias.

Hacerlo en el nivel macro para un juego como Fallout 3 es simplemente una cuestión de aumentar el alcance del problema. Empiezas seccionando el paisaje por cuadrícula u otros métodos geométricos, y cosas de desove/desaparición a medida que el jugador se mueve de una sección a la siguiente. Lo ideal es mantener el tamaño de cada área pequeña para que el estado en memoria no sea alto. Calcula el estado mínimo necesario para mantener alrededor de las instancias de NPC y elementos, y en los datos de diseño etiqueta tanto como sea posible para reabrir automáticamente para que no se guarde ningún estado.

Si desea apuntar a una estructura de datos específica, un ejemplo de formato de serialización podría ser una secuencia lineal indexada por un árbol de punteros, donde la organización del árbol corresponde a la disposición del mapa.

Answer 7

En una nota relacionada, los motores de juego a menudo emplean la compresión Zip, para mantener el tamaño de todo ese contenido bajo y también para acelerar algunas operaciones.

Answer 8

Además de lo que todos los demás dijeron, me gustaría agregar que el estado no implica necesariamente solo posición y movimiento, sino también las propiedades para el estado respectivo. Por lo general, un motor de juego tiene una función que le permite guardar los datos de una determinada clase.

Digamos que tiene una clase de jugador y usted está bien en la historia, al hacer clic en guardar los datos posibles que pueden almacenarse es:

• Dónde está el jugador situado en el nivel/mapa
• ¿Cuáles son sus atributos: salud, maná, fuerza, inteligencia, etc
• ¿Qué habilidades tiene él.
• ¿Qué nivel tiene?

A nivel mundial también puede tener:

• ¿Cuántas referencias (nombres que permiten que el motor para recoger un objeto de una lista) a los objetos están siendo almacenada en ese nivel específico, en otra palabras cuando cargas qué objetos se deben cargar junto con él.
• ¿Estamos usando física? Si es así, ¿quién la usa?

Y muchos más. Fallout 3 tiene un tipo de guardar, otro juego tendrá otro. Realmente depende del género y el motor en uso.

Answer 9

En Fallout 3 en particular, el mapa está dividido en forma de cuadrícula. Solo puedes ver tu casilla actual y las que están inmediatamente después. El tipo de almacén de datos no es realmente importante: puede ser una base de datos SQLite, puede ser un árbol serializado en disco, o puede ser algo completamente diferente.

... que habría que tener un gigantesco conjunto de todos los objetos en el juego , y actualizar constantemente una lista más pequeña que contiene los objetos visibles a render?

Generalmente sí, pero la "matriz gigantesca" no necesita estar en la memoria. Y hay más listas: objetos en cuadrícula actual y adyacente (puede ser atacado desde atrás, no en la lista visible), la lista visible, la lista de temporizadores ...

Sucedería si finalmente tocara cada objeto en el juego? ¿Su juego de guardar se haría cada vez más grande?

Podría - si hay una tabla de estado predeterminada para todo, el guardado solo puede contener las diferencias. La salvación crecerá a medida que progreses.

Todo se conserva cuando sale/regresa a un lugar.

Nope. Los objetos que arrojes fuera de tu casa eventualmente desaparecerán. Cuerpos también, probablemente. Los monstruos aleatorios se reagrupan de vez en cuando. Esto es conveniente para los diseñadores de juegos y coherente con el mundo real.