Operation Flashpoint: Dragon Rising

Operation Flashpoint: Dragon Rising (da qui in poi OF:DR) e’ un gioco di stampo militare la cui area di gioco si estende per oltre 220Km  quadrati.
Questa enorme estensione ci ha obbligato a pensare ogni singolo elemento del gioco in modo che funzioni correttamente in questo ambiente.
Come esempio estremizzato, prendiamo l’Universo. L’Universo e’ grande e pieno di cose interessanti.
E’ talmente grande che eventi con probabilita’ bassissima di accadere accadono molte volte al secondo.
Cosi’, seppur in scala ovviamente ridotta, succede nei gioco open-world: e’ necessario prevedere ogni accadimento e non lasciar perdere quelli piu’ rari “perche’ non succedono mai”, perche’ e’ molto probabile che accadranno.
In genere, aumentando il numero di tester, gli eventi rari accadono anche piu’ volte al giorno.

Le feature richieste da un sistema di gestione dei personaggi sono le seguenti:
- supporto di numerosi tipi di personaggi, per dare varieta’
- limite massimo di personaggi disegnabili contemporaneamente molto elevato
- distanza massima a cui il personaggio va disegnato molto elevata
- visualizzazione accurata dei danni, come il sangue o la perdita di un arto
- qualita’ di visualizzazione elevata per il maggior numero di personaggi possibile, soprattutto se si trovano vicino al giocatore
- qualita’ molto elevata per gli elementi visibili del giocatore stesso (mani, braccia)

Tutti questi requisiti richiedono un attento studio dell’uso della memoria (sia di sistema che video) e una serie di scelte in tutte le fasi dello sviluppo, dalla preparazione del dato al rendering.
Gli articoli che scrivero’ copriranno tutte queste fasi e mostreranno le scelte compiute per ottenere il risultato.

Tutte questi requisiti richiedono un attenta pianificazione nelle seguenti aree:
- Produzione e trattamento del dato
- Caricamento dei dati in streaming
- Selezione del miglior LOD
- Rendering

Produzione e trattamento del dato:
In questa parte parleremo delle strategie e dei tool che sono stati implementati per avere i dati nella maniera piu’ adatta ai nostri scopi. Parleremo di elaborazione sulle bones per il supporto della medesima animazione su N LOD e su vari tipi di personaggio, oltre che all’elaborazione che e’ stata richiesta per avere una gestione dei danni leggera e hardware-friendly.

Caricamento dei dati in streaming:
tutti i giochi open-world richiedono un massiccio utilizzo dello streaming e OF:DR non fa eccezione. Ogni singolo elemento di OF:DR e’ caricato in streaming ed i personaggi non fanno eccezione. In particolare i personaggi utilizzano un sistema di loading specializzato, che verra’ spiegato nel dettaglio.

Selezione del miglior LOD:
la strategia di scelta dei LOD e’ un argomento estremamente importante, poiche’ la qualita’ e le prestazioni ne dipendono. Il sistema dei personaggi di OF:DR utilizza un sistema specializzato, in modo da poter mostrare i personaggi nella maniera migliore in ogni momento.

Rendering:
Partendo dallo skinning fino ad arrivare all’illuminazione ed alla gestione dei danni, il rendering dei personaggi e’ stato affrontato avendo sempre in mente le prestazioni e la resa a video. In questa parte spieghero’ le scelte fatte per poter avere personaggi qualitativamente competitivi e correttamente integrati in un ambiente estremamente complesso come quello proposto da OF:DR.

Partiamo dalle specifiche richieste.
Ogni personaggio deve avere una divisa completa e un viso. Ogni personaggio deve, inoltre, avere un equipaggiamento visibile che ne identifichi il ruolo.

Ogni personaggio e’ stato quindi diviso in tre elementi.

Corpo:
















Testa e mani (parti con pelle visibile):






Equipaggiamento:














Ognuno di questi tre elementi sara’ skinnato con il medesimo scheletro, in modo che le pose assunte dai tre elementi sia coerente, ma possiamo facilmente intuire che molte bones non sono nemmeno pesate in tutte e tre le parti.
Basta guardare la parte con la testa e le mani per intuire che usare l’intero scheletro su tutte e tre le parti non e’ una scelta affrontabile.
In piu’ dobbiamo considerare anche l’esistenza di piu’ LOD (in questo caso tre): non sarebbe una scelta vincente quella di utilizzare il medesimo scheletro per tutti i LOD, cosi’ come non e’ una scelta vincente quella di avere la stessa animazione rifatta su diversi scheletri (con meno dettaglio per i lod inferiori), per i seguenti motivi:
- memoria: le animazioni occupano spazio
- Sincronizzazione: in ogni momento dovremmo essere certi di avere le animazioni sincronizzate a tutti i LOD.
Questo e’ un problema di correttezza del dato.  Le animazioni non sono un asset facilmente verificabile.

Parleremo di questo argomento nel prossimo articolo, dove trattero’ la problematica della preparazione del dato.