Fare videogiochi: una panoramica
su un po' tutto quanto
l
Alessandro Monopoli, Senior rendering
programmer Codemasters LTD
Tre parti
l
l
l
Fasi dello sviluppo, con il rapporto con i vari
reparti
Fase tecnica, dove faccio una breve panoramica
su come erano fatti gli engine e come sono fatti
oggi
Presentazione di un breve esercizio per voi, che
risolveremo assieme
Breve presentazione
Breve Presentazione
Breve Presentazione
Prima fase: che gioco fare
l
l
l
Questa scelta dal molti anni non e' piu' nelle
mani dei designer
La scelta e' guidata dal mercato, dalle analisi di
settore, dalla politica, dalle guerre in corso e da
cio' che succede.
ESEMPIO: Sono stati recentemente cancellati 2
videogiochi aventi come tema un terremoto in
Giappone
Che gioco fare
l
l
Questa scelta puo' semplicemente non esserci:
una software house puo' prendere una
commessa ed eseguirla
ESEMPI
-
Devil may cry – Ninja Theory per Capcom
-
MotoGP 2008 – Milestone per Capcom
-
Silent Hill:SM – Climax per Konami
-
Castlevania LOS – Mercury Steam per Konami
-
Mirror's Edge – DICE per EA
Prime basi
l
Una volta saputo che bisogna fare, partono le
riunioni
-
Tecnologia: cosa serve?
l
Assunzioni: vanno fatte? Che tipo di profilo?
(senior, junior)
-
Outsourcers: serviranno?
-
Online: serve? Se si', di che tipo? E' un gioco
solo online?
-
Piattaforme: per cosa si lavora?
Online
l
E' importante definire l'online
-
Ha un costo di sviluppo enorme
-
Puo' fare il successo di un titolo sul lungo
periodo (Warcraft 2, Diablo 2, Starcraft (Caso
Korea del sud) )
-
Molto complesso da testare
-
Puo' richiedere strutture esterne costose (server,
che vanno manutenuti)
Giochi puramente Online
l
Il caso dei MMOG (Massively multiplayer
online game)
-
Incredibilmente costosi (e rischiosi, caso APB)
-
Solitamente PC only: tremendo gestire la
cardinalita' di configurazioni
-
Mondi enormi == bug dappertutto
-
Difficili da progettare e manutenere
-
Un grosso nome (WOW) che mangia tutto
Preproduzione
l
In questo momento verranno prodotti tutti i
prototipi necessari per capire cosa si vuole
portare in produzione
-
Nuove tecnologie
-
Nuove soluzioni
-
Refactoring
-
Potenziale uso di middleware esterni
Rapporto con gli altri reparti
l
In questa fase, il rapporto tra i reparti e'
fondamentale.
-
Una scelta semplice per il rendering potrebbe
portare a grosse ripercussioni per il gameplay e
l'AI
-
Una scelta semplice per i grafici potrebbe non
andare bene al marketing (es. ferite sulle
persone)
-
Una riorganizzazione del codice potrebbe non
andare bene alla produzione
Rendering VS Gameplay
Rendering VS AI
I ponti sono un problema classico
Code VS Production
l
l
Scopo della produzione e' fare in modo che il
progetto arrivi in fondo
-
Organizzazione dei task e controllo che vengano
portati a termine
-
Cancellazione e aggiunta di features
-
Morale del team
Una modifica troppo profonda al codebase
spaventa la produzione
-
Rischio: se la roba che c'era prima andava,
perche' cambiare?
Soluzioni
l
Tutti questi problemi possono essere risolti
tramite estenuanti riunioni e un set di prototipi
atti a dimostrare che e' possibile fare quello che
si vuole fare
Esempi di problemi in fase di
produzione
l
l
l
l
Forzatura di una feature per mostrare un nuovo
gadget tecnologico (Metal Gear Solid 4,
Heavenly Sword)
Cambio generazionale durante lo sviluppo
(Eternal Darkness: Nintedo 64 → Gamecube)
Critiche dal mondo della politica (Two Days in
Fallujia)
Sovrastima delle potenzialita' dell'hardware
(Fable)
Esempi di problemi di produzione
l
l
l
l
Middleware o tool acerbi (Too Human)
Perdita di un grosso numero di elementi nel
team o perdita di un elemento chiave (Infinity
Ward, Team Ninja)
Cambio della moda durante lo sviluppo (Guitar
Hero, Rhythm games in generale)
Aumento spropositato dei costi di produzione
(Indiana Jones Project - Lucasarts)
Produzione
l
La fase di produzione e' quella fase in cui
-
Tutti i prototipi vengono finalizzati
-
Tutte le feature vengono implementate
-
Gli asset vengono prodotti
Produzione: metodologia Agile
Scrum
l
Da responsabilita' a chi fornisce il prodotto
l
Semplifica la gestione
l
Semplifica l'insorgere di imprevisti
l
Fornisce facilmente proiezioni di consegna
Alpha
l
l
Si entra in “Alpha” quando
-
E' possibile giocare il gioco dall'inizio alla fine
-
E' “feature complete”
Non e' necessario che
-
Ci siano tutti gli asset
-
Tutte le feature siano definitive
-
Il gioco sia stabile in ogni condizione
Alpha
Beta
l
l
Quando l'Alpha viene accettata, si punta alla
beta.
La beta e' quella fase in cui
-
Tutti gli asset sono a posto
-
Tutte le feature sono a posto
-
Il gioco e' adeguatamente rifinito
-
Il gioco e' stabile nella maggior parte dei casi
Beta
Release candidate
l
l
Quando la beta viene completata, il gioco e'
rifinito per bene, e' tutto pulito e stabile ed e'
pronto per essere consegnato al pubblisher per i
suoi test.
Versione PC: test interni e qualche test
microsoft se si vuole il marchio “Game for
windows Live”
Submissions
l
l
l
Xbox360, PS3, ecc.... : si manda il gioco alla
casa madre, dove sara' testato
approfonditamente.
Non si controlla solo che funzioni, ma che non
avvilisca la macchina (ossia sia adeguatamente
bello)
Se tutto e' a posto, si ha in mano la famosa
GOLD
FINITO!
l
l
Quando la submission e' passata, il gioco e'
finito.
Non puo' piu' essere toccato: solo le patch
potranno cambiarlo da ora in poi
Patch
l
l
Un software scritto da 150-200 persone che
utilizza librerie esterne e interne e ha un
codebase di milioni di linee di codice non puo'
essere bug-free. O quantomento, non puo'
esserlo in tutte le possibili permutazioni che un
gioco moderno offre.
Le console next gen HD based (X360&PS3) e il
PC offrono da sempre il supporto alle patch
Patch
l
l
Gli scopi delle patch sono
-
Correggere problemi post-rilascio
-
Aggiungere contenuti mancanti al rilascio
Problemi tipici
-
AI
-
Deadlock a causa di condizioni rare (RPG su
tutti)
-
Bilanciamento statistiche di gioco (RPG, FPS)
-
Rimozione DRM
Patch Day 1
l
l
Domanda: “Perche' ho comprato un gioco e
appena l'ho messo dentro mi ha detto che c'e'
una patch? Non potevano metterla direttamente
nel gioco, visto che e' disponibile lo stesso
giorno?”
La risposta e' principalmente di natura
finanziaria
Patch Day 1: motivi
l
l
l
Un gioco potrebbe avere una data di uscita non
modificabile in nessun modo. Esempi:
-
Chiusura anno fiscale (spiegazione)
-
Gioco legato a un film o competizione sportiva
-
Competitors
La submission di un gioco richiede circa due
settimane
Questo significa che si potrebbe essere obbligati
a consegnare il gioco al meglio possibile perche'
passi la submission e poi accordarsi per una
patch al day 1
Cosa succede se si fallisce la data
di uscita?
l
Se il gioco ha una data di uscita non
modificabile in nessun modo, la mancata
consegna per la data stabilita puo' portare a:
-
Cancellazione del prodotto
-
Chiusura dello studio
-
Licenziamento degli esecutivi
-
Perdita di una licenza profumatamente pagata
DLC
l
l
l
I DLC (Downloadable Content) sono un nuovo
nome per le espansioni
Vanno dal semplice nuovo costume all'aggiunta
di pezzi gioco
Controversi
-
A volte sbloccano funzionalita' gia' presenti ma
bloccate
-
Qualita' altalenante
-
Prezzo considerato improprio (soprattutto dopo
che Apple ha abbassato il valore del lavoro)
DLC
l
l
Di fatto allungano la vita di un progetto
Il gioco va progettato dall'inizio con i DLC in
mente: tutto deve essere espandibile
Chiusura finale
l
l
l
Una volta che non si forniscono piu' patch e
DLC, il progetto e' chiuso.
Non c'e' piu' tempo allocabile == non ci si puo'
piu' lavorare
Il progetto si prende per intero e si salva su
storage ad alta capacita' (nastri)
-
Un progetto medio moderno ha dimensione
totale di circa 1TB e puo' raggiungere i 2.5TB
Parte tecnica: architettura degli
engine
l
l
Nel passato remoto (anni '80) ogni gioco era
sviluppato quasi da zero, per sfruttare al meglio
le risorse disponibili per quel gioco in
particolare
Al massimo i seguiti usavano la tecnologia
precedente per svilupparla meglio
Passato remoto
l
C64
l
Amiga (tutti i modelli)
l
NES, SNES
l
Master System, Megadrive, Saturn
l
Gameboy, Gameboy advance
l
Tutti gli altri (Colecovision, Intellivision,
Spectrum, ecc...)
Passato Remoto
Passato remoto
l
Hardware estremamente eterogeneo
-
Vari processori per varie cose
-
Tutto diverso tra una macchina e l'altra
-
Coin op addirittura costruiti attorno al gioco che
si deve fare
-
CASO: Atari 2600
Dimensione di un videogioco
l
l
l
l
Ai tempi i videogiochi erano salvati su cartucce,
audio cassette o floppy
Ogni macchina aveva il suo formato
Alcune macchine avevano l'HD (Amiga, PC
prima generazione)
Dimensione che varia da 4 kb al massimo di
circa 16-20 Mb poco prima dell'arrivo dei CDROM
Supporti
Passato remoto
PC single core
l
l
l
I PC “Ibm Compatibili” propongono una
soluzione standard de-facto, a cui i produttori di
hardware si adattano
Hardware quindi piu' o meno similare tra le
varie macchine
Soprattutto, hardware potente (16 Mhz!!!)
PC single core
Organizzazione
l
l
Il gioco e' diviso in due parti
-
Gameplay
-
Rendering
Prima si esegue il gameplay e poi il rendering e
poi si ricomincia da capo
Organizzazione
Tempo (33 ms se possibile)
Gameplay
Rendering
Il tempo impiegato ha una importanza relativa, basta che
vada abbastanza veloce (20-30 fps) tra tutto quanto. Per
certi giochi anche 15 fps sono accettabili
Organizzazione
l
l
l
Il multithreading qui e' quasi controproducente:
i cambi di contesto uccidono le performance
Alcune CPU lo consentono a stento (es. 286)
Va bene solo per certi compiti particolari, come
il caricamento asincrono e il movimento di
barrette di completamento durante i caricamenti.
Dimensione dati
l
l
I floppy e i CD (e DVD poi) consentono di
avere dimensioni dei dati nettamente piu'
consistenti
Si va da circa 300k a 4Gb, con l'avvento del
periodo PS2 e l'uso dei DVD-ROM come
formato.
Dual Core
l
l
l
Questo tipo di organizzazione e' andato avanti
per molti anni, fino all'apparire delle CPU dualcore
A questo punto l'uso del multithreading diventa
estremamente conveniente: puo' quasi
raddoppiare le performance
PERCHE' “QUASI”?
Dual Core
Gameplay
Synch
Rendering
Due thread principali con synch in fondo, durante il quali avviene lo scambio
dei parametri in duble buffering
Problemi
l
Il gameplay e' avanti di un frame rispetto al
rendering
-
l
Crea ritardi nell'input, percettibili in certi generi
di gioco (beat'em up, per esempio)
Double buffering dei parametri e' costoso per la
memoria
Vantaggi
l
l
Nessuna concorrenza: i due core viaggiano
indipendenti senza collisione alcuna, con il solo
synch in fondo
Sfruttamento completo del sistema
Dimensione dei dati
l
l
I PC Dual core arrivano senza troppi
cambiamenti nel mondo nello storage
Dimensioni che vanno da 600Mb a 7Gb
Ancora piu' core
l
l
Quad core, X360 (3 core 2 thread ognuno), PS3
(CPU dual core + 6 SPU)
La soluzione dual thread non puo' sfruttare
l'hardware adeguatamente
-
Soluzione semplice: lanciare qualche thread
accessorio (loading, fisica)
-
Anche cosi' avremo tempi morti da tutte le parti
Task based
Start
Gameplay
Start
Rendering
Task based
l
Il sistema a task prevede lo spezzettamento di
un problema in tanti problemi piu' piccoli
indipendenti da loro
-
Potrebbero richiedere uno step di
ricongiungimento (strategia “Divide et Impera”)
l
Non piu' lag tra gameplay e rendering
l
Utilizzo completo e dinamico di tutte le risorse
l
Puo' richiedere la riscrittura di ampie parti di
codice
Dimensioni
l
L'arrivo del Blu ray e del digila delivery
aumentano nettamente le possibilita' di storage
l
Gli HD sono ormai “senza limite” (piu' di 1 TB)
l
In media i giochi vanno da 4Gb a 30Gb
Gli oggetti sono sempre nostri
amici?
l
Il tipico caso e' quello di una classe contenente
dei dati eterogenei che richiede di essere
aggiornata in un loop
l
For (i=0; i<n;++i)
l
{ objArray[i].update()}
l
(Esempio alla lavagna)
Data Oriented Design
l
l
l
In questo caso gli oggetti creano problemi con
macchine con cache limitata
La soluzione e' di raggruppare i dati in
collezioni omogenee ed avere gli oggetti con i
dati eterogenei come puntatori che puntano
all'array
La cache ringraziera'
Esercizio
l
Implementare un sistema che fornisca queste
funzionalita':
-
Riceva in input una funzione e un set di dati
-
Divida questo set di dati in sottoinsiemi
-
Per ogni sottoinsieme crei un thread che esegua
la funzione sul set di dat
Esercizio
l
l
l
l
Applicare questo sistema ad un set di oggetti
che rappresentano delle cellule.
Ogni cellula guadagna una unita' di nutrimento
ogni secondo
Ogni dieci secondi, la cellula si divide e crea
un'altra cellula
Ogni 95 secondi la cellula muore
Esercizio
l
Gestisci la creazione e distruzione in modo da
non creare deadlock