Forging
Forging defines the higher-tier conversion layer where valid refined inputs become durable gameplay outputs under stricter execution rules, explicit eligibility gates, and append-only history.
Overview
Forging is the higher-tier conversion layer of the PVERSE gameplay system. It exists to turn valid refined-state inputs into more durable or more advanced gameplay outputs under stronger constraints than earlier conversion systems.
This page is intentionally structural rather than balance-final. It explains the meaning of forging, the role it plays in the wider gameplay loop, how execution is resolved, and how records are preserved. Exact materials, recipe compositions, batch sizes, yield tables, and limits are controlled outside this page through SSOT and enforced runtime logic.
Scope
Forging defines the higher-tier conversion layer inside the Game Systems section.
- forging eligibility, execution flow, and outcome resolution
- bounded attempts with explicit success or terminal failure states
- durable output creation under server-side enforcement
- forward-only history and non-retroactive tuning boundaries
Core Model
The core model is that forging is a discrete, rule-bound conversion attempt. It consumes valid refined inputs, evaluates the attempt under current runtime gates, and resolves into a single terminal result that becomes durable history.
- forging is batch-based rather than free-form continuous conversion
- each attempt resolves exactly once into a final result
- durable outputs are credited only after authoritative resolution
- future rule changes affect future attempts only and do not rewrite past records
Operational Behavior
In operational terms, forging begins only after the system confirms that the attempt is eligible. Inputs must exist in valid state, the account must meet current execution requirements, and the attempt must pass all active rules such as locks, limits, cooldowns, or other safety conditions.
Once accepted, the attempt is reserved, resolved, and committed as authoritative history. The system then applies the outcome by consuming the required inputs and crediting the resulting durable output when applicable. If the attempt fails under a valid terminal path, the result is still recorded as part of forward-only history rather than silently disappearing.
Atomic attempt model
Forging attempts are interpreted as atomic at the gameplay layer. They do not partially complete in a way that creates ambiguous ownership or unclear historical state. An attempt either resolves under a valid final path or is rejected before execution.
Explicit rejection boundary
If the attempt does not satisfy current runtime rules, the system rejects it explicitly rather than reinterpreting it informally. This keeps forging auditable and prevents vague or hidden state transitions.
Constraints
- this page does not publish full material requirements, recipe compositions, batch sizes, caps, or distribution tables
- forging does not define protocol truth, participation administration, vesting, or external market policy
- client display does not establish forging truth; authoritative state is resolved server-side
- future forging updates apply forward-only and do not silently mutate historical records
Integrity Considerations
Forging integrity depends on separating meaning, configuration, and enforcement. Documentation defines what forging is and where it applies. SSOT owns mutable values such as recipes, limits, distributions, and costs. Code enforces reservations, resolution rules, and append-only record creation.
- forging attempts should be idempotent or safely reject duplicate execution paths
- durable outputs must only be credited from committed authoritative resolution
- historical forging outcomes remain auditable even after future tuning or rule updates
Future Expansion
As PVERSE expands, forging may connect to broader item families, richer equipment identity, more visible recipe classes, stronger linkage to sockets or special effects, and separate balance references for advanced production systems. The conceptual model should remain stable: forging is a stricter higher-tier conversion layer with explicit execution and forward-only history.
Summary
- Forging defines the higher-tier conversion layer of the gameplay system.
- It transforms valid refined inputs into durable outputs through bounded attempts.
- This page fixes structure and behavior, not full recipe material lists.
- All forging outcomes and policy updates follow forward-only interpretation.