Ein Spielstand ist meist genau dann undurchsichtig, wenn man ihn am dringendsten braucht — dieser Betrachter erkennt deshalb die Familien, die echte Spiele verwenden, und zeigt, was jede Spezifikation offenlegt. Das NBT der Minecraft-Familie wird Tag für Tag gemäß der wiki.vg-Spezifikation geparst (alle 12 Tag-Typen, gzip/zlib/raw-Hüllen — level.dat ist gzip, servers.dat roh). Unreal-Engine-Saves werden über die Magie "GVAS" erkannt und gemäß dem uesave/gvas-Layout dekodiert: Save-Version, UE4- und UE5-Paketversionen, das FEngineVersion-Tupel mit Branch-String und die Tabelle benutzerdefinierter Versionen; Palworld-Saves aus Steam werden über ihren echten Container (zwei Header-Ints, "PlZ1"-Magie, zlib-Strom) bis zur GVAS-Nutzlast entpackt. SQLite-Saves werden über node:sqlite nur-lesend geöffnet und Tabelle für Tabelle mit Zeilenzählungen und Vorschauzeilen aufgelistet. Textsaves werden strukturell erkannt: JSON (Deck-Builder-Stil), XML (ein Stardew-Valley-SaveGame wird an seinen dokumentierten Root-Feldern erkannt), INI (einschließlich [/Script/…]-Konfiguration von Unreal) und Lua-Tabellen (Hades-Familie). Zip-Container werden mit ihren inneren Einträgen gemeldet. Alles übrige fällt auf eine Shannon-Entropie-Lesung, einen Hex-Dump der ersten 256 Bytes und einen Scan druckbarer Strings zurück, mit einer String-Heuristik für Source-Engine-.sav-Dateien, deren Block-Token (ADVSYS, EntityPatch, Response System…) in der Valve Developer Community dokumentiert sind. Fortschrittsrelevante Felder (name, level, gold, health, seed, playtime…) landen in einem Schlüsselfakten-Panel, und jedes Parsen ist begrenzt — Knotenbudget, Tiefenlimit, Array-Vorschauen —, denn Spielstände sind nicht vertrauenswürdige Eingaben. Wo leben Saves? Steam-Cloud-Spiele halten sie unter Steam/userdata///remote (laut Steamworks-Dokumentation); der Rest, wo das Spiel will. Dieses Werkzeug verändert Ihre Datei nie — es liest eine Kopie im Speicher und rendert nur.