Progetto chiuso – in questa forma

Il progetto viene ufficialmente cancellato, nella forma attuale riscontrabile in questo blog.

La quantità di materiale “dietro le quinte” che ho prodotto è diventata, per me, troppo interessante per dedicarla allo sviluppo di un MUD in italiano. I MUD sono una vera nicchia, e l’Italia non ha un bacino di utenti adeguato.

ZoM nascerà, quindi, ma sarà in inglese (almeno inizialmente). E non è detto che sarà (solo) un MUD. Ma vedrete in futuro.

Lascio il blog come è, per ora, giusto per strappare un sorriso a chi dovesse capitarci. L’ambientazione è ormai anni luce dai pochi elementi che si ritrovano nei vari post.

Buon divertimento a tutti con il vostro personale escapismo!🙂

Rivoltare il server come un calzino.. si può fare!

Qualcuno si sarà chiesto perché son sparito, e si sarà risposto che il progetto è morto. Ebbene no! Il tempo libero (veramente libero) è poco, ma continuo a dividerlo tra sviluppo di ZoM e videogiochi (son umano anch’io :)).

Il problema è che spesso mi piace “sovra-ingegnerizzare” le cose. E quindi prendo il codice del server e lo rivolto come un calzino. La fase due per questo è ancora al 50% purtroppo.

Per me è importante farlo, a parte gli scherzi: mi evita di portarmi dietro orrende brutture dovute all’inesperienza, e mi permette anche di sperimentare nuove tecnologie e modelli che altri sviluppatori usano con successo da tempo.

In particolare, sto attualmente trasformando ZoM per farlo aderire ad un modello chiamato “Sistema ad Entità e Componenti”. Detta in termini semplici, si sposta una buona parte dell’organizzazione “logica” delle entità (razze viventi e oggetti) dal codice vero e proprio (Java nel caso di ZoM) ai dati (database SQL per ZoM). Dopo aver razionalizzato tutte le strutture, si modifica il codice in modo che i dati siano caricati e processati. Per una spiegazione completa e interessante, leggete qui.

Un esempio pratico è il seguente:

  • Ho nel DB un “Modello” per la razza umana. Ad esso possono essere ad esempio associati:
    • Vari componenti come: “Struttura”, “Habitat”, “Magia”, “Attributi”, “SkillTree”, “Posizione”
    • Dati di default per ogni componente, ad esempio nel componente Struttura sono salvate le informazioni che reputo importanti per un umano (è un corpo bipede con tot arti i e i dati di default per la razza, un altezza media di 160cm e un peso medio di 60kg).
  • Ho poi delle “istanze”, le entità, che rappresentano un particolare Umano (creato a partire dal “Modello Umano” e utilizzando i valori di default come base)
  • Ogni Entità ha associati i “dati di istanza” delle componenti ereditate dal modello. Ad esempio il particolare Umano Fabio peserà sui 75kg e sarà alto meno di un metro e ottanta, e avrà ancora tutti gli arti al suo posto (normale corpo Bipede)

Nel codice vero e proprio dovrò poi scrivere:

  • Il codice per ogni Componente (ad esempio per il componente “Contenitore”, c’è bisogno che si mantenga internamente lo stato (aperto, chiuso, bloccato), il “codice” dalla chiave che lo può bloccare/sbloccare se esiste, e la lista di oggetti attualmente contenuti in quello specifico contenitore.
  • Vari “Sistemi” che sappiano utilizzare uno o più componenti per fare qualcosa. Ad esempio potrei fare un sistema “UsaContenitore” a cui possa essere chiesto di aprire un contenitore, metterci dentro qualcosa, chiuderlo o bloccarlo.

Il Sistema sopracitato, “UsaContenitore”, utilizzerà non solo il componente “Contenitore” ma anche il componente “Struttura” per calcolare ad esempio la capienza del contenitore.

Il modello in sé è bello ma in un gioco multiutente complesso (anche se testuale) non è facile tenerlo bello pulito e separato (ad esempio la tentazione di mettere la “capacità contenitiva” dentro il componente struttura è alta.. ma a quel punto i due componenti Struttura e Contenitore diventano accoppiati troppo, e questo dovrebbe esser compito del Sistema).

Insomma, avrò di che divertirmi per un altro po’, se poi sarò soddisfatto continuerò con lo sviluppo dei contenuti (finire Attributi e passare alle Skill è la massima priorità dopo di questo!).

Stay tuned!

Lezioni dallo sviluppo di un MUD – Programmazione

Questo è il secondo episodio della serie su come sviluppare un tuo MUD. Qui trovi l’episodio precedente.

Ci eravamo lasciati con due punti che io reputo fondamentali:

  1. le idee non valgono molto: siamo tanti, e di idee fighe siamo circondanti e bombardati giorno e notte
  2. se non sai programmare, nessuno lo farà per te: vale anche per il resto delle capacità richieste per una simile impresa, ma questa è la prima e fondamentale.

Continua a leggere

Lezioni dallo sviluppo di un MUD – Prologo

Quella che segue è la prima parte di una piccola “Guida per aspiranti sviluppatori di MUD”, molto poco “teorica” e chiaramente basata sulla mia esperienza. Mano a mano che lo sviluppo continuerà, cercherò di toccare tutti i punti fondamentali di programmazione, design, competenze artistiche, management (eh si!), così che se hai deciso di imbarcarti in questa impresa, tu sappia di che morte dovrai morire🙂

Comincio con un “prologo” sulle origini di Zenith, e su cosa ho imparato finora. Buona lettura!

Continua a leggere