license: public domain CC0
NEW AND IMPROVED VERSION AVAILABLE HERE:
AI-Driven Interactive Game Design System: A Novel Architecture for Declarative Game Development
A comprehensive design for a multi-agent system that enables iterative, traceable, and refactorable game design through immutable state architecture, declarative rules, and intelligent automation.
Abstract
This document presents a novel architecture for game development that fundamentally rethinks the relationship between design intent, executable specifications, and implementation. By combining multi-agent AI systems, declarative rules engines, immutable state management, and comprehensive lineage tracking, we enable game designers to work at the level of intent while maintaining complete bidirectional traceability to implementation. The system supports continuous iteration through time-travel debugging, automatic refactoring, and multi-frame convergence patterns that separate simulation correctness from presentation smoothness.
Key innovations:
- Compositional traceability: Complete bidirectional lineage from design rules through specs to implementation
- Immutable state architecture: Structural sharing enables instant replay and comparison without explicit snapshots
- Multi-frame convergence: Separation of simulation state from presentation enables complex feature interactions
- AI-assisted refactoring: Automatic detection and execution of architectural transformations
- Declarative execution model: Hierarchical rules and state machines with automatic priority resolution
1. Problem Statement
1.1 Current State of Game Development
Modern game development suffers from several fundamental challenges:
Loss of design intent: As games evolve, the connection between "why we made this decision" and "how it's implemented" is lost. Code becomes the sole source of truth, but code cannot express intent.
Refactoring paralysis: Adding new features often requires unanticipated interaction patterns (multi-system negotiation, pre-death hooks, reentrant state changes). Refactoring is risky because:
- Impact is unclear (what breaks if I change this?)
- Relationships are implicit (hidden dependencies)
- Testing is incomplete (edge cases emerge from interactions)
Iteration friction: Tuning game feel requires:
- Manual replay of the same section repeatedly
- Guessing which parameters affect the desired change
- Rebuilding/restarting to test changes
- No comparative analysis between iterations
Coupling complexity: Game systems inevitably cut across any decomposition:
- Screen shake touches combat, camera, audio, particles, UI
- Death handling involves health, animation, progression, saves, UI
- Jump feel depends on input, physics, animation, camera, audio
State management chaos:
- Imperative, in-place mutation makes debugging hard
- Can't easily inspect "what changed" between frames
- Replay requires complex event replay systems
- No simple way to compare execution paths
1.2 The Fundamental Impossibility
No execution model can anticipate all future feature requirements. New features inevitably require new interaction patterns:
- Revenge perk (action triggered after death detected but before death finalized)
- Martyr explosion (reentrant death during death processing)
- Combo finishers (multi-system negotiation before execution)
Traditional architectures force painful refactoring when these patterns emerge. We need a system where refactoring capability is the primary feature, not execution model completeness.
2. Core Architecture
2.1 The Artifact Graph: Lineage as Foundation
Every artifact (rule, spec, code) exists in a directed acyclic graph with explicit lineage:
Design Rule (Intent)
↓ refined_by: AI Agent
Formal Specification (Behavior)
↓ implements: Code Generator
Implementation (Code)
↓ tested_by: Test Suite
Bidirectional traceability:
- Forward: Design change → AI proposes spec update → generates code changes
- Backward: Code divergence detected → AI traces to spec → asks if intent changed
Example lineage:
rule_id: "screen_shake_on_heavy_damage"
intent: "Screen must shake on heavy damage to emphasize impact"
domain: "game_feel"
↓ derives_from
spec_id: "screen_shake_heavy_damage_v2"
trigger:
event: "DamageEvent"
condition: "damage > target.maxHealth * 0.30"
computation:
shake_intensity: "min((damage / maxHealth) * 2.0, 1.0)"
↓ implements
code: "ScreenShakeSystem.cpp"
function: "onDamageEvent()"
lines: [145-167]
constants:
HEAVY_DAMAGE_THRESHOLD: 0.30 # linked to spec.trigger.condition
SHAKE_MULTIPLIER: 2.0 # linked to spec.computation
2.2 Multi-Agent System
Specialized AI agents manage different aspects of the design-to-implementation pipeline:
1. Orchestrator Agent
- Routes designer input to appropriate agents
- Manages conversation flow
- Prevents infinite loops
2. State Manager Agent
- Maintains canonical game design document (GDD) structure
- Tracks implementation status
- Generates reports and diffs
3. Design Specialist Agents
- Mechanics, Narrative, World, Systems, Economy, etc.
- Each has domain-specific knowledge and prompting
- Propose additions/changes in their domain
4. Validator Agent
- Reviews proposals for consistency
- Checks dependencies
- Flags contradictions
- Challenges assumptions
5. Technical Feasibility Agent
- Evaluates implementation complexity
- Estimates development time
- Flags technical risks
- Suggests scope reductions
6. Integration Agent
- Identifies ripple effects across systems
- Maintains dependency graphs
- Proposes holistic solutions
7. Refactoring Agent
- Detects when architecture is insufficient
- Suggests refactoring patterns
- Generates transformation plans
- Executes safe migrations
8. Convergence Analyzer Agent
- Predicts multi-frame convergence time
- Suggests visual masking techniques
- Validates smoothness of execution
2.3 Immutable State Architecture
Core principle: Previous state + input → new state (no in-place mutation)
// Every frame creates new state
GameState update(const GameState& previousState, const Input& input) {
GameState newState = previousState; // Structural sharing
newState.player = updatePlayer(previousState.player, input);
newState.entities = updateEntities(previousState.entities);
return newState; // Previous state untouched
}
// History is automatic
StateRingBuffer<GameState> stateHistory(3600); // 60 seconds at 60fps
void mainLoop(Input input) {
auto prevState = stateHistory.getCurrent();
auto newState = make_shared<GameState>(update(*prevState, input));
stateHistory.push(newState);
}
Structural sharing prevents memory explosion:
- Persistent data structures (like Clojure's PersistentVector)
- Only modified paths allocate new memory
- Unchanged subtrees share pointers
- Typical overhead: 50KB per frame vs 10MB for full copy
Benefits:
- ✅ Every frame IS a snapshot (no explicit snapshot logic)
- ✅ Instant replay (just reference old state)
- ✅ Instant comparison (diff any two states)
- ✅ Timeline branching (test parameter changes in parallel)
- ✅ Thread-safe (immutable data can be read anywhere)
- ✅ Determinism verification (replay from inputs, compare states)
2.4 Declarative Rules Engine
Game logic expressed as rules, not imperative code:
rule: "death_check_with_revenge_perk"
priority_class: "critical_correctness"
execution_flow:
stages:
- detect_death:
condition: "player.health <= 0"
- pre_death_hooks:
if: "player.hasRevengePerk"
action: "trigger_revenge_damage"
- commit_death:
action: "set_player_state(DEAD)"
convergence_time: 3 # frames
visual_masking: "damage_flash"
AI generates implementation:
// GENERATED FROM: spec:death_check_with_revenge_v1
// Frame 0: Apply damage
void applyDamage(DamageEvent& e) {
player.health -= e.amount;
}
// Frame 1: Detect death
void detectDeath() {
if (player.health <= 0) {
player.deathPending = true;
}
}
// Frame 2: Run hooks
void runPreDeathHooks() {
if (player.deathPending && player.hasRevengePerk) {
triggerRevengeDamage();
}
}
// Frame 3: Commit death
void commitDeath() {
if (player.deathPending) {
player.state = DEAD;
}
}
Hierarchical organization:
rules/
├── core/
│ ├── physics.drl # Gravity, collision
│ └── time.drl # Frame timing
├── systems/
│ ├── combat/
│ │ ├── damage.drl
│ │ └── death.drl
│ └── movement/
│ └── jump.drl
└── meta/
└── difficulty.drl # Modifies base rules
Dependencies flow downward only. Meta-rules can override base rules while preserving lineage.
3. Key Innovations
3.1 Multi-Frame Convergence
Insight: At 60fps, state can take 2-5 frames to converge if presentation remains smooth.
Dual-state model:
struct SimulationState {
// Can be temporarily inconsistent
float playerHealth; // Might be -10
bool isPlayerDead; // Might be false while health < 0
bool hasConverged;
int convergenceFramesRemaining;
};
struct PresentationState {
// Always renderable
float displayHealth; // Clamped [0, maxHealth]
AnimationState currentAnim; // Always valid
float damageFlashIntensity; // Masks convergence
};
Example: Death with multi-frame convergence
Frame 0: Damage applied, health = -10
Presentation: Show damage flash, interpolate health down
Frame 1: Death detected, deathPending = true
Presentation: Flash still visible, health bar animating
Frame 2: Revenge perk triggers damage to enemies
Presentation: Flash fading, health reached 0
Frame 3: Death committed, death animation starts
Presentation: Smooth transition to death animation
Player experience: Smooth 50ms death sequence. No visible inconsistency.
What this enables:
- Complex multi-system features (negotiation, hooks, dependencies)
- Safe refactoring (can split atomic operations into stages)
- Better game feel (intentional interpolation and smoothing)
Visual masking techniques:
- Damage flash (red overlay)
- Screen shake + flash (heavy impact)
- Slow motion (dramatic moments)
- Intentional health bar lag (easier to track changes)
3.2 Global Priority and Execution Graphs
Challenge: Game systems have global interdependencies (death must check before effects, but after damage).
Solution: Explicit dependency graph with semantic priority classes.
priority_classes:
critical_correctness: [700-1000] # Death, invulnerability
gameplay_logic: [400-700] # Damage calc, buffs
effects_cosmetic: [100-400] # Particles, sounds
ui_updates: [50-100] # Health bars, icons
execution_flow: "damage_to_death"
stages:
- validation:
priority: critical_correctness
nodes: [invulnerability_check, damage_calculation]
- application:
priority: critical_correctness
depends_on: [validation]
nodes: [apply_damage, death_check]
- effects:
priority: effects_cosmetic
depends_on: [application]
conditional:
death_check.result == true: [death_effects]
death_check.result == false: [damage_effects]
AI validates and visualizes:
Priority: 1000 (Invulnerability Check)
↓
900 (Damage Calculation)
↓
800 (Apply Damage)
↓
700 (Death Check) ◄── CRITICAL DECISION
├─ True → 650 (Death Effects)
└─ False → 600 (Damage Effects)
Conflict detection:
⚠️ Priority conflict detected!
Rule: "critical_hit_special_shake"
→ Priority: 750 (before death_check at 700)
→ Triggers screen shake
But: death_check (700) should cancel ALL shakes
Suggestion: Move critical_hit_shake to 650 (after death_check)
3.3 Record/Replay System
During play: Append-only event stream (very lightweight)
void recordFrame() {
// Just push state reference (cheap)
stateHistory.push(currentState);
// Record events for debugging
eventLog.append(currentFrameEvents);
}
Entering debug mode: Current state already captured (instant)
Replaying: No event replay needed - just reference old state
void jumpToFrame(int targetFrame) {
int framesAgo = currentFrame - targetFrame;
currentState = stateHistory.get(framesAgo);
// That's it. Instant.
}
Memory overhead with structural sharing:
- Frame 0: 10MB (initial state)
- Frames 1-60: ~50KB each (only changes)
- Total for 60 seconds: ~13MB
Parameter override and branching:
void createBranch(string name, int fromFrame,
map<string, Variant> overrides) {
auto startState = stateHistory.getFrame(fromFrame);
// Replay forward with overrides
for (int f = fromFrame; f <= currentFrame; f++) {
auto input = recorder.getInput(f);
startState = updateWithOverrides(*startState, input, overrides);
}
branches[name] = startState;
}
// Compare branches
auto diff = compareStates(
branches["original"],
branches["higher_jump"]
);
3.4 Refactoring as First-Class Operation
Pattern library for common transformations:
1. Atomic → Phased
Before: death_check (instant, atomic)
After: death_detection → pre_death_hooks → death_commitment
2. Linear → Reentrant
Before: handleDeath() calls itself (undefined behavior)
After: Deferred execution queue prevents reentrancy
3. Single-Source → Multi-Source
Before: DamageEvent has one source
After: DamageEvent has vector<DamageSource>
4. Concrete → Negotiation
Before: Finisher executes immediately
After: Systems vote on whether finisher can execute
AI-detected refactoring need:
⚠️ Current architecture cannot handle:
"Revenge perk deals damage after death detected
but before death finalized"
Suggested refactoring:
Pattern: atomic_to_phased
Splits: death_check → [detect, hooks, commit]
Complexity: medium
Risk: medium
Affected:
- 1 rule: death_supersedes_damage_effects
- 3 specs: death_check, death_effects, damage_effects
- 12 code files
- 23 tests
[View Details] [Apply Refactoring] [Cancel]
Safe execution:
- Create checkpoint (all state captured)
- Apply transformation incrementally
- Validate after each phase
- Rollback if validation fails
4. Complete Workflow Example
4.1 Initial Design: Jump Mechanics
Designer intent:
"I want a platformer with snappy, responsive jumping"
AI conversation:
AI: Let me help you design the jump mechanics. A few questions:
1. How should jumps feel?
- Heavy and weighty
- Floaty and airborne
- Snappy and responsive ✓
2. Should players have air control?
- Full control
- Partial control ✓
- No control
3. Variable jump height (hold button = higher jump)?
- Yes ✓
- No
AI: Great! I'll create the jump mechanics spec.
Generated rule:
rule_id: "player_jump_feel"
domain: "movement"
intent: "Snappy, responsive jump with air control"
parameters:
jump_force: 400
gravity: 9.8
air_control: 0.6
variable_jump: true
min_jump_duration: 0.15
Generated spec:
spec_id: "jump_mechanics_v1"
derives_from: "player_jump_feel"
implementation:
on_jump_press:
- if: player.grounded
then: set_velocity_y(JUMP_FORCE)
while_jump_held:
- if: jump_duration < MIN_JUMP_DURATION
then: maintain_upward_velocity
air_movement:
- horizontal_control: AIR_CONTROL * input.horizontal
gravity_application:
- constant: GRAVITY
Generated code:
// IMPLEMENTS: spec:jump_mechanics_v1
// LINKED TO: rule:player_jump_feel
static constexpr float JUMP_FORCE = 400.0f;
static constexpr float GRAVITY = 9.8f;
static constexpr float AIR_CONTROL = 0.6f;
PlayerState updatePlayer(const PlayerState& prev, const Input& input) {
PlayerState next = prev;
// Jump on press (if grounded)
if (input.jumpPressed && prev.grounded) {
next.velocity.y = JUMP_FORCE;
next.jumpStartTime = currentTime;
}
// Variable jump height
if (input.jumpHeld &&
(currentTime - prev.jumpStartTime) < 0.15) {
next.velocity.y = max(next.velocity.y, JUMP_FORCE * 0.5);
}
// Air control
if (!prev.grounded) {
next.velocity.x += input.horizontal * AIR_CONTROL;
}
// Gravity
next.velocity.y -= GRAVITY;
return next;
}
4.2 Iteration: Jump Feels Too Floaty
Designer plays game, jumps, feels off:
[Jump happens]
Designer presses F6 → Bookmarks last 60 frames
Debug mode activated:
┌─────────────────────────────────────────────────────┐
│ Jump Analysis (Frames 30-47) │
├─────────────────────────────────────────────────────┤
│ Detected: │
│ Jump apex: 300px (frame 47) │
│ Hang time: 0.82s │
│ ⚠️ Feels floaty (ideal hang time: 0.6s) │
│ │
│ Suggested changes: │
│ 1. Increase gravity: 9.8 → 12.0 │
│ 2. Reduce jump_force: 400 → 380 │
│ │
│ [Try Option 1] [Try Option 2] [Try Both] │
└─────────────────────────────────────────────────────┘
Designer clicks "Try Both":
[System creates branch timeline with new parameters]
[Replays frames 30-60 with gravity=12.0, jump_force=380]
[Shows side-by-side comparison]
┌──────────────────┬──────────────────┐
│ Before │ After │
│ 🟡 (300px) │ 🟡 (240px) │
│ ↓ │ ↓ │
│ 🧍 │ 🧍 │
│ Frame 47 │ Frame 45 │
│ │ │
│ Floaty feel │ Snappy feel │
└──────────────────┴──────────────────┘
[Accept Changes] [Try Different Values] [Revert]
Designer clicks "Accept Changes":
AI: I'll update the jump mechanics. Here's what will change:
Lineage trace:
↑ Code: PlayerController.cpp (2 constants)
↑ Spec: jump_mechanics_v1 → v2
↑ Rule: player_jump_feel
Impact:
- No conflicts detected
- Tests will pass (updating expected values)
- Related systems: camera tracking (will adjust automatically)
[Approve] [Review Details] [Cancel]
System updates:
- Creates spec:jump_mechanics_v2
- Regenerates code with new constants
- Updates test expectations
- Maintains lineage: v2 derives from v1, change rationale recorded
4.3 New Feature: Double Jump
Designer: "Add double jump ability"
AI analyzes:
AI: I can add double jump to the jump mechanics system.
Questions:
1. How many mid-air jumps? [1] [2] [Unlimited]
2. Full jump height or reduced? [Full] [80%] [50%]
3. Reset on wall touch? [Yes] [No]
[Generating spec...]
This will create:
- New rule: double_jump_ability
- Modified spec: jump_mechanics_v2 → v3
- Code changes: PlayerController.cpp (15 new lines)
- New parameter: double_jump_force = 320 (80% of base)
[Preview Changes] [Apply] [Cancel]
Lineage maintained:
rule:player_jump_feel
↓
spec:jump_mechanics_v1 (single jump)
↓
spec:jump_mechanics_v2 (tuned gravity/force)
↓
spec:jump_mechanics_v3 (added double jump)
↓
code:PlayerController.cpp (current)
4.4 Refactoring Example: Add Coyote Time
Designer: "Add coyote time - player can jump briefly after leaving ledge"
AI detects architecture limitation:
⚠️ Current jump system checks grounded state atomically.
Coyote time requires tracking "time since left ground."
Suggested refactoring:
Pattern: add_temporal_state
Changes:
- Add: PlayerState.lastGroundedTime
- Modify: Jump condition to check time threshold
- Affects: 1 spec, 1 code file, 3 tests
This is a simple refactoring (low risk).
[Apply Automatically] [Review First] [Cancel]
Applied changes:
// Before
if (input.jumpPressed && player.grounded) {
jump();
}
// After
const float COYOTE_TIME = 0.15f;
float timeSinceGrounded = currentTime - player.lastGroundedTime;
if (input.jumpPressed &&
(player.grounded || timeSinceGrounded < COYOTE_TIME)) {
jump();
}
Lineage updated:
spec:jump_mechanics_v3 → v4
added: coyote_time parameter
rationale: "Improve platform game feel"
5. Technical Considerations
5.1 Performance Characteristics
Immutable state overhead:
- State update: ~0.5ms (50KB allocation + reference counting)
- Ring buffer maintenance: <0.1ms
- Total overhead: ~3% of 16ms frame budget (acceptable for development)
Production optimization:
- Compile rules to optimized native code
- Use copy-on-write for hot paths
- Disable history in shipping builds (optional)
Structural sharing efficiency:
- 1000 entities, 10 change per frame: 99% memory sharing
- Static world data: 100% sharing across all frames
- Typical: 50KB per frame vs 10MB for full copy (99.5% savings)
5.2 Determinism Requirements
Critical for replay:
- No
rand() without seeded RNG - No system time queries in gameplay
- No floating-point non-determinism
- Input is only source of randomness
Verification:
void verifyDeterminism() {
auto recorded = recorder.getState(100);
auto replayed = replayFromInput(0, 100);
if (*recorded != *replayed) {
reportNonDeterminism(findDifferences(recorded, replayed));
}
}
5.3 Scalability Considerations
State size limits:
- Ring buffer: 3600 frames (60s) × 50KB = 180MB
- Acceptable for development
- Can reduce to 30s if needed
Large worlds:
- Spatial partitioning keeps most data unchanged
- Only active region copied per frame
- Distant entities: 100% sharing
Many entities:
- Persistent vector handles 100,000+ entities efficiently
- O(log32 N) updates (nearly constant time)
5.4 Multi-threading
Immutable data is inherently thread-safe:
- Rendering thread can read any historical state
- Physics simulation can run ahead speculatively
- AI can analyze past states on worker threads
Example: Async analysis
// Game thread
stateHistory.push(newState);
// Analysis thread (safe concurrent read)
auto state = stateHistory.get(60); // 1 second ago
auto analysis = analyzeGameplay(state);
ui.showSuggestions(analysis);
6. Implementation Roadmap
Phase 1: Proof of Concept (4-6 weeks)
- Immutable state architecture for simple game (Pong/Breakout)
- Basic event recording and replay
- Single AI agent for rule generation
- Demonstrate lineage tracking
Success criteria:
- Can jump to any frame instantly
- Can modify parameter and see change immediately
- Rule → spec → code lineage visible
Phase 2: Multi-Agent System (8-10 weeks)
- Implement agent specialization
- Add validator and refactoring agents
- Build execution graph visualization
- Implement priority conflict detection
Success criteria:
- AI suggests parameter changes from feedback
- AI detects architectural limitations
- AI proposes and executes refactorings
Phase 3: Production Features (12-16 weeks)
- Optimize structural sharing performance
- Add visual debug markers
- Implement timeline branching
- Build comprehensive UI
Success criteria:
- <5% performance overhead
- Side-by-side timeline comparison
- Professional iteration workflow
Phase 4: Complex Game (16-20 weeks)
- Apply to full-featured game (platformer or action game)
- Test with real design iteration
- Refine AI agents based on usage
- Optimize for production
Success criteria:
- Complete game built using system
- Demonstrates refactoring capability
- Proves iteration efficiency gains
7. Novel Contributions
7.1 To Game Development
- Bidirectional traceability: First system to maintain complete lineage from design intent to implementation
- Refactoring-first architecture: Treating refactoring as primary capability, not maintenance task
- Multi-frame convergence: Formal separation of simulation correctness from presentation smoothness
- Immutable game state: First production game engine built on persistent data structures
7.2 To AI Systems
- Multi-agent game design: Novel application of specialized AI agents to creative software development
- Context-aware code generation: Code generation that maintains semantic lineage to high-level intent
- Automated refactoring detection: AI that identifies architectural limitations and proposes patterns
7.3 To Software Engineering
- Compositional traceability: Pattern applicable beyond games to any iterative creative software
- Visual debugging through time-travel: Leveraging immutability for unprecedented debugging capabilities
- Declarative execution with imperative performance: Rules compile to optimized code while preserving semantics
8. Conclusion
This design presents a comprehensive rethinking of game development tooling. By combining immutable state architecture, multi-agent AI systems, declarative rules, and comprehensive lineage tracking, we enable a workflow where:
Designers work at the level of intent ("Jump should feel snappy") AI bridges to implementation (generates specs and code) Iteration is instantaneous (replay with parameter changes) Refactoring is safe (complete impact analysis and lineage) Complexity is manageable (explicit dependencies and priorities)
The system doesn't eliminate the need for human creativity, judgment, or expertise. Instead, it amplifies these capabilities by:
- Removing friction from iteration
- Making implicit knowledge explicit
- Enabling rapid experimentation
- Maintaining design rationale
The future of game development isn't AI replacing game designers. It's AI as an intelligent assistant that helps designers iterate faster, understand their systems better, and safely evolve their games as requirements change.
The architecture presented here is buildable with current technology and offers genuine improvements to the game development process. The path forward is clear: start with simple proof of concept, validate the core ideas, and incrementally build toward production-ready tooling.
9. References and Further Reading
Immutable Data Structures:
- Okasaki, Chris. "Purely Functional Data Structures" (1998)
- Bagwell, Phil. "Ideal Hash Trees" (2001)
- Hickey, Rich. "Persistent Data Structures and Managed References" (Clojure design)
Rules Engines:
- Forgy, Charles. "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem" (1982)
- JBoss Drools Documentation
- Clara Rules (Clojure rules engine)
Game Architecture:
- Nystrom, Bob. "Game Programming Patterns" (2014)
- Gregory, Jason. "Game Engine Architecture" (2018)
- Blow, Jonathan. "Immediate Mode GUI" paradigms
AI-Assisted Development:
- OpenAI Codex and GitHub Copilot studies
- Multi-agent systems for software development (emerging research)
Time-Travel Debugging:
- Mozilla rr (record and replay)
- Undo Live Recorder
- Redux DevTools (web development)
Appendix A: Glossary
Artifact Graph: Directed acyclic graph connecting design rules, specifications, and implementation code with explicit lineage relationships.
Convergence: Process by which simulation state becomes consistent over multiple frames while presentation remains smooth.
Lineage: The traced relationship showing how implementation derives from specifications and rules, enabling bidirectional impact analysis.
Multi-frame Convergence: Architectural pattern allowing game state to take multiple frames to reach consistency while maintaining smooth visual presentation.
Persistent Data Structure: Immutable data structure that preserves previous versions when modified through structural sharing.
Priority Class: Semantic grouping of execution priorities (critical_correctness, gameplay_logic, effects_cosmetic, ui_updates).
Structural Sharing: Memory optimization technique where unchanged portions of data structures are shared between versions through reference counting.
State Snapshot: Complete capture of game state at a specific frame; in this architecture, automatic through immutability.
Document Version: 1.0
Date: February 2026
Status: Design Specification
