Hierarki Informasi HUD Mobile: Apa yang Ditampilkan saat Combat, Lobby, dan Modal
Visibilitas dan prioritas HUD per state game; kaitannya dengan Safe Area, layer floating text, dan stacking modal—tabel spesifikasi plus langkah Play dan acceptance perangkat.
- game-ui-design
- game-dev-ai
- ui-to-engine
- hud
- mobile
- unity
- godot
- cocos
- vberai
- 2026
Kegagalan HUD jarang berupa “kita lupa health bar”—melainkan terlalu banyak elemen berprioritas sama di satu layar: tab lobby saat combat, toko yang bisa di-tap di atas cinematic, atau HUD di bawahnya masih menangkap tap saat modal terbuka. Mock desain sering kali satu frame dan tidak pernah menandai “sembunyikan currency saat combat”—Anda butuh spesifikasi state × layer agar engineering bisa menetapkan visibilitas, pemblokiran input, dan urutan draw.
Di bawah ini memakai Unity UGUI (Prefab, Canvas.sortingOrder, raycast Graphic) sebagai istilah utama. Godot: CanvasLayer layer + Control mouse_filter; Cocos: urutan draw node + BlockInputEvents / blocker layar penuh—kriteria dan tabelnya sama. Detail Safe Area, floating text, dan pengurutan Canvas: Safe Area, floating damage numbers. Perangkat, semua locale, dan build Release: checklist pra-rilis item 1, 2, dan 5.
Kriteria gagal (salah satu saja = tidak lulus): selama alur modal / cinematic / pembayaran, HUD di bawahnya masih interaktif (kecuali spesifikasi menyatakan “setengah layar masih bisa dioperasikan”); saat combat, promo non-combat yang tidak bisa ditutup menghalangi area permainan; info yang sama ditampilkan dua kali (misalnya koin di top-bar plus UI koin besar saat combat) tanpa catatan produk; kontrol dari state sebelumnya masih tersisa (terlihat atau masih memblokir raycast); dengan locale stres multibahasa, layout minimal combat masih terpotong untuk teks panjang (DE/ES, dll.).
Tentukan state dulu, baru kontrol
| State game (contoh) | Tujuan HUD | Biasanya tampil | Biasanya disembunyikan / diturunkan |
|---|---|---|---|
| Lobby / home | Navigasi + resource + event | Currency atas, tab bawah, pintu masuk event | Skill combat, crosshair |
| Combat / in-level | Aksi + info bertahan hidup | Health, skill, pause | Tab lobby, banner event layar penuh |
| Cinematic / CG | Tanpa input atau hanya skip | Tombol skip | Hampir semua HUD (atau hanya skip) |
| Modal (toko, pengaturan) | Fokus pada dialog | Kontrol di dalam modal | HUD di bawahnya raycast mati atau seluruh layer disembunyikan |
| Pembayaran / kepatuhan | Menyelesaikan alur | Syarat, konfirmasi | Overlay promo dalam game |
Sepakati enum state dengan desain + engineering (misalnya GameUIState.Lobby | Combat | Cinematic | Modal). Root UI berlangganan ke state machine (grup Prefab Unity / cabang scene Godot / prefab Cocos)—hindari SetActive / visible yang tersebar di setiap skrip tombol.

Layer dan urutan sort (spesifikasi netral engine)
Dokumentasikan dari bawah ke atas (angka lebih tinggi = di depan):
| Layer | Konten | Input |
|---|---|---|
| L0 | Latar belakang layar penuh / bleed UI scene | Tidak ada |
| L1 | HUD combat (health, placeholder joystick) | Ya |
| L2 | Floating text / tips combat | Tanpa raycast (floating damage numbers) |
| L3 | Toast sistem / marquee | Biasanya tidak ada |
| L4 | Modal / dialog layar penuh | Ya; memblokir tap L1–L3 |
| L5 | Koneksi terputus, update paksa | Ya; memblokir semua |
Unity: sortingOrder / beberapa Canvas; Godot: CanvasLayer layer; Cocos: urutan sibling di bawah satu Canvas atau Canvas berlapis + mask. Saat modal terbuka, naikkan L4 dan matikan raycast L1 / mouse_filter / BlockInput—bukan sekadar “digambar di atas tapi tap tetap lolos.”

Prioritas informasi (contoh combat)
Jika combat hanya bisa menyimpan N blok yang terbaca di layar kecil, batas default:
| Prioritas | Blok | Strategi penurunan |
|---|---|---|
| P0 | Health / terkait kondisi gagal | Jangan disembunyikan |
| P0 | Pause / keluar combat | Jangan disembunyikan |
| P1 | Skill / aksi utama | Gabungkan ke lebih sedikit tombol |
| P2 | Teks objektif singkat | Ikon + detail saat long-press |
| P3 | Currency, pintu masuk event | Disembunyikan saat combat secara default atau di menu pause |
| P3 | Pintu masuk chat | Ciutkan jadi ikon |
Penurunan harus tetap terbaca di locale stres multibahasa (DE/ES, dll.)—bukan uji penyusutan khusus bahasa Inggris.

Acceptance (5 langkah)
- Daftar state — Dari alur utama, enumerasi transisi (masuk level, buka toko, CG, reconnect).
- Screenshot per state — Editor Play dan perangkat Release masing-masing (item pra-rilis 1 dan 5); verifikasi node dengan
SetActive(false)/visible=falsemasih memblokir input. - Spot-check modal — Dengan toko / pengaturan / pembayaran terbuka, tap pada tombol HUD sebelumnya harus tidak melakukan apa pun (raycast transparan layar penuh atau mask BlockInput).

- Silang dengan Safe Area — Kontrol P0 combat berada di dalam inset aman (Safe Area).
- Commit aset berversi — Tabel state mengendalikan visibilitas (Unity ScriptableObject / Godot Resource / konfigurasi Cocos)—bukan penyembunyian sementara hanya di Scene.
Yang perlu ditambahkan desain
| Deliverable | Tujuan |
|---|---|
| Wireframe per state (minimal Lobby / Combat / Modal) | Engineering mengonfigurasi visibilitas |
| Daftar “boleh disembunyikan” combat di mock | Hindari menggambar setiap elemen di satu frame |
| Spesifikasi modal: latar diredupkan, tap-through diizinkan? | Menetapkan kebijakan raycast |
| Z-order layer promo / event | Selaraskan dengan L4/L5 |
Desainer tidak perlu menulis state machine—tabel + anotasi mengurangi tebakan.
Routing perbaikan
| Gejala | Kemungkinan penyebab | Tindakan | Penanggung jawab |
|---|---|---|---|
| Masih bisa tap combat setelah dialog | Raycast di bawahnya menyala | Matikan raycast Graphic pada layer modal / mask layar penuh | Engineering |
| Event layar penuh saat combat | Tidak ada tabel state | Sembunyikan P3 saat combat; persetujuan desain | Engineering + desain |
| HUD tersisa setelah cinematic | Tidak ada hook state Cinematic | State machine menyembunyikan HUD secara seragam | Engineering |
| Dua tampilan currency | Bar lobby tidak dimatikan saat combat | Sembunyikan top bar saat Combat atau gabungkan sumber data | Engineering + desain |
| Locale panjang terpotong di layout minimal combat | DE/ES tidak diuji | Jalur locale overflow | Desain + engineering |
FAQ
Dua Canvas untuk lobby dan combat?
Boleh—atau satu Canvas dengan grup. Yang penting adalah visibilitas state + raycast, bukan jumlah Canvas.
Toko setengah layar—apakah itu modal?
Ya. Spesifikasikan apakah bagian bawah bisa di-tap dan apakah logika combat dijeda.
Bertentangan dengan UX “less is more”?
Tabel hierarki adalah aturan produk, bukan estetika; P3 bisa dibuka kembali untuk event melalui flag state machine.
Bar overhead world-space di 3D?
Itu adalah info combat, dikelola bersama L1; Aturan sort world-space selaras dengan floating damage numbers dan Safe Area.
Lanjutkan membaca
Panduan lain yang mungkin Anda suka
Figma ke Unity UI: Dari Design Frames ke Prefabs dengan VberAI Studio
Ubah tata letak Figma menjadi hierarki Unity UI—impor, edit bahasa alami, dan ekspor prefab di VberAI Studio, plus peran Figma MCP dan Unity MCP setelah handoff.
- figma-to-unity
- figma-to-code
- figma-ai
- figma-design
Unity Generate UI vs Design-to-Engine: Kapan Generate di Editor, Kapan Ekspor dari Canvas
Panduan batas, kriteria gagal, dan langkah acceptance antara Unity Generate UI vs Figma·PSD→canvas Studio→Prefab. Bukan tutorial langkah demi langkah.
- game-ui-design
- game-dev-ai
- ui-to-engine
- unity
Godot MCP vs Penulisan Manual: Kapan Kontrol Mesin AI Masuk Akal
Panduan keputusan praktis: gunakan VberAI Godot MCP untuk prototipe dan boilerplate, pertahankan GDScript tulisan tangan untuk jalur panas—berdasarkan praktik scene dan sinyal Godot.
- godot-mcp
- vberai
- comparison
- GDScript