Skip to content

Author: Paolo Gambardella

Breve guida di sopravvivenza per designer junior

Published by Paolo Gambardella on 22/05/2026

Ieri sera ero al BCN Gamedev Society, un incontro mensile di sviluppatori di giochi di Barcellona. Ho parlato con molte persone e reincontrato vecchi amici. Ho anche avuto modo di dialogare con diversi junior che vogliono entrare nell’industria, concept artist e game designer. Tutti con un problema in comune: come si ottiene esperienza se nessuno ti assume perché non hai esperienza?

Non è una domanda nuova. Ma oggi ha una risposta diversa rispetto a dieci anni fa.

Il codice si sta riscrivendo

Ho letto un post su LinkedIn che mi ha fatto riflettere. L’idea di fondo era questa: il denaro è sempre stato il codice con cui la società trasformava il tempo umano in qualcosa di leggibile dai sistemi.

  • Hai un’abilità → diventa un salario.
  • Hai una necessità → diventa un prezzo.
  • Hai un futuro → diventa credito.

Il problema è che il denaro è un sistema a “bassa risoluzione”. Può misurare il rendimento, non il senso. Può premiare l’output, non l’orientamento.

E adesso l’IA sta smontando esattamente quella promessa: se creare varianti di asset grafici, fare QA su scenari ripetitivi, o mediare informazioni tra team sono cose che le macchine fanno meglio. Cosa rimane al junior che stava imparando facendo esattamente quelle cose?

Il problema concreto

Facciamo un esempio reale. Un junior concept artist vuole entrare nell’industria. Ha studiato, ha un portfolio decente. Ma uno studio sceglie spesso un senior che, con ComfyUI e prompt ben costruiti, produce in meno di una giornata quello che il junior farebbe in una settimana.

L’esperienza la si accumula facendo, ma se i lavori “di ingresso” vengono automatizzati, dove si impara? Come fare per imparare per osmosi in questa nuova realtà?

Consigli di sopravvivenza

Ho alcune idee concrete.

1. Smetti di competere dove l’IA vince.

L’IA vince sulla velocità di produzione, sulla consistenza, sulla variazione infinita. Non vince sul gusto, sulla direzione artistica, sull’intuizione di cosa funzionerà con quel giocatore, in quel contesto culturale, con quel tono emotivo.

Se il tuo portfolio mostra “so redigere un GDD velocemente”, sei nel territorio sbagliato. Se mostra “so scegliere, curare, dirigere e so spiegare perché una scelta funziona”, hai molte più speranze secondo me.

2. Pubblica cose piccole fatte con altre persone

Un game designer junior con cinque piccoli giochi su itch.io fatti in una squadra vale più di uno con un portfolio di concetti non realizzati. I tuoi risultati dimostrano che hai attraversato l’intero ciclo: idea → prototipo → feedback → pubblicazione.

Questa è esperienza reale, in squadra. E non richiede che qualcuno ti assuma.

  • Game jam per lavorare direttamente con altre persone,
  • progetti personali che poi faremo provare ad altri e prenderemo appunti sul loro comportamento,
  • esperimenti di weekend che pubblicheremo su un Discord pubblico per raccogliere feedback.

L’obiettivo è costruire un track record di decisioni prese in base all’interazione con altre persone e comportamenti osservati nei nostri giocatori.

3. Cerca un senior da affiancare, non una posizione junior.

La dinamica “senior + IA” che sta diventando dominante crea paradossalmente spazio per collaborazioni informali. Un senior con troppo lavoro e pochi junior affidabili è spesso disponibile ad accettare aiuto in cambio di un piccolo investimento economico e mentorship. Non è ideale, ma è come funziona. E se stai vicino a qualcuno con esperienza e giudizio, impari per osmosi. È sempre stato così.

BCN Gamedev Society, community online, Discord di studi indie: questi sono i posti dove quelle conversazioni succedono.

4. Usa l’IA per sviluppare il tuo gusto.

La trappola per i junior è usare l’IA per produrre più cose, e finire per produrre più mediocrità in fretta!

  • Genera 50 varianti con l’IA.
  • Poi scegline una.
  • Sappi spiegare perché.
  • Poi itera.

La tua capacità di giudizio (cosa tenere, cosa scartare, perché) è l’unica cosa che non si automatizza a breve.

5. La sopravvivenza a breve termine è un problema separato.

Non ti dirò che il reddito universale di base arriverà domani a salvarti. Forse arriva, forse no. Nel frattempo ci sono le bollette da pagare.

Alcune opzioni concrete per pagare le bollette mentre costruisci il tuo track record:
– Freelance di gamification per clienti fuori dall’industria (startup, formazione aziendale, educational)
– Content creation: se riesci a spiegare game design in modo interessante, c’è un pubblico
– Tutoraggio, corsi online, workshop locali
– UX writing, product design, narrative design per clienti non-game

Nessuna di queste è la carriera che vuoi, ma sono ponti.

Conclusione

Il paradosso dell’esperienza non è nuovo, ma si sta acutizzando. E la risposta non è accumulare esperienza reale in modo non convenzionale:

  1. fare cose piccole e usarle come strumento per connettersi ad altri
  2. stare vicino a chi sa più di te
  3. sviluppare gusto e saper trasmetterlo agli altri.

Il denaro misura quello che è già leggibile al sistema. Quello che i sistemi non sanno ancora leggere è il gusto. L’intuizione. Il senso di cosa vale la pena fare.

Per ora, quello è ancora terreno nostro.

La differenza tra documento e documentazione

Published by Paolo Gambardella on 21/05/2026

Una delle responsabilità principali di un game designer è quella di scrivere documentazione di design. Chiunque è capace di scrivere documenti, ma un designer si dedica alla documentazione, che è qualcosa di diverso.

Un documento contiene pensieri, idee, qualunque cosa. Una documentazione, invece, è un tipo di documento specifico su qualcosa di concreto. Una ricerca su un gioco competitor. Il risultato di un playtest. Una feature che abbiamo costruito e osservato in azione. Un prototipo che ha risposto a una domanda precisa.

Per capire perché questa regola viene violata così spesso, è utile pensare a come si accumula la conoscenza durante lo sviluppo di un gioco.

Concept DOCUMENTS

All’inizio di un progetto, quasi tutto è incerto.

  • Constraints | Ci sono cose che sappiamo già: la piattaforma target, il genere, magari il budget.
  • Frontiers | Ci sono domande che sappiamo di dover rispondere: come funziona il core loop, quanto dura una sessione tipo.
  • Risks | Ci sono le cose che non sappiamo di non sapere ancora. I problemi di design che emergono solo quando il giocatore ha il controller in mano. Le interazioni tra sistemi che sembravano ovvie sulla carta e si rivelano un disastro in pratica. Le assunzioni che nessuno ha mai messo in discussione perché sembravano così ovvie da non meritare attenzione.

Un concept document vive quasi interamente in quel terzo strato. Non è documentazione, è un’istantanea dell’immaginazione del team in un momento preciso.

Game Design DOCUMENTATION

La documentazione vera emerge dopo. Dopo che abbiamo prototipato e scoperto che la meccanica che sembrava brillante non funziona come pensavamo. Dopo che abbiamo analizzato come un altro gioco ha risolto lo stesso problema. Dopo che abbiamo testato e osservato. A quel punto abbiamo qualcosa da documentare davvero.

Documenti e Documentazione

Un documento serve un obiettivo temporaneo. Gli appunti di una riunione sono un documento. Un concept doc è un documento. Una lista di idee buttate giù prima di una sessione di brainstorming è un documento. Sono strumenti di lavoro validi, necessari, e hanno una durata naturale: servono adesso, poi diventano storia.

La documentazione invece è pensata per durare.

  • Deve essere chiara per qualcuno che non era in quella riunione.
  • Deve essere pratica, un riferimento che si può usare davvero, non solo leggere.
  • Deve ispirare chi la legge sei mesi dopo, quando l’entusiasmo iniziale si è raffreddato e servono appigli concreti.
  • E deve essere attraente: non come esercizio estetico, ma perché se nessuno apre un documento, quel documento non esiste. Io adotto questa formula: 60% dello spazio deve essere occupato da elementi visuali (diagrammi, immagini, video,…). 30% da dati e tabelle. 10% testo. Una documentazione non è un trattato o un romanzo da leggere!

Non tutti i documenti sono documentazione, il progetto richiederà vari tipi di documento. La tua squadra ha bisogno invece di documentazione.

Come appare una documentazione vera

Una buona documentazione di design risponde a poche domande in modo inequivocabile: cos’è questo gioco? Perché è interessante? Qual è la fantasy, la promessa emotiva che fa al giocatore? Quali sono le feature core, non tutte le feature, solo quelle che definiscono l’identità del prodotto? Come funziona esattamente questo sistema? E abbastanza contesto produttivo da rendere il documento azionabile.

C’è un principio che trovo particolarmente utile in questo senso: se un team non riesce a spiegare il proprio gioco in modo chiaro e compresso, probabilmente il design non è ancora abbastanza chiaro. La chiarezza della documentazione riflette la chiarezza del pensiero. Un documento denso, pieno di sezioni e sottosezioni che cercano di coprire ogni eventualità, è spesso il segnale che non sappiamo ancora abbastanza per documentare.

E questo ci riporta alla regola numero 1. Se non hai ancora qualcosa di concreto da documentare, forse non è il momento di scrivere documentazione. È il momento di fare ricerca. Di costruire un prototipo. Di testare. Di rispondere alle domande che ancora non sai di avere. Di imparare e scoprire.

Questo documenta qualcosa che esiste, o qualcosa che vogliamo costruire?

Prototipi per apprendere

Published by Paolo Gambardella on 20/05/2026

I prototipi sono uno dei campi in cui il game design è evoluto moltissimo negli ultimi pochi mesi. I nuovi algoritmi di machine learning e automazione permettono a tutti di essere molto più rapidi a sviluppare artefatti che ci servono per imparare e far imparare alla nostra squadra. Questo è un gran progresso, ma può esasperare una tendenza che ho visto in alcuni team: creare un prototipo troppo sofisticato che si trasformi in una demo.

Il prototipo serve ad imparare, a rispondere domande. Una demo serve a convincere, ad avere greenlight, a vendere. Il problema sorge quando si crea un prototipo troppo raffinato da sembrare convincente, ma troppo ambiguo da poterti dire che stavi imparando. Finisci per non imparare nulla e non convincere nessuno.

Faccio un esempio pratico. Se è la prima volta che leggi queste righe, devi sapere che sono un consulente di game design specializzato in ideazione e pre-produzione di nuovi videogiochi soprattutto free-to-play. Ho un piccolo studio e con i miei aiutanti la settimana scorsa abbiamo creato questo prototipo usando Godot:

  • Il progetto è iniziato lunedì con una visione che ho da tempo che ho concretizzato in un documento di visione
  • il mio assistente Eduard ha ricercato altri giochi e mercoledì mi ha consegnato un concept document
  • Il giovedì ho dato questo documento in pasto a Claude Code e gli ho detto di generarmi un prototipo di base
  • Da venerdì a domenica ho fatto brevi interventi in base ad idee che mi venivano in mente mentre facevo altro.

Dopo aver consegnato il risultato al mio assistente, lo ha provato per un giorno intero e mi ha dato il suo punto di vista. La discussione si è mossa moltissimo verso problemi tipo “il track generato è monotono”, o “non riesci a scontrarti con le auto”. Tutte cose che valgono dalla demo in poi, ma non in questa fase. In due persone, discutendo, siamo riusciti ad identificare l’apprendimento reale, cosa ci piace di questo prototipo. Lo mettiamo da parte, lo documentiamo, e passiamo alla prossima fase di apprendimento.

Se non fossimo stati in due, se fossimo stati in un’azienda più grande, probabilmente avremmo dovuto anche preparare una presentazione con i learnings per allineare. È così che a me piace procedere, ma vi dico: la tentazione di voler risolvere i problemi tecnici o migliorare le “intelligenze” artificiali degli avversari virtuali è stata grande. Perchè? Perchè ora è facile, è rapido.

Tu puoi farlo, ma anche il tuo competitor può. Per me vince chi si centra nelle cose giuste al momento giusto. Oggi più che mai è necessario discernimento, un contatto mi ha detto che su Apple Store i tempi di approvazione si stanno allungando moltissimo data la quantità di app “vibe-coded” che stanno arrivando ai moderatori. Se dobbiamo attendere di più per le nostre approvazioni, tanto vale farlo su qualcosa di cui valga davvero la pena.

Viene una buona epoca per il game design

Published by Paolo Gambardella on 19/05/2026

Negli anni del boom del free-to-play per mobile, questo settore dell’industria del videogioco venne rapidamente dominato dal product management. Da un lato si capisce, dato che il business del free-to-play è centrato nell’acquisizione di giocatori, quindi nel performance marketing. Se il costo di acquisire un giocatore è inferiore ai soldi che in media vengono investiti da un giocatore nel gioco stesso, hai un business che funziona.

Quindi, lavorare da game designer per queste realtà diventava molto spesso un discorso puramente basato in dati. Io stesso mi sono più volte ritrovato a discutere con i miei capi per questioni che possiamo riassumere come: il mio gusto VS la realtà corrente del mercato. Faccio un esempio pratico: se per me, designer, una certa fantasia doveva essere espressa attraverso determinate meccaniche perchè avevo il sentore che avrebbe funzionato, la risposta di default era: “ok, e questa cosa dove l’hai vista? In quali altri giochi?”. Molto spesso era qualcosa che veniva piuttosto da un’esperienza personale, o altro. Magari un’app, o un film, o una mostra che avevo visitato mi dava un’idea. Niente, dovevo trovare assolutamente la maniera di spiegarlo con dati.

E infatti, i designer che poi hanno fatto più carriera in quel settore molto spesso si auto-definiscono data-driven. Sono capaci di ricercare ciò che è già presente nei giochi di successo e riapplicarlo tipo formula matematica al gioco su cui lavorano. Tanto di cappello, bella capacità, ma per me un designer deve sí avere un senso del contesto di business, ma anche un gusto. Per me, già che siamo quì a metterci tanta energia tanto vale creare qualcosa di nuovo, metterci del nostro. Alla gente piace quando hai qualcosa da dire.

Secondo me è il nostro momento, adesso. Voglio dire, è il momento dei designer che vogliono esprimere il loro gusto. Secondo me il data-driven design è morto. In realtà era sempre stato un lavoro ripetitivo e molto poco creativo, ma credo che nell’epoca dell’IA dove un agente fa tutto questo in molto meno tempo e per una frazione del prezzo, è meglio coltivare piuttosto il nostro gusto. Meglio guardare film, studiare altri tipi di app, andare a mostre. Meglio, insomma, cercare davvero la nostra voce.

Ciò in cui credo, e in cui ho sempre creduto, è il data-informed design. Un designer che si rispetti deve sempre cercare di empatizzare con i giocatori, e non c’è miglior modo che raccogliere dati. Ma questo non deve condizionare il nostro gusto, altrimenti offriremo sempre cavalli a chi ha bisogno di qualcosa di nuovo, tipo una vettura ai tempi di Ford. Un designer non può andare alla cieca.

Ma un game designer deve avere la possibilità di creare, di apportare qualcosa di nuovo per il mondo. È assurdo contrattare persone per ripetere formule, e secondo me questa cosa è condannata a sparire, perchè ora abbiamo l’algoritmo giusto. Algoritmo che ci permette di concentrarci su ciò che davvero conta.

Powered by