Data Catalogs

Data Catalogs are the bridge between simple serialized data and real runtime/editor values.

Instead of storing direct object references everywhere, you store stable ids:

• catalog id (Catalog)
• entry key (Key)

Then the system resolves those ids to actual values through registered catalogs.

Why This Architecture Is Powerful

• Serialization everywhere: Data remains plain and serializable across ScriptableObjects, JSON, save files, and tooling.
• Stable schema: Your runtime model does not need to change when underlying asset providers change.
• Inspector-friendly: You can still select assets visually (dropdown + preview) while storing only string keys.
• Portable data: Key-based data can be authored in-editor, generated by tools, or loaded from external sources later.
• Future-ready pipelines: The same key model works for local catalogs now and remote/web-fed catalogs later.

Real-World Benefit

You can keep a field like IconKey as two strings, but in inspector it still behaves like asset selection.

That means:

• designers get clear previews and dropdowns
• serialized data stays lightweight and diff-friendly
• runtime can resolve values from whichever catalog source is currently registered

Core Interfaces

• ICatalog - catalog identity + key listing
• IAssetCatalog / IAssetCatalog<T> - key to value resolution
• AssetCatalog<T> - common typed implementation

Registration Model

Catalogs are registered via ServiceLocator using catalog id as key:

Consumers resolve by key:

Web / Remote JSON Direction

This model also supports future external content flows:

• import data from local JSON files
• fetch remote JSON payloads
• map incoming ids to catalog keys
• resolve runtime values from registered providers

The key point is that your gameplay schema stays unchanged because it already stores ids, not hard references.

Related Pages

• Data Package
• CatalogKey
• Service Locator