Open Source Implementation of the 2004 Video Game, Fable

Tackling a reimplementation of Fable (2004) — often affectionately dubbed by the community as something like "OpenAlbion" or "OpenFable" — is a massive but rewarding undertaking. Because Fable is a complex, 3D action-RPG with proprietary physics, scripting, and AI systems, your project needs strict foundational rules to survive. Here is a comprehensive developer guideline and descriptive manifesto to serve as the "North Star" for your repository. --- ## Project Overview: OpenAlbion **Mission:** To create a modern, cross-platform, open-source engine capable of running *Fable (2004)* and *Fable: The Lost Chapters*. This project is an **engine reimplementation**. We are building the car; the user must supply the gas. The engine will read the original game data, handle the logic, and render the graphics using modern APIs. We aim for 100% vanilla parity first, followed by quality-of-life modernizations (uncapped framerates, ultrawide support, improved modding). ## 1. The "Clean Room" Legal Directive To protect the project and its contributors from DMCA takedowns, we adhere strictly to clean-room design principles. * **No Original Code:** You may not copy, paste, or directly translate leaked source code, decompiled binaries, or disassembled assembly from the original executable into this repository. * **No Assets in Repo:** Do not commit *any* original game assets (textures, sounds, models, animations, scripts) to the repository. Even a single proprietary icon is a copyright violation. * **Black-Box Reverse Engineering:** We observe the game's behavior (memory values, file outputs, network packets, visual rendering) and write fresh code that replicates that behavior. * **Asset Requirement:** The engine must be hardcoded to check for a legally obtained Fable installation directory before booting. ## 2. Technical Stack Recommendations Choose a stack that balances high performance with modern developer ergonomics. | Component | Recommendation | Rationale | | --- | --- | --- | | **Core Language** | C++20 or Rust | Essential for memory management and performance in a 3D RPG. | | **Window/Input** | SDL2 | Industry standard for cross-platform window creation and gamepad support. | | **Graphics API** | Vulkan / OpenGL 4.5 | Vulkan offers the best modern performance; OpenGL acts as a stable fallback. | | **UI Framework** | Dear ImGui | Perfect for building internal debug tools and reverse-engineering inspectors. | ## 3. Development Phases Do not attempt to build the combat system before you can draw a tree. We will build the engine in strict layers. ### Phase 1: The Virtual File System (VFS) Fable packages its data into proprietary archive files (`.wad`, `.big`, or specific Lionhead formats). * **Goal:** Build an archive parser that mounts the user's Fable directory on the fly. * **Rule:** The engine must read these files directly from disk into memory without permanently unpacking them to the user's hard drive. ### Phase 2: Asset Parsing & Rendering Before things move, they must be drawn. * **Goal:** Reverse-engineer the file headers for 3D meshes, textures, and skeletal rigs. * **Milestones:** Render static level geometry, apply textures, load character models, and finally, play standard idle animations. ### Phase 3: World State & Scripting Fable is heavily driven by scripts for quests, NPC schedules, and the morality system. * **Goal:** Map out Lionhead's proprietary scripting language or bytecode. * **Milestones:** Create a script interpreter that can execute original quest triggers, read NPC AI routines, and handle the "Hero Save" logic. ### Phase 4: Physics & Gameplay Mechanics Replicating the "feel" of Fable is the hardest part. * **Goal:** Implement collision, combat math, and the physics engine. * **Milestones:** Replicate the flourish combat timing, spell targeting (Will powers), and the Havok-style ragdoll physics used in the original release. ## 4. Reverse Engineering Guidelines When tearing down Fable's proprietary systems, contributors should follow this workflow: 1. **Hex Editors & Hex Rays:** Use tools like Ghidra or r2 *only* to understand data structures and algorithms, not to copy code. **Document First:** Before writing a parser, write a Wiki page documenting the binary structure of the file format (e.g., "The Fable `.STB` string file format consists of a 4-byte header..."). **Build Viewers:** Write standalone, lightweight debug tools (using ImGui) to view isolated assets—like a standalone Fable Model Viewer—before integrating that code into the main engine. ## 5. Community & Modding Ethos While vanilla parity is the primary goal, OpenAlbion is designed to eventually surpass the original engine's limits. * **Hardcode Nothing:** If a value (like max health, weapon damage, or UI scale) was hardcoded in the original 2004 executable, expose it in a JSON or XML configuration file in our engine. * **Embrace Modders:** The Virtual File System should eventually support a "mod folder" priority override, allowing players to load custom textures and scripts without overwriting their base game files.

A complete project foundation: clean-room contribution policy and legal compliance checklist, full engine architecture design document (module boundaries, threading model, C++20 stack with SDL2/Vulkan/ImGui), CMake-based repository skeleton with CI configuration, coding standards, and an extensive reverse-engineering wiki documenting the known binary layouts of Lionhead archive containers (.big, .wad, .stb, .lev) with annotated header tables, field-by-field structure specs, and a documented black-box RE workflow for contributors.

Working C++20 code for the VFS layer: memory-mapped readers for the .big/.wad container formats that mount a user-supplied legal Fable installation without unpacking to disk, install-directory validation and boot gate, a layered mount system designed for future mod-folder overrides, an entry indexing/caching subsystem, a CLI archive inspector (list/extract-to-memory/hash entries), full unit test suite against synthetic fixture archives generated from the documented specs, and developer documentation for the VFS API.

Parsers for the core asset formats: texture decoding (DXT/palettized variants per the documented specs), 3D mesh and skeletal rig parsing, animation track decoding, and the .stb string/localization format. Includes standalone ImGui-based debug tools — a Model Viewer, Texture Browser, and Archive Explorer — built as isolated executables before engine integration, plus wiki pages documenting each format discovered, conversion utilities to open interchange formats for verification, and test coverage with synthetic fixtures.

The Vulkan renderer with OpenGL 4.5 fallback: render-graph abstraction, shader pipeline (GLSL sources for terrain, static meshes, skinned characters, and Fable's stylized lighting), level geometry loading and culling, texture streaming from the VFS, skeletal animation playback system with blending, a free-fly debug camera, and in-engine ImGui inspectors for draw calls, scene hierarchy, and animation state. Delivered as buildable code with renderer architecture documentation and frame-capture validation notes.

A clean-room interpreter for Lionhead's quest scripting/bytecode system: documented opcode reference produced via black-box observation methodology, a stack-based VM with tracing debugger and ImGui script inspector, world-state management (regions, entity spawning, NPC schedule framework), the morality/alignment state model, Hero save-game serialization (load and write compatibility with original saves), and an integration harness that executes the opening quest triggers end-to-end with regression tests.

Gameplay systems replicating vanilla parity: collision world (navmesh walking, raycasts, trigger volumes), combat math with flourish timing windows, Will-power spell targeting, impulse-based ragdoll approximating the original Havok behavior, and frame-timing work for uncapped framerate correctness. Plus the modding ethos deliverables: every formerly hardcoded constant externalized into documented JSON config files, VFS mod-folder priority overrides, a modder's guide, and a tuning/inspection ImGui suite for comparing behavior against the original game.