Darklands Restoration Project

Before anything can be rewritten, every function needs a name. The AI agent worked through all 388 functions across 14 code segments, naming each one by analysing Ghidra pseudocode. The naming pass produced a segment map covering decompressors, a pack file reader, a renderer, and CRT-layer functions whose Borland origins show through in coding patterns, though these are static identifications, not runtime proofs.

The systems that have been runtime-validated are the ones that matter most: the custom record-driven loader (an RTLink-derived overlay system that packs the game's entire code into DARKLAND.EXE itself, with its stub table confirmed at 0x1b465–0x1b52d) and the 99-state game loop dispatched via a far function pointer table, with the dispatch mechanism confirmed live at 0x13cd1.

Runtime validation runs on a custom patched DOSBox-X instance: the agent sets breakpoints and captures register and memory state while a human pilot navigates the graphical menus. That hybrid workflow carried Phase 1 across the finish line and is now the primary tool for Phase 2.

Having a name for every function is only the beginning. Phase 2 goes inside each subsystem to understand exactly what it does: how data structures are laid out in memory and on disk, how algorithms work, how the game state machine transitions between its 99 states.

On the disassembly side: the add-to-party overlay has been traced end-to-end through four layers: RTLink stub → far dispatcher (15DF:0329) → setup wrapper (15DF:0348) → slot writer (15DF:0D59) → UI finalization, all runtime-confirmed. The Create New World overlay worker is characterised: a four-slot reuse cache, a counted variable-length record blob at DS:A895, and slot/UI initialization. The setup/menu selector text system is a template engine with $-token substitution and jump-table dispatch. The loader resolver records (0x12-byte format) are decoded. The character hot-slot layout (DS:0x9C00, stride 0x80, in-party flag at +0x69) and the RNG (LCG, seed at 0x7B20) are confirmed.

On the format side: save files, the CAT archive system, world data (locations, cities, enemies, items, saints, alchemy), the wilderness map (328×932 RLE hex grid), the PAN animated sequence format, DGT audio, bitmap fonts, and dialog trees are all documented. Several formats remain undocumented. Everything documented is browsable in the DARK tool.

Still in progress: the full character struct base, save/load function mapping, and complete state handler identification across all 99 game states.

Phase 3 has not started yet. It begins once Phase 2 has produced sufficient coverage of the game's core systems. The planned approach uses Spice86, a reverse engineering framework for 16-bit real-mode x86 programs. Its key capability: the original DOS executable runs alongside C# override functions in a hybrid execution model. You replace one function at a time, verify it behaves identically, and move on to the next. The game remains fully playable throughout.

This is exactly how Cryo's 1992 Dune game was reverse engineered in the Cryogenic project. Phase 3 will apply the same approach to Darklands: each system fully mapped in Phase 2 becomes a C# override, validated against the real executable.