Gestione progetti, Unreal Engine e testing. Una giornata di accelerazione a Bologna Game Farm

Giovedì 13 febbraio 2025 si è tenuto un nuovo incontro di Bologna Game Farm a Le Serre Dei Giardini Margherita, aperto a tutto l'ecosistema gaming dell'Emilia Romagna.

18 Febbraio 2025

Giovedì 13 febbraio 2025 si è tenuto un nuovo incontro di Bologna Game Farm a Le Serre Dei Giardini Margherita, aperto a tutto l’ecosistema gaming dell’Emilia Romagna. Una giornata dedicata ad argomenti molto tecnici e proprio per questo hanno assistito gli studenti del primo anno del corso programmer di Demetra Formazione.

La mattinata si è aperta con la consueta serie di interventi volti a dare consigli di carattere pratico nati dall’esperienza dei team intervenuti.

Nacon Studio Milan, da RIMS a Terminator: la gestione di progetti complessi

Marco Ponte e Sergio Rocco, hanno raccontato l’esperienza di Nacon Studio Milan nella gestione di videogiochi dal design molto complesso. Per questo hanno utilizzato come esempio RIMS e Terminator (videogioco non ancora pubblicato) per trarne delle conclusioni generali.

All’avvio di un progetto è fondamentale fare l’analisi e la modulazione dello sforzo.

Quindi va analizzato il progetto e separato in varie “sezioni”. Ad esempio in un gioco survival simile a Terminator si possono prendere i vari momenti di gameplay come la parte di shooting, l’hacking e lo spostamento tramite veicoli.

Modulare lo sforzo significa capire quale sezione del gioco ha più importanza, ad esempio, riprendiamo il nostro ipotetico gioco survival. La parte di shooting è uno dei momenti di gameplay centrale ed è quello che un giocatore farà di più mentre è in gioco quindi il suo valore sarà 10 nell’economia del progetto.

L’hacking invece è un’opzione facoltativa che permette di evadere alcuni scontri o di aprire porte chiuse, essendo una opzione con cui nemmeno tutti i giocatori avranno a che fare il suo valore sarà più basso, 3.

Lo spostamento tramite veicoli invece viene utilizzato spesso nel gioco ma non è una core feature: è un modo per velocizzare gli spostamenti, ma non ci sono gare o minigiochi collegati. Pertanto il suo valore sarà 7.

In questo modo si dirige l’effort dove serve. Questa impostazione può aiutare anche relativamente ai costi. Se lo shooting nel nostro gioco si riesce a rendere soddisfacente anche adattando un blueprint di Unreal e quindi anche a livello di costi risulta adeguata, è un ottima cosa e magari permette di poter spostare risorse su feature secondarie.

L’hacking, che per il nostro progetto vale 3, ci richiede di creare un sistema nuovo con costi non giustificabili visto il peso che ha in gioco. Questo è un sintomo che la feature va tagliata.

È bene partire a lavorare con un GDD che tenga presente i tempi e costi totali ipotizzati, ma che non sia scolpito nella pietra. Va raffinato con il procedere del progetto, arrivando ad essere sempre più aderente alla realtà.

Anche per il GDD è bene ragionare sull’effort, non ha senso scrivere un design document molto approfondito se il gameplay che stai facendo è simile a quanto già fatto da altri e basta usare degli esempi da altri giochi.

Lo stesso vale in programmazione se si possono usare plugin, template o blueprint è bene usarli, specialmente se questo velocizza la prototipazione. Il testing è fondamentale durante lo sviluppo di un progetto, non va sottovalutato.

Quando si dirige un progetto che va a toccare tanti ambiti diversi, come può essere un videogioco, bisogna avere una conoscenza trasversale dei progetti videoludici. Bisogna riuscire a rapportarsi con ogni settore della produzione: dalla programmazione all’UI artist.

Ogni membro del team darà un punto di vista parziale, viziato dal suo argomento e ruolo. Le priorità di un programmatore e di un UI artist possono essere molto diverse anche sullo stesso progetto.

Per questo esiste lo spotlight. Si tratta di un momento in cui tutti i settori si siedono a un tavolo comune e si trovano soluzioni ai problemi insorti.

Altri consigli sono di ricordare che spesso si tende a sottostimare le difficoltà. Ci sono metodi per aggirare la cosa e avere tempistiche giuste. Ad esempio si può fare un prototipo veloce, per avere così un’idea corretta dati alla mano. Oppure si può concordare con il team un piano b che permetta di ridurre lo scope del progetto nel caso ci sia stato un errore di calcolo.

Untold Games: una guida ad Unreal Engine 5

Matteo Sosso di Untold Games ha fatto una panoramica su Unreal Engine 5 e i suoi benefici anche per piccoli team.

Unreal Engine è un motore grafico sviluppato da Epic Games, utilizzato in innumerevoli videogiochi tra cui Fortnite. Il motore e le sue funzioni sono principalmente pensati per progetti molto grandi ma i numerosi sistemi integrati e una buona quantità di materiali didattici collegati lo possono rendere appetibile anche per team indie.

Matteo Sosso ha iniziato la sua escursione nell’engine partendo da tre sistemi molto pubblicizzati: Nanite, Lumen e Niagara.

Nanite è una tecnologia di rendering virtualizzato delle geometrie introdotta in Unreal Engine 5. In parole semplici, permette di usare modelli 3D con un livello di dettaglio estremo, senza preoccuparsi dell’ottimizzazione manuale. Per gli sviluppatori indie può essere utile per velocizzare la creazione di LOD (Level of Detail) dei modelli in game.

Lumen è il sistema di illuminazione globale dinamica di Unreal Engine 5. Permette alla luce di interagire in tempo reale con l’ambiente, creando effetti realistici senza bisogno di pre-renderizzare tutto.

Niagara è il sistema avanzato per creare effetti particellari in Unreal Engine. Con esso si possono generare effetti visivi come fuoco, fumo, pioggia, esplosioni, magie e molto altro in modo altamente personalizzabile. Utilizza un sistema basato su nodi: Gli sviluppatori possono modificare ogni aspetto delle particelle con un’interfaccia visuale, senza bisogno di programmare.

A questi sistemi se ne aggiungono altri meno conosciuti ma che possono facilitare la fase di sviluppo di un videogioco.

Ad esempio l’engine presenta un sistema multiplayer integrato e ottimizzato nell’engine, facilmente scalabile anche su giochi con uno scope piccolo.

Mentre il sistema di gestione delle animazioni e creazione animazioni procedurali, può semplificare la creazione di animazioni per i personaggi in gioco. Con Control Rig si può creare rigging e animazioni procedurali direttamente nell’editor, mentre Physical Animation attiva la simulazione fisica su varie parti del personaggio.

I sistemi di gestione IA possono essere creati con Behavior Tree che funziona a eventi, si tratta di un sistema più vecchio e meno integrato con la versione attuale di Unreal, ma comunque utile. Lo State Tree, è invece una macchina a stati gerarchica, quindi si presta a vari usi non solo per IA.

Esistono poi anche sistemi pensati per il pathfinding e percezione ambientale: Perception System, che simula vista, udito e altri sensi. Navigation System e Environment Query System, più pensati per il movimento degli npc.

Superati questi sistemi principali, si è proseguiti con una lista di altre risorse utili.

  • Mass, permette di gestire un elevato numero di entità in gioco, è data oriented e diviso in Mass Entity e Mass Gameplay.
  • Ability system, è un sistema complesso per la gestione delle abilità in game, il personaggio in gioco ha una ability legata ai tag. Serve a separare la logica dal codice.
  • Localization Dashboard, gestisce le localizzazioni. Permette anche di raggruppare i testi in target come ad esempio: gioco, credits, dlc.
  • Input Mapping, gestione avanzata e granulare degli input, e Input Mapping Contest, il contest è una collezione di azioni a cui do tasti di default. Ad esempio in un gioco survival i comandi cambiano in base a se il personaggio è a piedi oppure su un veicolo.
  • Editor di Interfacce Utente. View model, permette di decidere quali dati leggerá la UI. Così si può creare un model view finto per testare la UI.

Sistema di generazione procedurale, pensato per giochi enormi open world. Per un team piccolo può essere utilizzato per velocizzare i processi di creazione ambienti o asset.

Open Lab: Testing, come approcciarlo

Pietro Polsinelli di Open Lab ha parlato di come massimizzare la produttività e di come avere un ambiente di sviluppo dinamico, preparato a attuare modifiche importanti sul gioco e ad avviare testing che parte dal team e va verso l’esterno.

In primis, all’inizio dello sviluppo, se si usa Unity, è bene valutare se sia meglio usare qualcosa di già fatto o meno. Alcuni plugin sono quasi perfetti e non ha senso non usarli per altri, forse, possiamo fare di meglio.

Per il testing è meglio creare un metodo per permettere di saltare le parti non utili (ad esempio momenti narrativi) e andare diretti dove serve.

In più avere menù di debug disponibili sulla build permette di far avere quelle feature anche a chi non sviluppa o in ambienti che non lo prevedono (ad esempio il mobile).

Ogni scena di gioco deve essere autonoma, si deve poter aprire da sola e configurare per facilitare il testing. Devo poter entrare in una scena con impostazioni diverse, ad esempio poter selezionare unità specifiche in uno strategico o abilità in un GDR.

Ad esempio nel caso del videogioco “Becoming Saint” il gameloop era già pronto da un anno ma permanevano molti problemi di bilanciamento, che solo grazie al testing sono stati risolti. Per questo il testing è un fattore fondamentale per avere un videogioco solido.

Polsinelli ha concluso con un consiglio generale sul bilanciamento di gioco. Bisogna trovare un punto di strozzatura, un momento di gameplay dove il giocatore ha risorse ridotte in modo da poter avere scontri bilanciati. La libertà totale rende solo estremamente complicato il bilanciamento.

Nel pomeriggio i team si sono nuovamente confrontati con i tutor per proseguire il percorso di accelerazione.

Si è trattata sicuramente di una giornata più tecnica rispetto alle precedenti ma proprio per questo ha sicuramente dato enormi spunti di riflessione ai team vincitori del bando e agli studenti presenti.