Performance
Choose representative devices and a realistic test route
Optimization starts with a repeatable question. Select devices that reflect the audience you want to support, including a modest phone rather than only a powerful development machine. Define a route through onboarding, ordinary play, a busy area, and the shop. Record the game version and relevant settings so later comparisons mean something. Studio's device emulator is useful for screen layout and controls, but it is not a substitute for measuring real-device memory and performance. Note crashes, long loading pauses, and unclear interactions separately. A single average frame rate can hide the particular moment that makes a new player leave before they understand the game. Keep the same test account, route, and content version when comparing two optimization attempts so unrelated changes do not obscure the result.
Make touch targets readable and predictable
Place important actions where fingers can reach them without covering critical information. Use sufficiently large buttons with spacing that prevents accidental neighboring presses. Do not make an icon's meaning depend entirely on a tooltip available only through a mouse hover. Show the action name when the symbol is unfamiliar. Test the interface in portrait-like narrow layouts and supported landscape ratios, accounting for safe areas and system controls. Keep purchase buttons separate from jump, respawn, and close controls. If a player repeatedly buys or opens a prompt while trying to move, the problem is not a lack of attention; the interface needs a clearer distinction between navigation, gameplay, and commerce.
Use input-aware controls instead of a desktop assumption
Support the platform's appropriate input mechanisms and test interactions with actual touch. A pointer click handler alone may not describe a console or mobile interaction as well as a suitable cross-input activation event. Avoid requiring a keyboard key without an equivalent touch control. Explain an action when it first becomes relevant rather than displaying a wall of control instructions before play. Keep the game usable when the on-screen keyboard appears for a text field. If a menu pauses local input, restore it correctly when the menu closes. Those details can matter more to retention than adding another decorative panel to the shop.
Measure geometry, textures, lighting, and script work separately
Investigate the component that actually causes the slowdown. Excessive scene detail, heavy transparency, costly lighting, large textures, physics activity, and repeated script work create different bottlenecks. Use the available profiling tools and compare a typical area with a worst-case gathering. Reduce unnecessary work before lowering every visual setting indiscriminately. Reuse appropriate assets and avoid creating duplicate content identifiers without a reason. Test simplified effects at real viewing distances; a detail that is invisible on a phone may still cost resources. Preserve a baseline scene or capture so a performance change can be evaluated for visual quality as well as speed.
Reduce work that continues when nobody benefits from it
Look for loops and effects that keep running outside the player's relevant area or after an interface closes. A background preview, temporary particle system, or repeated scene search may be inexpensive once but costly when several systems do it constantly. Give temporary objects and event listeners explicit owners and cleanup paths. Prefer event-driven updates where that matches the feature instead of repeatedly scanning every object. Do not assume that wrapping work in a coroutine makes it cheap; an expensive step can still block before a yield. Profile after a long session as well as immediately after spawning, because leaked resources often appear only after repeated use.
Make commerce load reliably without dominating the session
The shop should remain readable and dismissible under slower conditions. Load information in a way that does not block essential movement or force players to stare at an empty purchase panel. Display the actual supported price information and a clear loading or unavailable state when it cannot be retrieved. A retry should not create duplicate prompts. Test cancellation, returning from a purchase flow, and resuming play on a device with limited resources. Revenue improvement is a hypothesis, not a guaranteed outcome of a faster frame rate. Track whether people complete the first activity, return voluntarily, and encounter fewer errors before attributing a change in spending to one optimization.
Run a release review with experience metrics
After implementing a small group of improvements, repeat the same device route and compare the results with the baseline. Inspect memory pressure, frame consistency, loading behavior, and touch usability alongside player retention. Note content or discovery changes that could affect the audience during the comparison. Ask a new tester to finish the opening task and locate the shop without instructions. Keep a list of supported constraints so future art and scripting work does not reintroduce the original bottleneck. A mobile-friendly game is an ongoing production choice, not a one-time low-quality mode. The best outcome is an experience that remains understandable and responsive when ordinary players use ordinary devices for an entire session.
Official references and current requirements
Policy details were checked on October 31, 2026. Fees, eligibility, and program rules can change; check the official requirements before publishing or requesting a payout.