Lo so ormai siamo ai livelli delle più becere produzioni cinematografiche seriali: Parte I, Parte II e adesso, tocco di fantasia: Parte III!
Il livello di questo post cercherà quindi di, ammesso che sia umanamente possibile, abbassare ulteriormente l'asticella come d'altronde la tradizione cinematografica impone ovvero il crollo verticale di ogni aspetto produttivo con l'aumentare del numero dei seguiti.
Come promesso, quest'oggi andrò ad illustrarvi lo ScriptEngine: come nasce, si sviluppa, rituali di accoppiamento e integrazione col proprio habitat. Scusate il tono stile lezioni di Nettuno ma sento una certa affinità col programma: orari di messa in onda e stesso audience.
Lo ScriptEngine è quella parte che rappresenta il cuore del motore, si posiziona tra l'AssetManager (da cui preleva i dati) e lo strato di Presentation (a cui li invia per essere visualizzati) occupandosi in sostanza di gestire il ciclo tipico di ogni gioco:
- Leggi eventuali input dell'utente
- Aggiorna le entità del gioco
- Mostra a video i risultati
Per svolgere questo scopo definisce al suo interno tutta una serie di funzioni che servono a manipolare le entità del gioco e le interazioni tra le stesse.
Ad esempio quando un giocatore clicca su un punto dello schermo è compito di questo strato fare in modo che le entità si aggiornino correttamente facendo sì che ad ogni ciclo il personaggio si muova fino a destinazione.
Queste funzioni vengono poi esposte tramite un linguaggio di script permettendo così, tramite l'editor, di implementare la logica delle varie azioni andando a definire quindi la storia e l'evolversi del gioco.
Ci sarà quindi ad esempio una funzione per caricare una stanza, piuttosto che una funzionalità per specificare che un personaggio si deve muovere in una determinata posizione oppure dire qualcosa etc.
Se fossi un programmatore figo, con i cosiddetti e con un sacco di tempo libero mi sarei fatto un linguaggio di script ad hoc per l'occasione ma siccome non ho nessuna di queste caratteristiche preferisco non addentrarmi un una problematica così complessa per puro sfizio. Visto che ho l'obiettivo di realizzare qualcosa di usabile in tempi compatibili con la vita umana (soprattutto la mia) ho deciso di integrare un linguaggio già fatto, collaudatissimo e molto usato: LUA.
La scelta è caduta su questo linguaggio prima di tutto per la sua diffusione e semplicità garantendo quindi poco sforzo da parte degli utilizzatori finali (sempre che un giorno ce ne siano) secondo per la presenza di DynamicLua una libreria per il binding con C# particolarmente semplice da utilizzare che mi ha permesso di esporre facilmente le funzionalità del motore (tradotto: con poche e semplici linee di codice, minimizzando invocazioni poco raffinate a divinità di ogni pantheon conosciuto).
Ultima cosa da segnalare, ma non di poco conto, questo strato del motore si occupa anche di regolare la velocità del ciclo di gioco adattandolo al FrameRate (velocità di visualizzazione delle varie entità ad opera della Presentation) in modo che, per esempio, un'animazione risulti alla stessa velocità indipendentemente dall'Hardware su cui gira il motore.
Questo viene fatto da una parte imponendo al massimo 60 cicli al secondo per evitare che chi ha Deep Blue in casa veda animazioni velocissime, dall'altra saltando uno o più cicli per compensare la differenza con il FrameRate massimo.
Se ad esempio un computer dovesse renderizzare 30 FPS, nell'animazione di una camminata formata da 10 passi (1, 2, 3, 4, 5, 6, 7, 8, 9 e 10) invece di considerarli tutti verrebbero mostrati solo: 1, 3, 5, 7, 9. Il risultato è che visualizzando la metà dei Frame nel doppio del tempo la durata finale dell'animazione risulta uguale al caso ideale dei 60 FPS.
E se un PC non riuscisse a realizzare neanche un ciclo al secondo!? Beh in quel caso visto il modesto carico di lavoro richiesto dal motore vorrebbe dire avere a che fare con un Hardware equiparabile ad una calcolatrice di quelle da fustino del detersivo quindi sto abbastanza sereno (in realtà non molto visto che in questo caso il motore va in crash pesante quindi non passate la demo a nessuno che non sia dotato almeno di un calcolatrice scientifica).
Per inciso per adesso l'unico catorcio su cui ho ottenuto meno di 60 FPS è proprio il portatile che sto usando per lo sviluppo... ANUBI!
Direi che le premesse sono state rispettate in pieno: tedioso e soporifero come un corso di analisi matematica di Nettuno delle 2 del mattino, adesso manca solo la parte sulla Presentation e poi con i tecnicismi abbiamo finito... a parte ovviamente un piccolo dettaglio chiamato Editor ma non voglio creare troppa hype ;)
Alla prossima puntata con il fantastico mondo delle librerie grafiche: ne volete sapere di OpenGL, modalità video e double buffering? Io no quindi non contate su di me, se ho usato l'ennesima libreria già fatta ci sarà un motivo no? :P
0 commenti:
Posta un commento