Yaaro Ki Rasoi
Interaction Systems Built for Performance Stability
A kitchen simulation game designed around responsive interaction systems, scalable gameplay architecture, and stable performance across a wide range of mobile devices.
Yaaro Ki Rasoi focused on high-frequency player interactions like cooking, chopping, plating, and serving inside a dense interactive environment where responsiveness directly affected gameplay quality.
The challenge was not building the mechanics.
It was making those systems scale without performance collapse as the project grew.
Kitchen simulation games create a unique technical problem.
Individually, systems like chopping, cooking, plating, UI prompts, and interaction feedback are simple to prototype. But when all of them run together inside a dense environment, performance and maintainability become the real challenge.
Frequent interactions, heavy UI feedback, FX usage, and multiple simultaneous gameplay states can quickly create hidden CPU and GPU cost, especially on mobile devices.
The goal was to build interaction systems that remained responsive under production load, while avoiding the common trap of solving performance problems too late.
Optimization had to be part of the architecture, not post-production cleanup.
I owned the design and implementation of gameplay interaction systems, mobile performance strategy, and production-focused architecture decisions across Unreal Engine C++ and Blueprints.
The focus was not just feature delivery, but ensuring those systems could scale safely without constant refactoring.
The real problem was system density.
As more interactable objects, UI prompts, effects, and gameplay loops were added, performance degradation became increasingly visible, especially on lower-end mobile devices.
Three major bottlenecks emerged:
- ›Heavy world-space UI usage
- ›Excessive Tick-based logic
- ›High-cost Niagara FX
Each problem looked separate, but the root cause was the same: Systems that worked individually were too expensive when combined.
“How do we preserve responsiveness and clarity without allowing performance cost to scale with every new mechanic?”
That question shaped every technical decision.
World-Space Widget Optimization
Early versions relied heavily on world-space widgets for interaction prompts, progress indicators, and gameplay feedback.
As interactable objects increased, so did rendering overhead.
- ›GPU cost from excessive UI rendering
- ›Frame drops during interaction-heavy moments
- ›Performance inconsistency across device tiers
Instead of removing feedback entirely, I restructured where and how UI was rendered.
- ›Minimizing active world-space widgets at runtime
- ›Moving frequently visible UI to screen-space HUD systems
- ›Widget pooling for reuse instead of repeated creation/destruction
- ›Updating UI only when gameplay state changed
This significantly reduced rendering overhead while preserving gameplay clarity.
Replacing Tick-Driven Logic with Event-Driven Systems
As gameplay systems expanded, many features relied heavily on Tick() in both C++ and Blueprints.
- ›High CPU usage
- ›Inefficient polling-based updates
- ›Hidden runtime cost during complex gameplay states
I performed a full audit of Tick usage and replaced it wherever continuous updates were unnecessary.
- ›Removing unnecessary Tick functions
- ›Replacing polling with timers for periodic logic
- ›Moving logic to event-driven execution
- ›Reserving Tick only for frame-critical updates
This reduced CPU load while keeping gameplay responsive and easier to maintain.
Niagara FX Optimization Through Practical Trade-Offs
Niagara added strong visual polish, but on mobile devices it created significant performance instability.
- ›FX-heavy moments caused major frame drops
- ›Visual consistency varied between devices
- ›Lower-end devices struggled to maintain responsiveness
Instead of forcing Niagara across the entire project, I made selective trade-offs.
- ›Replacing many Niagara effects with flipbook-based sprite animations
- ›Using pre-baked effects for frequent gameplay interactions
- ›Reserving Niagara only where it delivered clear gameplay value
This improved device coverage significantly without sacrificing gameplay readability.
Centralized Interaction Architecture
Interaction systems were redesigned to avoid expensive per-object logic and duplicated execution paths.
- ›Centralized interaction handling instead of isolated per-object systems
- ›Event-based interaction checks instead of continuous polling
- ›Clear separation between interaction detection and interaction execution
This reduced duplication, simplified debugging, and made new kitchen mechanics significantly easier to extend safely.
The final architecture delivered both stable performance and stronger production scalability.
The result was not just better optimization, but safer long-term production support.
If development continued further, the next major focus would be:
- ›Adaptive quality settings based on real-time device profiling
- ›Deeper FX scalability systems across device tiers
- ›Analytics-driven performance tuning for live optimization
- ›Stronger tooling for performance validation during content expansion
The important part is that the current architecture supports these improvements without requiring major rewrites.
That is what production-ready architecture should do.
Performance problems are rarely visual problems first.
They are usually architectural problems that become visible through performance.
World-space UI, Tick-heavy logic, and expensive FX were not isolated bugs. They were symptoms of systems scaling without enough structural control.
Yaaro Ki Rasoi reinforced a principle that applies across both Unity and Unreal projects:
If the system feels slow, unstable, or inconsistent, players experience it as bad gameplay, not bad optimization.
Good engineering protects both performance and player trust.