Case Study
An RTS engine for
100,000 concurrent units.
A fantasy factory game that fuses factory management with real-time strategy, built on a custom Entity-Component-Space system designed to handle massive unit counts without sacrificing frame rate or gameplay depth.
100K+
Concurrent units
ECSS
Custom architecture
100s
Sprite iterations
12+
Interconnected systems
The Game
Phylactory is set in a vibrant fantasy world where players build sprawling factories while commanding armies of units called Thralls. It's a factory sim and an RTS running simultaneously, which meant every system had to work at two scales simultaneously: the micro-level of pipe flow and crafting recipes, and the macro-level of hundreds of thousands of units moving in formation.
The scope demanded an architecture that could handle complexity without accumulating technical debt. Godot 4 had no built-in ECS, and the only third-party option wasn't compatible, so I built one from scratch.
Hundreds of thousands of Thralls organizing into formations in real time.
Every system had to work at two scales: pipe flow and crafting recipes, or hundreds of thousands of units in formation.
The Architecture
The Entity-Component-Space System (ECSS) extends the standard ECS pattern with Spaces, shared contexts that let systems communicate without coupling. The data-oriented design ensures cache-efficient memory access, and certain systems leverage GPU acceleration for rendering and physics at scale.
Entities
Individual game objects (units, buildings, factory elements) identified by unique IDs for streamlined management.
Components
Data-only attributes like position, velocity, and command handling, stored in cache-efficient ComponentStorage objects.
Spaces
Shared contexts that allow different systems to communicate and access common game state without tight coupling.
Systems
Game logic (movement, rendering, commands, selection) that operates on entities with specific component combinations.
Archetypes
Groups of entities with similar component signatures, enabling targeted batch processing and memory-efficient iteration.
Godot had no ECS. The only third-party one didn't support Godot 4.
With 100,000+ concurrent entities and complex component combinations, Godot's node-based architecture wasn't designed for this scale. So I built a custom ECSS from scratch: archetype-based storage, GPU-accelerated rendering, and shared Spaces for cross-system communication.
The Systems
Phylactory's gameplay emerges from a web of interconnected systems. Energy powers buildings that process resources moving through pipes, while trains carry materials between factory zones and Thralls organize into formations for combat, all running simultaneously on the ECSS.
Movement & Formations
Flocking, group movement, and configurable formations including huddles, lines, and checkerboard patterns with adjustable spacing and direction.
Pipes Network
Dynamic fluid flow calculations that update as pipes are placed, with realistic pressure and flow-rate logic throughout the factory.
Energy Network
A pump-powered energy distribution system (called "Wumbo") that supplies power to buildings, mirroring real-world grid distribution.
Train System
Track-based transportation with strategic stops, enabling logistics planning and resource movement across the factory.
Inventory & Grid Placement
Item management with categorization, stacking, and filtering, paired with a grid-based placement system for precise building positioning.
Skill Tree & Crafting
Progression through unlockable abilities and a crafting system for creating and upgrading items, tying into the factory pipeline.
The Wumbo energy network powering factory buildings.
The crafting system tied into the factory pipeline.
The Art
Every sprite, tileset, and visual effect was hand-crafted in Aseprite. The Wizard character alone went through hundreds of iterations, each pixel tuned to convey wisdom, mystery, and power. His familiar Tomey is a floating book with two eyes and a bookmark tail, but no mouth, limbs, or body. The challenge was giving it personality despite having almost nothing to animate. I leaned on squash-and-stretch and natural movement offsets (slight bobbing delays between the cover and pages) to make it feel alive and expressive with just eye direction and shape deformation.
Beyond character design, every asset includes normal and emissive maps so the day-night cycle's dynamic lighting casts real shadows and reflections across the entire world.
Pixel Art & Normal Maps
Hand-designed sprites with normal and emissive maps for dynamic lighting, all crafted in Aseprite across hundreds of iterations.
Visual Shaders
Rain particle systems and underwater entry effects that add atmospheric depth without compromising frame rate.
Day-Night Cycle
Dynamic normal-based lighting that casts shadows and reflections adapting to time of day, making the world feel alive.
Lorenomicon
An interactive lore book weaving backstory and world-building through a narrative interface that rewards exploration.
The Lorenomicon, an interactive lore book for world-building.
Character Design
I needed the Wizard to encapsulate the game's tone: magical, slightly enigmatic, and powerful without being generic. I started broad, exploring silhouettes and color palettes in Aseprite, then narrowed through hundreds of iterations until the final design emerged, one that not only defined the character but set the color language for the entire game.
Tomey is just a book with eyes, so every bit of personality comes from animation: squash-and-stretch on reactions, slight delays between the cover and pages during movement, and eye direction tracking the Wizard. Those small offsets make it feel like a living thing. The final pairing became the emotional anchor of the game's visual identity.
A selection from hundreds of Wizard iterations exploring silhouette, color, and personality.
The final Wizard and Tomey pairing, the emotional anchor of the game's visual identity.
The Wizard's color palette didn't just define a character. It set the visual language for the entire game.
What I Learned
I learned that the data layout determines the game you can make.
With object-oriented inheritance, adding a new system meant touching every entity class it interacted with. With the ECS, adding a new system meant writing a query over existing components. Features that would have taken days in the old architecture took hours. The 100,000-unit count was possible because of the data layout, not because of optimization tricks.
I learned to treat every art asset as a technical contract.
Each sprite needs a color layer, a normal map, and an emissive map that all align pixel-for-pixel. A single misaligned normal map breaks the lighting for that entire character under the day-night cycle. I stopped thinking of art and code as separate workflows and started treating every asset as a specification the rendering system depends on.
I learned that the best gameplay emerges from systems you didn't explicitly design.
When pipes, energy, trains, and combat all communicate through shared Spaces, players discover strategies I never planned for. That changed how I think about game systems design: instead of scripting every interaction, I focus on building clean interfaces between systems and letting the combinatorics do the work.
Built with