Kingdom Engine Asset System Plan

Product outcome

A person arriving from Unreal, Unity, or Godot should be able to answer these questions without documentation:

1. Where are my project assets?
2. What level am I editing?
3. What is selected and where do I change it?
4. How do I create, import, reimport, preview, instance, and find an asset?
5. Which changes are editor-only, which are synchronized to play, and which require a rebuild?

The target workspace is intentionally familiar:

Garden is the authoritative asset and level authoring surface. Kingdom consumes the same saved level and presents runtime state. A renderer limitation may keep the runtime in a separate process, but it must not create a second asset model.

Current audit (2026-10-01)

This section is the authoritative implementation snapshot. The detailed tables below remain the capability-depth backlog: an older row marked Missing means the complete editor/runtime workflow described by that row is still missing, not necessarily that no registry descriptor or partial service exists.

Registry and workspace snapshot

• The built-in registry contains 64 asset types: 22 runtime-ready, 32 authoring-preview, and 10 experimental.

The 2026-10-17 UI Document authoring slice raises the registry to 65 types: 22 runtime-ready, 33 authoring-preview, and 10 experimental. It adds a validated widget hierarchy, anchor layout preview, asset reference checks, dedicated editor controls, Python operations, and a cooked preview artifact. Packaged player UI rendering and full UI/2D parity remain open.

• The engine workspace now has a project Content Browser, World Outliner, actor/component Details, prefab apply/revert, Sequence Editor, world-production tools, console, profiler, launch-readiness, and build/deploy panels.
• The first playable-project tranche is implemented through the public Python API and the same New Game dialog: a lit/collidable Level, active camera, skinned starter mannequin, editable skeleton and skin binding, IK/Control Rig, locomotion controller, input map, physics scene, player prefab, Ruleset, and Build Profile are created and validated as one dependency-closed operation.
• Starter variants currently include playable sandbox, third-person exploration and combat, first-person shooter, side-scroller, fighting, top-down action, and an 8-bit pixel platformer. Only variants backed by qualification evidence may be promoted from Preview to Production.
• Six explicit, Python-callable quality profiles cover cinematic 4K, high 1440p, balanced 1080p, performance 900p, low-spec 720p, and pixel-perfect 320 × 180. Visual style, project scalability, and renderer upscaling quality remain separate contracts.
• Play-state UX distinguishes Edit, Simulate, Paused, and standalone Play; Pause/Step are enabled only where supported, and Stop, Eject, and Reset have separate commands. Unsupported controls are not presented as functional.
• The viewport/selection tranche now supports Ctrl/Shift multi-selection in the viewport and outliner, multi-highlight, group focus/transform/duplicate/delete, cycle-safe parenting, folders, hide/isolate/show-all, persistent actor locks, ordered component stacks, camera piloting, nine persistent camera bookmarks, and selection-preserving level undo/redo. Workspace Undo/Redo routes to the focused level or dedicated asset/graph editor; Content Browser operations keep their recoverable operation history. The saved-Level Python API exposes the same actor query, transform, visibility, isolation, lock, duplicate/delete, folder, parenting, component-order, and camera-bookmark operations without requiring widget automation.
• The Content Browser lifecycle baseline now distinguishes source files, imported assets, authored assets, level-local instances, and current cooked artifacts. It includes persistent static/dynamic collections, structured and negated search, a recoverable cancel/retry import queue, thumbnail state badges, asset revision history, opt-in Perforce status/history/changelists and confirmed edit/add/revert/sync actions, project-wide redirect and legacy- reference repair, and matching headless Python operations. Imports copy in cancellable chunks on a worker and atomically publish only complete files.
• Content Browser scale qualification now emits a repeatable receipt for a deterministic 50,000-document inventory, compiled advanced-query latency, database inventory latency, throughput, and lifecycle capability evidence.
• The first high-value asset-editor depth pass replaces guidance-only pages with saveable and validated controls for material parameters/static switches, static and skeletal mesh geometry/material slots, animation-controller parameters/transitions, and effect timelines/scalability. These use the same serialized properties and import settings exposed to Python and cooking.
• The second depth pass adds texture channel transforms, mip policy and per-platform compression overrides; separates input actions, contexts and bindings with a non-destructive live value probe; and adds physical-animation drive and solver-profile authoring to Physics Assets. Invalid authored values block save, while the Python input API audits a candidate transaction before it is persisted.
• The character-production depth pass adds complete Animation Clip pages for tracks, curves, events, sync markers, root motion, additive setup and compression; Skeleton hierarchy, socket and retarget-pose authoring; and Skin Binding deformer stacks, transfer policy and export policy. Skeletons now have cycle-safe validation and a dedicated runtime cooker. Cross-page validation runs before save, and equivalent transactional Python operations reject bad hierarchy or binding changes before touching the asset.

Strong foundations already present

• AssetDatabase stores source records, dependencies, derived artifacts, invalidation events, and file watching.
• .tcscene is a versioned scene archive and already supports live changed-chunk publication to a connected playtest.
• .tcimg and .tcskin provide specialized image-project and skin-transfer persistence.
• Runtime compilation already discovers mesh, material, texture, collision, audio, and rig-blob dependencies.
• Static/skinned geometry, PBR and procedural materials, media textures, effects, physics, animation, rigging, simulation, procedural generation, and player packaging have meaningful implementation behind them.

Current launch gaps

• Core editor interactions still need end-to-end qualification: multi-selection, grouped transforms, component reordering, camera piloting/bookmarks, isolate/ hide/lock, cross-editor transactions, saved layouts, recent assets, and command search must all behave consistently on real projects.
• Content Browser qualification still needs physical representative-project UI evidence for thumbnail decode, incremental refresh, redirected depots, and multi-user Perforce failure/conflict paths. Synthetic 50k-query evidence is a repeatable regression gate, not a substitute for hardware/project testing.
• Cooperative mid-file cancellation is implemented for the built-in file-copy importer. Future decoding/transcoding importers must call the same cancellation checkpoints inside their own expensive phases before they qualify.
• The 32 authoring-preview and 10 experimental asset types need type-specific editor/runtime qualification; registry presence and a visible editor page are not parity evidence.
• Cooking/building still needs resumable orchestration, cancellation, exact asset-linked failure reporting, size/cost reports, and broader platform proof.
• UI/2D, localization, accessibility, media-playlist, geometry/VDB cache, addressable/DLC, replay/benchmark, and automation-test workflows need broader first-class coverage.
• Native runtime launch gates remain open for broad GPU backends, shader/pipeline caches, streaming stress, job scheduling, network prediction, save migration, and golden scenes across supported hardware.

Execution order

1. Implemented; qualification continues: default playable project, template, quality, and explicit runtime-state UX.
2. Implemented baseline; qualification continues: viewport selection, hierarchy, component ordering, camera navigation, and transaction routing.
3. Implemented baseline; qualification continues: Content Browser lifecycle, reference safety, collections, search, import queue, revision/VCS views, and explicit content/cook states.
4. In progress: deepen the highest-value asset editors; the first mesh, material, animation-controller, and effect-system authoring controls are now joined by texture, input-map, Physics Asset, Animation Clip, Skeleton, and Skin Binding controls. They are saveable, validated, undoable, cook-backed, and Python-backed. Viewport manipulation, richer bulk editing, and measured per-platform proof remain.
5. Make cook/package/build guided, resumable, and diagnostically precise.
6. Add the missing first-class asset workflows.
7. Close native runtime and hardware qualification gates.

Canonical model

Four kinds of project content

1. Source — externally authored truth such as FBX, USD, glTF, PNG, EXR, WAV, OGG, VDB, Alembic, fonts, video, and source code.
2. Authored asset — an engine-editable resource with a persistent UUID, schema, properties, references, import provenance, and editor routing.
3. Instance — a level-local placement or component that references assets; it is not a duplicate asset.
4. Derived artifact — platform/quality-specific cooked data. It is disposable, reproducible, read-only, and never the authoring truth.

Required asset descriptor

Every first-class type registers one AssetTypeDescriptor:

type_id, display_name, family, icon, color, schema_version
extensions, creatable, importers, factory
editor_id, previewer_id, inspector_schema, thumbnailer_id
dependency_extractor, validator, cooker, runtime_loader
hot_reload_class, export_adapters, migration_chain

Every authored asset carries:

asset_id (UUID, never path-derived)
type_id and schema_version
display_name and project-relative virtual path
source provenance and importer settings
hard, soft, editor-only, and build-only references
tags, collections, owner, revision, content hash
platform/quality overrides

Use a common .tcasset envelope for new engine-native resources and .tcmeta sidecars for imported sources. Existing .tcscene, .tcimg, and .tcskin files remain supported specialized containers and gain the same UUID/reference header. Moves create temporary redirects; validation can later fix references and remove the redirect.

Complete asset taxonomy

Status meanings:

• First-class — independently persisted and broadly usable today.
• Embedded/partial — meaningful implementation exists but lacks the complete asset lifecycle.
• Missing — needs a new contract and/or substantial tool/runtime work.

Project, world, and composition

Geometry and environment

Rendering, materials, and images

Animation and character

FX, simulation, and physics

Audio and media

Gameplay, scripting, AI, and data

UI, 2D, localization, and accessibility

Build, delivery, and diagnostics

Per-type definition of done

An asset type is not complete because a runtime struct exists. It is complete only when all applicable gates pass:

1. Registered descriptor and versioned serialization.
2. Create/import/reimport path with presets and clear errors.
3. Stable UUID, dependency extraction, reference fixing, move/rename safety.
4. Thumbnail and compact hover summary.
5. Inspector schema with defaults, reset, multi-edit, undo/redo, tooltips and basic/advanced grouping.
6. Dedicated editor or truthful preview, including an empty state and next step.
7. Drag/drop semantics into a level or compatible property.
8. Validation, source-control state, dirty state, and save behavior.
9. Derived-data cooker plus platform and quality overrides.
10. Runtime loader, memory accounting, hot-reload class and failure fallback.
11. Export/interchange policy and loss report where applicable.
12. Unit, round-trip, corrupt-input, migration, performance and golden-preview coverage.

Interaction rules familiar to engine users

• Double-click opens the correct contextual editor.
• Drag an asset into Garden to create an instance; drag it onto a compatible Inspector property to assign a reference.
• Right-click and + Add expose the same searchable Create menu.
• Selecting a source asset shows Import; selecting an authored asset or scene object shows Inspector.
• F frames selection, Ctrl+P quick-opens any asset, and breadcrumbs support back/forward navigation.
• Rename/move is reference-safe. Delete always lists referencers and offers replace, fix, or cancel.
• Hover shows type, path, dimensions/duration/polycount, import status, revision, dependencies, and platform warnings.
• Every editor uses the same Save, Locate in Assets, Find References, Reimport, Validate, and Play/Preview actions.
• Basic mode shows creative controls; Advanced mode reveals compiler, solver, memory, platform, and low-level settings.

Delivery phases

Phase 0 — Asset kernel and familiar shell

Build AssetTypeRegistry, UUID metadata, redirect/fix-up support, source versus derived distinction, editor routing, and a dockable Assets browser. Add searchable Create/Import, grid/list views, breadcrumbs, filters, favorites, collections, thumbnails, Inspector/Import routing, drag/drop, reference search, and validation.

Acceptance: a user can import, locate, rename, move, reimport, inspect, preview, instance, find referencers, delete safely, and undo the relevant operation without opening a command console.

Phase 1 — Playable 3D vertical slice

First-class: Level, Prefab, Static Mesh, Skeletal Mesh, Skeleton, Skin Binding, Animation Clip, Material, Material Instance, Shader Graph, Texture, Collision, Physical Material, Behavior Script/Gameplay Graph, Data Asset, Input Map, Effect System, Simulation Profile, Audio Clip, Game Ruleset, Build Profile.

Acceptance: import a character/environment, construct a reusable prefab, add input/gameplay, play the current Garden level in Kingdom, edit a material/effect, see live sync, and package without manually entering a path.

Phase 2 — Specialized editors and world building

Animation state machine/blend space/retargeting, terrain, foliage, splines, navigation, AI trees/blackboards, audio graph/mixer, cinematics, environment, post process, render targets, sprites/atlases, UI documents, fonts, localization, import presets.

Phase 3 — Top-tier simulation and character assets

Cloth, soft body/flesh/jiggle, destruction, fluid/smoke/fire/goop domains, simulation caches, VDB/geometry caches, groom/hair, physics assets, Control Rig, facial/phoneme assets, replication profiles, replay and benchmark assets.

Phase 4 — Large-project production

World streaming/data layers, addressable groups/DLC, multi-user locks and ownership, source-control status, bulk operations, dependency-size analysis, asset audit dashboards, automated migrations, redirect cleanup, headless cooks, and qualified platform build profiles.

First executable slice

Implement Phase 0 in this order:

1. AssetTypeDescriptor and AssetTypeRegistry with explicit built-in type IDs.
2. UUID identity and .tcmeta sidecars; preserve the current path-derived ID as a migration alias only.
3. Asset operations service for create/import/reimport/move/rename/delete/fix-up.
4. Editor/preview/inspector routing registry.
5. Assets browser integrated beside Scene in Garden and Kingdom.
6. Register the Phase 1 types already backed by runtime systems before creating new specialized editors.
7. Extract Material, Effect System, Simulation Profile, Gameplay Graph, Input Map, Data Asset, and Prefab from scene-only metadata into independently reusable resources while maintaining embedded-data migration.

The first demonstration should be deliberately small: import a mesh and texture, create a material instance and prefab, place it in Garden, move the asset safely, find its level referencer, press Play Current Level, edit one exposed value, and observe Kingdom update without a rebuild.

Benchmark rationale

• Unreal treats project content as assets managed through the Content Browser, including both imported content and engine-authored types such as Blueprints.
• Unity presents one asset workflow spanning import, authoring, build, delivery, and runtime loading; its Project/Hierarchy/Scene/Game/Inspector separation is immediately legible.
• Godot uses a broad serializable Resource base and treats saved scenes as instantiable PackedScene resources, while keeping import settings beside source files.

Tech Connector should borrow those learned interaction patterns while retaining its differentiator: one portable scene and asset graph spanning DCC authoring, live simulation, game runtime, and explicit interchange fallbacks.

Primary references:

• Unreal Engine: Assets and Content Packs
• Unreal Engine: Working with Assets
• Unreal Engine: Recommended Asset Naming Conventions
• Unity 6: Asset Workflow
• Unity: ScriptableObject
• Godot: Assets Pipeline
• Godot: Resources