Ogni crate deve rispondere a quattro domande
Prima dei premi definiamo il percorso: origine della chiave, condizione di utilizzo, contenuto possibile e stato della cassa. Se una di queste risposte è assente, l’interfaccia può diventare ingannevole anche senza volerlo. Una crate visibile ma non ottenibile deve dirlo chiaramente; una chiave ottenibile deve indicare dove viene utilizzata.
La struttura iniziale di EclipsMC distingue Vote, Boost, VIP e VIP+. Non tutte devono necessariamente avere lo stesso ciclo di disponibilità. Proprio per questo lo stato fa parte del modello dati e non dovrebbe essere comunicato soltanto attraverso il colore del nome.
Il voto ha bisogno di una catena verificabile
La Vote KEY nasce da un evento esterno: il voto su un portale. Questo introduce un passaggio che il server non controlla completamente. Il giocatore usa un nickname, il portale registra l’azione, EclipsMC riceve la conferma e assegna la chiave. Se il nickname non coincide o la conferma tarda, l’utente deve sapere cosa controllare.
Per questo la pagina voto spiega origine, nickname e consegna invece di limitarsi a un pulsante. In gioco, la cassa deve usare lo stesso nome della chiave e non creare varianti come “VoteKey”, “Vote Key” e “Key Vote” in superfici diverse.
Un evento Discord deve diventare un premio Minecraft senza passaggi opachi
La crate Boost collega due piattaforme. La parte delicata è l’associazione tra account Discord e giocatore Minecraft, oppure una procedura manuale controllata quando l’automazione non è disponibile. In entrambi i casi il premio deve essere idempotente: lo stesso evento non dovrebbe generare più chiavi perché un servizio viene riavviato o una conferma viene letta due volte.
La documentazione pubblica può spiegare come si ottiene il premio; i dettagli amministrativi restano nei sistemi staff. Separare questi due livelli riduce domande ripetitive senza esporre procedure sensibili.
Visibile non significa disponibile
VIP e VIP+ possono essere mostrate come parte dell’ecosistema senza permetterne l’apertura finché la logica non è pronta. La cosa importante è evitare una falsa affordance: se il giocatore vede un pulsante, un ologramma o una cassa e l’interfaccia sembra attiva, si aspetta che esista un modo normale per usarla.
Quando una crate è futura, preferiamo uno stato esplicito e un comportamento neutro: niente consumo di chiavi, niente errore generico e niente premi parziali. Quando passa ad attiva, lo stato cambia insieme a documentazione, sorgente della chiave e lista premi.
Il feedback deve distinguere errore, requisito e successo
“Non puoi aprire questa cassa” è troppo generico. Il giocatore deve capire se manca una chiave, se la crate è disattivata, se esiste un cooldown o se si è verificato un errore. Messaggi differenti permettono anche allo staff di diagnosticare più rapidamente un report.
Lo stesso vale per animazioni e suoni: possono rendere gratificante l’apertura, ma non devono nascondere il risultato effettivo. Il premio ricevuto va mostrato in modo leggibile e registrato dove necessario per ricostruire contestazioni o bug.
Provare il ciclo completo, non soltanto il click
- Ottenimento della chiave dalla sorgente prevista.
- Apertura con chiave valida e rifiuto senza chiave.
- Stato disattivato o futuro senza consumo accidentale.
- Premio registrato e consegnato una sola volta.
- Messaggi coerenti tra GUI, ologramma, chat e sito.
- Comportamento invariato dopo riavvio del server.
Una crate è affidabile quando il giocatore può prevederne il comportamento
L’effetto sorpresa deve riguardare il premio, non le regole del sistema. Origine della chiave, disponibilità e feedback devono essere chiari. Questa prevedibilità riduce ticket, evita promesse ambigue e rende più semplice aggiungere nuove casse senza creare eccezioni incontrollate.