IronRoot
Systems Design — Full Breakdown

Description: 
An RPG where combat, faction reputation, and NPC memory dynamically shape quests, world state, and player progression
Discipline: 
Systems Design, Combat Design, AI Systems, Narrative Architecture
Engine: Unreal Engine 5Tools: 
C++, Blueprints, Behaviour Trees, EQS, UE5 DataTables

Jump to: The System • Architecture • System Breakdown • Scenario • Interdependency • Failure Case • My Approach • System Contributions   • Full Project Page
What Is the System?
IronRoot is a world-state driven RPG where every player action feeds into a shared systemic layer that continuously reshapes the game. All gameplay systems write to a shared world state that determines what is possible next.

Instead of branching from explicit choices, progression emerges from accumulated behavior. Two players can complete the same quest and experience entirely different outcomes based on how they played.
The defining feature:  Combat, dialogue, and exploration are inputs into a shared world-state system that continuously reshapes what is possible next.
CORE DESIGN PHILOSOPHY
IronRoot is built around a simple premise: the world is political. Every faction has interests, every NPC has allegiances, and every player action has political cost. Reputation is the accumulated consequence of who you chose to side with, fight against, and betray.
POLITICAL CONSEQUENCE VS EMOTIONAL CONSEQUENCE
Most narrative RPG systems model emotional consequence: how characters feel about the player. IronRoot models political consequence: what the player's faction alignment makes possible or impossible in the world. The question is not "does this NPC trust me" but "what does my standing allow."
Design Inspiration:  The faction architecture was informed by the reputation systems in Fable II and Dragon Age: Origins: both demonstrated how political standing with factions can feel like a living consequence of playstyle rather than a tracked meter. Mount & Blade: Bannerlord was the closest technical parallel: independent factions with real-time attitude states that reshape NPC behavior, pricing, and quest access based on accumulated player history. Kingdom Come: Deliverance reinforced that world-state consequence should emerge from how you play, not just what you choose.
System Architecture
Every player action feeds into two parallel tracking systems, faction reputation and NPC memory, which converge into a shared world state that continuously reshapes the game:
Player Actions
combat outcomes · dialogue tone · quest decisions · exploration choices
↓
Faction Reputation
4 factions · independent values · real-time updates
Political Memory
past choices · quest outcomes · alliance history
↓
World State
the shared variable all systems read from and write to
↓
Quest Availability
NPC Behavior
Enemy Encounters
The system creates a loop where player action shapes world state, and world state reshapes every future action.
  Design principle: No system operates in isolation: all gameplay loops read from and write to the same world state.
System Breakdown
A. Faction Reputation System — The Backbone
Four independent factions each maintain their own reputation value, updated in real-time through combat, dialogue, and quest decisions.
FACTION SYSTEM TRACKS
Reputation Values → 4 independent faction scores, each updated by combat outcomes, quest decisions, and dialogue tone
NPC Attitude States → Hostile / Neutral / Allied: updated in real-time, influencing quest availability, pricing, and encounter behavior
Cross-Faction Effects → gaining standing with one faction can reduce it with rivals; decisions carry systemic cost
Progression Gating → faction thresholds gate questlines, zone access, and NPC services, alignment determines opportunity
Design intent: Reputation is a core progression currency and directly gates access, alters pricing, and determines narrative paths.
B. Political Memory System — The Consequence Layer
NPCs maintain persistent memory of player behavior across sessions, enabling long-term political consequence rather than isolated reactions. Using Blueprints and C++, the system adjusts dialogue responses, unlocks or gates questlines, and shifts NPC attitudes based on accumulated history.
Memory InputWhat NPC TracksWorld Effect
Past quest outcomesWhether player completed, failed, or abandoned questsFuture quest availability from that NPC changes
Dialogue toneHonesty, aggression, or deception in past interactionsNPC trust level adjusts, gates high-value dialogue
Combat behaviorWhether player attacked faction members or protected themHostility or alliance status updates in real-time
Faction alignmentCurrent standing with NPC's affiliated factionPricing, services, and narrative access shift accordingly
NPCs respond to accumulated player history rather than isolated events, ensuring that long-term behavioral patterns shape outcomes more than any single decision.
Design intent: The world should remember what the player did, not just what they selected.
C. Quest Gating System — The Progression Layer
Six branching questlines gated by combined faction thresholds and NPC memory flags. Two players can complete identical objectives but unlock entirely different content based on their faction alignment and prior behavior.
EXAMPLE GATE
Quest unlocks when: Faction Standing ≥ threshold AND NPC Memory flag = positive

Both conditions are shaped by behavioral history. A player who completed the required quests but attacked faction members in combat will be blocked.  
Design intent: Progression is earned through alignment, not completion.
D. Combat System — The World-State Input
Melee and ranged combat with real-time hit detection, enemy health logic, and lock-on targeting. The key systems design decision: combat outcomes feed directly into faction reputation, linking every encounter to world state rather than treating combat as isolated gameplay.
Combat Mechanics
Melee + ranged with real-time hit detection
Lock-on targeting for structured encounters
Ability states, stamina, and visual/audio feedback
Enemy health logic with damage scaling
Systemic Connection
Killing faction members reduces reputation
Protecting allies increases faction standing
Combat style logged in NPC memory
Encounter outcomes feed into world state
Design intent: Combat outcomes feed into faction reputation linking gameplay performance directly to world state.
E. AI Behavior System — The Encounter Layer
Enemy behavior built with Unreal's Behavior Trees and Environment Query System (EQS). Enemies patrol, pursue, and adapt their attack patterns based on player positioning and health making every encounter feel responsive.
AI BEHAVIOR STATES
Patrol → route-based patrol with environment awareness, transitions to alert on player detection
Pursuit → EQS-driven pursuit adapting to player movement and positioning in real-time
Combat → dynamic attack patterns adapting to player health, distance, and engagement style
Retreat / Regroup → threat-based decision making, enemies disengage and reposition based on combat state
Design intent: Enemy behavior adapts to player engagement style, reinforcing combat as a systemic input rather than an isolated encounter.
Example Gameplay Scenario
The player completes a quest for Faction A but during the mission, they kill two Faction B guards to take a shortcut. No explicit warning fires. The system just updates.
Quest Completed for Faction A
Faction A reputation increases: quest outcome logged in NPC memory
↓
Faction B Guards Killed En Route
Faction B reputation drops · hostile attitude flag triggers · NPC memory logs combat behavior
↓
World State Updates
two systems changed simultaneously — one improved, one degraded
↓
Player Reaches Faction B Town
merchants charge higher prices · questline locked · guards are hostile on sight
WHAT THE PLAYER EXPERIENCES
The player succeeded at the quest. But the world changed around them: not because they failed, but because of how they played. 
This is the system working as designed. No penalty screen. No explicit warning. Just consequence delivered through the world.
System Interdependency
No single system controls progression: world state emerges from the alignment of all systems simultaneously.
Player identity is expressed through faction alignment.
This creates a loop where player action shapes world state, and world state reshapes every future action.
Combat
faction reputation input
Dialogue
NPC memory input
Exploration
world discovery input
affects ↓
updates ↓
feeds into ↓
World State
faction reputation + NPC memory:  the shared variable everything reads from
↓ gates
↓ modifies
↓ reshapes
Quests
availability · branching
NPC Behavior
attitude · pricing · dialogue
Encounters
hostility · AI behavior
CASCADE EXAMPLE
Combat kills Faction B guards → Faction B reputation drops → NPC attitude flips to hostile → Quest gate closes → New hostile encounter spawns in previously safe zone → Player must rebuild reputation to reopen path  
System Failure Case: When Faction Systems Feel Cosmetic
The clearest sign a faction system has failed: players ignore it. That's what happened in the early prototype.
What Players Did
Ignored faction standing entirely
Treated reputation as dialogue flavor
Made decisions without considering faction cost
Optimized quests without systemic thinking
Why It Happened
Faction only changed dialogue tone, no mechanical weight
No quest gating tied to reputation thresholds
No pricing or access changes based on standing
Consequence was invisible, system exposed itself as cosmetic
ROOT CAUSE → FIX → RESULT
No mechanical weight → Tied faction standing to quest gating, pricing, and NPC hostility; reputation now has direct mechanical consequences
Invisible consequences → Combat outcomes now visibly update faction state in real-time; players could observe the system responding to their choices
No cross-system integration → Connected combat, dialogue, and quest outcomes to a single shared world state; no action is isolated from the faction system
After the fix: players began making decisions strategically by weighing faction cost against quest reward. Reputation became a resource to manage, not a meter to ignore.
My Approach
I approached IronRoot as a systems integration problem: the goal was not to build strong individual systems, but to ensure every system contributed to a shared world state so that no player action existed in isolation from faction reputation or political memory.
Step 1 — Built World State as the Core Layer
Designed faction reputation and NPC memory as the backbone before building any other system. Everything else like combat, AI, quests was built to write to and read from this shared state rather than operating independently.
Step 2 — Connected Combat to Faction Consequences
Made the design decision early that combat outcomes must feed into faction reputation. This required integrating the combat hit detection system with the faction tracking backend so every kill, assist, or retreat had a systemic consequence beyond the encounter itself.
Step 3 — Built NPC Memory in Blueprint + C++
Designed the NPC memory system to track player choices, tone, and quest outcomes persistently using Blueprint for designer-facing dialogue logic and C++ for the backend state tracking. Memory flags feed directly into dialogue gating and quest availability.
Step 4 — Iterated on Consequence Visibility
The critical insight from playtesting: players need to feel the system without having it explained. Iterated on how and when faction consequences surfaced, making them visible enough to feel real, delayed enough to feel earned rather than punitive.
System Contributions
SYSTEM CONTRIBUTIONS
Faction System → Designed a 4-faction reputation system where combat and dialogue dynamically shift world state, gating quests, pricing, and NPC behavior in real-time
Political Memory → Engineered persistent NPC memory tracking player decisions across quests and encounters, influencing dialogue, quest availability, and faction alignment
Quest Architecture → Built 6+ branching questlines gated by faction alignment and NPC memory, enabling different outcomes for identical objectives
Combat Systems → Developed melee and ranged combat systems with lock-on targeting, and ability states; combat outcomes feed directly into faction reputation
AI Behavior → Implemented AI using Behaviour Trees and EQS, enabling patrol, pursuit, and adaptive combat based on player positioning
Systems Integration → Integrated combat, dialogue, and exploration into a shared world state, ensuring no system operates in isolation
Key Design Takeaways
Faction systems only work when they have mechanical weight
If reputation only changes dialogue, players ignore it. Once it gates quests, pricing, and NPC behaviour, it becomes a strategic resource rather than flavour.
All gameplay systems must feed into a shared state
Combat, dialogue, and exploration feel disconnected unless they write to the same system. A shared world state model ensures that every action has consequences beyond its immediate context.
Consequence visibility is a design problem
Consequences must be readable but not explicit. Too immediate and it feels punitive. Too delayed and it feels arbitrary. The goal is to make outcomes feel earned without exposing the system.

← Back to Full IronRoot Page