Decision: Clean Path (Wargame + LangGraph) vs OpenXcom Path
Status: ACTIVE (analysis, not decided) Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-11T19:50:00Z Claim: analysis | 2026-05-11T19:45:00Z Session: Strategic trade-off analysis — continue clean LangGraph build or extend Akashic Abyss OXCE prototype
Prior Context
- [[langgraph-game-surface]] — Clean path architecture
- [[langgraph-engine-evaluation]] — Wargame Engine recommended
ports/akashic-abyss/in langgraph-game-surface.git — OXCE prototype
Short Answer
The clean path (Wargame Engine + LangGraph) is the correct long-term substrate. The OXCE prototype validates the concept (XCOM metaphors work for agent management) but is the wrong engine substrate. Extending OXCE would require C++ engine development, not modding. The save/load cycle cannot be bypassed through OXCE's YAML modding system — it requires modifying the C++ source code (300K+ LOC).
Trade-off Matrix
| Dimension | Clean Path (Wargame + LangGraph) | OXCE Path (Extend Prototype) |
|---|---|---|
| Language | Python only | C++ (OXCE engine) + Python (LangGraph bridge) |
| State model | Live LangGraph state via checkpointer | Save files (.sav); requires C++ engine mods for live state |
| Time to interactive prototype | Weeks (build rendering, already have LangGraph patterns) | Days (already runs), but weeks to add real-time state bridge |
| UI surface | Must build from scratch via Wargame's node-tree viewport | XCOM tactical UI exists (inventory grid, stats, base, geoscape) |
| Code we control | 100% Python | OXCE is 300K+ LOC foreign C++; NOMADX.rul is 100 lines we wrote |
| Modifiability ceiling | Every layer is modifiable | Limited to OXCE's YAML ruleset system (items, research, Ufopaedia text, mission scripts) |
| What we reuse | Wargame's node-tree, scene system, GUI, messaging, save/load | OXCE's tactical engine, inventory, research tree, base management, combat |
| Platform | Python runs on RG, Pi, Mac, anything | aarch64 binary only (RG40XXV, Pi 4) |
| Risk profile | Building rendering from scratch (mitigated by Wargame Engine foundation) | Fighting foreign C++ codebase; bridge failure modes |
| 10-unit constraint | Trivial for Python + pygame | Overkill — OXCE is built for 20+ soldiers + aliens + civilians |
Can OXCE's Save/Load Cycle Be Adjusted Via Modding?
No. The OXCE modding system (YAML rulesets) can add: - New items, weapons, armor, facilities, crafts - New research topics and Ufopaedia entries - New mission types with scripted events - Custom soldier stats and transformations
It CANNOT (via modding alone): - Make HTTP calls or open network sockets - Call external processes - Stream state in real time - Bridge to a Python runtime or LangGraph - Add custom UI panels beyond what the engine natively renders - Modify the save/load cycle behavior - Add event hooks that trigger external actions
The save/load cycle is baked into OXCE's C++ architecture. Bypassing it requires: 1. Modifying OXCE C++ source code (~300K LOC) 2. Adding an HTTP client or socket layer to the game loop 3. Hooking into specific game events (end of turn, base screen open, research complete) 4. Serializing game state to send to LangGraph 5. Deserializing LangGraph responses back into game state 6. Cross-compiling for aarch64 (ARM) 7. Maintaining a fork of OXCE with these modifications
This is C++ engine development, not modding. It would take longer than building the clean version and produce a fragile fork of a moving upstream.
What OXCE Proved (Validated)
The Akashic Abyss prototype validated that: 1. XCOM/TFTD metaphors map naturally to agent management (ARMOR = mode, WEAPON = role, EQUIPMENT = tools) 2. A game surface on a handheld device works as an agent control interface 3. Wave structure (OVERWATCH/POINT/BODY/ANCHOR) maps to agent deployment phases 4. Research/archive systems map to intel harvesting and knowledge depots 5. The save file as state persistence is the primitive version of what LangGraph checkpointer provides
These are concept validations, not code validations. They inform the clean path design; they don't argue for extending OXCE.
Observed: What OXCE Gives That's Hard to Replicate
| OXCE Feature | Clean Path Equivalent | Difficulty to Replicate |
|---|---|---|
| Tactical UI (inventory grid, stat screen) | Wargame GUI system + custom panels | Medium (~200-300 lines pygame) |
| Base management (facility placement) | Wargame scene system + tile placement | Medium |
| Research tree progression | LangGraph conditional edges + state flags | Trivial (already in architecture) |
| UFO interception / combat | Not needed for agent management surface | N/A |
| Geoscape globe | Not needed — 2D hex/tile grid | N/A |
| Soldier stats + progression | Unit state entries (roles, configs, history) | Already in the model |
None of the features that make OXCE a good XCOM game are needed for an agent management surface. The features that map to agent management (research tree, archive system, base management, soldier stats) are easier to build cleanly than to extract from OXCE.
Recommendation
Continue the clean path. The OXCE prototype was an essential concept validator but is the wrong engine for the next iteration. The save/load cycle is a fundamental architectural constraint of OXCE, not fixable through modding. Building a pygame rendering layer (on Wargame Engine's foundation) with LangGraph as the state authority is the correct long-term architecture.
OXCE remains valuable as: - A concept reference (mission reports, swarm maps, wave structure design) - A design language reference (XCOM UI patterns, color palette, information hierarchy) - A working example of the TFTD metaphor in practice - Save files + screenshots for reference during clean-path development