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
Aseprite
Every sprite hand-drawn
2023 –
Ongoing personal project
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 at once, so every system had to work at two scales: the micro-level of pipe flow and crafting recipes, and the macro-level of a hundred thousand units moving in formation.
Godot 4 had no built-in ECS, and the only third-party option wasn't compatible, so I built one from scratch.
100,000+ Thralls organizing into formations in real time.
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.
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.
Godot's node-based architecture wasn't designed for 100,000+ concurrent entities, so I built the ECSS from scratch.
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, and every asset includes normal and emissive maps so the day-night cycle's dynamic lighting casts real shadows and reflections across the world.
Pixel Art & Normal Maps
Hand-designed sprites with normal and emissive maps for dynamic lighting, all drawn in Aseprite.
Visual Shaders
Rain particle systems and underwater entry effects that add atmospheric depth.
Day-Night Cycle
Dynamic normal-based lighting that casts shadows and reflections adapting to time of day.
Lorenomicon
An interactive in-game book that holds the world's lore and backstory.
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 until one design defined both the character and the color language for the whole 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.
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.
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