Eclips Lab · Case study 02

Progettare la lobby

La lobby è la prima interfaccia del network. Se richiede spiegazioni continue, mostra messaggi inutili o usa oggetti poco comprensibili, il problema non è il giocatore: è il percorso.

01 · Obiettivo

Il primo minuto deve essere leggibile senza tutorial obbligatori

Quando un giocatore entra in un network nuovo compie quasi sempre le stesse domande mentali: dove sono, cosa posso giocare, come entro in una modalità e cosa significano gli oggetti che ho nell’hotbar. Se la risposta richiede cinque messaggi in chat, una parete di hologram e tre menu diversi, la lobby sta trasferendo il proprio lavoro cognitivo al giocatore.

Su EclipsMC abbiamo quindi scelto di trattare ogni elemento come parte di un percorso: NPC per la scelta rapida, oggetti solo quando svolgono un’azione frequente, scoreboard per informazioni contestuali e sito/Discord per spiegazioni più lunghe. La lobby deve orientare; non deve tentare di contenere tutta la documentazione del network.

02 · Selettore

Un NPC deve dire cosa succede prima del click

Un NPC con un nome generico costringe il giocatore a provare. Un’etichetta come “SOLO • Clicca per giocare” comunica invece modalità e azione nello stesso punto. Abbiamo lavorato su questo principio anche nella posizione dello sguardo e nella distanza di visibilità: il personaggio deve risultare presente, non invadente, e il testo non deve occupare metà dello schermo.

Il click deve inoltre avere un solo significato. Se la pressione di una plate, il click sull’NPC e un oggetto della hotbar aprono flussi diversi verso la stessa modalità, il sistema diventa difficile da testare e da spiegare. Ridurre gli ingressi ridondanti semplifica sia l’esperienza sia la manutenzione.

03 · Hotbar

Ogni oggetto deve avere un verbo chiaro

Gli oggetti della lobby funzionano bene quando il giocatore può descriverli con un verbo: scegli, mostra, nascondi, apri, torna. Icone decorative o oggetti che cambiano significato tra lobby diverse introducono esitazione. Nel nostro lavoro, per esempio, il controllo della visibilità dei giocatori è stato reso più esplicito usando stati visivi distinti invece di affidarsi a un oggetto poco intuitivo.

La regola è semplice: se due stati sono opposti, anche l’aspetto deve suggerirlo. Verde e rosso, visibile e nascosto, attivo e disattivo devono essere distinguibili a colpo d’occhio. Tooltip e testo restano importanti, ma non dovrebbero essere l’unico modo per capire lo stato corrente.

04 · Attività secondaria

Il parkour deve finire bene quanto inizia

Un parkour in lobby sembra una funzione semplice finché non si prova tutto il ciclo. Partenza, checkpoint, caduta, reset, completamento, uscita e ritorno allo start devono avere una logica coerente. Un teletrasporto corretto prima del riavvio ma non dopo rivela che il valore è rimasto soltanto nello stato runtime o non è stato salvato nella configurazione prevista.

Abbiamo quindi iniziato a testare il parkour come un piccolo prodotto indipendente: non solo “si può saltare”, ma “il giocatore può entrare, fallire, riprovare e terminare senza rimanere bloccato o perdere il contesto della lobby”. Lo stesso criterio si applica a qualsiasi attività secondaria.

05 · World protection

Proteggere senza rendere il mondo morto

Una lobby pubblica deve impedire modifiche al mondo, danni e interazioni distruttive, ma deve continuare a permettere ciò che rende l’ambiente utilizzabile: menu, NPC, leve o interazioni previste dal design. Per questo le protezioni globali non vengono trattate come un unico interruttore “blocca tutto”.

La configurazione viene pensata per categorie: costruzione e rottura, combattimento, fame e danni ambientali, esplosioni e fuoco, inventari e drop, veicoli, teletrasporti. Separare le responsabilità riduce gli effetti collaterali e rende più facile capire quale regola ha bloccato un’interazione legittima.

Il principio è importante anche per la sicurezza: l’obiettivo non è pubblicare un elenco di comandi amministrativi, ma mantenere una policy leggibile in cui ogni permesso ha una ragione.

06 · Testo

Un messaggio inutile è comunque rumore

Le lobby accumulano facilmente testo proveniente da plugin differenti: teletrasporti, protezioni PvP, join/quit, placeholder, avvisi di sistema. Ogni singolo messaggio può sembrare innocuo; insieme producono una chat che parla più del necessario.

Su EclipsMC abbiamo rimosso o riscritto messaggi come avvisi PvP che non aiutavano a prendere una decisione, traduzioni residue e formule generiche in inglese. Un messaggio deve apparire quando il giocatore può fare qualcosa con quell’informazione: correggere un’azione, capire uno stato o ricevere una conferma importante. Se non cambia nulla, spesso è meglio non mostrarlo.

07 · Informazioni

TAB e scoreboard non devono competere

Il TAB può contenere identità del network, ping, nome giocatore e informazioni globali. La scoreboard laterale dovrebbe invece descrivere il contesto corrente: lobby, modalità o partita. Ripetere IP, Discord, sito, statistiche e stato in ogni superficie crea densità senza aggiungere informazione.

Abbiamo lavorato sull’allineamento grafico e semantico: stessa palette, punteggiatura coerente, nomi leggibili e statistiche pertinenti alla modalità. Anche dettagli come i due punti in “Vittorie:” o “Morti:” contribuiscono alla sensazione che il sistema sia stato progettato come un insieme e non assemblato plugin dopo plugin.

08 · Checklist

Come controlliamo una lobby dopo una modifica

  • Ingresso da nuovo giocatore: nessun elemento richiede conoscenze pregresse.
  • NPC: testo leggibile, click unico, destinazione corretta.
  • Hotbar: ogni oggetto ha uno scopo e uno stato comprensibile.
  • Parkour: partenza, reset, fine e persistenza dopo riavvio.
  • Protezioni: niente grief, ma interazioni legittime funzionanti.
  • Chat: nessun messaggio duplicato, tecnico o non traducibile.
  • TAB/scoreboard: informazioni non contraddittorie e coerenti con lo stile.
  • Mobile/site: i collegamenti esterni mostrati in game puntano a pagine realmente utilizzabili.
IP copiato!