Run any Skill in Manus with one click

ue5-mobile-gameplay

Stars0

Forks0

UpdatedApril 13, 2026 at 20:48

Use when changing UE5 mobile gameplay flow, menu-to-battle state, touch input routing, hidden debug bindings, deterministic simulation ownership, or verification for a smartphone-first game. Applies to controller state, battle bootstrap, Enhanced Input, and automation-backed gameplay checks.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

strmt7

strmt7/project_air_defense

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	ue5-mobile-gameplay
description	Use when changing UE5 mobile gameplay flow, menu-to-battle state, touch input routing, hidden debug bindings, deterministic simulation ownership, or verification for a smartphone-first game. Applies to controller state, battle bootstrap, Enhanced Input, and automation-backed gameplay checks.

UE5 Mobile Gameplay

Load first

AGENTS.md
docs/reference/ue5-mobile-agent-skill-sources.md
docs/planning/ue5-gameplay-migration-matrix.md
docs/architecture.md

Rules

Separate deterministic gameplay state from presentation state. Menus, HUD, and camera surfaces must not own the simulation.
Use the player controller or a dedicated coordinator for menu-to-battle state changes, touch routing, and debug-only keyboard paths.
Treat hidden keyboard bindings as verification aids only. Visible player-facing UX must remain touch-first.
Prefer explicit state transitions over implicit auto-start behavior when a real main menu exists.
Keep gameplay verification two-layered: automation or unit coverage for deterministic logic, runtime screenshot or log proof for player-facing flow.
Do not claim a system is ported because the scene boots. The system must be reachable from the mobile-visible UI.
When adding a verification shortcut, also document the normal touch path.

Done means

the player can reach battle from a touch-first menu
gameplay state and UI state are distinct
debug bindings remain hidden from player-facing surfaces
deterministic logic stays testable outside the viewport

More from this repository

same repository

ue5-mobile-rendering

strmt7/project_air_defense

Use when changing UE5 smartphone rendering, graphics settings, anti-aliasing, ambient occlusion, reflections, post-process, device profiles, or mobile performance tiers. Applies when exposing graphics options to players or claiming that a visual feature works on-device.

2026-04-170

ue5-commonui-menu-systems

strmt7/project_air_defense

Use when changing a major UE5 front-end menu, options flow, modal stack, routed input surface, or layered smartphone-first menu architecture. Applies to CommonUI adoption decisions, activatable-widget stacks, menu settings flows, and player-facing mobile front-end structure.

2026-04-130

ue5-mobile-ui

strmt7/project_air_defense

Use when changing any UE5 player-facing menu, HUD, pause surface, settings surface, touch control, or smartphone layout. Applies to UMG/CommonUI choice, safe zones, touch hit targets, information density, keyboard-hint suppression, and keeping the playfield visible on phones.

2026-04-130

verification-loop

strmt7/project_air_defense

State the narrowest correct verification lane and report exactly what passed.

2026-04-120

android-visual-qa

strmt7/project_air_defense

Use when validating Project Air Defense with screenshots, OCR, template matching, or live emulator navigation, especially when libGDX SurfaceView content is not visible in the Android accessibility tree.

2026-04-120

android-3d-air-defense

strmt7/project_air_defense

Use this skill when building, debugging, balancing, profiling, or visually upgrading the Project Air Defense Android 3D missile-defense prototype, especially for libGDX battle flow, mobile rendering quality, interception logic, HUD ergonomics, and emulator-verified Android fixes.

2026-04-110

name	ue5-mobile-gameplay
description	Use when changing UE5 mobile gameplay flow, menu-to-battle state, touch input routing, hidden debug bindings, deterministic simulation ownership, or verification for a smartphone-first game. Applies to controller state, battle bootstrap, Enhanced Input, and automation-backed gameplay checks.

UE5 Mobile Gameplay

Load first

AGENTS.md
docs/reference/ue5-mobile-agent-skill-sources.md
docs/planning/ue5-gameplay-migration-matrix.md
docs/architecture.md

Rules

Separate deterministic gameplay state from presentation state. Menus, HUD, and camera surfaces must not own the simulation.
Use the player controller or a dedicated coordinator for menu-to-battle state changes, touch routing, and debug-only keyboard paths.
Treat hidden keyboard bindings as verification aids only. Visible player-facing UX must remain touch-first.
Prefer explicit state transitions over implicit auto-start behavior when a real main menu exists.
Keep gameplay verification two-layered: automation or unit coverage for deterministic logic, runtime screenshot or log proof for player-facing flow.
Do not claim a system is ported because the scene boots. The system must be reachable from the mobile-visible UI.
When adding a verification shortcut, also document the normal touch path.

Done means

the player can reach battle from a touch-first menu
gameplay state and UI state are distinct
debug bindings remain hidden from player-facing surfaces
deterministic logic stays testable outside the viewport