Gerarchia delle informazioni nell'HUD mobile: cosa mostrare in combattimento, lobby e modali

I fallimenti dell’HUD raramente sono “ci siamo dimenticati una barra della salute”—sono troppi elementi con la stessa priorità su una sola schermata: schede della lobby durante il combattimento, uno shop toccabile sopra una cinematic, oppure l’HUD sottostante che continua a intercettare i tap quando un modale è aperto. I mock di design sono spesso a frame singolo e non indicano mai “nascondi la valuta in combattimento”—serve una specifica stato × livello così l’engineering può definire visibilità, blocco dell’input e ordine di disegno.

Qui sotto si usa Unity UGUI (Prefab, Canvas.sortingOrder, raycast delle Graphic) come terminologia principale. Godot: CanvasLayer layer + Control mouse_filter; Cocos: ordine di disegno dei nodi + BlockInputEvents / blocker a schermo intero—stessi criteri e tabelle. Dettagli su Safe Area, testo fluttuante e ordinamento dei Canvas: Safe Area, numeri di danno fluttuanti. Dispositivo, tutte le lingue e build Release: checklist pre-lancio punti 1, 2 e 5.

Criteri di fallimento (uno solo = non superato): durante flussi modali / cinematic / di pagamento, l’HUD sottostante è ancora interattivo (a meno che la specifica non dica “metà schermo ancora operabile”); in combattimento, una promo non di combattimento non dismissibile blocca l’area di gioco; le stesse informazioni mostrate due volte (es. monete nella barra superiore più una grande UI monete in combattimento) senza nota di prodotto; controlli dello stato precedente che rimangono (visibili o ancora bloccanti per i raycast); con le lingue di stress multilingua, il layout minimale di combattimento ritaglia comunque testi lunghi (DE/ES, ecc.).

---

Definire prima gli stati, poi i controlli

Stato di gioco (esempi)	Obiettivo HUD	Di solito mostrare	Di solito nascondere / degradare
Lobby / home	Navigazione + risorse + eventi	Valuta in alto, schede in basso, ingresso eventi	Abilità di combattimento, mirino
Combattimento / in-livello	Azioni + info di sopravvivenza	Salute, abilità, pausa	Schede lobby, banner eventi a schermo intero
Cinematic / CG	Nessun input o solo skip	Pulsante skip	Quasi tutto l’HUD (o solo skip)
Modale (shop, impostazioni)	Focus sul dialogo	Controlli nel modale	HUD sottostante raycast disattivati o intero livello nascosto
Pagamento / compliance	Completare il flusso	Termini, conferma	Overlay promozionali in-game

Concordare l’enum degli stati con design + engineering (es. GameUIState.Lobby | Combat | Cinematic | Modal). Le radici UI si iscrivono alla state machine (gruppi di Prefab Unity / rami di scena Godot / prefab Cocos)—evitando SetActive / visible sparsi su ogni script di pulsante.

---

Livelli e ordine di sort (specifica engine-neutral)

Documentare dal basso verso l’alto (numero più alto = davanti):

Livello	Contenuto	Input
L0	Sfondo a schermo intero / bleed della scena UI	Nessuno
L1	HUD di combattimento (salute, placeholder joystick)	Sì
L2	Testo fluttuante / suggerimenti di combattimento	Nessun raycast (numeri di danno fluttuanti)
L3	Toast di sistema / marquee	Di solito nessuno
L4	Modale / dialogo a schermo intero	Sì; blocca i tap di L1–L3
L5	Caduta di rete, aggiornamento forzato	Sì; blocca tutto

Unity: sortingOrder / più Canvas; Godot: CanvasLayer layer; Cocos: ordine dei sibling sotto un Canvas oppure Canvas a livelli + maschera. Quando si apre un modale, alzare L4 e disabilitare i raycast di L1 / mouse_filter / BlockInput—non solo “disegnato sopra ma i tap passano attraverso”.

---

Priorità delle informazioni (esempio di combattimento)

Se il combattimento può mantenere solo N blocchi leggibili su schermi piccoli, limiti predefiniti:

Priorità	Blocco	Strategia di degradazione
P0	Salute / legato alla condizione di fallimento	Non nascondere
P0	Pausa / uscita dal combattimento	Non nascondere
P1	Abilità / azioni primarie	Unire in meno pulsanti
P2	Testo obiettivo breve	Icona + dettaglio con pressione lunga
P3	Valuta, ingresso eventi	Nascosti in combattimento per default o nel menu pausa
P3	Ingresso chat	Collassare a icona

Le degradazioni devono restare leggibili nelle lingue di stress multilingua (DE/ES, ecc.)—non test di riduzione solo in inglese.

---

Accettazione (5 passi)

1. Elencare gli stati — Dal flusso principale, enumerare le transizioni (entrare nel livello, aprire lo shop, CG, riconnessione).
2. Screenshot per stato — Editor Play e device Release ciascuno (punti pre-lancio 1 e 5); verificare che i nodi con SetActive(false) / visible=false blocchino comunque l’input.
3. Spot-check dei modali — Con shop / impostazioni / pagamento aperti, i tap sui precedenti pulsanti dell’HUD non devono fare nulla (raycast trasparente a schermo intero o maschera BlockInput).

4. Incrociare con la Safe Area — Controlli P0 di combattimento dentro il safe inset (Safe Area).
5. Committare asset versionati — La tabella degli stati guida la visibilità (Unity ScriptableObject / Godot Resource / config Cocos)—non nascondimenti temporanei solo in Scene.

---

Cosa dovrebbe aggiungere il design

Deliverable	Scopo
Wireframe per stato (almeno Lobby / Combattimento / Modale)	L’engineering configura la visibilità
Lista “può nascondersi” del combattimento sul mock	Evitare di disegnare ogni elemento su un solo frame
Specifica modale: sfondo oscurato, tap-through consentito?	Definisce la policy dei raycast
z-order del livello promo / eventi	Allineare con L4/L5

I designer non devono scrivere la state machine—tabelle + annotazioni riducono le congetture.

---

Routing delle correzioni

Sintomo	Causa probabile	Azione	Owner
Si può ancora toccare il combattimento dopo il dialogo	Raycast sottostanti attivi	Disabilitare il raycast delle Graphic sul livello modale / maschera a schermo intero	Engineering
Evento a schermo intero in combattimento	Nessuna tabella degli stati	Nascondere P3 in combattimento; approvazione del design	Engineering + design
HUD rimasto dopo la cinematic	Nessun hook dello stato Cinematic	La state machine nasconde l’HUD in modo uniforme	Engineering
Due display di valuta	Barra lobby non disattivata in combattimento	Nascondere la barra superiore in Combattimento o unire la fonte dati	Engineering + design
Lingua lunga ritagliata nel layout minimale di combattimento	DE/ES non testati	Percorso overflow delle lingue	Design + engineering

---

FAQ

Due Canvas per lobby e combattimento?
Va bene—oppure un Canvas con gruppi. Ciò che conta è visibilità dello stato + raycast, non il numero di Canvas.

Shop a metà schermo—è un modale?
Sì. Specificare se il sottostante è toccabile e se la logica di combattimento va in pausa.

Conflitti con la UX “less is more”?
La tabella di gerarchia è una regola di prodotto, non estetica; P3 può riaprirsi per gli eventi tramite flag della state machine.

Barre overhead in world-space nel 3D?
Sono info di combattimento, gestite con L1; Le regole di sort in world-space si allineano con numeri di danno fluttuanti e Safe Area.