Visualizzazione post con etichetta AssetManager. Mostra tutti i post
Visualizzazione post con etichetta AssetManager. Mostra tutti i post
0

Sotto il cofano... Parte II

CiacioZ 24.1.14 ,
Lo so che eravate in trepidante attesa di un nuovo emozionante articolo pieno interessantissimi e coinvolgenti approfondimenti tecnici ma appostarsi sotto casa mia urlando "ESCI! ESCI! ESCI!" mi è sembrato un tantino eccessivo... in ogni caso la prossima volta evitate di mettere la polo di Equitalia che tanto non ci casco, bel tentativo ma ci vuole ben altro, mi ricordo per esempio quella volta che una ragazza si mise a picchiare furiosamente i pugni alla mia porta "APRI! APRI! APRI!", ma io non l'ho fatta uscire... perchè l'amore è sacrificio!
Ma sto divagando... dunque come vi avevo minacc... hem preannunciato nella prima parte relativa alla descrizione dell'architettura generale in questo articolo tratteremo, rullo di tamburi... l'AssetManager!

L'AssetManager è quel livello dell'applicazione che si occupa di memorizzare e caricare gli asset del gioco, quindi la grafica, i suoni, le animazioni etc.
L'implementazione attuale sfrutta la serializzazione binaria degli oggetti messa a disposizione dal Framework.Net
Per chi fosse poco pratico dell'argomento (tranquilli faccio tanto il maestrino ma non è che ne sappia poi così tanto) questa funzionalità permette di salvare un oggetto in formato binario su disco e richiamarlo successivamente ottenendolo nello stesso stato in cui l'avevamo salvato.
Bingo direte voi! Ed in effetti visto che il Framework di Microsoft si sobbarca già buona parte del lavoro è una gran bel passo in avanti ma il primo problema che è sorto immediatamente è stato: come faccio ad impacchettare e a gestire tutte le risorse del gioco in un unico file?
Già perché il metodo che fornisce il Framework di base prevede che venga serializzato un oggetto in un file.
Questo ovviamente è uno scenario che ho scartato subito in quanto non aveva senso avere millanta file per ogni locazione, personaggio etc. non siamo mica ai tempi di Maniac Mansion o Zack McKracken* ;)  

L'idea per risolvere questo problema mi è venuta leggendo alcune note tecniche sui file delle avventure della Lucas disponibili sul sito dello ScummVM a questo indirizzo.
In pratica nello SCUMM™ ovvero il motore utilizzate per le avventure della LucasFilm/Arts c'è un file che fa da indice per le risorse e un file che contiene tutte le risorse.

Applicando lo stesso concetto al mio programma ho così fatto in modo che esistano due file:

Resources.Bin
E'la serializzazione binaria di una lista che associa al nome di una risorsa la posizione che occupa la sua versione serializzata nel file Resources.Dat

Resources.Dat
Continene tutte le risorse serializzate in versione binaria.

Quando tramite lo script di gioco viene fatta caricare la locazione tramite il comando:

ShowLocation("Locazione1")

Il motore di gioco chiede all'AssetManager "Dammi l'oggetto locazione che corrisponde alla chiave 'Locazione1'... magari in un modo più tecnico e ostentando quell'accento binario tipico degli scatolotti grigio sabbia ma è per rendere l'idea ;)

L'AssetManager sbrigate le quisquilie burocratiche, bacio all'anello esadecimale "Documenti grazie" "Lei non sa che strato software sono io!" etc. controlla nella lista deserializzata dal file Resources.Bin dove si trova l'oggetto richiesto: "Locazione1 primo piano a destra, interno ventordici", si posiziona nel punto indicato del file Resource.Dat e deserializza l'oggetto corrispondente.

Il tutto funziona piuttosto bene e permette per adesso di caricare in tempo reale locazioni, personaggi etc. senza attese di caricamento e minimizzando al massimo lo spreco di RAM.

Tutto fantastico quindi? Ovviamente no, il problema della serializzazione binaria del Framework.Net è che le stringhe non vengono convertite in binario e sono quindi leggibili editando il file, una soluzione potrebbe essere per esempio quella adottata sempre dallo SCUMM™ (fonte ScummVM) che consiste nell'applicare un'operazione XOR sul contenuto del file in modo da renderlo difficilmente leggibile da qualche ardito smanettone che volesse modificare con facilità le risorse del gioco.
Per adesso va bene così, ma è sicuramente nella lista dei "TODO".

Il primo approfondimento sugli elementi che compongono il motore di gioco è teminato, era una hola quella!? Spero resisterete qualche giorno in attesa di scoprire cosa si nasconde dietro... lo ScriptEngine!

Mwahahaha haha ha a...




*Nelle prime versioni dello SCUMM™ (Manica Mansion e Zack McKracken) c'era un file per ogni locazione: 1.lfl, 2.lfl etc.
0

Sotto il cofano... Parte I

Eccoci al primo attesissimo (!?) appuntamento di una serie di articoli in cui spiegherò l'architettura dell'engine e del suo funzionamento interno.

Siccome vi vedo impazienti come fan di Guerre Stellari alla prima de "La minaccia fantasma" comincio subito con lo spiegozzo, spero solo in reazioni migliori rispetto al film di Lucas :P

Attenzione! Se dovete andare in bagno o comprare i pop-corn questo è l'ultimo momento utile per farlo.

Architettura Generale:
Il motore si divide sostanzialmente in 3 parti: l'AssetManager, lo ScriptEngine e la Presentation.

AssetManager:
E'la parte del motore che si occupa di salvare e caricare le risorse inserite tramite l'editor quindi gli sfondi, la grafica i suoni etc.

ScriptEngine:
Definisce il binding tra il linguaggio di script e le funzioni interne, si occupa inoltre di gestire la logica interna del motore.

Presentation:
Si occupa di renderizzare a video le immagini e gestire l'interazione con il giocatore.

Questa separazione è realizzata in modo che ogni strato o layer sia completamente trasparente per gli altri, questo vuol dire che per esempio quando tramite uno script viene utilizzata la funzione per caricare una locazione, lo strato dello ScriptEngine chiama una funzione dell'AssetManager che gli restituirà l'oggetto richiesto.
Come l'AssetManager esegue il suo compito è completamente trasparente per lo ScriptEngine e questo concetto si applica anche allo strato di Presentation. 
Quando lo ScriptEngine ad esempio deve visualizzare il personaggio, chiama un metodo del Presentation che in maniera totalmente indipendente si occuperò di visualizzarlo a schermo.

Questo approccio, noto in programmazione col termine MVC (Model-View-Controller) permette tra l'altro di poter modificare uno strato o layer in maniera indipendente dagli altri.
Ad esempio la Presentation attualmente sfrutta la libreria SFML ma se un domani volessi sostituirla con una diversa potrei riscrivere la parte di Presentation senza toccare minimamente le altre parti dell'engine.

Nelle prossime puntate descriverò in dettaglio ogni layer dell'applicativo approfondento un po'di più le scelte implementative.
 
Copyright 2010 Alone in the Code