Sviluppo videogames [The Dreamer]

Per tutti quelli che si domandano come funziona lo sviluppo di un videogioco, ho deciso di pubblicare un paper semplicissimo che riguarda la “nascita” di una classe per un npc.
Queste cose sono segretissime e sono il vero e proprio cuore di un videogioco, infatti, determinano le possibilità di interazione con un elemento (in questo caso npc). Partiamo sempre da una lista di necessità, cercando di metterci nei panni del personaggio inserito nell’ambiente. Ci chiediamo “cosa potrà fare?”, “come si muoverà?”, “che cosa potrà bloccarlo?” e 1000 altre domande.

Finalmente uno stralcio di paper in lingua italiana, dedicato a tutti quegli sviluppatori imbarazzati di appartenere al fanalino di coda dell’industria videoludica.
Ovviamente non è presente il codice, bensì i primi step che affrontiamo quotidianamente…il linguaggio in questa fase è “umano” e non è necessario essere dei cervelloni!

PS: prima che mi vengano fatte osservazioni del tipo “[…]in italia ci sono molte realtà di sviluppo di videogiochi[…]”, cosa successa di recente con una azienda di sviluppo, voglio sottolineare che mi sto riferendo a prodotti destinati a console next-gen. Quì a PlaySys stiamo sviluppando per XBox360 e sistemi Windows Vista, Seven e XP (da DirectX 9.0 in poi). Se mi rispondete che state sviluppando videogame con Flash e fatturate milioni di euro l’anno, ricordate che vi state riferendo ad un mercato differente (dallo sviluppo alla tipologia di entrate).

l’npc deve avere degli stati che ne derminano l’animazione ed i dialoghi.

L’npc nonna ad esempio può avere lo stato “rilassato” e la sua animazione sarà quella di una passeggiata predefinita, oppure con lo stato “aiuto” sarà ferma e oscillerà il braccio per richiamare l’attenzione.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

L’npc dovrà aver collegato sempre un trigger ed un emettitore sonoro ad area.

L’npc nonna esegue le proprie animazioni in base allo stato, ma quando ci si avvicina le animazioni vengono sostituite da una animazione idle (respiro) e l’npc ruoterà su se stesso per guardare il giocatore.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

L’npc ha un bounding box per le collisioni ed un baloon invisibile.

Entrambi sono di default invisibili, ma quando si comincia la conversazione il baloon diventa visibile e viene applicata una texture uguale al dialogo corrente. I dialoghi saranno alla Zelda, ossia non sarà presente un doppiaggio ma solo dei rumori (sbuffi, sbadigli, ringhi ecc) e parlerà SEMPRE e SOLO l’npc.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Quando si entra nell’area del trigger appare una GUI.

Questa GUI serve per indicare al giocatore di premere il tasto A per iniziare il dialogo.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I controlli si svincolano dal player durante i dialoghi.

Durante un dialogo (entrata trigger + pressione A) i controlli si disabilitano, ad eccezione del tasto A per proseguire e del tasto B per uscire dal dialogo. La camera effettua anche una variazione della focale, in questo modo è più vicina ai personaggi ma non è necessario spostarla (per poi riposizionarla alla fine del dialogo).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Premendo il tasto A durante un dialogo il dialogo prosegue

dialogo_nonna ++
baloon.mostra texture numero (dialogo_nonna);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Premendo il tasto B durante un dialogo si esce ed il dialogo viene riposizionato al numero corretto per un successivo inizio

baloon.mostra texture numero (dialogo_nonna_fine);
if dialogo > x
dialogo = dialogo_ripristina per prossima volta;
end if