Skip to content

Rift Types And Variables

Purpose

This document defines the official rift taxonomy for EchoSpire: Portals.

It covers the currently implemented rift node types, the design role of each type, and the variable set that should be available for authoring, balance, simulation, and UI presentation.

Terminology Rule

In current code, map nodes are represented as RiftNodeType values.

In design terms, these are the playable rift encounter and service types that structure a realm.

The official current set is:

  • Combat
  • Elite
  • Boss
  • Event
  • Shop
  • Rest
  • Treasure
  • Anchor
  • Protection
  • Sanctuary

Rift Design Principle

Rift types should not only answer the question, what screen do we show next?

They must also answer:

  • what kind of pressure is being applied
  • what kind of reward or recovery is offered
  • what quest purpose this node can serve
  • what variables content authors are allowed to tune

Shared Variables For All Rift Types

Every rift should support a shared baseline data model.

Recommended shared variables are:

  • riftType: the node family
  • displayName: player-facing title
  • subtitle: short flavor tag or operation label
  • realmId: source realm definition
  • questId: current owning quest
  • actIndex: campaign act or chapter placement
  • threatTier: combat and pressure rating
  • rewardTier: reward quality band
  • factionOwnerId: controlling or originating faction when relevant
  • resonanceTags: tags explaining narrative connection to the wider quest chain
  • passiveOverrides: local modifiers that stack with realm passives
  • introBeatId: optional pre-node narrative beat
  • completionBeatId: optional post-node narrative beat
  • failureBeatId: optional failure narrative beat
  • uxPresentationKey: presentation and VFX routing key
  • telemetryTags: analytics labels for simulation and balancing

Combat Rift

Purpose

The default conflict node. It establishes baseline pacing, enemy ecology, and card-economy pressure.

Key Variables

  • encounterPoolId
  • enemyGroupTemplateId
  • waveCount
  • spawnPattern
  • objectiveType such as eliminate, survive, hold, interrupt
  • turnPressureRule
  • hazardRules
  • openingModifiers
  • victoryRewards
  • failurePenalty

Elite Rift

Purpose

Higher-risk combat with sharper identity, stronger rewards, and more memorable mechanics.

Key Variables

  • all Combat Rift variables
  • eliteTraitSet
  • signatureMechanicId
  • rewardBias
  • relicChance
  • rareCardChance
  • narrativeWeight

Boss Rift

Purpose

The major climax node for a realm, quest chapter, or campaign act.

Key Variables

  • all Elite Rift variables
  • bossId
  • bossPhaseCount
  • bossArenaRule
  • phaseTransitionBeats
  • chapterClearRewards
  • campaignStateChange
  • legendFlag when this is a capstone outcome

Event Rift

Purpose

Narrative choice, risk-reward exchange, lore revelation, or anomaly interaction outside standard combat.

Key Variables

  • eventTemplateId
  • choiceSetId
  • skillCheckRules
  • resourceCosts
  • branchOutcomes
  • codexUnlocks
  • questFlagsSet
  • questFlagsRequired
  • canEscalateToCombat
  • canSpawnRivalHero

Shop Rift

Purpose

Controlled economy node for acquiring cards, relics, services, intelligence, or faction-specific contraband.

Key Variables

  • shopPoolId
  • inventoryBias
  • refreshRules
  • currencyTypes
  • factionVendorId
  • serviceOptions
  • blackMarketRisk
  • questExclusiveStock

Rest Rift

Purpose

Recovery node that trades tempo for stability.

Key Variables

  • healAmountRule
  • alternateActions
  • upgradeOptionCount
  • removeCardOption
  • statusCleanseRules
  • storyRestBeatId

Treasure Rift

Purpose

High-value reward node that should feel discovered, stolen, excavated, or earned.

Key Variables

  • treasurePoolId
  • relicTableId
  • riskGate
  • trapRules
  • questArtifactId
  • lorePayloadId
  • currencyRewardRule

Anchor Rift

Purpose

Stabilize the realm, reveal hidden routes, and interact directly with the reality state of the map.

This is a signature EchoSpire node type and should remain mechanically and narratively special.

Key Variables

  • anchorStrengthRequired
  • revealRadiusRule or fullRevealRule
  • stabilityShift
  • realmPassiveAdjustment
  • anomalyResistance
  • anchoringMiniObjective
  • anchorFailurePenalty
  • mapStateEffects
  • transitionUnlocks

Protection Rift

Purpose

Defend a named asset, person, machine, archive, convoy, or ritual for a defined survival window.

This type already exists in the current tutorial slice and should remain a first-class authored encounter type.

Protection Rifts must be designed so every class has at least one viable line of play.

That does not mean every class heals the target the same way. It means the encounter rules must allow multiple protection solutions: drawing aggro, intercepting hits, repairing assets, suppressing threats, spawning decoys, or reshaping space.

Key Variables

  • protectableEntityId
  • protectableName
  • protectableMaxHp
  • surviveTurns
  • friendlySupportRules
  • enemyTargetingBias
  • failurePenalty
  • scarCardId
  • questConsequences
  • successBonus
  • protectableType such as living, mechanical, ritual, convoy, archive
  • movementRule for stationary defense, escorted movement, or checkpoint progression
  • checkpointCount
  • repairable or healable
  • interceptAllowed
  • tauntSensitivity
  • enemyObjectivePriorityRule
  • lossThresholdRule
  • optionalDefenseBonusRule

Official Protection Design Rule

When a Protection Rift is authored, the content should be reviewed against all five class identities to make sure success is not locked to one narrow answer.

Examples:

  • Anchor should be able to absorb or redirect pressure.
  • Drifter should be able to delete or disrupt priority attackers.
  • Conduit should be able to clear waves and create emergency stabilization windows.
  • Machinist should be able to defend through Constructs, cover, and repair.
  • Catalyst should be able to use lures, mutation spikes, and unstable rescue tools.

Sanctuary Rift

Purpose

Strategic service node tied to longer-form run continuity, stability budget, repairs, recalibration, and faction-specific preparation.

This should be treated as more important than a simple rest stop.

Key Variables

  • stabilityBudget
  • availableServices
  • repairRules
  • recalibrationRules
  • defragmentRules
  • factionExclusiveOption
  • saveCheckpointRule
  • heroProgressHooks
  • questUpdateBeatId

Transit Interrupts

Transit interrupts are not currently a primary RiftNodeType, but they are an official structural part of the run.

They represent disruptions during travel between nodes or realms.

Recommended transit-interrupt variables are:

  • interruptType
  • triggerChance
  • hazardRule
  • shortEncounterTemplateId
  • narrativeBeatId
  • rerouteRule
  • resourceTax

Rift Families By Function

For campaign authoring, rift types should also be understood by function:

  • pressure rifts: Combat, Elite, Boss, Protection
  • recovery rifts: Rest, Sanctuary
  • economy rifts: Shop, Treasure
  • narrative-control rifts: Event, Anchor

This functional grouping is useful for pacing rules, map generation, and quest authoring.

Rift Authoring Rules

1. The Rift Type Must Predict The Player's Question

Players should be able to infer the basic risk and opportunity profile from the node type.

2. The Variables Must Stay Data-Driven

Rift authoring should not require new code for every content variant. New code should be reserved for new behaviors, not new content records.

3. Quest Stakes Must Be Visible In The Rift Data

If a node matters to the story, that should be explicit through beats, flags, rewards, or consequences.

4. Realm Flavor Must Survive The Template

A Protection Rift in a frozen historical echo should not feel identical to a Protection Rift in a machine-scar maintenance district.

5. UI Needs Type-Specific Payloads

The UX layer should receive enough structured data to present distinct framing, warnings, and payoff language per rift type.

Official Direction Summary

The canonical direction is:

  • the current official playable rift types are the ten node families already reflected in the codebase
  • each type should expose a defined variable set for content authoring and simulation
  • Anchor, Protection, and Sanctuary are strategically important identity nodes for EchoSpire, not filler variants
  • transit interrupts should be treated as a formal secondary rift structure even if they remain outside the primary node enum
  • rift data should carry gameplay, narrative, telemetry, and presentation payloads together