rpgCore
Multi-genre game engine with ECS architecture and NEAT AI integration
The Problem
Build a flexible game engine capable of powering multiple game genres (space shooters, RPGs, tycoon games) with integrated AI learning systems. The challenge was bridging Python's scripting capabilities with Godot's visual rendering while maintaining clean separation of concerns.
My Approach
- → ECS (Entity-Component-System) architecture for decoupled game logic
- → Godot 4.x C# frontend for rendering and visual debugging
- → Python core engine with NEAT genetic algorithm for AI training
- → IPC communication between C# and Python via sockets
- → 100% unit test coverage for all core systems
Key Highlights
- 1,400+ lines of well-tested core engine code
- 31/31 tests passing (100% pass rate)
- Complete architecture documentation (DELIVERABLES.md, BUILD_PIPELINE.md)
- Multi-genre support: Space, RPG, Tycoon compatible
- NEAT AI integration showing neural network evolution visualization
How It Works
rpgCore represents my most ambitious technical project—a production-grade game engine built as a proof of concept for cross-language architecture at scale.
The Challenge
Most game engines are monolithic, written in a single language. I wanted to explore what happens when you intentionally separate concerns: high-level game scripting in Python, real-time rendering in C#/Godot, and AI training in a separate Python process.
Architecture Highlights
The system consists of three tightly coupled components:
Python Core Engine: Houses all game state, physics, AI logic, and ECS framework. Uses Pydantic for configuration, supports hot-reloading of game logic without restarting the Godot editor.
Godot Frontend: C# layer handles rendering, input, visual debugging. Communicates with Python core via socket IPC using Protocol Buffers for efficient serialization.
NEAT Integration: Neural networks evolve through genetic algorithm, learning to play games through environmental feedback. Visualization shows real-time network architecture changes.
Key Technical Decisions
Why ECS? Component-based architecture allows games to define behavior declaratively. New game types only need new component combinations—no code changes.
Why Godot? Open source, supports C# scripting, provides excellent visual debugging tools. HTML5 export possible for future web deployment.
Why Python for core? Rapid prototyping, mature ML libraries, excellent for non-performance-critical game logic (gameplay decisions, state management).
Why IPC instead of embedding? Decoupling Python and C# processes prevents one crash from taking down the whole system. Allows independent scaling and debugging.
Testing & Documentation
Every core system has unit tests. The BUILD_PIPELINE.md walks through the exact steps to compile Godot, launch Python workers, and run integrated tests. This level of documentation is rare in game development but critical for maintainability.
Lessons Learned
This project taught me that architectural clarity often matters more than raw performance for game prototyping. The overhead of socket communication between Python and C# is negligible compared to the benefits of clear separation of concerns. The 100% test pass rate gives me confidence to refactor aggressively without fear of regressions.