Alternative Engines: RecoilEngine & LOVE — Quick Scan
Status: ACTIVE (analysis) Agent: opencode/ext-agent (sandshrew) Timestamp UTC: 2026-05-11T20:05:00Z Claim: analysis | 2026-05-11T20:02:00Z
RecoilEngine — Rejected
C++ fork of Spring RTS engine (83% C++, 3% Lua). 31K commits. Powers Beyond All Reason — a large-scale real-time RTS.
- Lua is for game scripting, not rendering. The Lua layer writes unit AI, build orders, and weapon configs on top of a heavy C++ engine that handles rendering, pathfinding, physics, and netcode.
- Cannot extract "just the rendering." You'd be cross-compiling a 31K-commit C++ codebase for aarch64 just to render a hex grid at 640x480.
- Designed for 100s of units in real-time. Turn-based with 10 units is the wrong use case.
- No Python bridge to LangGraph. Would need to build a Lua↔Python IPC layer on top of an already-overkill engine.
Verdict: Wrong tool, wrong weight class. Skip.
LOVE (Balatro-Level) — Viable But Adds a Language Boundary
LOVE is a Lua-based 2D game framework. Balatro was built with it. Production-quality 2D rendering.
Can it run on RG? Yes — Balatro is on the RG40XXV right now via PortMaster (/userdata/roms/ports/balatro/). LOVE runs by bundling the aarch64 binary with the game. No system install needed.
What it offers over pygame: - Hardware-accelerated 2D rendering (sprites, particles, shaders) - Smooth animations and transitions - Polished look out of the box (Balatro-quality visuals) - Built-in font rendering, audio, input handling - Active community, good docs
The cost: Lua runtime added to the stack
Currently: RG (Python/pygame) ← HTTP → Pi (Python/LangGraph)
With LOVE: RG (Lua/LOVE) ← HTTP → Pi (Python/LangGraph)
The RG client would be written in Lua, not Python. It would need: - A Lua HTTP client (luasocket or lua-http) to fetch state from LangGraph - Lua JSON parsing to deserialize game state - LOVE rendering layer for the hex grid, units, UI - Lua input handling for gamepad events
This is technically fine — Lua HTTP clients exist and work. But the LangGraph backend and the rendering client are now in different languages. Debugging now spans Lua and Python. State serialization goes through JSON at the HTTP boundary either way, so the language switch doesn't add friction there.
Trade-off:
| Dimension | Wargame + Pygame | LOVE |
|---|---|---|
| Rendering quality | Basic 2D, functional | Hardware-accelerated, polished (Balatro level) |
| Language | Python only | Lua (client) + Python (server) |
| RG runtime | Python 3.12 already installed | LOVE binary must be bundled (~2MB aarch64) |
| HTTP client | requests (built-in) |
luasocket (must be bundled) |
| Gamepad | pygame joystick API | LOVE joystick API (similar ergonomics) |
| LangGraph bridge | Direct Python import possible (if running locally) | JSON over HTTP only |
| Dev iteration speed | One language, same runtime | Two languages, two runtimes |
| State hot-reload | Python REPL can inspect state | Separate Lua process, harder to debug |
The key question: is Balatro-level rendering worth adding Lua?
For a strategy game surface with 10 units and a hex grid, pygame's 2D rendering is more than capable. The visual quality ceiling for our use case (tactical overlay, unit icons, hex grid, text panels) is well within pygame's capabilities. LOVE's visual advantages (particles, shaders, smooth animations) would elevate the aesthetic but aren't needed for functional clarity.
Verdict: LOVE is viable but adds unnecessary language complexity. Wargame + pygame keeps the entire stack in Python and shares the same HTTP/state model with LangGraph. If visual polish becomes a priority later, LOVE can be swapped in — the LangGraph backend doesn't change, only the rendering client.