Yaaro Ki Rasoi – Project Case Study

Yaaro Ki Rasoi revolves around frequent player interactions like cooking, chopping, plating and serving all happening in a dense, interactive environment.

While the gameplay itself was straightforward to prototype, maintaining stable performance on mobile devices while preserving responsiveness and visual clarity became the real challenge as the project scaled.

• Lead Game Developer
• Gameplay Systems & Interaction Design
• Performance Optimization (UE5 Mobile & PC)
• C++ & Blueprint Architecture
• Technical Problem Solving

As development progressed, three major performance bottlenecks emerged:

1. Heavy use of world-space UI widgets
2. Excessive Tick-based logic in C++ and Blueprints
3. High-cost Niagara FX on lower-end devices

Each problem required a different approach but all shared the same root cause:
systems that worked in isolation didn’t scale well together.

The Problem

Early versions of the game relied heavily on world-space widgets to display contextual information—progress indicators, interaction prompts, and status feedback.
As more interactable objects appeared on screen, the number of world-space widgets increased rapidly, leading to:

• GPU overhead from UI rendering
• Frame rate drops during busy gameplay moments
• Inconsistent performance across devices

The Solution

Instead of removing UI feedback, I rethought how and where it was rendered:

• Minimized the number of world-space widgets active at any given time
• Converted frequently visible UI elements to screen-space widgets or centralized HUD components
• Implemented widget pooling to reuse UI elements instead of constantly creating and destroying them
• Reduced unnecessary widget updates by refreshing UI only when state changed

Result

This significantly reduced rendering overhead and stabilized frame rates during interaction-heavy gameplay.

The Problem

As gameplay systems grew, many behaviors relied on Tick()—both in C++ and Blueprints.
While convenient early on, this led to:

• High CPU usage
• Inefficient polling-based logic
• Performance degradation on mobile devices

The Solution

I performed a full audit of Tick usage and replaced it wherever possible:

• Removed unnecessary Tick functions
• Replaced continuous updates with timers for periodic logic
• Shifted logic to event-driven execution
• Ensured Tick was only used where frame-level updates were absolutely required

This approach reduced CPU load while keeping gameplay responsive.

The Problem

Niagara effects added visual polish but came with a significant cost especially on lower-end and mid-range mobile devices.

In stress scenarios:

• FX-heavy moments caused frame drops
• Visual consistency varied between devices

The Solution

Rather than forcing Niagara everywhere, I made a pragmatic trade-off:

• Replaced many Niagara FX with flipbook-based sprite animations
• Used simpler, pre-baked visual effects for common interactions
• Reserved Niagara only for cases where it delivered clear gameplay value

This ensured smoother gameplay across a wider range of devices without sacrificing clarity.

Beyond these core challenges, I also focused on:

• Centralized interaction handling instead of per-object logic
• Event-based interaction checks instead of polling
• Clean separation between interaction detection and execution

This reduced duplication and made the system easier to extend as new kitchen mechanics were added.

• Noticeably improved frame rates on mobile devices
• Reduced CPU and GPU load during peak gameplay
• More consistent performance across device tiers
• Cleaner gameplay logic with fewer hidden performance costs
• Systems that scaled without constant refactoring

If development continued further, the next focus areas would be:

• Adaptive quality settings based on device profiling
• Further FX scalability controls
• Deeper analytics-driven performance tuning

The current architecture supports these improvements without major rewrites.

• World-space UI must be used sparingly in simulation-heavy games
• Tick-based logic doesn’t scale. Event-driven systems do
• Visual fidelity should adapt to device capability
• Performance problems are often architectural, not cosmetic