Skip to main content

Architecture and Roadmap

Procedural Recipes are intended to become a consumer-neutral procedural kernel. The current Tile, Material, and SDF document types are the compatibility base for that evolution.

Architectural boundary​

Recipe core
parsing and validation
deterministic fields and patterns
colors and surface materials
SDF coverage
consumer-neutral render surfaces
|
+-- Tile / project adapter
+-- Avatar wearable adapter
+-- Avatar headgear adapter
+-- future UI adapter
+-- future paint and stamp adapters
+-- future geometry adapter

The core must not depend on Avatar, UI, map, ruleset, or renderer-specific entity types. A consumer supplies dimensions, coordinate mapping, seed, time, palette, and any semantic masks. It then converts the typed result into its own representation.

Ownership​

  • A recipe owns procedural visual logic and named outputs.
  • A Material owns reusable surface appearance.
  • An SDF owns reusable coverage or silhouette.
  • A consumer binding owns context such as equipment channels, map placement, widget state, or target dimensions.
  • A ruleset or item owns gameplay meaning.

For example, a helmet item owns its head slot and armor value, its SDF owns the silhouette, its Material owns the hammered-metal appearance, and the Avatar adapter owns fitting those assets to each frame.

Stability policy​

New work should preserve existing Tile and Material documents. Shared primitives should be generalized underneath those documents rather than replacing their syntax prematurely.

When a new consumer is added:

  1. define the small typed output contract it needs;
  2. define the coordinate and seed context it supplies;
  3. reuse existing recipe outputs where possible;
  4. keep consumer-specific metadata outside the recipe;
  5. add deterministic previews and cache signatures;
  6. document whether the binding is stable or experimental.

Planned directions​

These are design goals, not currently supported authoring contracts:

  • richer shared SDF primitives, transforms, repetition, and smooth operations;
  • canonical Avatar part coordinates and optional authored UV guides;
  • recipe-driven buttons, panels, borders, and icons with UI state inputs;
  • procedural brushes and stamps using shared coverage and materials;
  • particle-emitter outputs;
  • consumer-neutral geometry output with extrusion and placement adapters;
  • complete recipe-authored Avatar parts while retaining current atlases;
  • a visual Recipe editor backed by the same canonical text format.

The guiding constraint is that a feature should strengthen the shared procedural vocabulary. It should not create another isolated procedural subsystem that only one Eldiron tool can understand.