RevFramework — Crafting System¶

Overview¶

It is designed for production projects, with predictable behaviour, clear extension points, and strong integration with other RevFramework systems.

Crafting supports two execution semantics:

• Best-effort execution (default) — fast, forgiving, suitable for most gameplay systems
• Escrow execution (opt-in) — stronger execution guarantees when reservation/hold adapters honour their contracts

Both modes share the same service, pipeline, and extension points. Only the execution guarantees and failure behaviour differ.

Key design goals¶

• Service-first: CraftingService runs all logic — preflight, acceptance, scheduling, delivery, and events.
• Result-first: Most operations return structured results (CraftCheck, CraftProbe, CraftJob) for clarity and debugging.
• Extensible: Plug in custom ICraftingValidator, ICraftingModifier, or routing components.
• Deterministic: Supports deterministic RNG for testing, replay, and server verification.
• Pipeline-agnostic: Works with or without Inventory/Currency modules; behaviour adapts to available capabilities.

Persistence responsibility¶

The service exposes APIs for saving and restoring active crafting jobs:

• SaveActiveJobs(...)
• RestoreJobs(...)

These APIs define:

• what data to persist (active jobs)
• how jobs resume and progress (including offline behaviour)

They do not provide a persistence system.

Crafting does not implement:

• save files
• cloud sync
• cross-session storage

You decide:

• when to save
• where to store data
• when to restore

🗝️ We define the job model and lifecycle — you own persistence.

What’s included¶

Hook-up summary¶

Minimal setup requires only a CraftingService in the scene.

1. Add the service¶

GameObject → RevFramework → Crafting → CraftingService

• Optionally assign adapters:
• InventoryCraftingAdapter → connects to SceneInventoryService
• CurrencyCraftingAdapter → connects to SceneCurrencyService
• Optionally assign any component implementing IWallClockProvider to Wall Clock Component for offline progress tracking. Without one, SystemWallClock is used; an object that does not implement the interface is refused with a warning and the same fallback.

If escrow execution is required, provide adapters that implement reservation and hold capabilities.

2. Create recipes¶

• Use RecipeCore (data-only) or RecipeDefinition (designer asset).
• Define inputs, outputs, cost, craft time, and station tag.

3. Link to gameplay¶

• Add Validators (e.g., cooldowns, requirements).
• Add Modifiers (e.g., bonuses, chance outputs).
• Optional workbenches provide trigger-based crafting interactions.

4. Test with a Teaching Panel¶

Open one of the scenes below and press Play — its panel is already placed in the scene, and the overlay draws itself. There is no Teaching menu. To put a panel in a scene of your own, add a Crafting*Panel component to a GameObject.

See the Samples → Crafting → Scenes section for the full set of demo scenes.¶

Integration with other RevFramework modules¶

Multiplayer Note¶

RevFramework Crafting is netcode-agnostic but deterministic.

• Consistent results with identical seeds and inputs (when deterministic RNG is used)
• Adapters enforce authority; replication is up to your netcode
• Jobs can be serialized and replayed server-side

Extension points¶

• Implement ICraftingValidator for custom rules
• Implement ICraftingModifier for dynamic behaviour
• Implement ICraftingOutputRouter for routing
• Implement reservation/hold adapters for escrow
• Extend Teaching Panels for debugging or tooling

Typical one-liner usage¶

var req = new CraftRequest(player, recipe, 1, "Backpack", "Forge");
crafting.Enqueue(req);

Where to learn¶

• Docs: See the Crafting section of this site
• Videos: Quickstart, Offline Progress, Routing & Space, Validators & Modifiers, Kitchen Sink
• In-Editor Panels: Add any Crafting*Panel component to test live

TL;DR¶