Skip to content

Paolo's Blog Posts

Fai il lavoro, anche se nessuno ti paga ancora

Published by Paolo Gambardella on 27/05/2026

Oggi è diventato difficilissimo entrare in un settore quando ne sei fuori. E vale doppiamente per il videogioco, soprattutto se non sei geograficamente in posizione vantaggiosa; lontano da Londra, Montreal, Amsterdam, o da qualunque hub del momento.

Sognare va bene. Ma uno deve essere pratico.

La miglior forma di trovare lavoro è averlo già. Un portfolio che parla, un progetto reale da mostrare, una voce riconoscibile. Se non hai lavoro, devi inventartelo.

Stare seduto a mandare curriculum e aspettare risposte non è una strategia. È un modo per sentirti occupato mentre in realtà stai fermi. È meglio usare quel tempo per lavorare su un progetto personale: un prototipo, una analisi pubblica, una serie di post, qualcosa che esiste nel mondo.

I momenti senza ingresso nel settore sono momenti da usare, non da subire. Sviluppa la tua voce. Costruisci cose. Parla di quello che stai imparando.

Ti servirà dopo. Credimi.

Come si giustifica un gioco nel 2026

Published by Paolo Gambardella on 26/05/2026

Io e Eduard stiamo lavorando a un progetto indipendente, dato che siamo in un momento in cui possiamo far portfolio. Se è la prima volta che leggi queste righe, sono un consulente di game design specializzato nella fase di ideazione e pre-produzione di nuovi giochi mobile casual f2p. Eduard è il mio assistente, arrivato da poco grazie ad un bootcamp nel quale il sottoscritto insegnava. La collaborazione sta andando a gonfie vele, ma come sempre ci sono momenti in cui si ha un carico di lavoro inferiore.

Il progetto nuovo si chiama RETROFP per il momento, ed è un’idea che mi gira in testa da un po’: prendere il metodo Habby (trovare un metagioco comune a vari titoli e cambiare solo il core) e portarlo su Steam applicandolo ai classici che ci hanno formato.

Abbiamo definito e realizzato un primo prototipo dal quale abbiamo imparato, ora siamo sul secondo. È un modo anche per formare il mio collaboratore, quindi ci prendiamo il nostro tempo. In questi giorni mi sto chiedendo: perché questo gioco, adesso?. Oggi credo che questa domanda non è più opzionale e si può scomporre in tre parti.

Cosa prometti al giocatore?

Si tratta di fantasia e di identità: chi diventa il giocatore mentre gioca?

  • Su RETROFP, il primo gioco è ispirato a F-Zero, ma è rally futuristico. La scelta più radicale che abbiamo fatto è questa: la macchina non sbatte mai. Non si perde. Si va solo più o meno veloci, e basta.
  • F-Zero è un gioco sulla velocità da sopravvivere. Il nostro è un gioco sulla velocità da abitare. La fantasia non è “reggi la pressione e vinci”, ma “niente può fermarti, cerca la vetta”. Velocità come espressione, non come rischio.

L’idea è dunque quella di lasciare i giocatori liberi di sperimentare con le fisiche. Nella nostra immaginazione, sarà un gioco piacevole da riprodurre dal vivo per un pubblico di fan. Stiamo facendo una serie di prototipi su questa fantasia.

Dove sei sullo spettro tra familiare e nuovo?

I giocatori vogliono sempre novità, ed ogni gioco si posiziona su uno spettro. Da un lato, troppo familiare: sparisce nel rumore, nessuno ha un motivo per sceglierlo rispetto a ciò che già esiste. Dall’altro, troppo nuovo: nessuno capisce cosa sta guardando, il costo cognitivo di avvicinarsi è troppo alto.

  • RETROFP ha molti elementi familiari: il racing, il metagioco di sblocco, gli eventi live. Gli elementi nuovi sono più precisi: nessun crash, un framework stile Habby applicato a Steam (praticamente inesistente in quella forma), un core che cambia per ogni titolo all’interno dello stesso ombrello.
  • Il pattern è ricombinazione: un meccanismo collaudato portato dove non è mai arrivato.

Il rischio non è solo nel design, ma anche nel marketing e comunicazione. “Non sbatti mai” corre il rischio di arrivare ad essere percepito come “troppo facile”. Una delle risposte che stiamo cercando nei nostri prototipi è anche quella di anticipare possibili obiezioni da parte dei nostri potenziali giocatori e diffusori del gioco (giornalisti, streamer, etc).

Perché tu, perché adesso?

Una buona proposta risponde a due domande distinte che spesso vengono confuse tra loro. La prima è il perché commerciale: perché qualcuno dovrebbe comprarlo? Che spazio occupa nel mercato? Perché adesso? La seconda è il perché artistico: perché voi fate questo gioco? Cosa volete che il giocatore senta che altri giochi non gli stanno dando?

  • Per RETROFP, il perché commerciale è lo spazio vuoto tra il mobile engagement di Habby e la qualità indie di Steam. Quel territorio è quasi deserto secondo la mia osservazione.
  • Il perché artistico è diverso: vogliamo che la gente senta la fantasy di F-Zero ma vogliamo che la velocità sia un regalo e non un rischio aggiunto.

La domanda “perché questo gioco?” non è una domanda per i publisher. È una domanda per te, prima di tutto. E se non hai ancora la risposta, è meglio scoprirlo adesso.

Augurateci buona fortuna!

Il presente è cross-functional, il futuro high-quality

Published by Paolo Gambardella on 25/05/2026

Le store sono sommerse da giochi. Lo vediamo tutti, ed è una conseguenza diretta di qualcosa di ovvio: fare un gioco semplice è diventato rapidamente accessibile. Godot, Unity, asset store, AI per il codice, tutorial su YouTube per qualsiasi cosa. Il tempo di sviluppo si è compresso in modo brutale. E allora lo fanno tutti.

Il risultato è un diluvio. Cloni, giochi generati con pipeline semi-automatizzate, prodotti assemblati più che progettati. Ognuno di questi giochi ha la stessa caratteristica: è fatto in fretta, con un team piccolo o da soli, con poco investimento per unità.

Quando tutti fanno la cosa facile, la cosa difficile acquista valore. Lo sta dimostrando finanche Roblox, con la sua nuova strategia di dedicarsi ai giochi HD. Se i giochi semplici diventano commodità, allora i giochi che richiedono qualcosa che non si genera automaticamente diventano rari.

Il punto che mi sta occupando la testa

Le squadre del futuro prossimo hanno una caratteristica nuova: possono essere davvero cross-functional. Non nel senso buzzword che sentiamo nelle aziende da anni. In modo concreto, pratico, radicale.

Facciamo degli esempi.

  • Un designer non deve più aspettare un programmatore per costruire un prototipo. Con gli strumenti di oggi, può costruire qualcosa di funzionante in ore. Può testare il suo loop di gioco prima che il meeting con il tech team sia messo a calendario.

  • Un artista può implementare direttamente in engine senza aspettare il supporto dei tech artist. L’artista che capisce un po’ di come funziona il motore non è più un’eccezione esotica, è una risorsa normale.

  • Un writer può testare la propria narrativa in una build funzionante senza aprire un ticket e aspettare che il team di gameplay “apra uno slot nel prossimo sprint”.

Non spariscono i ruoli. Sparisce l’alibi.

Attenzione: non sto dicendo che i ruoli specializzati diventeranno inutili. Un tech artist esperto fa cose che un artista con shader graph non farà mai. Un programmatore senior risolve problemi che un designer con un AI coding assistant non riesce neanche a formulare.

Il punto è diverso. La barriera di trasferimento tra ruoli si abbassa. E con quella barriera sparisce anche la scusa più comoda dell’industria: questa non è mia responsabilità.

Se prima potevi stare in una nicchia confortevole e aspettare che qualcun altro facesse la sua parte, oggi il contesto sta cambiando. Il team che si siede ad aspettare il “blocco del programmatore” quando il designer potrebbe prototipare, o il “blocco del tech artist” quando l’artista potrebbe implementare, è un team che sta sciupando tempo in modo artificiale.

L’agilità non è un valore astratto. È la capacità concreta di portare un’idea dal cervello a uno schermo funzionante nel minor tempo possibile, con le risorse disponibili. Oggi le risorse disponibili sono cambiate.

La cosa difficile da copiare

C’è una domanda sottostante a tutto questo: cosa non si può automatizzare o clonare?

La risposta che mi sono dato è: un team che funziona davvero bene insieme, su una visione che vale davvero la pena sviluppare, con abbastanza competenze sovrapposte da non dipendere da nessun singolo collo di bottiglia.

Quella combinazione non si può copiare. Impossibile da generare con un prompt.

Ed è esattamente quella combinazione che serve per fare i giochi che, nei prossimi anni, avranno più speranza. Cosa vuol dire? Che le aziende più furbe saranno capaci di ritenere talento, non trattarlo come bestie da soma per poi licenziare tutti a titolo pubblicato.

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.

Powered by