Runes
Runes define the modular enhancement layer of PVERSE. They are socket-based items identified by the symbols A through Z and 0 through 9, and they may be attached to pickaxes according to the socket capacity of the equipped tool.
Overview
Runes are the modular enhancement objects of the PVERSE tool layer. Their purpose is to create build variation, long-horizon collection value, and meaningful socket-based customization without collapsing the system into one flat stat ladder.
This page defines what runes are, how their identity system works, how they connect to pickaxe sockets, and how their drop timing is interpreted. It intentionally focuses on structure and role rather than disclosing final drop rates, exact effect magnitudes, or full balance tables.
Scope
Runes define the modular enhancement layer inside the Game Systems section.
- rune identity structure using alphabetic and numeric rune classes
- socket-limited attachment to pickaxes and related tool-state boundaries
- daily time-windowed drop availability and live-ops availability rules
- forward-only rune acquisition, attachment, and state integrity
Core Model
The core model is that a rune is a distinct attachable enhancement object with symbolic identity. A rune does not exist as free-floating power by itself at runtime; it becomes functionally meaningful when held, attached, and interpreted through a valid pickaxe socket boundary.
- runes are modular items rather than permanent baked-in tool stats
- rune identity is expressed through symbol classes rather than only tier language
- attachment is limited by the socket capacity of the host pickaxe
- future rune changes apply forward-only and do not silently rewrite prior rune history
Rune Identity
Rune identity is currently built from two symbol families.
A–Z Rune Family
Alphabetic runes provide the main symbolic rune set. Each letter rune should be treated as a distinct rune identity rather than as a cosmetic alias of a broader class.
0–9 Rune Family
Numeric runes provide a second symbolic rune set. These are treated as full rune identities alongside letter runes and may be used for alternate build logic, rarity structure, progression symbolism, or future combinational behavior.
Together, these two families define the current canonical rune identity space: A–Z and 0–9.
Socket Linkage
Runes may be attached only when a pickaxe has available socket capacity. The number of active rune attachments is therefore bounded by the current realized socket count of the equipped or targeted pickaxe.
This means rune power is not independent of the tool system. Runes are structurally subordinate to socket availability. A pickaxe with fewer available sockets cannot host more attached runes than its current valid socket state allows.
Drop Availability
Rune drops are governed by daily availability windows rather than unrestricted always-on acquisition. This creates a live-ops rhythm around rune hunting and prevents rune supply from behaving like a permanently open faucet.
The existence of a window means three things: rune drops may be enabled only during specific daily periods, window state is authoritative on the server side, and missing a window does not retroactively create eligibility outside that period. Exact timing and pool composition remain configurable rather than fixed in this page.
Operational Behavior
In operational terms, the rune system moves through three stages: acquisition, attachment, and persistence. First, a rune becomes eligible to drop only if the current daily availability window is active. Second, the acquired rune must exist in valid inventory state. Third, it may be attached to a pickaxe only if the host tool has available sockets and passes current runtime validation.
Once attached, the rune becomes part of the tool-side state under current enforcement rules. Removal, replacement, fusion, destruction, upgrade, or special interaction behavior may be defined by adjacent systems, but this page fixes the core meaning: runes are socket-bound modular enhancements with time-gated acquisition.
Constraints
- this page does not publish exact daily drop schedules, drop rates, pool weights, or effect magnitudes
- runes cannot bypass the socket limit of the host pickaxe
- client timers or local assumptions do not override authoritative server window state
- future rune policy changes apply forward-only and do not silently rewrite historical rune records
Integrity Considerations
Rune integrity depends on separating symbolic identity, live configuration, and authoritative state. Documentation defines what runes are and how they are structured. SSOT owns mutable parameters such as drop windows, pool composition, and internal effect values. Code enforces acquisition eligibility, inventory persistence, socket validation, and attached-state truth.
- rune drops should resolve from authoritative server windows rather than client display alone
- attached runes must remain bounded by valid socket state at all times
- historical rune acquisition and attachment outcomes remain auditable even after future tuning changes
Future Expansion
As PVERSE expands, runes may connect to fusion systems, set logic, symbol combinations, stronger socket specialization, live event pools, and broader special-effect interpretation. The conceptual model should remain stable: runes are symbolic modular enhancements that drop during defined daily windows and operate only through valid socket-bearing tools.
Summary
- Runes are socket-based modular enhancements for pickaxes in PVERSE.
- The canonical rune identity space currently consists of A–Z and 0–9 runes.
- Rune drops are available only during defined daily time windows.
- All rune acquisition and attachment behavior follows forward-only interpretation and authoritative socket validation.