Crate Dependency Graph

This page shows how Flint’s twenty-six crates (plus the tools/arch-analyzer workspace member) depend on each other. Dependencies flow downward — higher crates depend on lower ones, never the reverse.

Dependency Diagram

                     ┌─────────────┐
                     │  flint-cli  │  (binary; also embeds the player)
                     └──────┬──────┘
                            │
      ┌──────┬──────┬───────┼────────┬──────────┬───────────┐
      ▼      ▼      ▼       ▼        ▼          ▼           ▼
  ┌──────┐┌─────┐┌──────┐┌────────┐┌────────┐┌───────┐┌────────────┐
  │viewer││query││const ││asset-gen││procgen ││ music ││flint-player│ (binary)
  └──┬───┘└──┬──┘└──┬───┘└───┬────┘└───┬────┘└──┬────┘└─────┬──────┘
     │       │      │        │         │        │           │
     ▼       │      │        │         │        ▼           │
  ┌────────┐ │      │        │         │ ┌─────────────┐    │
  │debug-ui│◄┼──────┼────────┼─────────┼─┤input-capture│◄───┤  (player → debug-ui is optional)
  └──┬─────┘ │      │        │         │ └─────────────┘    │
     │       │      │        │         │                    │
     ▼       │      │        │         │   ┌────────┬───────┼────────┬──────────┐
  ┌────────┐ │      │        │         │   ▼        ▼       ▼        ▼          ▼
  │ render │◄┼──────┼────────┼─────────┼───────────────────────────────────────────┐
  └──┬──┬──┘ │      │        │         │ ┌──────┐┌───────┐┌────────┐┌─────────┐┌─────────┐
     │  │    │      │        │         │ │script││physics││ audio  ││animation││particles│
     │  ▼    │      │        │         │ └──┬───┘└───┬───┘└───┬────┘└────┬────┘└────┬────┘
  ┌────────┐ │      │        │         │    └────────┴────────┴──────────┴──────────┘
  │terrain │ │      │        │         │                       │
  └───┬────┘ │      │        │         │                       ▼
      │      │      │        │         │                 ┌───────────┐
      ▼      ▼      ▼        ▼         ▼                 │  runtime  │
  ┌──────┐┌────────────────────────────────────────┐     └─────┬─────┘
  │scene ││                 flint-ecs               │◄──────────┘
  └──┬───┘│      (hecs wrapper, stable IDs)        │
     │    └──────────────────┬──────────────────────┘
     │                       ▼
     │                ┌──────────────┐        ┌────────┐        ┌────────┐
     └───────────────►│ flint-schema │        │ import │───────►│ asset  │
                      └──────┬───────┘        └───┬────┘        └───┬────┘
                             ▼                    ▼                 ▼
                      ┌─────────────────────────────────────────────┐
                      │                  flint-core                  │
                      │       (EntityId, Vec3, Transform, Hash)      │
                      └─────────────────────────────────────────────┘

The long arrow into render comes from the player (top right) and from viewer and debug-ui; the systems row beneath it (script, physics, audio, animation, particles) does not depend on render. Some edges are left out for legibility (every crate reaches flint-core; render, animation, viewer and asset-gen reach import; render reaches scene; terrain also feeds debug-ui). The table below is complete.

Dependency Details

Key Properties

Acyclic. The dependency graph has no cycles. This is enforced by Cargo and ensures clean compilation ordering.

Layered. Crates form clear layers:

1. Core — fundamental types (flint-core)
2. Schema — data definitions (flint-schema)
3. Storage — entity and asset management (flint-ecs, flint-asset)
4. Logic — query, scene, constraint, import, asset-gen, procgen, procgen-ai, music
5. Systems — render, terrain, runtime, physics, audio, input-capture, animation, particles, script
6. Tooling overlays — debug-ui (panels over the renderer), viewer
7. Applications — player, android
8. Interface — CLI binary (flint-cli), player binary (flint-player)

Two entry points. The CLI binary (flint-cli) serves scene authoring, validation, and the rhythm-game tooling (play-chart, replay-chart, render-suite). The player binary (flint-player) serves interactive gameplay, and flint-cli embeds it so flint play and flint-player run the same code. Both share the same underlying crate hierarchy.

Mostly independent subsystems. The constraint, asset, physics, audio, particles, asset generation, and render systems don’t depend on each other. The exceptions are deliberate: flint-script depends on flint-physics (raycasts, camera direction) and flint-animation (layer and sequence bindings); flint-input-capture depends on flint-music for the InputEvent type and clock bridge; flint-render depends on flint-terrain for the shared vertex format and on flint-scene for the post-process and environment definitions; and flint-debug-ui depends on flint-render because its panels mirror and write through to renderer state. Most subsystems can still be built and tested in isolation.

External Dependencies

Key third-party crates used across the workspace: