DimensioneX/it/multiarea

Come far diventare il proprio gioco multi-area

Questo articolo scaturisce dall'esperienza maturata nello splitting di Underworld, e si riferisce alla versione 6.0.2a di DimensioneX.

Se avete altre versioni del software potreste incontrare delle inesattezze. Essendo però questo articolo un WIKI potete voi stessi correggerlo dove serve usando la linguetta EDIT o lasciare commenti usando la linguetta DISCUSSION.

Buona lettura.

Cosa vuol dire Multi-Area

Nel maggio del 2005 DimensioneX ha iniziato a supportare la suddivisione in aree. Ciò significa in pratica che più "mondi" (WORLDS) possono essere collegati in gruppo, detto tecnicamente CLUSTER, e in pratica divengono aree di uno stesso grande ambiente.

Questo significa diversi vantaggi, vediamo quali sono.

I vantaggi

• In primo luogo poter sviluppare un grande gioco in aree significa scalabilità, cioè: Una volta che ho due aree, farle diventare tre, quattro o dieci diventa un gioco da ragazzi. Le aree diverse condividono infatti un blocco di codice comune e, se non vogliamo faticare troppo, possono essere prodotte "in serie" con minimo sforzo.
• Le aree diverse sono indipendenti e condividono regole comuni. Questo significa che è possibile mettere tanti sviluppatori a lavorare ognuno sulla sua area senza dover impazzire a coordinare il gruppo. Certo, un minimo di coordinazione serve per le regole comuni, ma comunque ognuno può rimanere gestore della sua porzione e essere indipendente dagli altri.
• Il carico del server di gioco è ottimizzato. A causa della gestione non troppo snella che il motore DimensioneX mette in atto (ricordiamo che è scritto in Java, linguaggio che di suo non brilla per rapidità d'esecuzione) potremmo stimare che il tempo di esecuzione vari con il quadrato del numero degli oggetti. Questo significa che se dimezzo in numero degli oggetti (perchè ho spezzato il mondo in due mondi) la velocità non è un mezzo, ma un quarto (infatti un mezzo elevato al quadrato dà come risultato un quarto).

Che ci vuole

La suddivisione di un gioco in aree non è indolore, ma non è nemmeno una tragedia.

Ci vuole qualche ora di lavoro (diciamo un pomeriggio per starci larghi) per la prima bozza funzionante e poi un periodo - diciamo di una settimana - di aggiustamenti saltuari per mettere una pezza agli inevitabili imprevisti, periodo che può allungarsi tranquillamente fino a un mese come è stato per Underworld. Notare che non si parla di un mese di lavoro ma di qualche minuto per aggiustare qua e là ciò che non va, man mano che i difetti saltano fuori. Se gli utenti sono preparati potrebbe persino essere divertente.

Come si fa

Presenterò qui il metodo usato a mò di ricetta. La procedura va seguita usando buon senso e chiedendo aiuto sul forum se ci si trova nei guai.

La prima bozza

Questo si fa diciamo in un pomeriggio e alla fine avete una bozza del vs gioco multiarea già funzionante.

1. Fate un backup del vostro gioco, intendo il sorgente. Non si sa mai.

da qui in avanti supporremo che il vostro gioco sia chiamato gioco.dxw.

2. Aprite il vostro gioco.dxw, andate subito nella sezione SCRIPTS e selezionate tutti gli eventi/funzioni/sub che qui si trovano. Sposteremo poi tutto questo codice in un nuovo file che chiameremo common.DXL che creiamo subito con il nostro editor di testo nella stessa cartella in cui si trova il nostro gioco (system). Nella sezione SCRIPTS del nostro gioco inseriremo quindi una istruzione

SCRIPTS

Include "common.dxl" 

END_SCRIPTS

Proviamo ora a rieseguire il nostro gioco. Dovrebbe funzionare come prima.

3. Sempre nel nostro gioco.dxw andiamo in cima, vicino alla tag WORLD. Lì inseriamo una tag che specifica che questa è un area di un CLUSTER:

WORLD
	NAME    	Il mio gioco
	CLUSTER		polipo

Il nome del cluster non ha importanza, però la logica è che il NAME è il nome dell'area mentre il CLUSTER è un identificativo che rappresenta, all'interno del server, la somma risultante di tutte le aree, il gruppo delle aree insomma. Questa tag è importante perchè DimensioneX accetta di far passare persone e cose solo tra aree dello stesso CLUSTER.

4.