Mobile Screen Resolution, Aspect Ratios, and Safe Areas

1) Resolution vs. Physical Size vs. Density (What Actually Changes Across Devices)

Mobile devices vary in three related but distinct ways: pixel resolution (how many pixels), physical size (inches), and pixel density (pixels per inch, PPI). Confusing these leads to UI that looks tiny on high-density phones or huge on low-density tablets.

Key terms you must separate

• Resolution (px): The framebuffer size, e.g., 2532×1170. This affects how many pixels you can draw, and how expensive rendering can be.
• Physical size (in): The real-world diagonal size. A 6.1" phone and a 7" tablet can share similar resolutions but feel very different in hand.
• Density (PPI): How tightly pixels are packed. Higher PPI means the same pixel-sized UI appears physically smaller.
• DP/SP (density-independent units): A logical unit that scales with density. Use these for UI sizing rules rather than raw pixels.

Practical rule: treat gameplay and UI differently

• Gameplay should be driven by a world unit system (meters/units/tiles), not pixels.
• UI should be driven by logical units (dp/sp) and constraints (anchors, margins), not absolute pixel coordinates.

Step-by-step: define your project’s “reference” sizes

1. Pick a reference UI width (common choice: 360dp logical width for phones). You will scale UI elements relative to this, not to pixels.
2. Pick minimum readable text sizes in logical units (e.g., 12–14sp for secondary labels, 16–18sp for primary UI, depending on style).
3. Pick a reference gameplay camera framing (e.g., “show 10 world units vertically” for portrait or “show 12 units horizontally” for landscape). This becomes your baseline for aspect-ratio handling.
4. Set a performance-aware render scale policy: allow internal resolution scaling (e.g., 0.75×) on weaker devices while keeping UI crisp (render UI at native or separate pass if your engine supports it).

Common pitfall checklist

• Do not size buttons in pixels (e.g., 64px) and assume they are finger-friendly; density changes physical size.
• Do not assume “1080p” means “same size UI”; 1080×2400 on a 6.7" phone differs from 1080×1920 on a 5" device.
• Do not tie physics step or movement speed to frame resolution; keep gameplay time-based.

2) Aspect-Ratio Strategy: Extend View, Crop, Letterbox, Adaptive Layout

Aspect ratio differences (e.g., 16:9, 19.5:9, 4:3) change how much of the world is visible and where UI lands. You need an explicit strategy per game mode (gameplay camera) and per screen (UI layout).

When to use “extend view”

• Your gameplay is not harmed by extra visibility (e.g., endless runner lanes already bounded, or fog-of-war limits information).
• You can guarantee that additional world shown does not expose unintended areas (spawn points, out-of-bounds, puzzle solutions).

When to use “crop”

• Fairness depends on consistent visibility (e.g., arena shooters, competitive platformers).
• You rely on tight composition (boss tells, hazards) and want them to occupy consistent screen space.

When to use letterboxing

• You must preserve a specific composition (e.g., pre-rendered backgrounds, fixed camera cutscenes).
• You can accept reduced usable area and ensure UI stays within the active viewport.

Adaptive layout: the default for UI

Even if gameplay uses crop or letterbox, UI should adapt. Use anchors, constraints, and safe-area insets to place HUD elements relative to corners/edges, not absolute coordinates.

Step-by-step: choose a gameplay aspect policy

1. Define your “design aspect” (e.g., 16:9 landscape or 9:16 portrait) and document it.
2. Decide fairness requirements: if extra visibility changes difficulty or PvP advantage, avoid extend view.
3. Pick one primary policy per gameplay mode: extend or crop. Reserve letterbox for special cases.
4. Define clamps for extreme ratios (e.g., treat anything wider than 20:9 as 20:9 for camera calculations) to avoid excessive zoom-out/zoom-in.
5. Validate UI separately with adaptive layout and safe areas (next sections).

3) Safe Areas: Notches, Rounded Corners, System Gestures

Modern phones can have camera cutouts, rounded corners, and system gesture areas. “Safe area” is the region where critical UI should live to avoid being obscured or hard to interact with.

What can break your UI

• Notches/cutouts can overlap top HUD (health, currency, pause).
• Rounded corners can clip corner icons that sit too close to the edge.
• Gesture navigation areas (bottom/home indicator, side back gestures) can conflict with buttons placed at the very bottom/edges.
• Status bars and navigation bars can appear/disappear or change size.

Two zones to define: “Critical” vs. “Peripheral”

• Critical UI zone: must always be visible and tappable (health, primary actions, pause, confirm/cancel).
• Peripheral UI zone: can be closer to edges or partially occluded without breaking play (decorative frames, background panels, non-essential labels).

Step-by-step: reserve safe space for HUD

1. Query safe-area insets from the OS/engine (top, bottom, left, right).
2. Create a “SafeAreaRoot” container that applies padding equal to these insets.
3. Anchor critical HUD to SafeAreaRoot (not to the full screen). Example: top-left health panel anchored to SafeAreaRoot’s top-left with an additional margin.
4. Add extra “gesture padding” beyond safe-area if needed (commonly bottom padding) so buttons are not adjacent to gesture zones.
5. Test in both orientations if your game supports rotation; insets can swap and change.

Implementation sketch (engine-agnostic pseudocode)

// Called on startup and whenever orientation/UI insets change
insets = GetSafeAreaInsets()  // {left, right, top, bottom} in pixels or logical units
SafeAreaRoot.paddingLeft   = insets.left
SafeAreaRoot.paddingRight  = insets.right
SafeAreaRoot.paddingTop    = insets.top
SafeAreaRoot.paddingBottom = insets.bottom + GestureExtraBottom

// Example: place pause button
PauseButton.anchor = TOP_RIGHT of SafeAreaRoot
PauseButton.margin = {x: 12dp, y: 12dp}

Design guidance for safe areas

• Keep tap targets away from screen edges even if they are “safe”; edges are harder to hit and can conflict with gestures.
• For top HUD, avoid placing important text directly under the status bar region; treat it as volatile.
• If you use full-bleed backgrounds, allow them to extend behind notches; only constrain interactive/critical elements.

4) Camera Framing and World Scaling Rules (2D and 3D)

Camera strategy determines how much gameplay space is visible and how consistent the experience feels across devices. The goal is to keep gameplay-relevant visibility consistent (or intentionally variable) while maintaining stable controls and readable UI.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

2D: orthographic camera rules

In 2D, you typically use an orthographic camera. The key choice is whether to keep vertical size constant or horizontal size constant.

• Constant vertical world units (recommended for portrait games): keep the same vertical gameplay space visible; wider screens show more horizontally (extend view) or you crop horizontally depending on policy.
• Constant horizontal world units (common for landscape platformers): keep the same horizontal run-up/jump distances visible; taller screens show more vertically.

Step-by-step: constant-vertical framing (2D)

1. Pick a design vertical size in world units, e.g., designOrthoSize = 5.0 (half-height in many engines).
2. Compute current aspect ratio a = screenWidth / screenHeight.
3. For extend view: keep orthoSize = designOrthoSize; accept that horizontal visible units change with a.
4. For crop: adjust orthoSize so that horizontal visible units match the design aspect (effectively zooming in/out to maintain constant width).

// Crop to maintain constant horizontal width (2D)
designAspect = 16/9
currentAspect = screenW / screenH

// Keep width constant: orthoSize scales with aspect ratio
orthoSize = designOrthoSize * (designAspect / currentAspect)
orthoSize = Clamp(orthoSize, minOrtho, maxOrtho)

2D world scaling: avoid “pixel-perfect” assumptions unless you commit fully

• If you use pixel art, decide whether you will enforce integer scaling (may require letterboxing) or allow filtering and accept minor shimmering.
• Keep collision and movement in world units; rendering scale should not change physics.

3D: perspective camera rules

In 3D, the main levers are field of view (FOV) and camera distance. Aspect ratio affects horizontal vs. vertical FOV depending on how your engine defines it.

• Constant vertical FOV (common): wider screens show more horizontally (extend view). This is often acceptable for non-competitive play.
• Constant horizontal FOV: taller screens show more vertically; useful if lateral visibility must be consistent.
• Dynamic camera distance: keep FOV stable but move camera to maintain consistent framing of a target area.

Step-by-step: clamp visibility for fairness (3D)

1. Choose whether your game’s fairness depends on consistent visibility. If yes, avoid unlimited extend view.
2. Define min/max aspect ratios you will support without changing gameplay visibility too much (e.g., 4:3 to 20:9).
3. Clamp the effective aspect used for camera calculations to that range.
4. If needed, add subtle environment “padding” (walls, fog, occluders) so extra visibility does not reveal unintended information.

// Clamp aspect ratio used for camera projection (3D)
currentAspect = screenW / screenH
effectiveAspect = Clamp(currentAspect, 4/3, 20/9)
SetCameraAspect(effectiveAspect)

UI-to-world alignment (both 2D and 3D)

• For markers, nameplates, and off-screen indicators, always convert world positions to screen positions after camera adjustments and safe-area padding.
• If you place UI near edges (e.g., off-screen arrows), compute against the safe-area rect, not the full screen rect.

5) Test Scenarios with Acceptance Criteria

Testing must cover both layout correctness (no clipping, safe areas respected) and gameplay consistency (visibility and difficulty not unintentionally altered). Use a device matrix plus emulator/simulator configurations.

Recommended device/aspect coverage

• Very tall phone (e.g., ~20:9)
• Standard phone (16:9 or 19.5:9)
• Tablet (4:3)
• Small phone (lower physical size, high density)
• Notch/cutout device (varied inset shapes)
• Gesture navigation enabled vs. disabled (where applicable)

Scenario A: Main HUD on extreme aspect ratios

• Setup: Load a gameplay scene with full HUD (health, ammo/energy, pause, minimap, notifications).
• Acceptance criteria:
  • No HUD element is clipped by screen edges, rounded corners, or cutouts.
  • All critical HUD elements remain inside the safe-area rect with at least a defined margin (e.g., 8–16dp).
  • HUD does not overlap critical gameplay view more than intended (e.g., minimap panel does not cover player path).

Scenario B: Text readability at minimum size

• Setup: Open screens with dense text (settings, inventory, shop, tutorial popups).
• Acceptance criteria:
  • Primary text is readable on the smallest supported physical device at normal viewing distance.
  • No text truncation occurs for longest localized strings you support (test with a “long string” locale or pseudo-localization).
  • Line height and padding prevent glyph clipping (no cut descenders/accents).

Scenario C: Tap target safety near edges and gesture zones

• Setup: Place the device in gesture navigation mode; test bottom and side UI (confirm buttons, action bar, back button).
• Acceptance criteria:
  • Critical buttons are not within the gesture-conflict band (your defined extra padding beyond safe-area).
  • Repeated taps near edges do not trigger OS gestures more than an acceptable threshold (define internally, e.g., “<1 accidental gesture per 30 taps” during QA run).
  • Tap targets meet your minimum size in logical units (e.g., at least 44–48dp square equivalent).

Scenario D: Gameplay visibility consistency

• Setup: Use a fixed seed or deterministic level segment. Capture screenshots on multiple aspect ratios at the same gameplay timestamp.
• Acceptance criteria:
  • If using crop or letterbox: the visible gameplay region matches the design framing within a small tolerance (e.g., same hazards visible at the same time).
  • If using extend view: extra visibility does not reveal out-of-bounds areas, spawn points, puzzle solutions, or competitive advantage.
  • Player character scale on screen remains within a defined range (e.g., 90–110% of design reference height in pixels or screen percentage).

Scenario E: Camera + UI alignment (world markers)

• Setup: Enable nameplates, quest markers, damage numbers, off-screen arrows.
• Acceptance criteria:
  • Markers do not render under notches/cutouts; they clamp to the safe-area rect.
  • Off-screen indicators point correctly and do not jitter when rotating or resizing.
  • Markers remain legible and do not overlap excessively on narrow screens (apply stacking or prioritization rules).

Scenario F: Orientation change (if supported)

• Setup: Rotate device during gameplay and in menus.
• Acceptance criteria:
  • No one-frame “jump” that leaves UI in unsafe regions; safe-area recalculates immediately.
  • Camera reframes according to the selected policy (extend/crop/letterbox) without breaking gameplay state.
  • UI layout reflows correctly (no overlapping panels, no off-screen buttons).

Scenario G: Performance-aware resolution scaling (visual stability)

• Setup: Enable your dynamic resolution or render scale options; test at min and max scale.
• Acceptance criteria:
  • UI remains crisp and correctly aligned (no blurred text if UI is meant to be native-resolution).
  • Gameplay remains playable: important silhouettes and hazards remain distinguishable at minimum render scale.
  • No artifacts appear at safe-area boundaries (e.g., post-processing not bleeding into letterbox bars if used).