Un archivo de partida suele ser opaco justo cuando más lo necesitas, así que este visor reconoce las familias que los juegos reales usan y muestra lo que cada especificación expone. El NBT de la familia Minecraft se analiza etiqueta a etiqueta según la especificación de wiki.vg (los 12 tipos de etiqueta, envoltorios gzip/zlib/raw — level.dat es gzip, servers.dat raw). Los saves de Unreal Engine se identifican por la magia "GVAS" y se decodifican según el diseño de uesave/gvas: versión del save, versiones de paquete UE4 y UE5, la tupla FEngineVersion con su rama, y la tabla de versiones personalizadas; las partidas de Palworld de Steam se desenvuelven a través de su contenedor real (dos enteros de cabecera, magia "PlZ1", flujo zlib) hasta la carga GVAS. Los saves en SQLite se abren en solo lectura con node:sqlite y se listan tabla a tabla con recuentos y filas de vista previa. Los saves de texto se detectan estructuralmente: JSON (estilo deck-builder), XML (un SaveGame de Stardew Valley se reconoce por sus campos raíz documentados), INI (incluida la configuración [/Script/…] de Unreal) y tablas Lua (familia Hades). Los contenedores Zip se informan con sus entradas internas. Todo lo demás cae en una lectura de entropía de Shannon, un volcado hexadecimal de los primeros 256 bytes y un barrido de cadenas imprimibles, con una heurística de cadenas para los .sav de Source engine cuyos tokens de bloques (ADVSYS, EntityPatch, Response System…) están documentados en la Valve Developer Community. Los campos relevantes para el progreso (name, level, gold, health, seed, playtime…) se extraen a un panel de hechos clave, y cada análisis está acotado — presupuesto de nodos, límite de profundidad, vistas previas de arrays — porque las partidas guardadas son entrada no confiable. ¿Dónde viven los saves? Los juegos con Steam Cloud los guardan en Steam/userdata///remote (según la documentación de Steamworks); el resto depende del juego. Esta herramienta nunca modifica tu archivo — lee una copia en memoria y solo renderiza.