Game Data Catalog
What This System Is
The game-data catalog is the author-facing source of truth for item definitions and the authored economy links that consume them. Runtime and tooling read a prepared catalog snapshot; authors should edit the source shards and generated-family manifest, then regenerate the aggregate.
How Authors Use It
assets/gameplay/game_data_catalog.manifest.json describes the catalog composition. It points at the shard files under assets/gameplay/game_data/ and names the generated aggregate output at assets/generated/gameplay/game_data_catalog.json.
The current source shards are:
item_taxonomy: item kinds, categories, equipment kinds, class tokens, authoring templates, and snippets.item_aliases: legacy or renamed item IDs that resolve to canonical live IDs.items: authored item definitions.vendor_stocks: vendor inventories, costs, availability conditions, and relationship deltas.crafting_recipes: recipe inputs, outputs, optional conditions, and rewards.loot_tables: weighted item drops, count ranges, guarantees, and drop chances.loadout_rules: starter and rules-driven item grants.gathering_nodes: gatherable sources and yielded items.
The aggregate is generated from those shards plus generated item-family content. Do not hand-edit assets/generated/gameplay/game_data_catalog.json; if it drifts, repair it with:
cargo run -p aether --bin aether-generated-artifact -- --write game_data_catalog_aggregate
Use --check game_data_catalog_aggregate in review or CI to prove the aggregate still matches the source shards.
Loading Contract
The pure loader entry point is load_game_data_catalog_from_str_with_context. The context supplies the manifest shards, optional generated item-family manifest JSON, generator adapters, composition errors, and asset validation signatures. Current-asset helpers are responsible for reading files and then calling the context-driven loader.
Catalog loading:
- parses and migrates the source schema to the current target schema;
- composes shard records through schema descriptors;
- appends generated item-family rows when the catalog path requires them;
- normalizes item definitions, taxonomy templates, and reference-friendly IDs;
- records source locations for authored and generated rows;
- validates references and metadata before the snapshot is handed to editor or runtime code.
The manifest and loader are intentionally shard-first. If a tool edits a catalog snapshot in memory, it still needs to write the appropriate source shard or manifest-backed source rather than treating the generated aggregate as canonical.
Rules And Invariants
Item IDs And Aliases
Item IDs are stable content IDs. Runtime and authoring lookup trims IDs and resolves them case-insensitively, while validation reports duplicate IDs instead of relying on the prepared index's first-match behavior.
Aliases are compatibility rows with alias_id, item_id, and reason. They let old references survive a rename while authors migrate sources to the new ID. Alias resolution can follow alias chains and protects itself from loops.
Alias validation rejects:
- empty alias IDs or empty target IDs;
- duplicate aliases;
- aliases that conflict with a live item ID;
- self-targeting aliases;
- aliases pointing at missing or removed items.
Reference repair workflows should prefer rewriting references to the canonical ID, then keeping a short-lived alias only when old content or external data still needs it.
Taxonomy Templates
item_taxonomy.json owns the authoring vocabulary: item kinds, categories, equipment kinds, consumable categories, weapon kinds, playable class tokens, authoring templates, and reusable snippets.
Templates are how authors make consistent items quickly. Each template has an ID, label, display-name default, ID prefix, default kind/category/stack, and optional equipment or consumable defaults. The template registry validates that IDs are unique, labels are present, stacks are nonzero, and equipment or consumable defaults match the requested item kind.
Snippets are smaller reusable edits for existing items, such as stat blocks, trade metadata, repair metadata, or consumable effects. They should be used when a field group needs to be applied repeatedly without replacing the whole item.
CSV And Bulk Import
The item authoring workbench supports bulk authoring through variants, batch edits, snippets, and import dry runs. Import accepts CSV or catalog JSON. CSV is selected when the source name ends in .csv, or when the first non-empty input line looks comma-separated rather than JSON.
The dry run produces one row per parsed item with a status:
Create: the item ID is new and the draft builds cleanly.Update: the item ID already exists and the imported draft builds cleanly.MissingFields: the row has neither an item ID nor enough identity fields to generate one.Invalid: the row parsed, but item metadata or draft validation failed.
Applying an import only persists Create and Update rows. Missing item IDs can be generated from the display name using the item kind prefix, then uniqued with a numeric suffix. CSV headers are routed through game-data item field descriptors, so prefer known headers such as item ID, display name/name, kind/type, equipment slot, weapon damage, repair material, market/trade flags, and effects. The CSV parser handles quoted fields, escaped quotes, CRLF, and quoted newlines, and reports malformed quotes with line numbers.
Vendors, Crafting, Loot
Vendor, crafting, loot, loadout, gathering, farming, equipment, quest, scene, and NPC-service references all flow through the shared item reference index.
Vendor stock entries can reference both sold items and cost items. Crafting recipes reference input and output items. Loot tables reference drop item IDs with weights and quantity/chance rules. Loadout rules and gathering nodes add more item references that can become stale after item renames.
When changing an item ID, preview reference repair before saving. The game-data rewrite path covers vendor rows, crafting rows, loot drops, loadouts, gathering yields, aliases, and equipment repair materials. Some usages are intentionally diagnostic-only or are queued to their owning subsystem, including farming crop fields, equipment interfaces, quests, scene trigger conditions, and NPC services.
Generated Item Families
assets/gameplay/game_data_item_families.json generates asset-backed item rows that would be noisy or brittle to author by hand. Its schema version is checked by the production parser. Core generators include:
farming_cropsnamed_iconsgrid_iconsgrid_sheets
Player-preview authoring can add generator adapters for paperdoll or preview-specific item families. Generated rows carry provenance through GameDataGeneratedItemFamilySource: source asset path, source record path, family ID, family tag, generator name, and item ID. The catalog doctor uses that provenance so generated family entries are not treated like orphaned hand-authored items.
Generated families are still catalog content. They must validate assets, IDs, aliases, references, and schema version just like source shards.
Validation And Debugging
Structured validation covers schema version, duplicate IDs, required item metadata, item icons, paperdoll assets, aliases, vendor stock, crafting recipes, loot tables, loadout rules, gathering nodes, farming references, and gameplay-condition item references.
The item catalog doctor is an on-demand lifecycle report. It flags:
MissingItemReferenceRemovedItemReferencedOrphanedItemStaleAliasUnusedVariant
Doctor reports produce shared validation issues with repair labels and why-this-matters text. Draft, hidden, removed, deprecated, and generated item-family rows are handled differently from live authored rows so the report focuses on actionable catalog cleanup.
Run the normal bake diagnostics after catalog edits:
cargo run --bin aether-bake -- --fail-on-diagnostics
Examples
- Edit the source shard or
game_data_item_families.json, not the generated aggregate. - Use templates, snippets, batch edits, or CSV/JSON import when making repeated item changes.
- Preview reference repair before renaming or removing item IDs.
- Regenerate or check the aggregate with
aether-generated-artifact. - Run bake diagnostics before handing content to runtime.