1 external engine patterns and boundaries
forgejo-actions edited this page 2026-07-13 19:45:35 +00:00

External Engine Patterns And Boundaries

This ledger records external engine patterns that informed Aether's architecture. It is not a commitment to mirror another engine wholesale. Each entry names the useful constraint, the Aether-shaped direction, and the boundary that keeps authored data, runtime state, and server authority idiomatic to this Rust workspace.

Engine or system Pattern Aether direction Boundary
Bevy ECS Relationships and required components Use ECS relationships where they remove local ownership glue for scene graphs, preview roots, spawned children, NPC or trigger attachments, editor selections, detach-before-delete flows, and clone safety. Use required components for common marker bundles such as scene roots, graph nodes, actors, interactables, and authoring preview entities. Keep serialized authored graphs independent of Bevy entity ids and hierarchy internals. Pilot relationships narrowly and prove despawn, detach, clone, save/load remapping, and undo/redo behavior before broader rollout.
Bevy asset pipeline Asset dependencies and custom loaders Treat authored files as dependency-declaring inputs for validation, invalidation, local preview, and bake manifests. Keep custom loaders thin: load raw authored assets or prepared caches, then let domain code validate and convert them. Do not hide authoring dependency decisions in loader side effects. Bake records retain explicit source hashes, dependency signatures, output ids, schema versions, and validation summaries.
Unreal Gameplay Tags Hierarchical semantic tags shared across gameplay systems Use a shared taxonomy for conditions, facts, effects, actions, diagnostics, validation, and editor filtering so authoring tools and authority code share a vocabulary. Tags classify and route behavior. Authority-critical rules remain typed Rust code, with validation around authored tag use.
Unreal Gameplay Ability System Data-driven actions and effects backed by typed execution Shape the effect/action kernel around explicit inputs, costs, target filters, conditions, emitted events, and diagnostics so preview, replay, and server authority can compare outcomes. Avoid a reflective mega-framework. Combat math, anti-cheat checks, persistence mutations, and packet effects stay typed and testable.
Unreal Data Registries Typed read-only catalogs resolved by gameplay code Keep quest, NPC, dialogue, item, encounter, UI, and game-data catalogs as typed registries that local preview, standalone packs, and server authority can load from the same prepared data. Runtime registries are read-only. Authoring edits pass through transactions, validation, and bake manifests before becoming registry entries.
Unreal StateTree Authored AI graphs with parameters, context, evaluators, tasks, and transitions Use enemy and encounter work as the proving ground for data-driven AI. Authored state-tree-style assets may select behavior while runtime tasks remain typed and observable. AI graphs are not a second scripting language for trusted server logic. State transitions report trace data and validation issues for editor diagnostics.
Unity ScriptableObjects Authored data containers separated from runtime systems Keep authored definitions as stable, inspectable records with ids, references, validation metadata, and migration paths. Runtime systems consume resolved DTOs or registry entries instead of mutating authoring documents. Live runtime state belongs in session resources, authority snapshots, or save data, never in authored assets.
Unity Entities baking Stateless conversion from authoring inputs to runtime-ready data Model bakers as dependency-aware conversions that emit runtime caches, manifests, validation summaries, and invalidation data for preview, standalone, and server startup. Bakers do not own hidden mutable state or unrelated writes. The runner owns filesystem I/O; the baker declares inputs, outputs, schema, dependencies, and diagnostics.

Practical Rules

  • Prefer small Bevy ECS pilots when a relationship or required component removes repeated glue and can be verified with focused edge-case tests.
  • Keep authored data, runtime DTOs, and ECS entities separate enough that save files, server authority, and replay fixtures do not depend on Bevy internals.
  • Treat tags, registries, and state-tree-style AI as authoring and diagnostic affordances around typed runtime code, not replacements for authority logic.
  • Route external-engine inspiration through Aether's transaction, validation, bake, replay, and protocol boundaries before expanding a pattern.