Eclips Codex

Che cos'è EclipsMC e cosa deve fare questo sito

EclipsMC è un network Minecraft italiano costruito attorno a minigames, community e servizi collegati. Il sito non è pensato soltanto come una pagina promozionale con un indirizzo IP: deve funzionare come estensione del network. Quando un giocatore non ricorda quale versione usare, vuole capire una modalità, deve preparare un report o vuole distinguere una funzione attiva da una ancora in sviluppo, il portale deve fornire una risposta leggibile senza obbligarlo a cercare tra decine di messaggi.

L'identità EclipsMC viene quindi trattata su tre livelli. Il server è il luogo in cui si gioca. Il portale raccoglie informazioni, guide e strumenti della community. La documentazione conserva le regole e il significato dei sistemi nel tempo. Nessuno dei tre livelli sostituisce gli altri: una guida non può rendere disponibile una modalità che non è ancora online, e una funzione del sito non dovrebbe essere descritta come contenuto editoriale soltanto perché possiede una pagina.

Questo Codex rappresenta il livello documentale. È scritto per i giocatori attuali e futuri di EclipsMC e viene aggiornato quando una modifica cambia davvero ciò che una persona deve sapere. Non contiene credenziali, configurazioni sensibili o procedure amministrative riservate allo staff. La trasparenza utile consiste nello spiegare comportamento e regole pubbliche, non nel pubblicare dettagli che appartengono all'infrastruttura privata.

Entrare su EclipsMC senza confondere sito e server

L'indirizzo pubblico del network è eclipsmc.it. In Minecraft Java va inserito nella schermata Multiplayer come indirizzo server, senza https://, senza slash finali e senza trasformarlo in un URL web. La versione indicata dal portale è Java 1.20.1+; quando il supporto cambia, il valore pubblicato sul sito deve essere considerato più affidabile di vecchi screenshot o messaggi non aggiornati.

La prima diagnosi di un problema di accesso parte sempre da pochi controlli: versione corretta, indirizzo scritto correttamente, profilo Minecraft funzionante e test con un client il più possibile pulito. Un modpack non è richiesto come base per entrare nel network. Se un client modificato introduce errori, il confronto con un profilo vanilla o minimale permette di capire se il problema è locale oppure riproducibile anche senza modifiche.

Dopo l'ingresso il giocatore viene orientato dalla lobby e dalle interfacce del network. La pagina Primo accesso contiene la procedura passo passo e gli errori più comuni. Il Codex mantiene invece il principio generale: prima si verifica il requisito, poi si modifica il client. Installare Java differenti, cancellare cartelle o cambiare launcher senza una diagnosi rende più difficile capire quale azione abbia davvero risolto il problema.

Quando l'accesso fallisce in modo persistente, il report deve contenere almeno il momento del tentativo, la versione usata, il testo dell'errore e ciò che è già stato provato. Questo evita risposte generiche e permette allo staff di confrontare casi simili. La guida ai report spiega come trasformare un “non funziona” in informazioni riproducibili.

La lobby è l'interfaccia fisica del network

In un network di minigames la lobby non è soltanto una stanza di attesa. È il primo menu che il giocatore incontra, ma invece di essere composto solo da pulsanti vive dentro Minecraft: NPC, oggetti, scoreboard, testi, aree protette e collegamenti alle modalità devono comunicare la stessa cosa. Se due elementi mostrano informazioni differenti, il problema non è soltanto estetico: l'utente perde fiducia su quale dato sia corretto.

EclipsMC tratta quindi la lobby come un'interfaccia. Le azioni principali devono essere riconoscibili senza richiedere una spiegazione esterna; gli NPC devono comunicare con nomi e testi coerenti; le interazioni che non servono devono essere ridotte; i messaggi di sistema devono essere utili e tradotti; gli elementi puramente decorativi non devono competere con ciò che porta realmente a una modalità o a un servizio.

La protezione della lobby ha un obiettivo diverso da quella di un'arena. In lobby il giocatore deve poter interagire con ciò che è previsto, ma non deve poter modificare l'ambiente o produrre comportamenti che disturbano gli altri. Per questo i permessi e le protezioni vengono pensati per categorie di azione: costruzione, uso, interazione, danno, fame e altri comportamenti non sono necessariamente la stessa cosa. La pagina pubblica non espone i comandi amministrativi usati per applicare queste regole; spiega invece il risultato che il giocatore può aspettarsi.

Anche il parkour di lobby, quando disponibile, è considerato un'attività secondaria: deve essere raggiungibile senza interferire con il flusso di accesso alle modalità e deve riportare correttamente il giocatore alla situazione prevista al termine o in caso di caduta. Se una funzione persiste solo fino al riavvio, per EclipsMC non è ancora considerata stabile.

SkyWars: cosa deve sapere il giocatore

SkyWars è la modalità per la quale EclipsMC dispone oggi della documentazione pubblica più approfondita. Il principio di gioco è immediato: i partecipanti partono separati, raccolgono risorse iniziali e decidono quanto rapidamente esporsi per raggiungere zone con maggiore valore. L'equipaggiamento è importante, ma posizione, tempismo e gestione dell'inventario determinano spesso più del singolo oggetto trovato.

Il Codex non sostituisce la Guida SkyWars, che contiene consigli di partita. Qui interessa chiarire l'architettura visibile al giocatore. Una partita deve presentare una capienza coerente, nomi delle mappe comprensibili, una fase di attesa leggibile, cage che svolgono il proprio ruolo senza diventare ostacoli permanenti e una scoreboard che descriva lo stesso stato che il server sta realmente utilizzando.

Quando una modalità possiede varianti come Solo, squadre o forme ranked, il nome nell'interfaccia deve descrivere la variante realmente selezionabile. Non utilizziamo il semplice fatto che una modalità sia prevista nella roadmap come prova che sia disponibile. Questa distinzione è particolarmente importante per i nuovi giocatori: vedere una voce “Doubles” o “Ranked” in una pagina informativa non deve essere interpretato come garanzia che la coda sia già aperta.

Le statistiche hanno la stessa regola. Vittorie, morti, partite e altri valori devono provenire da una sorgente coerente e mantenere lo stesso significato tra scoreboard, TAB, eventuali profili e pagine future. Un numero presentato senza contesto può sembrare preciso ma essere inutile; per questo il network preferisce mostrare meno dati, purché leggibili e coerenti, invece di duplicare contatori con definizioni diverse.

Scoreboard, TAB, messaggi e resource pack devono raccontare la stessa realtà

Un network Minecraft comunica continuamente attraverso piccoli elementi: una riga nella scoreboard, il TAB, il titolo di un NPC, un messaggio in chat, un oggetto di menu, un hologram o una grafica distribuita tramite resource pack. Ognuno di questi elementi sembra indipendente, ma per l'utente formano un'unica interfaccia. Per questo EclipsMC evita di trattarli come decorazioni scollegate.

La scoreboard ha il compito di mostrare poche informazioni ad alta priorità nel contesto giusto. In una lobby globale può servire conoscere lo stato generale; dentro SkyWars servono invece dati della modalità. Il TAB deve mantenere identità, nomi e valori compatibili con la scoreboard, senza introdurre una seconda versione della stessa informazione. Se il server mostra una capienza in un punto e un'altra altrove, la soluzione non consiste nel cambiare soltanto il testo più evidente: bisogna individuare quale componente possiede il valore corretto.

Il resource pack viene usato per rafforzare l'identità visiva senza trasformarsi in una barriera all'accesso. Asset suddivisi, immagini del TAB, cache del client e URL di distribuzione possono produrre problemi che non esistono nel file originale. Per questo ogni modifica grafica viene verificata anche dal punto di vista della consegna al client. Una grafica perfetta che il giocatore non riceve non è una feature completata.

I messaggi di chat seguono un criterio simile. Testi in inglese rimasti da configurazioni predefinite, messaggi tecnici non utili e notifiche ripetitive vengono considerati rumore. Il giocatore dovrebbe ricevere informazioni che spiegano cosa è successo e, quando possibile, cosa può fare dopo. Un messaggio che impedisce un'azione senza contesto è meno utile di un feedback breve ma coerente con il comportamento del network.

Una ricompensa deve avere origine, regola e risultato comprensibili

Progressione e ricompense funzionano soltanto quando il giocatore può capire perché ha ottenuto qualcosa. EclipsMC separa quindi tre concetti: la progressione, che rappresenta avanzamento o sblocco; la ricompensa, che viene assegnata per un'azione o un risultato; e la presentazione, cioè il modo in cui il premio viene mostrato attraverso crate, chiavi, menu o messaggi.

Il sistema di voto è un esempio semplice: il sito può spiegare dove votare e quali ricompense sono previste, ma l'effettiva consegna deve essere verificabile dentro il network. Se una chiave dipende da un evento esterno — voto, boost Discord o altra azione — la catena deve essere leggibile: evento riconosciuto, premio assegnato, feedback al giocatore, utilizzo della ricompensa. Quando uno di questi passaggi non è ancora disponibile, la presentazione non dovrebbe far credere che l'intero flusso sia già completo.

Le crate vengono trattate allo stesso modo. Una cassa visibile può essere utile per mostrare un sistema futuro, ma deve distinguersi da una cassa realmente utilizzabile. Nomi come Vote, Boost, VIP o VIP+ descrivono categorie di reward; non costituiscono da soli una dichiarazione sullo stato operativo del sistema. Il Changelog e gli avvisi nel gioco restano la fonte per sapere cosa è effettivamente attivo al momento.

Questa prudenza evita due problemi: promesse premature e documentazione che diventa falsa appena cambia una configurazione. Il Codex descrive il modello del sistema; le pagine operative e il Changelog descrivono l'implementazione disponibile in un determinato momento.

Sito, Forum, Discord e Roadmap hanno responsabilità diverse

La community EclipsMC vive su più superfici. Discord è adatto alla conversazione immediata, agli avvisi e ai ticket. Il Forum conserva discussioni che hanno valore oltre il singolo momento. La Roadmap rende visibile il lavoro in corso senza trasformare ogni card in una promessa di rilascio. Il Changelog registra ciò che è realmente cambiato. Il Codex conserva il significato stabile dei sistemi. Separare questi ruoli riduce contraddizioni e permette di trovare le informazioni con meno attrito.

Gli account del portale servono a sbloccare funzioni che richiedono identità o autorizzazione. Le aree staff non sono contenuto pubblico e non vengono presentate ai motori di ricerca come pagine editoriali. Un Command Center, per esempio, può essere molto importante per la gestione interna ma non aggiunge valore a un visitatore anonimo; resta quindi protetto e separato dalla documentazione pubblica.

Il Forum segue una logica analoga. La singola conversazione può essere utile alla community, ma non viene automaticamente trasformata in una pagina editoriale indicizzata. Se una discussione produce una soluzione stabile e riutilizzabile, quella soluzione può essere incorporata in una guida o nel Codex, dove viene riscritta, verificata e mantenuta. In questo modo la documentazione cresce grazie alla community senza diventare una copia automatica dei suoi messaggi.

La Roadmap è intenzionalmente diversa dal Changelog. Nella Roadmap può apparire un'idea, un'attività in sviluppo, un test o un lavoro bloccato. Nel Changelog deve apparire una modifica realmente pubblicata. Questa differenza è parte dell'identità EclipsMC e impedisce che un progetto futuro venga scambiato per una funzione già disponibile.

Prima si misura, poi si ottimizza

Problemi di fluidità, latenza e caricamento possono avere origini differenti. FPS bassi sono principalmente un problema di rendering del client; ping elevato riguarda la comunicazione di rete; TPS bassi descrivono invece la capacità del server di elaborare il mondo e le logiche in tempo. Mescolare queste metriche porta a soluzioni casuali: ridurre la distanza di rendering può aiutare gli FPS, ma non risolve una connessione instabile; cambiare texture può alleggerire il client, ma non modifica il ping.

La guida alle prestazioni parte proprio da questa distinzione. Il giocatore dovrebbe costruire una baseline: cosa succede in lobby, cosa succede in partita, quanta differenza esiste tra client pulito e configurazione abituale, se il problema è costante o compare solo in determinate situazioni. Una descrizione precisa permette anche allo staff di capire se più utenti stanno osservando lo stesso fenomeno.

Il resource pack merita un controllo separato. Problemi di download, cache o hash possono manifestarsi come grafica mancante senza influenzare il funzionamento della modalità. Quando si testa un asset è utile distinguere tre fasi: il file corretto sul server web, la consegna corretta al client e il rendering corretto dentro Minecraft. Saltare uno di questi livelli può far sembrare sbagliato un asset che in realtà non è mai stato ricevuto.

EclipsMC non considera l'ottimizzazione una gara a utilizzare il maggior numero possibile di modifiche client. L'obiettivo è ottenere un comportamento stabile e comprensibile. Ogni modifica dovrebbe avere una ragione e un effetto osservabile; quando possibile, si cambia una variabile alla volta.

Regole chiare, prove utili e segnalazioni riproducibili

Il regolamento stabilisce ciò che è consentito nel network. Il Codex non lo sostituisce e non crea eccezioni: aiuta a capire come preparare una segnalazione e perché alcune informazioni sono più utili di altre. Una moderazione coerente dipende da fatti verificabili, non dalla quantità di messaggi inviati o dalla sicurezza con cui viene formulata un'accusa.

Per un comportamento scorretto, una prova utile dovrebbe mostrare il contesto sufficiente a comprendere cosa è successo. Per un bug, la priorità è invece la riproducibilità: pagina o modalità, momento, passaggi svolti, risultato atteso e risultato osservato. Screenshot e video sono molto utili quando aggiungono informazioni, ma non sostituiscono una descrizione precisa.

Lo stesso principio vale per i problemi tecnici. “Non mi entra” contiene troppo poco per distinguere un errore di versione da un problema di rete; “con Java Edition 1.20.1, alle 21:30, l'indirizzo viene mostrato online ma dopo la connessione compare questo errore” permette di iniziare una diagnosi. Il sistema ticket del Discord rimane il canale operativo, mentre la guida report e supporto spiega come preparare le informazioni.

La qualità del supporto dipende anche dal follow-up. Se una correzione viene proposta, il giocatore dovrebbe indicare se il problema è sparito, è cambiato o si presenta in condizioni differenti. Questo chiude il ciclo e impedisce che lo stesso caso rimanga indefinito.

Disponibile, in test, in sviluppo e pianificato non sono sinonimi

Uno dei problemi più comuni nei progetti online è il linguaggio ambiguo. Una funzione “annunciata” può essere interpretata come disponibile; una funzione “in test” può essere percepita come stabile; una card nella roadmap può sembrare una promessa con data certa. EclipsMC usa quindi una distinzione concettuale semplice.

Il Changelog è il registro delle modifiche pubblicate. La Roadmap mostra invece lavoro e intenzioni. Il Codex descrive i sistemi in modo stabile. Se le tre fonti sembrano in conflitto, bisogna privilegiare l'informazione più recente che descrive esplicitamente lo stato operativo.

Dove cercare una risposta in base alla domanda

Non tutte le informazioni hanno la stessa durata. Un regolamento può restare invariato per mesi, mentre lo stato di una modalità può cambiare dopo una release. Per questo il sito usa documenti con funzioni differenti.

• CodexSignificato dei sistemi, principi di utilizzo, relazione tra le aree del network.
• GuideProcedure pratiche: entrare, giocare, ottimizzare, collaborare e segnalare problemi.
• ChangelogModifiche effettivamente pubblicate con una data.
• RoadmapLavori, idee, test e priorità che non equivalgono ancora a una release.
• Eclips LabProblemi reali, decisioni tecniche e metodo usato per arrivare a una correzione.
• DiscordAvvisi immediati, ticket, conversazioni e comunicazioni che possono cambiare rapidamente.

Le risposte che il Codex deve rendere immediate