The Games That Designed Themselves

È quasi impossibile immaginare il gioco Ape Out senza una scimmia.

Eppure è proprio così che è nato.

Secondo il designer Gabe Cuzillo, avrebbe dovuto essere un gioco stealth con loop temporali.

in cui si potevano usare le meccaniche 'spingere' e 'afferrare' per strisciare lungo i muri.

Ma se nel gioco ci fossero state delle guardie,

di conseguenza dovreste aver avuto la possibilità di usare le stesse meccaniche contro di loro,

generando un gameplay in cui si possono prendere le guardie in ostaggio

e scaraventarle contro i muri.

Questa si è rivelata la parte più interessante del gioco

e così Gabe ha deciso di cambiare bruscamente direzione e costruire il gioco attorno a questo concept principale.

Ha rimosso tutto il superfluo, come lo stealth e i loop temporali.

E fatto tutto il possibile per enfatizzare questa idea,

in particolare sostituire il tizio calvo con uno scatenato gorilla di 150 chili.

Questo è un esempio di metodologia di game design chiamata "Follow the Fun" ["Segui il divertimento"]

È l'idea apparentemente semplice per la quale i designer dovrebbero ignorare piani e idee preconcette,

e osservare invece il gioco stesso per scoprire come dovrebbe proseguire lo sviluppo.

Prendete ad esempio quella minuscola gemma di tatticismo che è Into the Breach.

Questo titolo è stato concepito come un comune gioco in stile 'Advance Wars'

in cui i nemici attaccano casualmente e celano le proprie intenzioni fino al loro turno.

Se non per il fatto che il nemico avrebbe mostrato esattamente cosa avrebbe fatto durante il suo turno,

evidenziando la casella che avrebbe attaccato.

Gli sviluppatori di Subset hanno capito che questa era la parte più divertente

e hanno deciso di basare il resto del gioco quasi esclusivamente su questi attacchi telegrafati.

E questo ha contribuito a definire le rimanenti decisioni di design che lo studio doveva prendere.

Perché se sapete cosa faranno i nemici,

non sarebbe sufficiente muovere le vostre unità fuori dalla loro zona d'attacco?

Giusto, allora forse il gioco consiste nel proteggere degli edifici statici.

E così ora si tratta di spingere via i nemici affinché i loro attacchi falliscano.

Ma in realtà potreste farlo in modo che i nemici si uccidano l'un l'altro.

Potete capire perché i designer che usano questo metodo dicono che il loro gioco,

in parte, si è progettato da solo.

Ecco Sam Coster di Crashlands, sviluppato da Butterscotch Shenanigans.

"Ci piace pensare a questo processo come al gioco che scopre se stesso nel tempo.

Perché come iteratori, piuttosto che designer, il nostro compito è semplicemente giocare

ascoltare il gioco, sentirlo, e in un certo senso percepire cosa vuole diventare

e poi seguire il sentiero di ciò che è divertente."

Ora, l'idea che un gioco si progetti da solo

è sicuramente eccitante per coloro che ambiscono a creare il prossimo grande successo.

Ma le grandi idee per i giochi non appaiono semplicemente dal nulla.

Quindi da dove provengono?

Beh, diamo uno sguardo alle origini del roguelike ritmico Crypt of the Necrodancer.

Il designer Ryan Clark volle vedere se fosse possibile riutilizzare il rapido decision-making di Spelunky

in un più tradizionale dungeon crawler a turni.

Creò quindi un veloce prototipo di roguelike

in cui avete solo un secondo per compiere il vostro turno.

Giocandolo, Ryan scoprì che aveva una qualità quasi ritmica,

e divenne ovvio che il gioco avrebbe dovuto basarsi sulla musicalità.

O magari dovremmo dare uno sguardo all'iconico movimento a mezz'aria di Rocket League.

Quando Psyonix stava lavorando al predecessore del gioco, Supersonic Acrobatic Rocket-Powered Battle-Cars,

(da allora hanno imparato molte cose sul marketing)

costruirono un gioco su delle macchine che combattono,

ma volevano aggiungere una meccanica sull'aumento della velocità.

Gli sviluppatori applicarono semplicemente una forza fisica al retro della macchina.

Durante i test, scoprirono che i giocatori avrebbero potuto usare questa forza a mezz'aria

per muoversi come razzi per l'arena.

Non era nei piani, ma gli sviluppatori capirono che aggiungeva al gioco un'enorme profondità

e un'ulteriore dimensionalità al gioco - e così decisero di tenerla.

Lo studio afferma: "abbiamo sviluppato questa meccanica quasi per caso."

In effetti, c'è un'intera bibliografia di giochi in cui bug, glitch e incidenti durante il processo di sviluppo

si sono trasformati in qualità.

Ad esempio, Hideki Kamiya trovò un bug in Onimusha: Warlords

che vi permetteva di lanciare in aria i nemici colpendoli ripetutamente.

Era divertente così Kamiya lo sviluppò ulteriormente,

trasformandolo nella meccanica principale di Devil May Cry.

Il punto è:

questo processo implica prendere un'idea iniziale - per quanto vaga, confusa o banale che sia -

e costruire un prototipo funzionante.

Ed è qui - durante il processo di codifica e gioco - che possono nascere nuove idee.

Sta quindi al designer essere aperto e attento a ciò che dice il gioco.

Capire cos'è interessante ed essere disposto ad esplorare tali aspetti,

anche se non si accordano del tutto a ciò che avevate in mente originariamente.

È così che Gunpoint è passato dall'essere un robot nello spazio che fa cadere frighi sulle persone,

all'essere un puzzle game su una spia che ricabla edifici.

Questa meccanica di ricablaggio era solo una possibile idea per un mini-game di hackeraggio

in un gioco a scorrimento laterale ispirato a Deus Ex.

Ma non appena il designer Tom Francis iniziò a prototipizzarlo,

il gioco che sarebbe diventato Gunpoint iniziò ad emergere.

Ecco Tom:

“Divenne subito palese che sarebbe dovuto diventare un puzzle game.

Era solo una meccanica per enigmi.

E così Gunpoint in un certo senso mi disse ciò che voleva essere.

Voleva palesemente essere un puzzle game.

E così ho fatto, ho solo ampliato enormemente la meccanica di hackeraggio.

Ci ho costruito attorno l'intero gioco."

Quindi questo processo in genere innesca i cambiamenti più significativi

verso l'inizio dello sviluppo del gioco,

il punto del gioco che Sam Coster descrive come una palla bianca e calda di magma malleabile.

Ma può comunque essere usato durante lo sviluppo, quando il gioco comincia ad avere una forma e a solidificarsi.

Come per la generazione di contenuti:

Jonathan Blow ha detto che gli enigmi di Braid

erano semplicemente una vetrina per le conseguenze inaspettate del suo game engine per i viaggi nel tempo.

Blow dice: "Avevo un ruolo da curatore.

Ripulire le risposte e presentarle in modo tale che potessero essere apprezzate dai giocatori."

Approfondimenti su questo video.

O può essere usato per ascoltare i feedback dei giocatori.

Mentre Chris Hecker creava SpyParty,

i giocatori trovavano ogni sorta di exploit e modi imprevisti di giocare.

Invece di correggere questi "bug", Chris li assecondò, rendendoli una vera e propria parte del gioco,

trasformando l'esperienza in qualcosa di più simile ai giochi mentali e ai trucchi psicologici.

E può essere usato come guida durante lo sviluppo generale di un gioco.

Ecco il designer di Subnautica, Charlie Cleveland:

"Pensi di sapere dove stai andando.

C'è un luogo all'orizzonte.

E ci sono molti percorsi e non sai come arrivarci.

Ma se ascolti il gioco, ti dirà dove vuole andare."

È così che il suo studio fece un gioco horror, senza che fosse l'intenzione all'inizio del progetto.

Ovviamente un simile processo di design rende molto difficile prevedere quanto durerà lo sviluppo.

È una delle ragioni per cui questa metodologia è più popolare nel mondo degli indie

piuttosto che nel mondo ferocemente irreggimentato delle grandi produzioni.

Come quando Tom Francis creò il suo secondo gioco, Heat Signature,

sperando che la vaga idea del "andare dentro le astronavi" si tramutasse magicamente in qualcosa di buono

proprio come accadde con Gunpoint.

Ma... non fu così. Almeno non per molto tempo.

In verità, Tom si rese conto di dover creare moltissime cose per scoprire cosa rendeva il gioco interessante,

protraendo così i tempi di uno sviluppo in cui progettò un sistema per la generazione delle navi,

l'intelligenza artificiale, un sistema di combattimento, un'intera mappa della galassia con un'economia, e così via.

Tom impiegò anni per capire che il combattimento a bordo era la parte più interessante.

Ed è per questo che è meglio ricordare che la frase reale

è un po' più lunga di "Segui il divertimento".

Ho ripercorso l'etimologia della frase fino a questo tipo: Marc LeBlanc.

È un designer che ha lavorato su Thief e System Shock,

ed un insegnante che ha contribuito ad idee come il framework MDA.

Quando coniò questa frase, in realtà iniziò con una nota espressione

proveniente dal mondo del design e dell'imprenditoria: "fallisci veloce".

È il processo per cui si compone velocemente qualcosa per vedere cosa funziona e cosa no.

Non è grave se fallite perché non avrete sprecato molto tempo,

e il cosiddetto "fallimento" vi dirà molto sulla direzione che dovrebbe prendere il prossimo tentativo.

Ci sono quindi delle tecniche concrete per accelerare il processo di iterazione?

Beh, una dovrebbe essere familiare agli spettatori di GMTK: le game jams.

Quelle frenetiche maratone di creazione di giochi

in cui dovete provare a creare un gioco in, forse, un solo weekend.

Arvi Teikari, che ha ideato il pluripremiato puzzle game Baba Is You durante una Game Jam,

parla del potere di questi eventi:

"L'idea è prendere un prototipo che hai in mente e provare a costruirci qualcosa attorno."

Se non funziona, poco male, puoi gettarlo alla fine della game jam.

Non sei legato all'idea oltre il tempo dedicato alla game jam."

Un'altra tecnica è usare strumenti che permettano una prototipazione rapida, come Game Maker e Godot.

O magari dei prototipi su carta, LEGO, o la suite per la creazione di giochi su PS4 Dreams.

Se avete già creato gran parte del gioco e volete solo generare dei contenuti,

potete sviluppare degli strumenti per la creazione di livelli per accelerare il processo creativo,

e coinvolgere più persone che possono aiutarvi.

Per Mario Galaxy 2, Nintendo creò dei semplici strumenti di creazioni di livelli

per incoraggiare tutte le persone del team ad ideare meccaniche uniche.

E per focalizzarvi velocemente su design e meccaniche, potete usare grafica, musica e trama temporanee.

Quando Klei creò il primo prototipo di Don't Starve per una game jam,

l'eroe del gioco era rappresentato da...

Link, di Zelda.

E infine, può aiutarvi avere un aspetto del gioco che non può assolutamente cambiare.

Sunni Pavolic di thatgamecompany dice che lo studio usò una metodologia molto iterativa per creare Journey

ma con l'idea fissa che il gioco avrebbe esplorato il tema dell'amore.

Questo ha dato a tutto il team una direzione precisa da seguire,

e ha contribuito a restringere la gamma di possibili idee da poter scoprire e sviluppare.

Se c'è una cosa che voglio sottolineare in questo video

è smetterla di aspettare che l'idea perfetta per il gioco si faccia avanti.

È facile pensare a qualcosa come Ape Out, Crypt of the Necrodancer o Crashlands

e presumere che questi giochi siano stati progettati in un lampo di intuizione

che è si è improvvisamente trasformato nel gioco finale.

E quindi se non riuscite a sviluppare un'idea altrettanto buona, perché perdere tempo?

Ma come vi ho mostrato in questo video, nulla potrebbe essere più lontano dalla verità.

In realtà, la cosa che lega tutti questi sviluppatori è l'aver iniziato costruendo qualcosa.

Solo allora, quando i designer hanno provato nuove idee, giocato i loro prototipi e anche creato dei bug,

i giochi che conosciamo oggi hanno iniziato a prendere forma.

Sono grandi designer non perché hanno avuto grandi idee ma perché sapevano come ascoltare il gioco,

sapevano quali strade seguire, sapevano come fallire velocemente e spesso,

e sapevano come fondere queste idee diverse in qualcosa di coerente.

Quindi se guardate Game Maker's Toolkit e pensate che vi piacerebbe creare un gioco

non aspettate l'idea perfetta.

Costruite qualcosa.

Così da poter ascoltare il gioco, seguire il divertimento

e, se siete fortunati, potreste scoprire che il gioco, in qualche modo, si progetta da solo.