Files
primalwiki/CONTEXT.md
2026-04-02 20:58:48 +02:00

2.2 KiB

Project Context

Concept

Interactive encyclopedia/learning app for the Primal Diet by Aajonus Vonderplanitz.

Graph-like structure as the primary navigation metaphor:

  • Interactive human body map as entry point
  • Body parts/systems → link to ailments
  • Ailments → link to recipes
  • Recipes → link to ingredients
  • Ingredients → link to properties/details

Content

Sourced from books by Aajonus Vonderplanitz. Curated by the owner only — no community editing, no authoring UI. All data hardcoded or loaded via config files, embedded in the binary at compile time.

Deployment Targets

  • Native executable (all data embedded in binary)
  • Browser via WASM (same codebase, two build targets)

UX Vision

Game-engine style — custom rendering, animations, smooth transitions, physics-based graph layouts. Not a traditional web UI.

Tech Stack

  • Zig + raylib-zig + Emscripten — chosen. Native binary and WASM from the same codebase. Package managed via build.zig.zon.
  • Raylib + C++ + Emscripten — considered, but Zig's @embedFile and compile-time data embedding are a better fit.
  • Mach (Zig game engine) — discarded, pre-1.0 and still maturing.
  • Three.js + Electron — discarded. Electron too heavy, sidesteps WASM.

Current Implementation State

Graph navigation is working (src/main.zig):

  • Data model: nodes of five kinds — body_part, ailment, recipe, ingredient, property — with typed link lists, all hardcoded in the binary.
  • Navigation: root view shows body systems in a radial ring; clicking any node drills into it, placing it at the centre with its linked nodes in orbit. Right-click or B navigates back. Nav history kept in a fixed-size stack.
  • Rendering: colour-coded circles per node kind, glow on hover, selection ring on the active centre node, edge lines to linked nodes, breadcrumb trail, colour legend, navigation hints.
  • WASM path: emscripten_set_main_loop hook in place; same drawFrame callback used for both targets.

Constraints

  • No widget toolkits — fully custom rendered
  • No authoring UI — content is defined in code or config
  • Same codebase must target both native and WASM