How to Keep Pet Controls and the Character Visible in a Compact Game Interface

List the information and actions a player needs during the main play loop. A useful first pass might include the pet, one primary action such as feeding or playing, and a compact indicator that clarifies whether that action is available. Move settings, collections, and less frequent actions into a secondary menu or a brief contextual panel. This is a design method, not a universal rule: a game whose central task is choosing among several actions may need more controls visible at once.

Give the character a defined visual area before fitting in the controls. Keep essential parts of its silhouette and expression clear, and avoid placing buttons or labels over them. If an action requires touching the pet directly, leave that interaction area unobstructed; if controls sit over the game scene, make sure they do not cover the part of the character players need to see. Apple’s game-control guidance recommends reducing virtual controls where direct interaction with game objects can do the job instead (Game controls).

Group frequent actions where they are easy to reach, and put secondary actions farther away or behind a menu. On a touch screen, avoid crowding buttons into the same region where a player’s hand obscures the pet. Apple suggests placing frequent touch controls near the thumb and secondary controls near the top of the screen; its guidance also says to account for comfortable reach and device boundaries. Treat those as starting points to test on the intended device and orientation, not as a fixed layout for every game.

Make the visible icon compact without shrinking the actual touch target to match. Apple recommends a minimum of 44 by 44 points for frequently used controls and 28 by 28 points for less important controls on its platforms. Android recommends at least 48 by 48 density-independent pixels for interactive touch targets. These are platform-specific measurements, so use the relevant platform’s units and guidance rather than treating the numbers as interchangeable (Apple game controls, Android accessibility guidance). Leave enough separation to avoid accidental taps, especially when two actions have different results.

A pet can remain technically on screen yet be hard to notice when controls, labels, or decorative panels compete with it. Use restrained visual weight for secondary interface elements: small icons, short labels, and panels that cover only the space they need. Keep the character’s face and other important details clear during the actions that matter most. If the game scene changes behind text or icons, consider a subtle backing or outline so the interface remains readable without adding a large opaque panel.

Check text and icons over both bright and dark parts of the scene. Contrast that works over one background can disappear when the pet moves or the scene changes. For text, the W3C’s WCAG guidance sets a 4.5:1 contrast ratio for normal-sized text and 3:1 for large text. WCAG is web-content guidance rather than a game-specific rule, but its contrast thresholds can serve as a useful check for interface text over variable backgrounds (W3C contrast guidance). Do not rely on color alone to communicate an unavailable action; also change its label, shape, or state visibly.

If persistent controls take too much room, reveal optional actions when the player opens a menu or selects the pet. Hide actions that are unavailable in the current state, and show a clear state change when a control is pressed. Apple specifically recommends adapting which virtual controls are visible to the gameplay context, including hiding controls that are not relevant and making active controls more visible. A practical pattern is to keep the primary action available, then reveal related choices in a small menu that closes after selection.

Keep state changes predictable. A control that vanishes when a player is about to use it can cause confusion, so reserve hide/show behavior for actions whose availability is clear from the current state. If a button becomes inactive, indicate that state and, where necessary, briefly explain what changed. Avoid letting an expanding menu cover the pet’s face or the area where the player needs to tap next.

Design against the usable area, not just the screen’s outer rectangle. Notches, camera cutouts, system bars, and gesture areas can overlap important controls near the edge. Apple’s layout guidance describes safe areas as regions that help keep content clear of interface elements and device features. Android likewise recommends honoring system-bar, gesture, and display-cutout insets, with critical controls kept away from cutouts (Apple layout guidance, Android edge-to-edge guidance). Background artwork can extend to the edge while interactive elements remain inset.

Do not assume one compact arrangement will fit every aspect ratio. Anchor controls to the usable area and let spacing or grouping adapt when the available width changes. Android’s game guidance for Unity recommends using the safe-area API and supporting different display sizes and aspect ratios. Test portrait or landscape layouts only if the game supports them, and recheck after rotation, window resizing, or a device fold if those configurations are in scope (Android guidance for Unity games on large screens).

A static mockup cannot show which areas the player’s fingers cover during use. Review the interface at its intended physical screen size, then try the main actions while watching for covered character details, missed taps, and controls that overlap system features. Repeat the check with the smallest supported display and a wider or taller aspect ratio. If possible, ask someone unfamiliar with the layout to perform the main task and note where they tap, hesitate, or lose sight of the pet.

Use a short pass/fail checklist for each supported layout:

• The pet remains visible during the main action, including its face or other essential details.

• The primary action is reachable, has a clear pressed state, and does not overlap another target.

• Labels and important status cues remain legible against changing scene backgrounds.

• No essential control sits beneath a cutout, system bar, or gesture area.

• Opening a secondary control does not hide the part of the character or play area needed for the next step.

If a check fails, change one thing at a time: remove a low-priority element, move a control toward the edge of the play area while respecting safe insets, or show secondary actions only when needed. Retest the same interaction. This makes it easier to see whether the change solved the visibility problem or merely moved it elsewhere.

• Apple Developer, Game controls

• Apple Developer, Layout

• Android Developers, Make apps more accessible

• Android Developers, Edge-to-edge design

• Android Developers, Make your Unity game great on all form factors

• W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.3: Contrast (Minimum)