L'errore che commettono tutti i nuovi sviluppatori

GMTK è supportato tramite Patreon - https://www.patreon.com/GameMakersToolkit

In questa puntata di Developing, voglio trasformare la mia idea per un gioco in realtà. Ma prima di tutto devo ripercorrere i miei tentativi falliti per capire da dove iniziare.

=== Credits ===

Filmati con prototipi

It Takes Two - https://youtu.be/QbMF1nCiIkQ
Ori - https://www.youtube.com/watch?v=HTksBJeoa1A
Subnautica - https://www.youtube.com/watch?v=pwWkAxzXxeQ
Cuphead - https://twitter.com/StudioMDHR/status/1046082248573882370
Slay the Spire - https://www.youtube.com/watch?v=eLITSvCz2rk
Last of Us Part II - https://youtu.be/KW4JlxAEAE0
Fall Guys - https://www.youtube.com/watch?v=01ZBzHMvVCE
God of War - https://www.youtube.com/watch?v=lreYsdHT54w

Sequenze di gioco

Artwork - https://www.kenney.nl
Character Controller - https://pressstart.vip/tutorials/2019/10/15/104/perfect-jumping-in-unity.html

Musiche: LAKEY INSPIRED @ https://soundcloud.com/lakeyinspired
Licenza per uso commerciale: Creative Commons Attribution 3.0 Unported "Share Alike" (CC BY-SA 3.0) License.
YouTube Audio Library

Nell'ultima puntata di Developing,
ho scelto il motore di gioco - Unity -

e ho iniziato ad imparare ad usarlo.

Ma ora è il momento di rivelare
l'idea per il mio gioco

e, beh, di iniziare a crearlo.

Ma da dove si inizia
a sviluppare un gioco?

Penso sia una domanda d'importanza
cruciale perché, come vedrete,

iniziare lo sviluppo di un gioco
col piede sbagliato

può rivelarsi disastroso per il progetto.

Fatemi spiegare.

Fatemi iniziare dall'idea per il gioco.

Creerò, e tenetevi forte
perché è pazzesco,

un platform bidimensionale
a scorrimento orizzontale.

Sì, lo so, tutti gli sviluppatori indie

iniziano con un platform
a scorrimento orizzontale.

Ma penso ci siano delle buone ragioni.

Amo il genere.

Nel complesso i platform
sono relativamente facili da creare -

quantomeno non è un MMO.

Ed ho creato molti video sul level design
e il character design per i platform,

il che dovrebbe tornare utile.

Inoltre sarà, tenetevi forte di nuovo,
un platform con una peculiarità.

L'idea è di rendere magnetico
il personaggio del mio platform,

ovvero respingerà alcune piattaforme
attraendone altre.

E si potrà cambiare la polarità
premendo un pulsante.

L'idea mi è venuta da questo gioco:
The Legend of Zelda: Oracle of Seasons.

In questo gioco c'è un guanto magnetico
come power-up

che permette a Link di respingere alcune
superfici attraendone altre.

Può essere usato anche per raccogliere
grandi sfere metalliche

da usare nella risoluzione dei rompicapo
e per combattere i nemici.

È una meccanica davvero forte ma sembra
limitata dal genere,

dalla prospettiva top-down
della telecamera,

e ovviamente dai limiti tecnologici
del Game Boy.

Così ho pensato: e se prendessi
in prestito quell'idea

e la implementassi in un genere diverso,
un frenetico platform 2D?

Qualcosa che richiama Celeste o
Super Meat Boy.

Un gioco in cui bisogna padroneggiare
il magnetismo

per avere velocità, fluidità
e precisione.

Questa è l'idea.

Mentre la domanda ora è: da dove inizio?

Apro Unity e inizio a programmare?

Apro Photoshop e inizio
a creare la grafica?

Inizio a pensare alla storia
o ai personaggi?

Da dove inizio?

Sarò sincero con voi: non è il primo
gioco che tento di creare.

Fin da bambino ho avuto idee per i giochi,

e in vari momenti della mia vita
ho provato a creare quei giochi

con diversi strumenti e quant'altro.

Ma non ho quasi mai finito quei giochi e
penso che la ragione sia sempre la stessa:

ho iniziato nel modo sbagliato.

Lasciate che vi mostri.

Ho preso questa cartella dalla casa
dei miei genitori

ed è piena di note e bozzetti e idee
per un gioco che stavo creando

alcuni anni prima di iniziare
Game Maker's Toolkit.

Questo è un tappetino per il mouse
di Starcraft Ghost.

Quel gioco non è mai uscito, giusto?
Potrebbe valere qualcosa,

lo metto tra la roba di eBay.

Il gioco avrebbe dovuto chiamarsi
Carter's Curse.

Parlava del famoso archeologo
Howard Carter,

il tizio che ha scoperto la tomba
di Tutankhamon.

E, almeno nel mio gioco, avrebbe anche
rievocato un'antica maledizione egizia

che lo avrebbe portato a combattere
zombie, mummie e antiche divinità egizie.

Ricordo di aver passato ore ed ore
a disegnare tutta questa roba.

Voglio dire... che nerd!

Comunque. Come avreste affrontato
questi nemici?

La risposta: giocando a dei rompicapo
Nonogram.

I Nonogram sono dei rompicapo a griglie
basati sulla logica, un po' come il Sudoku.

Nintendo ha creato molti giochi
del genere.

Ero davvero ispirato da giochi come
Bookworm Adventures

dove c'è un rompicapo
alla base dello schermo

che se completato danneggia i nemici in
una piccola scena di combattimento

in cima allo schermo.

La mia idea era simile: ci sarebbe stata
una griglia Nonogram alla base dello schermo

mentre Howard Carter avrebbe combattuto
i mostri in cima allo schermo.

Sono quindi passato allo sviluppo.

Stavo creando il gioco in un'app per iPad
chiamata Codea

che permette di creare giochi per iOS
sul vostro iPad.

L'avevo utilizzata in precedenza per una
vera e propria app Nonogram per iOS

quindi probabilmente avrei saputo
programmarlo,

ma volevo che la grafica fosse
meravigliosa così ho aperto Photoshop

iniziando a creare sprite e
frame d'animazione.

Ho ancora una cartella su Dropbox
piena di sprite e animazioni.

Ho creato molti personaggi diversi, le
mosse finali per Howard Carter,

una cutscene introduttiva, i menù con
dei bei pulsantoni da premere.

Ero davvero preso.

Ma poi ho capito una cosa. Una cosa
abbastanza importante. Una cosa...

abbastanza deleteria per il progetto.

Il gioco non era granché. Davvero pessimo,
per niente divertente.

E più programmavo, più sviluppavo,
e più capivo qual era il problema:

i Nonogram non hanno abbastanza profondità
per un gioco del genere.

Non ci sono né tattica né strategia,

non è possibile adattare le azioni
al tipo di nemico che si sta affrontando,

e in definitiva il combattimento
era irrilevante.

Avreste potuto ignorare l'intera sezione
superiore dello schermo

e il gioco avrebbe funzionato comunque

perché tutto ciò che fate è
giocare ad un Nonogram.

Significava non poter rendere il gioco
più difficile o interessante

a seconda del nemico che si affronta,

e significava che il giocatore avrebbe
fatto la stessa cosa ancora e ancora.

Avevo creato un gioco superficiale,
ripetitivo e noioso.

Forse avrei potuto aggiustarlo ma a quel
punto ero così avanti nello sviluppo

e così demoralizzato che ho
cestinato tutto.

Qual era stato il mio errore?

Beh, con un senno di poi
frutto di anni e anni...

è passato quasi un decennio...

mi sembra abbastanza ovvio cos'è accaduto.

Ovvero: quando fate un gioco dovete
create molte cose diverse.

Le principali sono la musica, la grafica,
il game design, la storia e il codice.

Ora è facile vederle sullo stesso piano...
ma non è così.

In molti casi il game design
non è alla pari

ma bensì è la base su cui poggiano
tutte le altre parti.

E così se quella parte è debole finirà
col far crollare il tutto.

Potete risolvere i bug e
ridisegnare la grafica

ma se il gameplay è viziato di per sé,

talvolta l'intero progetto
potrebbe essere irrecuperabile.

Ed è di fatto quello che
mi è accaduto.

Ho dedicato così tanto tempo
alla grafica e all'animazione

che nel momento in cui sono finalmente
arrivato al gameplay,

mi sono accorto che l'intero progetto
era difettoso.

Avevo di fatto costruito una casa su delle
fondamenta davvero instabili,

per poi ritrovarmi sorpreso e arrabbiato
quando il water è sprofondato nel pavimento.

È imbarazzante dire che non mi è successo
solo quella volta.

Volevo creare un gioco d'avventura
punta e clicca in stile noir

con un peculiare sistema d'indizi
generati proceduralmente -

ma ho dedicato così tanto tempo alla
storia e alla ricerca su quel periodo

che non ho mai iniziato a progettare
quel sistema.

E volevo creare una versione moderna
e frenetica del gioco mobile Snake

ma mi sono così impantanato
nel correggere i bug

e nel rendere perfetto
il codice per il movimento

che non ho mai scoperto se il gioco
fosse divertente

prima di annoiarmi ed esaurirmi.

E quindi ogni volta che ho cercato di
progettare un mio gioco

ho messo altri elementi come la storia
e la grafica davanti al gameplay.

Perché?

Penso si possa ridurre il tutto a due
presupposti decisamente errati.

Il primo presupposto è che se il gioco
era figo nella mia testa,

allora lo sarebbe stato
anche una volta creato.

Ovviamente non era così.

Il secondo presupposto

era l'impossibilità
di capire se il gioco fosse divertente

prima di completarlo.

Avrei dovuto continuare a lavorare finché
ad un certo punto

avrei capito se funzionava... giusto?

No, di nuovo sbagliato.

Ed è davvero imbarazzante da raccontare
perché ora le risposte appaiono ovvie.

Ma non erano ovvie allora.

È solo da quando faccio
Game Maker's Toolkit,

da quando studio lo sviluppo
dei videogiochi,

dopo aver intervistato dozzine
e dozzine di game designer

che so come nascono molti dei giochi
di maggior successo.

I game designer hanno continuamente
delle idee

e sono sicuro che nelle loro teste
suonino divertentissime.

Ma i migliori game designer sanno che
i loro cervelli sono dei gran bugiardi.

L'unico modo per sapere se un'idea
è buona è metterla in pratica, testarla.

Ma invece di creare l'intero gioco, un
designer deve semplicemente creare un...

prototipo.

Un prototipo è solo un piccolo
banco di prova per un'idea,

progettato unicamente per vedere
se l'idea è divertente o meno.

Di solito questi prototipi sono
davvero brutti

con una grafica raffazzonata o forme
di base o sprite presi da altri giochi.

Spesso sono buggati e scadenti

e non prevedono altro se non
le caratteristiche essenziali

necessarie per testare quella meccanica.

Sono solo una versione sufficientemente
funzionante dell'idea per il gioco,

costruita il più velocemente possibile,

con l'unico scopo di verificare
se l'idea per il gioco funziona.

È divertente o interessante?
Vale la pena dedicarvicisi?

È una base solida sulla quale costruire
il resto del gioco?

Ed è quello che farò. Questa volta
lo farò nel modo giusto.

Mi concentrerò esclusivamente
sulla creazione del prototipo,

e sarò estremamente disciplinato

e non mi dedicherò ad altro se non
a mettere alla prova questa idea.

Per quanto riguarda la grafica,
mi affiderò a Google Immagini.

Non ci sarà nessuna musica,
nessuna storia,

non penserò al nome del gioco
o dei personaggi,

Non inizierò a disegnare l'icona per un
gioco che non è stato ancora creato,

Mark, idiota.

Il codice sarà scadente e pieno di bug
perché sto ancora imparando ad usare Unity,

ma sarà abbastanza buono per verificare
se questa idea funziona.

Solo un banco di prova per testare
le meccaniche di gioco

e vedere cos'è divertente.

Quindi iniziamo, e apriamo Unity.

La prima cosa da creare

era un personaggio in grado di muoversi
a destra e a sinistra e saltare,

così ho applicato delle forze al rigidbody
alla pressione dei tasti dedicati.

Ci sono stati subito dei problemi
per niente incoraggianti,

ma alla fine ci sono riuscito.

Poi ho aggiunto un magnete alla scena

facendo in modo che il personaggio
ne fosse attratto.

Nel farlo sono dovuto diventare
un programmatore esperto

elevando le mie abilità di programmazione
fino alla mente galattica,

così mi sono scrocchiato le dita
e ho digitato questa linea di codice...

come muovere un rigidbody
verso un altro oggetto.

Ok, sì, ho usato Google,
trovato del codice,

e l'ho schiaffato nel mio progetto.

Ma mi sono assicurato di aver capito
come funziona -

fondamentalmente trova la direzione tra
il personaggio ed il magnete

per poi applicare le forze al rigidbody
in quella direzione.

Inoltre ho ottimizzato il codice in modo
che accelerasse all'avvicinarsi al magnete.

Poi ho fatto in modo che si potesse
spegnere il magnete premendo un pulsante

mantenendo però la velocità
del personaggio, librandolo in aria.

Quindi se inserisco una
piattaforma qui sopra

posso attirare il personaggio
verso il magnete,

lasciarlo andare e poi saltarci sopra.

Non è male... ma è un po'
difficile da controllare.

Forse il codice non è perfetto, le cose
sfuggono di mano abbastanza facilmente.

Ma mentre facevo
delle ricerche a riguardo,

mi sono imbattuto in qualcosa
di molto utile che c'è in Unity.

È un componente nativo chiamato
Point Effector,

che è fondamentalmente...
un campo magnetico.

Non so come mi sia sfuggito, la sua icona
è letteralmente un magnete.

Ecco come funziona.

Associate un collider ed un Point Effector
ad un GameObject,

e poi definite una forza d'attrazione.

Ora quando un rigidbody sarà nel collider,
sarà attratto verso il centro del campo.

Inoltre potete usare il sistema
di maschere di livello di Unity

in modo da attrarre solo
determinati oggetti.

Questo avrebbe certamente reso
più facile la creazione del gioco,

così ho decido di rifare il prototipo.

E, sì, il gioco è risultato più solido.

È più facile fare delle modifiche
e mi permette di fare così fighe tipo...

se aggiungo un punto d'attrazione ai poli
del magnete, succede questo - e non è male.

Ma quando ho creato questo secondo
prototipo, per qualche motivo,

non so bene perché,

ho deciso di non usare Mario come
personaggio

e di rimpiazzarlo con l'immagine
di un magnete.

E questo mi ha dato un'idea:

e se il personaggio non fosse magnetico
ma ci fosse un magnete nel mondo di gioco?

E il personaggio potesse avvicinarsi
e raccogliere il magnete?

Per farlo ho usato il sistema nativo
di Unity dei Joints, un altro componente.

Questo permette di collegare due rigidbody
usando vari tipi di giunto

come carniere (Hinge) e molle (Spring).

Quindi ora il personaggio
trasporterà il magnete

che, se attratto da un pezzo di metallo,
porterà con sé il personaggio.

Finché non lo lascerete andare
e sarete di nuovo liberi di muovervi.

E il gameplay che volevo in origine,
dove si usava la traiettoria del magnete

per lanciare il personaggio verso
una piattaforma più alta,

può essere ottenuto semplicemente
lasciando andare il magnete a mezz'aria.

Inoltre permette molte altre cose, come
usare due magneti o più.

E potreste, ad esempio, posizionare
il magnete qui sopra,

farvi inseguire da un nemico, disattivare
il magnetismo e... splat!

Oh, questa in effetti non è male.
Potrebbe funzionare.

Improvvisamente il gioco sembrava
molto più interessante

rispetto alla mia idea originale
che, devo ammettere,

iniziava a preoccuparmi un po'.

Se il vostro personaggio è magnetico
e viene attratto e respinto,

è facilissimo sentirsi
un po' fuori controllo.

Mentre con un magnete
come oggetto separato

ci sono momenti in cui si ha
il controllo totale del personaggio

mentre si è un po' fuori controllo
quando si trasporta il magnete.

Inoltre ero preoccupato
dalla carenza di idee

per un gioco in cui
il personaggio è magnetico.

Ma non appena ho avuto
due entità separate,

le idee hanno cominciato a fluire.

Inoltre adoro i giochi in cui
si fa avanti e indietro

tra due diverse tipologie di gameplay.

Pensate a come cambia Mario Odyssey
in base alla presenza del cappello.

Nel mio gioco il personaggio è agile e può
saltare molto in alto senza il magnete,

mentre è lento e pesante
quando lo trasporta -

ma ovviamente quel magnete
apre un mare di opportunità.

Non dovrei essere sorpreso che sia
emersa un'idea ancora migliore

durante la prototipazione.

Come abbiamo visto nell'episodio di GMTK
'The Games That Designed Themselves',

è abbastanza comune che emergano nuove
idee durante la prototipazione.

Pensiamo al gioco
Crypt of the Necrodancer:

nel progetto originario del gioco,
avrebbe dovuto essere un roguelike

con un esiguo margine di tempo
tra un turno e l'altro.

Ma durante lo sviluppo
i designer si sono accorti

che sarebbe stato ancora più
interessante se, al posto del timer,

ci fosse stato il ritmo di una canzone.

Quindi i prototipi non sono solo un modo
per testare e provare la validità di un'idea:

sono un modo per generare idee
nuove e migliori.

Durante questa fase ho fatto un'altra
interessante scoperta in Unity:

questo si chiama Sprite Shape.

E viene generalmente usato quando si
vuole fare del level design organico,

come nei giochi di Ori,

ma nel mio caso l'ho usato
per ottenere un colore uniforme

che mi ha permesso di fare
un rapidissimo level design.

Ho potuto assemblare
l'area di un prototipo

usando delle semplici maniglie
come in Photoshop.

E così ho ricostruito il prototipo

e questa volta ho voluto che il personaggio
fosse un po' più facile da controllare,

qualcosa di più simile ad un vero
personaggio dei videogiochi.

Non volevo rimanere impantanato nella
programmazione di movimenti e salti,

così ho scaricato da internet uno script
per il controllo del personaggio.

Funziona benissimo,

così in futuro potrò concentrarmi nel
migliorarlo, rifarlo o quant'altro.

Per ora non voglio dedicarci altro tempo.

In questo prototipo ho anche iniziato
a vagliare altre meccaniche

come il poter lanciare e richiamare a sé
il magnete come Thor e il suo martello.

E dato che il rigidbody del magnete
rimbalza sul rigidbody del personaggio,

darà un piccolo feedback
quando lo acchiappate.

È una sensazione di libertà ludica.
Bellissimo.

E poi ho pensato a vari scenari in cui
si può usare il magnete,

come lanciarlo contro un muro
per creare una piattaforma.

Magari collegarlo ad un pistone per poi
slacciarlo al momento giusto per farlo volare.

Magari invertire la sua polarità per
saltare tra due nastri trasportatori.

O ancora: abbassare questa piattaforma,

salirci sopra e poi cambiare la polarità
del magnete per lanciarsi in aria.

Whoa, non è niente male, vero?

Sembra proprio un videogioco.
È divertente!

Ed è stato il momento in cui ho sentito
che questa idea aveva del potenziale.

È originale: ho visto molti giochi basati
sul magnetismo, ma niente di simile.

Permette un gameplay basato sia sul
platforming sia sui rompicapo.

Sento che le idee per questo gioco
fluiscono così facilmente

che sarà possibile creare
molti livelli diversi.

E, soprattutto, è davvero divertente
da giocare.

Mi basta entrare in questa scena su Unity,

prendere un controller,
ed è tutto davvero piacevole.

È sicuramente un ottimo segno.

È questo il potere dei prototipi:

potete usarli per verificare se l'idea per
un gioco è effettivamente buona.

E se siete davvero fortunati,

potreste veder emergere nuove idee
durante questa fase di prototipazione.

Credo sia necessario un certo livello
di disciplina:

al momento non dovete concentrarvi
su nient'altro, solo il gameplay.

Ed è difficile.

In questo video non vi ho mostrato l'intera
settimana passata sugli effetti particellari,

gli shader, gli elementi dell'interfaccia
e cose così -

Sono ricaduto nella vecchia abitudine
di essere distratto e rapito

da cose che al momento
non sono importanti.

Ma per fortuna me ne sono reso conto e
ho cestinato quel prototipo

prima di tornare alle cose importanti.

E in definitiva penso che
abbia funzionato:

ho finito col creare qualcosa che
credo sia davvero divertente,

che abbia del potenziale, e sul quale
sono entusiasta di lavorare.

I giochi precedenti che ho cercato di
creare quando ero più giovane,

si basavano su una sorta di cieca speranza
che il gioco fosse divertente,

che non è il modo più incoraggiante
per creare un gioco.

Ma ora sento di star costruendo
su delle basi davvero solide

e ora tutti gli altri aspetti - la storia,
la musica, la grafica -

possono essere costruiti sapendo che
le fondamenta sottostanti sono solide.

E così credo che sia questo il modo
per iniziare a creare un gioco:

costruire un prototipo.

Resta solo una domanda:
poi cosa diavolo faccio?

Immagino che lo scopriremo
la prossima volta,

nel prossimo episodio di Developing.

Grazie mille per la visione,

e spero di rivedervi alla prossima
tappa di questo viaggio.

Arrivederci.

L'idea mi è venuta da questo gioco,
The Legend of Zelda: Oracle of Seasons.

Dannazione. Da questo gioco. Oops.

Da questo gioco.

Mi è venuta da questo gioco.

questo gioco.

questo gioco.

questo gioco: The Legend of Zelda:
Oracle of Seasons.

venuta da

L'idea mi è venuta da questo gioco:
The Legend of Zelda: Oracle of Seasons.

Questa era ottima.