Skip to content

Paolo's Blog Posts

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.

AI Slop vs. Creative Power: A Love-Hate Relationship

Published by Paolo on 15/05/2026

I have mixed feelings about the integration of artificial intelligence into our digital spaces. On one hand, public platforms are deteriorating. From YouTube recommendations to mobile game ads, our feeds are flooded with low-quality “AI slop”—clickbait thumbnails and content engineered purely around anger and hyperbole. The internet has become a frantic, exhausting battle for our attention.

Yet, as a creator, generative AI has completely revolutionized my workflow by automating the tedious parts of development:

  • Game Design Documents (GDD): I can instantly generate a robust structural base for 15 GDDs a month without redoing the groundwork every time.
  • Workflow Automation: Converting a massive document into actionable JIRA tasks used to take days; now, it takes an hour of high-level planning and bulk creation.

Beyond productivity, experimenting with these tools has brought back a sense of community. Sharing new AI discoveries in private chats feels exactly like the early days of the internet—reminiscent of finding an old IRC channel or a niche forum.

While the public internet grows increasingly dull due to algorithmic noise, the backend world of AI innovation has unlocked a frontier that is just as exciting as the internet itself once was.

Leveling up in Claude

Published by Paolo on 28/04/2026

Yesterday I was speaking with a design director about how I use Claude AI, and he made me discover a new method of using it, I was totally ignoring. In fact, all this AI hype makes me resistant to novelties, and I have to admit that I often lose opportunities because of that.

I think that it’s a very powerful tool, and my feelings are that I will save up lots of time from repetitive tasks such as creating subtasks in JIRA, setting up pages, summarize information that is already there, and so on. It’s definitely a level up in my career.

Freshness is safer in ideation stage

Published by Paolo on 27/04/2026

When two medics decided to make Baldur’s Gate, they didn’t have experience with CRPGs. When Mr. Myiamoto directed FZero on SNES he wasn’t a veteran in racing games. When a marketing guy from Ubisoft decided to make a realistic-style JRPG together with a programmer, he didn’t have previous experience in the genre.

Still, many companies publish job offers for specific positions requiring previous experience in the specific genre they are developing. It’s because of the belief that higher skill means faster results, and more important, less risks. This happens a lot on high-quality games and mobile F2P, because these business models became managed in a McKinsian way. And that, kids, is why they are in trouble.

Still, games like PRAGMATA are showing that there are audiences eager to new experiences, with unique blends of mechanics. I don’t know their stories, but I am playing the game and I wouldn’t be surprised if among their team there are designers with no previous experience with 3D action-adventure games. Video games like PRAGMATA are only possible when you are open to a completely different perspective, and when you let people work. I believe it’s hard to find this fit if your job offer filters opportunities out.

Experience within a genre is very important, don’t get me wrong. But the more I work, the more I realize I am full of biases. The more experience I get, the more I push for research and playtesting. New audiences are playing in ways often ignored by a big portion of developers, a sort of tunnel vision you have when you make always the same thing over and over.

read more: https://gamedesignskills.com/game-development/stages-of-game-development-process/

This is one of the reasons that led me to be a freelancer, also if it comes with a price as everything good in our life. Probably the worst one is when a client wants me to tell them the hour using their own clock. They close to proposal, because they don’t really understand (and they actively ignore) the opportunities of ideation stage.

A potential use case for Microsoft

Published by Paolo on 24/04/2026

I read the last email that the new CEO of XBox sent to her employees. It is honestly an inspiring take on what’s next for XBOX, I am positive about this person. Maybe the fact she is not a games veteran is good for her actual position. Or maybe I am just a dreamer, I don’t know.

There is one use case that I believe they can tackle pretty “easily”, and position themselves like the platform for everyone they want to become. There are successful f2p midcore titles that occupy too much space on the smartphone. Often they require the latest models to run at the higher quality. I believe that the f2p player doesn’t care of having a copy of what he is playing.

If XBOX manages to become the platform from which you can play the “Genshin Impacts” of the future in cloud on streaming, and maybe engage with mods and UGC for your fav games, there is the chance from them to become THE platform of the future. A sort of Roblox for Mobile f2p games. Of course, there are lots of limitation that may come from Apple and Google. Still, if they manage to do this right, they can really disrupt the market in my opinion.

There is a reading crisis

Published by Paolo on 23/04/2026

Lately I had the opportunity to review a couple of junior profiles, tests and interviews. The main issue I see is that many of them are becoming good at posing but they are also losing reading skills. I am worried, reading is so important to our profession.

During my day I review documents, chat with teammates, receive emails… all those activities involve reading. If I send to a potential candidate concrete instructions in plain English, I can admit interpretation of course. But, if I notice that you simply are ignoring instructions, I deduce that you didn’t read them.

I believe that one of my advantages as a professional are the 5 languages I speak fluently. That open to me lots of doors, because I can show reliability. I can prove with my messages that I am reading you. This is very basic and critical, you shouldn’t (as a designer) improve your technical skills with engines and tools; writing skills are also not more important than listening and reading. If you fail at that, I cannot approve your test.

If you are reading this, congrats, you are a reader. So maybe you are not part of the problem, but you can become part of the solution.

Three loops of Expedition 33

Published by Paolo on 22/04/2026

These days I am playing Clair Obscur: Expedition 33 pretty intensively (when other 40y-old-man-duties permit) these days. And I am also completing my bootcamp on videogames design and conceptualization. A class I gave was based on the 3 main loops of a game, and today I want to apply this knowledge to the 2025 GOTY.

Moment-to-moment (second-to-second)

This first loop is the central one, and it describes what the player does the most. You can say it describes the core dynamic, somehow. In case of Expedition33:

  • Action: Reactive turn-base combat
  • Challenge: groups of nevrons (enemies)
  • Reward: skill points, loot

WHY to repeat this loot: the game is divided in zones within an open world, the Player wants to complete the zone to unlock the next.

Core loop

The core loop is what the Player does the most during the game and gives meaning to the moment-to-moment loop. We can say that it considers the game session as a whole.

  • Action: Improve team stats
  • Challenge: complete zone sections
  • Reward: Advance with the story

WHY to repeat this loot: as any good JRPG it’s about the map! You want to play to unlock new venues and discover new places into the map.

Metagame loop

This loop describes what keeps the Players engaged, what makes them think “I need to return back into the game because I want to…”. Describes the features and mechanics that make me think into the game when I am not playing it. In the case of Expedition33:

  • Action: defeat bosses
  • Challenge: what will happen in the story?
  • Reward: plot twists and secrets discoveries

WHY to repeat this loot: the game is one great adventure story!

Powered by