Monarch Case Study | Porting a 300GB Unreal Engine PC Project to Android | NipsApp Game Studio
Case Study 014 Unreal Engine 5 Android Port 2026
Case Study / Mobile Port / Unreal Engine 5

How we hit 60 FPS on mid-range Android porting a 300GB Unreal PC project.

Monarch is a UE5 metaverse with hub worlds, portal zones, music gameplay, and multiplayer. Built for PC. Handed to us to ship on Android. This is what actually broke, what worked, and the numbers we hit on real devices.

Monarch Unreal Engine 5 metaverse running on a mid-range Android phone with hub world environment in heavy metal underground art style, NipsApp Game Studio mobile port case study
Project: Monarch Engine: UE 5 / Vulkan / Mobile Forward+
60fps
High-tier Android, locked
300gb
Source project size
<1.8gb
In-game RAM, all tiers
<15s
Hub load on mid-range
TL;DR

Monarch, ported to Android. Here's the short version.

NipsApp Game Studio took a 300GB Unreal Engine 5 PC project (Monarch, a music metaverse with hub worlds and portal zones) and shipped it on Android. Locked 60 FPS on high-tier devices. Locked 30 FPS on mid-range and minimum-tier hardware. Sub 1.8GB RAM across the whole device matrix. Most of the work was not "running it on mobile." It was rebuilding the parts of UE5 that don't exist on Android.

  • DLSS and FSR removed. Replaced with TAAU plus lower internal render resolution. TSR isn't ready on mobile yet.
  • Lumen and Nanite gone. Full lightmap rebake with art direction preserved. Standard LOD chains for meshes.
  • Deferred to Mobile Forward+. Around 40 post-process volumes rewritten zone by zone.
  • Materials rebuilt. Mobile shader instruction limits are hard. We used Material LODs and the Mobile Material framework on every hero asset.
  • Play Asset Delivery in three buckets: install-time, fast-follow, on-demand. Real flaky-network testing, not dev wifi.
  • Touch input rewritten from scratch with Enhanced Input. Multiplayer between PC and Android clients works in the same session.
  • Thermal-aware dynamic resolution scaling. 20 minute sustained-load tests every Friday. Not 5 minute bursts.

The 3D meshes were genuinely well done. Whoever set up the original asset pipeline on the PC project knew what they were doing: clean topology, sane LODs already in place, polycounts that weren't crazy. Saved us probably a month and a half. Everything else assumed a 4090.

01Plugins

DLSS and FSR don't exist on Android. Audit plugins on day zero.

The PC build had both. DLSS for Nvidia, FSR for AMD. Neither exists on mobile. Not "limited support." They literally do not exist on Android and the plugins won't cook.

We spent day one trying to just disable them, then realised the render pipeline had nodes wired through both. You have to actually rip them out. We replaced both with TAAU. Tried TSR first since it's the new approach but mobile support there isn't ready yet. We landed on lower internal resolution plus TAAU upscale, which gave the best perf-to-quality on mid-range.

If you're inheriting a PC project, audit the plugins on day zero. Don't be us.
02Lighting

Lumen and Nanite don't ship on mobile. Get art involved in week one.

Same deal as the upscalers. Neither works on Android. The original team built the lighting around Lumen because of course they did, why wouldn't you on PC. Rebaking the lighting was the single biggest art-side lift in the whole port.

We baked lightmaps for every static piece of hub geo. Capped dynamic shadow casters at one or two per view. Mobile GPUs absolutely will not do more. Distance-based shadow fading on everything else. Then leaned hard on emissive materials to keep the heavy-metal underground vibe alive.

Took maybe three weeks of art-engineer ping pong before it stopped looking flat. The lesson: engineers cannot bake lighting that preserves art direction. It can't be done. Get the art lead in from week one or you'll redo it.

For Nanite we just fell back to standard LOD chains. Source meshes were clean so regenerating LODs was mostly automatic. Materials on those meshes were the actual problem.

Side by side comparison of Unreal Engine Lumen lighting on PC versus baked lightmaps on Android mobile build of Monarch metaverse hub world
FIG 01 / Lighting rebake comparisonHub Zone 03
03Renderer

Deferred to Mobile Forward+ is project-wide. Don't half-commit.

The PC build was deferred. Mobile needs Mobile Forward or Forward+. This isn't a setting you flip. It's a project-wide config change that breaks things you forgot you were using. SSAO, SSR, SSGI, all your screen-space stuff. Either dies or becomes way too expensive. We rewrote post-process volumes per zone, around 40 of them across the project.

Forward+ on mobile in UE5 is actually fine if you commit to it. The trap is trying to keep half your deferred effects working alongside it, which is exactly what we did for a week before someone said okay we have to just do this properly. Free week of your life if you skip our mistake here.

04Materials

Materials. This is where the actual time went.

I cannot stress this enough.

Mobile shader cores have hard instruction limits. A "looks fine" PC material can run 200+ instructions because nothing matters on a 4090. On a Snapdragon 778G it's a slideshow. Not a slowdown. An actual slideshow.

Every hero material got rebuilt using UE's Mobile Material framework. Multi-layer materials, pixel-depth offsets, parallax, advanced translucency. Gone. Replaced. Material LODs got added everywhere (yes that's a real thing, no most people don't use them) so distant assets dropped to roughly 30-instruction versions.

The thing that actually saved us hours

Preview materials in ES3.1 and Vulkan shader preview modes inside UE before you cook. UE will happily let you ship a material that compiles on PC and then silently breaks on Android. Catching it in the editor is way faster than "okay why is the wall pink on this Pixel 6 specifically."

05Textures

Texture budgets that respect device tier, not PC defaults.

Original textures were sized for PC VRAM, which is to say, generously. We capped hero stuff at 2048, most other things at 1024. ASTC for the Vulkan path, ETC2 fallback for OpenGL ES 3.2.

Streaming pool budgets got set up to actually respect device tier instead of using PC defaults. Dungeon zones were the worst because environmental storytelling means tons of unique props. We replaced a bunch of unique meshes with instanced versions on shared atlased materials. Visual difference basically nothing. Draw calls dropped hard.

Monarch Android mobile port texture streaming and ASTC compression workflow with material LOD setup in Unreal Engine 5 editor
FIG 02 / Texture pipelineASTC / ETC2
06Delivery

The 300GB problem and how Play Asset Delivery solved it.

The project being 300GB on disk doesn't mean the APK is 300GB. Most of that is source files, intermediates, and plugin source. But the cooked Android content was still way past Google's 150MB base APK limit.

Play Asset Delivery handled it. We split into three buckets:

Install-time

Core hub, one starter zone, essential UI and audio. Ships with the install.

Fast-follow

Remaining hub zones, downloaded right after install completes.

On-demand

Individual portal zones, fetched the first time a player unlocks them.

This is more engineering than people expect. In-game download manager UI, retry logic, storage warnings, mobile-data warnings. Test it on actually flaky 4G, not on dev wifi, or you'll find out at launch what real users experience.

07Input

Touch input is a rewrite, not an adaptation.

Tab key, F key, keyboard mappings, none of that translates. We built it fresh with Enhanced Input System and touch mappings. Virtual joystick on the left thumb, camera on the right, action buttons sized to Android's 48dp accessibility minimum.

The emote system (air guitar, air drums, on-brand for a music metaverse) was actually the fun part. Radial emote wheel off a HUD button. We tested multiplayer sync between PC and Android clients in the same session and it worked first try, which never happens.

08Thermals

Thermal throttling is the silent killer. Test for 20 minutes, not 5.

You'll hit 60 FPS for 5 minutes on a Snapdragon 778G and think you've won. Then the device thermally throttles and your frame rate quietly tanks. If you're testing in 5-minute bursts, you are testing the wrong thing.

We added dynamic resolution scaling as a thermal fallback. When sustained-load profiling sees thermal events coming, the engine drops internal resolution before it drops frames. Players notice slightly softer image, not stutter. That tradeoff plays way better in user testing than the alternative.

20 minute sustained load tests on every device in the QA matrix, every Friday. If you're not doing this you don't know what your game does in the wild. You just know what it does for the first 5 minutes.
Android device thermal throttling test setup for Monarch Unreal Engine mobile port showing sustained load profiling on Snapdragon and Dimensity test phones at NipsApp Game Studio
FIG 03 / QA thermal rigFriday Sustained Load
09Numbers

What it actually runs at.

People always ask for the numbers. Here they are.

// Final performance targets, post-tuning
Minimum
SD 720G / Dimensity 900 / 4GB RAM
30 fps
Recommended
SD 778G / 870 / 6GB RAM
30 fps
High Tier
SD 8 Gen 1+ / Dimensity 9000+ / 8GB
60 fps

The 60 FPS on high tier is the headline number. Honestly the harder win was making the 30 FPS feel rock solid on the mid-range. Locked 30 with zero spikes feels better than an inconsistent 50. Anyone who's played a phone game that surges to 55 then drops to 28 every minute knows what I mean.

10Lessons

Things we wish someone had told us on day one.

Audit plugins on day one, not day three.We lost real time on DLSS and FSR before we figured out they had to come fully out of the render pipeline.
Don't try to bake lighting without art involved from week one.Engineers can rebake. They can't preserve art direction. Three weeks of ping-pong taught us that.
Build Play Asset Delivery in early.Retrofitting a download manager into a feature-complete project is genuinely miserable.
Thermal tests from week one, not just before launch.20 minutes minimum. The first 5 minutes is a lie.
Don't half-commit on Forward+.Just do the migration properly the first time. We wasted a week trying to keep deferred effects alive.
// What we do

NipsApp is an Unreal Engine mobile optimization company offering Unreal consulting and UE performance optimization services for studios shipping mobile games. We focus on Unreal Engine optimization services for PC-to-Android and PC-to-iOS ports, mobile-first lighting and material rebuilds, Forward+ migrations, Play Asset Delivery setup, and thermal-aware QA for sustained load.

// Next steps

Got an Unreal project that needs to ship on mobile?

If you're mid-port and stuck, or staring at a PC project wondering where to even start, we've done this. Forward+ migration, lighting rebakes, Play Asset Delivery, thermal tuning, the lot.

NipsApp Game Studio © 2026
Case Study 014 / Monarch / UE5 Android Port

ABOUT NIPSAPP

NipsApp Game Studios is a full-cycle game development company founded in 2010, based in Trivandrum, India. With expertise in Unity, Unreal Engine, VR, mobile, and blockchain game development, NipsApp serves startups and enterprises across 25+ countries.

🚀 3,000+ Projects Delivered 121 Verified Clutch Reviews 🌍 25+ Countries Served 🎮 Since 2010

SERVICES

GAME GRAPHICS DESIGN

VR/XR SIMULATION

TALENT OUTSOURCING

RESOURCES

WORK SAMPLES

CONTACT US

India Office:

Viddhya Bhavan, Panniyode Road, Vattappara, Trivandrum, Kerala, India

Email: [email protected]

Phone: +91 62384 72255

Apple Maps Icon View on Apple Maps Google Maps Icon View on Google Maps

UAE Office:

Office No: 102, Near Siemens Building, Masdar Free Zone, Masdar City, Abu Dhabi, UAE

COPYRIGHT © 2025 NipsApp Game Studios | Privacy Policy | Terms & Conditions | Refund Policy | Privacy Policy Product |
Facebook Twitter LinkedIn Instagram YouTube Clutch