Fare videogiochi: una panoramica su un po' tutto quanto. Alessandro Monopoli, Senior rendering programmer Codemasters LTD

Transcript

1 Fare videogiochi: una panoramica su un po' tutto quanto Alessandro Monopoli, Senior rendering programmer Codemasters LTD

2 Tre parti 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

3 Breve presentazione

4 Breve Presentazione

5 Breve Presentazione

6 Prima fase: che gioco fare 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

7 Che gioco fare 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

8 Prime basi Una volta saputo che bisogna fare, partono le riunioni Tecnologia: cosa serve? 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?

9 Online 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)

10 Giochi puramente Online 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

11 Preproduzione 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

12 Rapporto con gli altri reparti 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

13 Rendering VS Gameplay

14 Rendering VS AI I ponti sono un problema classico

15 Code VS Production 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?

16 Soluzioni 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

17 Esempi di problemi in fase di produzione 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)

18 Esempi di problemi di produzione 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)

19 Produzione La fase di produzione e' quella fase in cui Tutti i prototipi vengono finalizzati Tutte le feature vengono implementate Gli asset vengono prodotti

20 Produzione: metodologia Agile

21 Scrum Da responsabilita' a chi fornisce il prodotto Semplifica la gestione Semplifica l'insorgere di imprevisti Fornisce facilmente proiezioni di consegna

22 Alpha 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

23 Alpha

24 Beta 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

25 Beta

26 Release candidate 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

27 Submissions 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

28 FINITO! Quando la submission e' passata, il gioco e' finito. Non puo' piu' essere toccato: solo le patch potranno cambiarlo da ora in poi

29 Patch Un software scritto da 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

30 Patch 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

31 Patch Day 1 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

32 Patch Day 1: motivi 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

33 Cosa succede se si fallisce la data di uscita? 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

34 DLC 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)

35 DLC Di fatto allungano la vita di un progetto Il gioco va progettato dall'inizio con i DLC in mente: tutto deve essere espandibile

36 Chiusura finale 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

37

38 Parte tecnica: architettura degli engine 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

39 Passato remoto C64 Amiga (tutti i modelli) NES, SNES Master System, Megadrive, Saturn Gameboy, Gameboy advance Tutti gli altri (Colecovision, Intellivision, Spectrum, ecc...)

40 Passato Remoto

41 Passato remoto 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

42 Dimensione di un videogioco 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 Mb poco prima dell'arrivo dei CD- ROM

43 Supporti

44 Passato remoto

45 PC single core 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!!!)

46 PC single core

47 Organizzazione Il gioco e' diviso in due parti Gameplay Rendering Prima si esegue il gameplay e poi il rendering e poi si ricomincia da capo

48 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

49 Organizzazione 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.

50 Dimensione dati 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.

51 Dual Core 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?

52 Dual Core Gameplay Rendering Synch Due thread principali con synch in fondo, durante il quali avviene lo scambio dei parametri in duble buffering

53 Problemi Il gameplay e' avanti di un frame rispetto al rendering Crea ritardi nell'input, percettibili in certi generi di gioco (beat'em up, per esempio) Double buffering dei parametri e' costoso per la memoria

54 Vantaggi Nessuna concorrenza: i due core viaggiano indipendenti senza collisione alcuna, con il solo synch in fondo Sfruttamento completo del sistema

55 Dimensione dei dati I PC Dual core arrivano senza troppi cambiamenti nel mondo nello storage Dimensioni che vanno da 600Mb a 7Gb

56 Ancora piu' core 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

57 Task based Start Start Gameplay Rendering

58 Task based 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 ) Non piu' lag tra gameplay e rendering Utilizzo completo e dinamico di tutte le risorse Puo' richiedere la riscrittura di ampie parti di codice

59 Dimensioni L'arrivo del Blu ray e del digila delivery aumentano nettamente le possibilita' di storage Gli HD sono ormai senza limite (piu' di 1 TB) In media i giochi vanno da 4Gb a 30Gb

60 Gli oggetti sono sempre nostri amici? Il tipico caso e' quello di una classe contenente dei dati eterogenei che richiede di essere aggiornata in un loop For (i=0; i<n;++i) { objarray[i].update()} (Esempio alla lavagna)

61 Data Oriented Design 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'

62 Esercizio 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

63 Esercizio 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

64 Esercizio Gestisci la creazione e distruzione in modo da non creare deadlock