Skip to content

Crafting / Core

Purpose

This folder contains the core runtime implementation of the Crafting system.

Crafting.Core is where the actual crafting rules live: - preflight evaluation - input & currency consumption - job scheduling and execution - output delivery - failure handling - persistence & offline progress (job-based only)

If something meaningfully changes how crafting behaves at runtime, it belongs here.

This folder is not UI, not adapters, and not optional gameplay sugar. It is the authoritative source of truth for crafting behaviour.

What lives here

Primary service

  • CraftingServiceCore
  • The orchestration engine for all crafting operations.
  • Owns the job lifecycle from accept → run → deliver → complete/fail.
  • Integrates with inventory, currency, authority, routing, RNG, time, and persistence.
  • Exposes the supported public API used by gameplay, UI, and Teachables.

Strong / Escrow path

This path exists as an advanced atomic option and does not change or replace the job-based crafting model.

It exists primarily to allow plug-and-play strong crafting when used alongside RevFramework Inventory and Economy, while still exposing a public seam so custom inventory or currency backends can opt in by implementing reservation / hold adapters.

If a backend cannot reserve inputs or capacity transactionally, escrow is intentionally unavailable and the standard job pipeline should be used instead.

  • CraftingServiceCore.Escrow
  • An opt-in, immediate-only, strong crafting path.
  • Uses reservation / hold semantics to provide atomic commits when adapter contracts are honoured.
  • Implemented as a partial class to stay lock-step with core rules.

This is not a separate system and does not promise: - long-running escrow - multi-container atomicity - routed outputs

Those are deliberately out of scope.

Supporting domains

  • Context/
  • Immutable context (CraftContext) and mutable adjustments (CraftAdjustments)

  • Passed through modifiers, validators, and delivery logic

  • Contracts/

  • Public, serializable data contracts used by callers

  • Jobs, preflight results, requests, probes, enums

  • Lifecycle/

  • Unified lifecycle phase definitions used by job events

  • Recipe/

  • Pure, implementation-agnostic recipe data (RecipeCore)

  • Supported public resolution seam (RecipeResolve)

  • Internal/

  • Framework-only helpers and delegate hooks
  • Not a supported extension surface

What does NOT belong here

  • UI, panels, inspectors, or debug windows
  • Inventory or currency implementations
  • Game-specific logic (levels, perks, tech trees, etc.)
  • Long-lived reservations or economy simulation
  • Multi-container transactional guarantees

Those belong in adapters, validators, modifiers, or higher-level systems.

Public vs Internal

Public / supported API - CraftingServiceCore (supported public methods & events) - RecipeCore - RecipeResolve - Types under Contracts/ - Types under Lifecycle/

Internal / framework-only - Internal/ folder contents - Internal delegates (CraftModHook, CraftValidatorHook) - Recipe/Internal/RecipeCache

Teachables compile against the public surface only and must not rely on internals.

Supported extension points

Crafting is intentionally extensible without subclassing the core service.

Supported seams include:

  • Adapters
  • ICraftingInventoryAdapter (required)
  • ICraftingCurrencyAdapter (optional)

  • Reservation / hold adapters for escrow path

  • Modifiers

  • ICraftingModifier components on the owner or parents

  • Validators

  • ICraftingValidator components on the owner or parents

  • Routing

  • ICraftingOutputRouter for output destination selection

  • Authority

  • ICraftingAuthority for multiplayer / server-authoritative gating

If a behaviour cannot be achieved through these seams, it is intentionally unsupported.

Design notes

  • Crafting is service-driven, not recipe-driven.
  • Recipes are treated as immutable runtime data.
  • All mutation is gated and observable.
  • Failure reasons are explicit and surfaced.
  • Offline progress is deterministic and replay-safe when deterministic RNG is configured.
  • Partial success is never hidden — failure paths are first-class.

This folder is designed to survive hostile consumers, save/load cycles, and multiplayer authority without leaking internal assumptions.