Iron Curtain — Design Documentation

Trigger System (RTS-Adapted)

OFP’s trigger system adapted for RTS gameplay:

RTS-specific trigger conditions:

Countdown vs Timeout with Min/Mid/Max is crucial for RTS missions. Example: “Reinforcements arrive 3–7 minutes after the player captures the bridge” (Countdown, Min=3m, Mid=5m, Max=7m). The player can’t memorize the exact timing. In OFP, this was the key to making missions feel alive rather than scripted.

Mission Outcome Wiring (Scenario → Campaign)

D021 defines named outcomes at the campaign level (e.g., victory_bridge_intact, victory_bridge_destroyed, defeat). The scenario editor is where those outcomes are authored and wired to in-game conditions.

Outcome Trigger type — extends the existing Victory/Defeat trigger types:

Lua API for script-driven outcomes:

-- Fire a named outcome from any script context (trigger, module, init)
Mission.Complete("victory_bridge_intact")

-- Fire with metadata (optional — flows to campaign variables)
Mission.Complete("victory_bridge_destroyed", {
    bridge_status = "destroyed",
    civilian_casualties = Var.get("civ_deaths"),
})

-- Query available outcomes (useful for dynamic logic)
local outcomes = Mission.GetOutcomes()  -- returns list of named outcomes from campaign graph

-- Check if an outcome has fired (for multi-phase scenarios)
if Mission.IsComplete() then return end

Design rules:

• A scenario can define any number of Outcome triggers. The first one to fire determines the campaign branch — subsequent outcome triggers are ignored
• If a scenario is standalone (not linked to a campaign), Outcome triggers with names starting with victory behave as Victory, names starting with defeat behave as Defeat, and all others behave as Victory. This makes standalone playtesting natural
• Legacy Victory and Defeat trigger types still work — they map to the default outcomes victory and defeat respectively. Named outcomes are a strict superset

Outcome validation (editor checks):

• Warning if a scenario has no Outcome trigger and no Victory/Defeat trigger
• Warning if a scenario linked to a campaign has Outcome names that don’t match any branch in the campaign graph
• Warning if a scenario has only one outcome (no branching potential — may be intentional for linear campaigns)
• Error if two Outcome triggers have the same name and the same priority (ambiguous)

Example wiring:

Campaign Graph (D021):          Scenario "bridge_mission":

  ┌─────────────┐              Trigger "bridge_secured":
  │ Bridge       │                Condition: allied_present in bridge_area
  │ Mission      │───►            AND NOT building_destroyed(bridge)
  │              │                Type: Outcome
  └──┬───────┬───┘                Outcome Name: victory_bridge_intact
     │       │
     ▼       ▼                Trigger "bridge_blown":
  ┌─────┐ ┌─────┐               Condition: building_destroyed(bridge)
  │ 02a │ │ 02b │               Type: Outcome
  │(int)│ │(des)│               Outcome Name: victory_bridge_destroyed
  └─────┘ └─────┘
                              Trigger "defeat":
                                Condition: all player units destroyed
                                Type: Outcome
                                Outcome Name: defeat

Module System (Pre-Packaged Logic Nodes)

Modules are IC’s equivalent of Eden Editor’s 154 built-in modules — complex game logic packaged as drag-and-drop nodes with a properties panel. Non-programmers get 80% of the power without writing Lua.

Built-in module library (initial set):

Modules connect to triggers and other entities via visual connection lines — same as OFP’s synchronization system. A “Reinforcements” module connected to a trigger means the reinforcements arrive when the trigger fires. No scripting required.

Custom modules can be created by modders — a YAML definition + Lua implementation, publishable via Workshop (D030). The community can extend the module library indefinitely.

Waypoints Mode (Visual Route Authoring)

OFP’s F4 (Waypoints) mode let designers click the map to create movement orders for groups — the most intuitive way to choreograph AI behavior without scripting. IC adapts this for RTS with waypoint types tailored to base-building and resource-gathering gameplay.

Placing Waypoints

• Click the map in Waypoints mode to place a waypoint marker (numbered circle with directional arrow)
• Click another position while a waypoint is selected to create the next waypoint in the sequence — a colored line connects them
• Right-click to finish the current waypoint sequence
• Waypoints can be moved (drag), deleted (Del), and reordered (drag in the properties panel list)
• Each waypoint sequence is a named route with a variable name (e.g., north_patrol, convoy_route) usable in scripts and module parameters

Waypoint Types

Waypoint Properties Panel

Each waypoint has a properties panel:

Visual Route Display

Waypoint routes are rendered as colored lines on the isometric viewport:

┌────────────────────────────────────────────────────────┐
│                                                        │
│      ①───────────②──────────③                          │
│      Move        Attack     Guard                      │
│      (blue)      (red)      (yellow)                   │
│                                                        │
│          ④═══════⑤═══════⑥═══════④                     │
│          Patrol  Patrol  Patrol  (loop)                │
│          (green cycling arrows)                        │
│                                                        │
│      ⑦ · · · · · ⑧                                    │
│      Wait         Script                               │
│      (dotted, paused)                                  │
│                                                        │
└────────────────────────────────────────────────────────┘

• Color coding by type: Move=blue, Attack=red, Guard=yellow, Patrol=green (with cycling arrows), Harvest=amber, Wait=dotted gray
• Route labels appear above the first waypoint showing the route name
• Inactive routes (assigned to entities not currently selected) appear faded
• Active route (selected entity’s route) appears bright with animated directional arrows

Assigning Entities to Routes

• Select an entity or group → right-click a waypoint route → “Assign to Route”
• Or: Select entity → Properties panel → Route dropdown → pick from named routes
• Or: Module connection — a Patrol Route module references a named waypoint route
• Multiple entities/groups can share the same route (each follows it independently)
• Lua: entity:set_route("north_patrol") or entity:set_patrol_route("north_patrol") (existing API, now visually authored)

Synchronization Lines (Multi-Group Coordination)

OFP’s synchronization concept — the single most powerful tool for coordinated AI behavior:

• Draw a sync line between waypoints of different groups by holding Shift and clicking two waypoints
• Effect: Both groups pause at their respective waypoints until both have arrived, then proceed simultaneously
• Use case: “Group Alpha waits at the north ridge, Group Bravo waits at the south bridge. When BOTH are in position, they attack from both sides at once.”
• Synchronization lines appear as dashed white lines between the connected waypoints
• Can sync more than two groups — all must arrive before any proceed

Group Alpha route:     ①───②───③ (sync) ───④ Attack
                                  ╫
Group Bravo route:     ⑤───⑥───⑦ (sync) ───⑧ Attack
                                  ╫
Group Charlie route:   ⑨───⑩──⑪ (sync) ───⑫ Attack

All three groups wait at their sync waypoints until
the last group arrives, then all proceed to Attack.

This creates the “three-pronged attack” coordination that makes OFP missions feel alive. No scripting required — pure visual placement.

Relationship to Modules

Waypoint routes and modules work together:

• Patrol Route module = a module that wraps a named waypoint route with alert/response parameters. The module provides the “engage if threat detected, then return to route” logic; the waypoint route provides the path
• Guard Position module = a single Guard-type waypoint with radius and priority parameters wrapped in a module
• Escort Convoy module = entities following a waypoint route with “protect” behavior attached
• Hunt and Destroy module = entities cycling between random waypoints within an area

Waypoints mode gives designers direct authoring of the paths that modules reference. The same route can be used by a Patrol Route module, a custom Lua script, or a trigger’s reinforcement entry path.

Compositions (Reusable Building Blocks)

Compositions are saved groups of entities, triggers, modules, and connections — like Eden Editor’s custom compositions. They bridge the gap between individual entity placement and full scene templates (04-MODDING.md).

Hierarchy:

Entity           — single unit, building, trigger, or module
  ↓ grouped into
Composition      — reusable cluster (base layout, defensive formation, scripted encounter)
  ↓ assembled into
Scenario         — complete mission with objectives, terrain, all compositions placed
  ↓ sequenced into (via Campaign Editor)
Campaign         — branching multi-mission graph with persistent state, intermissions, and dialogue (D021)

Built-in compositions:

Workflow:

1. Place entities, arrange them, connect triggers/modules
2. Select all → “Save as Composition” → name, category, description, tags, thumbnail
3. Composition appears in the Compositions Library panel (searchable, with favorites — same palette UX as the entity panel)
4. Drag composition onto any map to place a pre-built cluster
5. Publish to Workshop (D030) — community compositions become shared building blocks

Compositions are individually publishable. Unlike scenarios (which are complete missions), a single composition can be published as a standalone Workshop resource — a “Soviet Base (Large)” layout, a “Scripted Ambush” encounter template, a “Tournament Start” formation. Other designers browse and install individual compositions, just as Garry’s Mod’s Advanced Duplicator lets players share and browse individual contraptions independently of full maps. Composition metadata (name, description, thumbnail, tags, author, dependencies) enables a browsable composition library within the Workshop, not just a flat file list.

This completes the content creation pipeline: compositions are the visual-editor equivalent of scene templates (04-MODDING.md). Scene templates are YAML/Lua for programmatic use and LLM generation. Compositions are the same concept for visual editing. They share the same underlying data format — a composition saved in the editor can be loaded as a scene template by Lua/LLM, and vice versa.

Layers

Organizational folders for managing complex scenarios:

• Group entities by purpose: “Phase 1 — Base Defense”, “Phase 2 — Counterattack”, “Enemy Patrols”, “Civilian Traffic”
• Visibility toggle — hide layers in the editor without affecting runtime (essential when a mission has 500+ entities)
• Lock toggle — prevent accidental edits to finalized layers
• Runtime show/hide — Lua can show/hide entire layers at runtime: Layer.activate("Phase2_Reinforcements") / Layer.deactivate(...). Activating a layer spawns all entities in it as a batch; deactivating despawns them. These are sim operations (deterministic, included in snapshots and replays), not editor operations — the Lua API name uses Layer, not Editor, to make the boundary clear. Internally, each entity has a layer: Option<String> field; activation toggles a per-layer active flag that the spawn system reads. Entities in inactive layers do not exist in the sim — they are serialized in the scenario file but not instantiated until activation. Deactivation is destructive: calling Layer.deactivate() despawns all entities in the layer — any runtime state (damage taken, position changes, veterancy gained) is lost. Re-activating the layer spawns fresh copies from the scenario template. This is intentional: layers model “reinforcement waves” and “phase transitions,” not pausable unit groups. For scenarios that need to preserve unit state across activation cycles, use Lua variables or campaign state (D021) to snapshot and restore specific values

Mission Phase Transitions, Map Segments, and Sub-Scenarios

Classic C&C-style campaign missions often feel like the battlefield “expands” mid-mission: an objective completes, reinforcements arrive, the camera pans to a new front, and the next objective appears in a region the player could not meaningfully access before. IC treats this as a first-class authoring pattern.

Map Segment Unlock (the “map extension” effect)

Design rule: A scenario’s map dimensions are fixed at load. IC does not rely on runtime map resizing to create phase transitions. Instead, designers author a larger battlefield up front and unlock parts of it over time.

This preserves determinism and keeps pathfinding, spatial indexing, camera bounds, replays, and saves simple. The player still experiences an “extended map” because the newly unlocked region was previously hidden, blocked, or irrelevant.

Map Segment is a visual authoring concept in the Scenario Editor:

• A named region (or set of regions) tagged as a mission phase segment: Beachhead, AA_Nest, City_Core, Soviet_Bunker_Interior_Access
• Optional segment metadata:
  • shroud/fog reveal policy
  • route blockers/gates linked to triggers
  • default camera focus point
  • associated objective group(s)
  • layer activation/deactivation presets

The Map Segment Unlock module provides a visual one-shot transition for common patterns:

• complete objective → reveal next segment
• remove blockers / open bridge / power gate
• activate reinforcement layers
• fire Radar Comm / Dialogue / Cinematic Sequence
• update objective text and focus camera

This module is intentionally a high-level wrapper over systems that already exist (regions, layers, objectives, media, triggers). Designers can use it for speed, or wire the same behavior manually for full control.

Example (Tanya-style phase unlock):

1. Objective: destroy AA emplacements in segment Harbor_AA
2. Trigger fires Map Segment Unlock
3. Module reveals segment Extraction_Docks, activates Phase2_Reinforcements, deactivates AA_Spotters
4. Module triggers a Cinematic Sequence (camera pan + Radar Comm)
5. Objectives switch to “Escort reinforcements to dock”

Sub-Scenario Portal (interior/mini-mission transitions)

Some missions need more than a reveal — they need a different space entirely: “Tanya enters the bunker,” “Spy infiltrates HQ,” “commando breach interior,” or a short puzzle/combat sequence that should not be represented on the same outdoor battlefield.

IC supports this as a Sub-Scenario Portal authoring pattern.

What it is: A visual module + scenario link that transitions the player from the current mission into a linked IC scenario (usually an interior or small specialized map), then returns with explicit outcomes.

What it is not (in this revision): A promise of fully concurrent nested map instances running simultaneously in the same mission timeline. The initial design is a pause parent → run child → return model, which is dramatically simpler and covers the majority of campaign use cases.

Sub-Scenario Portal flow (author-facing):

1. Place a portal trigger on a building/region/unit interaction (e.g., Tanya reaches ResearchLab_Entrance)
2. Link it to a target scenario (m03_lab_interior.icscn)
3. Define entry-unit filter (specific named character, selected unit set, or scripted roster subset)
4. Configure handoff payload (campaign variables, mission variables, inventory/key items, optional roster snapshot)
5. Choose return policy:
   • return on child mission victory
   • return on named child outcome (intel_stolen, alarm_triggered, charges_planted)
   • fail parent mission on child defeat (optional)
6. Optionally chain pre/post media:
   • pre: radar comm, fullscreen cutscene, briefing panel
   • post: debrief snippet, objective update, reinforcement spawn, map segment unlock

Return payload model (explicit, not magic):

• story flags (lab_data_stolen = true)
• mission variables (alarm_level = 3)
• named character state deltas (health, veterancy, equipment where applicable)
• inventory/item changes
• unlock tokens for the parent scenario (unlock_segment = Extraction_Docks)

This keeps author intent visible and testable. The editor should never hide critical state transfer behind implicit engine behavior.

Editor UX for sophisticated scenario management (Advanced mode)

To keep these patterns powerful without turning the editor into a scripting maze, the Scenario Editor exposes:

• Segment overlay view — color-coded map segments with names, objective associations, and unlock dependencies
• Portal links view — graph overlay showing parent scenario ↔ sub-scenario transitions and return outcomes
• Phase transition presets — one-click scaffolds like:
  • “Objective Complete → Radar Comm → Segment Unlock → Reinforcements → Objective Update”
  • “Enter Building → Cutscene → Sub-Scenario Portal”
  • “Return From Sub-Scenario → Debrief Snippet → Branch / Segment Unlock”
• Validation checks (used by Validate & Playtest) for:
  • portal links to missing scenarios
  • impossible return outcomes
  • segment unlocks that reveal no reachable path
  • objective transitions that leave the player with no active win path

These workflows are about maximum creativity with explicit structure: visual wrappers for common RTS storytelling patterns, with Lua still available for edge cases.

Compatibility and export implications

• IC native: Full support (target design)
• OpenRA / RA1 export: Map Segment Unlock may downcompile only partially (e.g., to reveal-area + scripted reinforcements), while Sub-Scenario Portal is generally IC-native and expected to be stripped, linearized, or exported as separate missions with fidelity warnings (see D066)

Phasing

• Phase 6b: Visual authoring support for Map Segment Unlock (module + segment overlays + validation)
• Phase 6b–7: Sub-Scenario Portal authoring and test/playtest integration (IC-native)
• Future (only if justified by real usage): True concurrent nested sub-map instances / seamless runtime map-stack transitions