Crafting System

Purpose and Scope

The Crafting System in RPG Engine v6 allows the player to convert existing items and resources into new items by using recipes stored in shared DataTables and executed through the inventory/equipment logic.

This document targets gameplay programmers and technical designers and focuses on recipe data, runtime crafting flow, UI entry points, restrictions, and integration with inventory, skills, buildings, and other gameplay systems. It does not cover step-by-step setup of new recipes or item authoring workflows.

High-Level Architecture

At a high level, crafting in RPG Engine v6 is not a separate standalone subsystem with its own dedicated gameplay component.
Instead, crafting is treated as an item exchange process handled primarily by BP_EquipmentComponent, with recipe discovery and filtering driven by item data, recipe tables, UI widgets, and optional crafting stations.

The system is built from four main layers:

Item definitions – DT_ItemData rows point to BP_ItemData assets, where each item can reference its crafting recipe.
Recipe definitions – DT_CraftData stores the actual list of required ingredients, result quantity, and special conditions.
Execution logic – BP_EquipmentComponent validates ingredients and removes consumed items from the player inventory, then adds the crafted result.
User interface – WB_CraftingTable displays craftable items, filter buttons, and recipe entries both in crafting tables and in the player inventory menu.

This makes crafting tightly integrated with the inventory and item systems rather than isolated from them.

Core Data Model

DT_ItemData and BP_ItemData

Every craftable item starts from DT_ItemData.

Each item row contains ItemData, which points to a BP_ItemData asset. Inside BP_ItemData / BP_II_Master, there is a parameter:

Crafting – DataTableRowHandle

This handle points to a row in DT_CraftData.
If the handle is valid, the item can be crafted. If it is empty, the item is not craftable through the recipe system.

This means DT_ItemData defines what the item is, while DT_CraftData defines how to obtain it through crafting.

DT_CraftData

DT_CraftData is the shared recipe table used for all crafting in the project, including regular crafting, station crafting, and building-related upgrades.

Each row contains:

Components (S_DataTableRowHandles Array) — list of required ingredients for the recipe.
CraftQuantity (integer) — number of result items added to inventory after successful crafting.
SpecialCraftCondition (S_CraftConditions) — additional requirement that must be satisfied before the recipe can be crafted. ### S_DataTableRowHandles

S_DataTableRowHandles describes one recipe ingredient entry.

Fields:

Handle (DataTableRowHandle) — reference to the item/resource row required by the recipe.
Quantity (int) — amount of that item/resource required for crafting.

A recipe can therefore require any number of items or resources, each with its own required quantity.

S_CraftCondition

S_CraftCondition defines an additional requirement for a recipe.

Fields:

CraftCondition (E_CraftCondition) — type of additional crafting requirement:
- None
- MinimalLevel
- StudiedSkill
MinimalLevel (integer) — required player level when CraftCondition == MinimalLevel.
StudySkill (DataTableRowHandle) — reference to a row in DT_Skills when CraftCondition == StudiedSkill.

This lets recipes require either:

no special condition,
a minimum player level,
or a learned skill from the skill tree.

There are no additional global environment restrictions for crafting.

Crafting Types

The project uses three practical crafting modes.

Inventory crafting

The player can craft directly from the inventory UI.

This is used for items that do not require a dedicated world station.
The recipe list is still driven by DT_ItemData + DT_CraftData, and ingredients are checked only against the player inventory.

Station-based crafting

The player can also craft by interacting with world stations, primarily BP_B_CraftingTable.

In this case, the same recipe system is used, but the available recipes are filtered by the station configuration and passed into the crafting widget through GenericFilter.

Special crafting

Special crafting is used for cases like building upgrades.

Although the presentation differs, the underlying logic still uses the same recipe table and the same general idea: consume input items/resources and produce a new gameplay result.

This means there is one shared crafting model across the project rather than separate systems for “items”, “stations”, and “building upgrades”.

Skill and State Integration

Crafting is integrated with the skill and state systems through learned crafting-related states.

The player can unlock crafting capabilities via the skill tree, and these learned skills are represented as CharacterStates.Craft.* tags added to the player’s active state container.

Implemented crafting-related character states include:

CharacterStates.Craft.AmmoElectro
CharacterStates.Craft.AmmoExplosive
CharacterStates.Craft.BasicMilitary
CharacterStates.Craft.Firearms
CharacterStates.Craft.LegendaryFirearms
CharacterStates.Craft.LegendaryMelee
CharacterStates.Craft.Melee
CharacterStates.Craft.Microchips
CharacterStates.Craft.Nylon
CharacterStates.Craft.Rubber
CharacterStates.Craft.Leather

If a recipe uses SpecialCraftCondition with StudiedSkill, the crafting logic checks whether the corresponding skill has been learned.
This ties recipe availability directly into the progression system and the player’s active character states.

Runtime Crafting Logic

BP_EquipmentComponent

BP_EquipmentComponent is the main runtime component responsible for crafting execution.

Crafting is treated as an exchange:

check whether the player has the required ingredients,
verify optional conditions,
remove required items from the inventory,
add the crafted item in the specified CraftQuantity.

There is no dedicated separate BP_CraftingComponent; the inventory/equipment stack already owns the required data and inventory mutation logic, so crafting lives there.

Ingredient validation

Ingredient validation is performed on the player side against the player inventory.

The system checks:

whether all Components from the selected recipe exist,
whether the player has enough quantity of each ingredient,
whether the special condition is satisfied.

There are no tool requirements in the current system; resources alone are sufficient, assuming the recipe’s special condition is also met.

Result creation

After a successful craft:

required items are removed from inventory,
the result item is added to inventory,
quantity is taken from CraftQuantity.

Because any item from DT_ItemData can have a crafting recipe, crafting is effectively connected to nearly every itemized gameplay domain in the project.

UI and Player Flows

All crafting is presented through the widget WB_CraftingTable.

There is no crafting queue.
Crafting happens as a direct action from the currently displayed recipe list.

Scenario 1: Crafting table in the world

The main station actor is BP_B_CraftingTable.

Important hierarchy:

BP_B_CraftingTable
child of BP_Building_Interact
BP_Building_Interact is a child of BP_Building_Master

Runtime flow:

The player interacts with BP_B_CraftingTable.
On the player controller, function BPI_PC_SpawnCraftingTable is called.
It receives GenericFilter as input.
BPI_PC_SpawnCraftingTable creates WB_CraftingTable and passes GenericFilter into it.
The widget runs Initialize, iterates through all filter types from GenericFilter, and creates WB_FilterItemButton instances.
Filter icons are loaded from InventoryFilterTextures in DA_GS_Texture, which is a map of GameplayTag -> Texture2D.
The recipe grid is then filled by Refill Craft Grid.

Crafting can also be opened from WB_InGameContainer.

Flow:

The player opens WB_InGameContainer.
In the section selector, the player chooses Craft.
WB_InGameContainer calls Open Section with type Craft.
It then calls Refill Craft Grid on the crafting widget already embedded in the container.

This gives the player access to the same recipe-driven crafting model without necessarily using a placed world station.

Refill Craft Grid

Refill Craft Grid is the function responsible for building the list of available recipes.

Inputs:

ItemTypeInput (GameplayTag)
All (bool)

Its logic:

iterates through all rows in DT_ItemData,
checks whether the item type matches ItemTypeInput,
checks whether the item actually has crafting data,
verifies that F_CraftData.Components is not empty,
creates WB_RecipData widgets for items that can be crafted.

WB_RecipData is the UI representation of one craftable recipe entry.

Crafting Stations

BP_B_CraftingTable

BP_B_CraftingTable is the main dedicated crafting station described in the current system.

It is a building-based interactable actor rather than a completely separate station framework.
This means stations participate in the same world/building ecosystem as other placeable structures.

The key station customization parameter is:

Filters – GameplayTagContainer

This filter determines which categories of items the station can craft.
Different crafting tables can therefore expose different sets of recipes simply by changing their filter configuration, without needing separate station classes.

There is no formal built-in split between “basic” and “advanced” crafting stations.
However, designers can create effectively different station tiers by giving different Filters to different BP_B_CraftingTable instances.

A crafting table can also be player-built, which links the crafting system directly with the building system.

Progress, Timing, and Network Behavior

Crafting time and progress bars are currently mostly a visual layer.

They exist to provide player feedback, but they are not treated as a deep persistent queueing system with long-running saved processes.

Important current rules:

no crafting queue,
no persistent background crafting process,
no save/load of active crafting jobs.

Because crafting changes inventory content, the authoritative state still needs to remain consistent with the rest of the multiplayer inventory logic.
The visual progress is secondary to the actual inventory transaction.

Save and Load

Crafting itself is not saved as an active runtime process.

Specifically:

crafting queues are not saved,
unfinished crafts are not saved,
craft stations do not persist recipe progress.

What is persisted instead are the normal gameplay systems around crafting:

player inventory and crafted items,
building actors such as BP_B_CraftingTable,
skill/progression states that unlock crafting capabilities.

So after loading, the player keeps the crafted items and their learned crafting skills, but there is no restoration of “in-progress” crafting actions.

Integration with Other Systems

Crafting is one of the most cross-cutting systems in the project because any item in DT_ItemData may be craftable.

Inventory and Equipment

This is the closest integration.

Recipe availability is discovered through item data.
Ingredient checks happen against the player inventory.
BP_EquipmentComponent consumes inputs and grants outputs.

Building

Crafting is used for building-related flows, especially upgrades.

Building recipes point into the same DT_CraftData table.
BP_B_CraftingTable itself is also a building actor, linking station-based crafting with the Building System.

Abilities and Progression

Crafting restrictions can require studied skills.

Learned skills are represented by active CharacterStates.Craft.*.
Recipe access can be gated by SpecialCraftCondition.

Weapons, Ammo, Armor, Resources, Usables

Because any item from DT_ItemData can define a crafting recipe, crafting naturally connects to:

firearms,
melee weapons,
ammo,
armor/clothing,
resources,
usable items,
building pieces,
interactables.

Quests

Crafting is not directly integrated with the quest system.

A crafted item may still be relevant to a quest indirectly, but the crafting system itself does not have dedicated quest hooks or quest-specific runtime logic.

Scope and Limitations

This document covers:

recipe data in DT_ItemData and DT_CraftData,
crafting conditions in S_CraftCondition,
crafting execution through BP_EquipmentComponent,
inventory and station-based crafting flows,
crafting UI through WB_CraftingTable,
integration with skills, buildings, and item systems.

This document does not cover:

editor setup for authoring new recipes,
per-widget UI art/layout details,
advanced queueing or background production systems,
quest scripting that may reference crafted items.

Those topics should be documented in dedicated How‑To and Reference docs.

inventory-and-equipment.md
interaction-and-items.md
building-system.md
abilities-and-unusual-skills.md
state-system.md
character-modules.md
weapon-modifications-reference.md
ammo-system.md
firearms-system.md
melee-system.md
armor-and-clothing.md
save-load-system.md