EcoRun
Endless Runner Systems Built for Production Scale
A mobile endless runner designed around scalable gameplay systems, production-ready architecture, and stable performance across a wide range of Android devices.
Rather than treating optimization as a late-stage fix, EcoRun was built with performance and maintainability as foundational engineering decisions from day one.
EcoRun was built to support long-term feature expansion without the common technical debt that endless runners often accumulate.
Systems like power-ups, progression loops, collectibles, obstacle spawning, and player state management tend to become tightly coupled very quickly. Early prototypes may work, but scaling them safely becomes expensive.
The goal was to avoid that trap by building gameplay architecture that could survive production growth, not just prototype success.
At the same time, the game needed to maintain stable performance across a wide range of Android devices, making optimization a core architectural concern rather than a later polish step.
I owned the design and implementation of production-critical gameplay systems, with a focus on architecture stability, modularity, and mobile performance.
The focus was not just building features, but building systems that could safely scale.
The main challenge was maintaining flexibility while gameplay complexity kept increasing.
As power-ups, abilities, progression systems, and live content expansion grew, the risk of architectural decay became obvious. Without strong boundaries between gameplay systems, even small feature additions could create regressions inside core movement and player logic.
At the same time, mobile performance constraints meant optimization could not be reactive. It had to be built into the foundation.
“How do we build an endless runner?”
“How do we keep an endless runner stable when its mechanics keep growing?”
That question shaped every technical decision.
Static Player + Moving World Architecture
Instead of continuously moving the player forward through the world, I used a static player with a moving environment approach.
- ›Camera consistency
- ›Lane switching precision
- ›Obstacle spawning control
- ›Floating-point stability during long sessions
- ›Future maintainability of progression systems
What seems like a small movement decision became one of the most important architectural choices in the entire project.
It simplified future expansion significantly while improving gameplay consistency across devices.
Refactoring PlayerController Using SOLID
Rather than relying on a monolithic PlayerController, responsibilities were separated into focused systems:
- ›Input handling
- ›Movement and physics
- ›Player states
- ›Ability and power-up handling
Each system communicated through events and interfaces instead of direct dependencies.
This reduced feature integration risk, improved testing safety, and allowed mechanics to evolve independently without destabilizing core movement logic.
This was critical for long-term maintainability.
Power-Ups as Temporary Modifiers
Power-ups were designed as temporary behavior modifiers instead of logic controllers.
- ›Clean activation and deactivation
- ›Predictable stacking behavior
- ›No permanent state corruption
- ›Safe addition of new abilities without rewriting existing systems
This approach made long-term feature expansion significantly safer and reduced regression risk during iteration.
Performance-First Mobile Architecture
Because EcoRun targets mobile devices, performance decisions shaped system design from the beginning.
- ›Object pooling for obstacles and collectibles
- ›Minimal Update() dependency
- ›Event-driven gameplay flow
- ›Deterministic gameplay interactions
- ›Lightweight collision handling
Instead of optimizing late, the architecture itself supported stable runtime performance.
Lighting and Visual Optimization
To achieve polished visuals without sacrificing FPS, I avoided expensive real-time lighting dependencies.
- ›Baked lighting for static environments
- ›Light probes for dynamic objects
- ›Fake blob shadows instead of real-time shadows
This delivered stronger visual quality while maintaining stable performance on mid-range Android devices.
The final architecture delivered both gameplay stability and production flexibility.
The result was not just a functional endless runner, but a gameplay foundation that could continue growing without repeated architectural rewrites.
If EcoRun were extended further, the next major focus would be:
- ›Deeper data-driven progression balancing
- ›Live Ops tooling for faster tuning updates
- ›Analytics-driven gameplay decision making
- ›More scalable backend-ready progression systems
The important part is that the current architecture supports these improvements without requiring major refactors.
That is the real success of the system.
Simple games often create the most dangerous technical debt because they look easy early.
Endless runners are a good example of this.
Without strong architectural decisions, small gameplay additions quickly turn into fragile systems that are difficult to maintain and expensive to expand.
EcoRun reinforced a principle I apply across all production work:
Building for scalability early reduces both bugs and long-term development stress far more than late optimization ever can.