Open World – Diario di sviluppo – Area di gioco esplorabile parte 1

Dopo svariati giorni di ricerca e documentandomi leggendo articoli sugli open world , mi sono reso conto che chi la fa da padrona è l’ambiente che ci circonda e, la cosa fondamentale, è avere un’area di gioco abbastanza vasta e variegata.
Giocando ad alcuni giochi del tipo ARK : Survival evolved, Life is feudal your own, i vari The Elder Scroll ma anche i vecchi titoli come la saga di Gothic mi sono reso conto di come può essere composto uno scenario Open World.
Ovviamente il problema principale di uno scenario tanto grande è l’ottimizzazione delle risorse, come mantenere basso il numero di vertici per impedire al game engine di “esplodere” . Il LOD (Level of detail) applicato al terreno è sicuramente una strada da percorrere e, facendo delle ricerche , sono arrivato ad un bivio :

“Potrei programmare uno shader in Open Shading Language (GLSL), ovvero sfruttando i comandi di tassellazione dinamica potrei aumentare e diminuire i vertici inquadrati dalla camera (In gergo tecnico camera frustum) in base alla distanza dalla stessa”; il filmato a questo link ne è un buon esempio e se volete provare vi consiglio di cominciare con questo tutorial che mi ha fatto scoprire Shadertoy.

“Potrei suddividere la mesh hi-poly in quadranti , duplicare i quadranti , decimarli e programmare uno script python che, in base alla distanza dalla camera, mi sostituisce i quadranti più lontani con quelli low-poly”,
così come si vede in questo link.

Dopo una settimana di scervellamento sugli shader che non ha prodotto risultato, ho optato per la seconda opzione ed un buon punto di partenza è stato “BUERAKI v 0.2.0”  trovato grazie ad un amico su youtube e scaricabile a questo indirizzo.
Aprendo il file contenente l’area di gioco di BUERAKI, ho notato che la mesh non era unica, ma tante mesh accostate le une alle altre a comporre un patchwork della mappa. Non ho notato una funzionalità specifica di LOD,  ma tenendo le mesh separate, blender le processa come tali dando priorità agli oggetti visibili nell’inquadratura.

Deciso sulla metodologia da applicare e facendo diversi tentativi sono arrivato a comporre una scena che sul layer zero ha 9 oggetti plane disposti su una griglia 3×3. Questi serviranno come mesh di base da sostituire con dei plane (nello specifico 3 chiamati LOD0 , LOD1 , LOD2) più dettagliati creati all’interno del layer 1. Ogni plane è stato appositamente inserito in un gruppo “Terrain”. Utilizzando upBge, ho creato un primo script legato ad un “empty” che imparenta una “camera” al cursore del mouse. Quest’oggetto “camera” simulerà la nostra camera player.
Ho creato un secondo script e l’ho legato alla camera tramite un sensor “Always”, questo verifica per tutti gli oggetti nella scena appartenenti al gruppo “Terrain” quale plane è in prossimità dell’oggetto “camera player” e lo sostituisce in base alla distanza. Ho imposto allo script 3 distanze, una per ogni oggetto “plane” all’interno del layer 1 ed il risultato lo potete vedere nel filmato a questo link.

E’ fondamentale, prima di buttarsi a capofitto in un progetto, fare molte simulazioni con pochi dati essenziali che non portino via molto tempo così da essere quasi sicuri del risultato finale.

Il prossimo passo sarà quello di migliorare questo script calibrando meglio le distanze della camera così da rendere più morbido il passaggio tra i vari livelli di LOD e magari aggiungendo la funzionalità per il quale gli oggetti posti dietro la camera vengono nascosti dalla scena così da alleggerire ancora di più il motore di gioco da calcoli inutili. Proseguendo a ragionare in quest’ottica, altre ottimizzazioni possibili sono quelle di disabilitare script ed azioni relative agli oggetti che non sono inquadrati o che sono troppo distanti da essere visti.

Al momento sono passato alla creazione della mappa di gioco. Questa cosa mi porterà via un pò di tempo tra creazione della bozza, height map e proporzioni varie ma non vedo l’ora di vedere come questo script funzioni su scenari più ampi.