Skip to content

Category: 🇮🇹 IT route

MailPoet routing — do not delete

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