Wargame Engine — RG40XXV Deployment Feasibility

Status: ACTIVE (confirmed viable) Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-11T20:00:00Z Claim: analysis | 2026-05-11T19:55:00Z Session: Deployment verification — can Wargame Engine run on RG40XXV?

Prior Context

• [[langgraph-engine-evaluation]] — Wargame Engine recommended as rendering layer
• [[langgraph-game-surface]] — Game backend architecture
• RG40XXV running KNULLI, Tailscale IP 100.119.202.114

Runtime Confirmed (Live Verification)

Deployment Path

Option A: Direct SSH (Development)

# Install Wargame Engine
pip3 install git+https://github.com/maximinus/wargame.git

# Copy game code
scp -r langgraph-game-surface/ root@RG:/userdata/game-surface/

# Launch script
cat > /userdata/roms/ports/Game-Surface.sh << 'EOF'
#!/bin/bash
cd /userdata/game-surface
python3 main.py
EOF
chmod +x /userdata/roms/ports/Game-Surface.sh

Option B: PortMaster (Distribution)

Standard PortMaster structure:

game-surface/
├── port.json          # metadata (title, desc, screenshot, genres)
├── Game-Surface.sh    # launcher (PortMaster-compatible)
├── screenshot.jpg     # boxart in EmulationStation
├── wargame/           # bundled engine (or pip install in launcher)
└── src/               # our game code

Launcher template (adapted from OpenXcomEX.sh pattern):

#!/bin/bash
XDG_DATA_HOME=${XDG_DATA_HOME:-$HOME/.local/share}
# PortMaster controlfolder detection (standard boilerplate)
if [ -d "/opt/system/Tools/PortMaster/" ]; then
  controlfolder="/opt/system/Tools/PortMaster"
elif [ -d "/opt/tools/PortMaster/" ]; then
  controlfolder="/opt/tools/PortMaster"
elif [ -d "$XDG_DATA_HOME/PortMaster/" ]; then
  controlfolder="$XDG_DATA_HOME/PortMaster"
else
  controlfolder="/roms/ports/PortMaster"
fi
source $controlfolder/control.txt
source $controlfolder/device_info.txt

GAMEDIR="/$directory/ports/game-surface"
cd "$GAMEDIR"

# Install dependencies if needed
pip3 install -q git+https://github.com/maximinus/wargame.git 2>/dev/null || true

# Launch (pygame handles gamepad natively — no gptokeyb needed)
python3 main.py

Why PortMaster Is Optional

PortMaster provides: - Standardized launcher with EmulationStation integration - Boxart, video preview, metadata - Auto-update mechanism - Dependency management

For development, none of this is needed. Direct SSH deploy + shell script is faster. PortMaster wrapping is a distribution concern, not a development blocker.

Why gptokeyb Is Likely Unnecessary

OpenXcomEX needs gptokeyb because OXCE is a C++ SDL1.2 app that only understands keyboard input. The gamepad buttons must be remapped to keyboard keys.

Wargame Engine + our code uses pygame's native gamepad API (pygame.joystick). The RG's controller shows up as a standard SDL2 joystick. All buttons, D-pad, and analog sticks are directly readable via pygame.JOYBUTTONDOWN, pygame.JOYHATMOTION, etc. No keyboard remapping needed.

Exception: if we want START+SELECT hotkey combinations (standard KNULLI pattern), gptokeyb can be layered on top. But for MVP, direct gamepad input in pygame is simpler.

Resource Budget

The RG is the rendering client. LangGraph runs on the Pi. The RG only needs: Python + pygame + Wargame + our thin client (~100KB code + HTTP calls to Pi).

Verified: The Display Resolution Question

pygame.display.list_modes() returned exactly [(640, 480)]. The RG's screen is 640x480 and pygame can render to it natively. No scaling or resolution adaptation needed. This matches the XCOM Deploy prototype's config (SCREEN_WIDTH=640, SCREEN_HEIGHT=480).

Open Questions

• Does Wargame Engine's pip install work on aarch64 without compilation? (Pure Python — should be fine)
• Does Wargame Engine's controller.run() loop play nicely with HTTP calls to LangGraph? (Main concern from [[langgraph-engine-evaluation]])
• Should the RG client run a local LangGraph node (for low-latency rendering state) or just be a dumb HTTP renderer?