Ho riscritto Donkey Kong con l'AI
e le botti mi hanno insegnato il progressive onboarding

La prima botte mi ha attraversato la scala come se non esistesse. La seconda si è incastrata a metà, sospesa nel vuoto, tremolante come un bug di rendering del 1996. La terza ha invertito direzione e risalito la rampa verso Donkey Kong, in un atto di ribellione che nemmeno Miyamoto avrebbe previsto. Ho capito subito che ricostruire Donkey Kong per PixelPrompt non sarebbe stato solo un esercizio di pixel art e nostalgia.

Il punto è che la fisica delle botti è solo la superficie. Sotto c'è qualcosa di più interessante: il modo in cui Miyamoto, con 16 KB di ROM e quattro schermi, ha costruito il sistema di onboarding più efficiente che io abbia mai visto. Nessun tooltip. Nessun popup. Nessuna scritta “premi A per saltare”. Solo level design puro.

Quattro schermi che insegnano senza parlare

Donkey Kong ha quattro schermi. Non quattro mondi, non quattro capitoli: quattro schermate singole, ognuna con un lavoro preciso da fare. Ogni schermo introduce esattamente una meccanica nuova. Mai due contemporaneamente. Questo è il cuore del progressive onboarding, e nel 1981 non aveva nemmeno un nome.

Schermo 1, le rampe (25m). Pauline in alto, Mario in basso, le botti che rotolano giù. La gravità racconta tutto: devi salire, devi evitare, puoi saltare. Tre meccaniche core comunicate in un colpo d'occhio, senza una sola parola. Le prime botti arrivano lente, con pause ampie. Il giocatore prova il salto, sbaglia, capisce il timing. Poi la frequenza cresce. Poi le botti iniziano a prendere le scale. La difficulty curve sale, ma il vocabolario è già stato insegnato.

Schermo 2, i trasportatori (50m). Una meccanica nuova: i nastri mobili. Il pavimento si muove sotto i piedi di Mario. Ma saltare e schivare li hai già imparati al piano di sotto. Il gioco aggiunge un solo elemento alla volta. Se avesse buttato dentro trasportatori, nuovi nemici e scale mobili tutto insieme, sarebbe stato un muro.

Schermo 3, gli ascensori (75m). Piattaforme mobili verticali. Ancora una sola novità su fondamenta solide. Il timing del salto (appreso negli schermi precedenti) ora si applica a bersagli che si muovono. Stesso principio, contesto più esigente.

Schermo 4, i rivetti (100m). Qui la struttura si ribalta: non devi più salire, devi rimuovere i rivetti dalla piattaforma camminandoci sopra. Nuova meccanica, ma tutte le skill precedenti (saltare, schivare, calcolare il timing) servono ancora. Il giocatore è stato preparato senza rendersene conto.

«Un buon game designer non spiega mai le regole. Le fa scoprire.»

Shigeru Miyamoto

Il pattern che il software moderno ha dimenticato

Quello che Miyamoto fece con vincoli hardware estremi ha un nome nel product design di oggi: progressive onboarding. Invece di bombardare l'utente con tutte le feature al primo avvio, gliele presenti una alla volta, nel momento in cui ne ha bisogno. Quattro principi, tutti visibili nei quattro schermi di DK:

• Una meccanica per livello. Ogni schermo insegna esattamente una cosa nuova. Mai due. Mai zero.
• Il contesto insegna. Non serve un tooltip se il layout rende ovvio cosa fare. Pauline in alto = sali. Botti che rotolano = evita.
• Fallimento sicuro. Le prime botti sono lente apposta. Puoi morire, ma capisci subito perché. Il feedback è immediato e leggibile.
• Skill stacking. Ogni schermo richiede le abilità dei precedenti più una nuova. Nulla viene sprecato, tutto si accumula.

Oggi vedo SaaS con tutorial di 20 schermate, popup che bloccano l'interfaccia, guide passo-passo che nessuno legge. Miyamoto risolveva tutto con il posizionamento di una botte e la pendenza di una rampa. Con 16 KB.

Developer insight: tre giorni per far scendere una botte da una scala

Questa è la parte che mi ha fatto perdere più tempo di qualsiasi altra feature. La logica di base (muovi Mario, sali le scale, salta) è venuta relativamente in fretta. Poi ho dovuto far rimbalzare le botti sulle scale. E lì tutto si è rotto.

Il problema sembra banale: una botte rotola sulla rampa, arriva a una scala, e a volte scende. Ma nell'originale le botti non scendono sempre. C'è una probabilità variabile che dipende dalla posizione della scala, dal livello corrente e da un fattore pseudo-random. Se tutte le botti scendessero il gioco sarebbe impossibile; se nessuna scendesse, sarebbe noioso. Miyamoto tarò quel valore con una precisione che oggi chiameremmo A/B testing.

Poi c'è il problema della collision. Una botte che rotola su una rampa inclinata e poi decide di scendere da una scala verticale deve cambiare completamente modello fisico. Sulla rampa si muove orizzontalmente con un offset verticale (segue la pendenza). Sulla scala si muove solo verticalmente. La transizione tra i due stati è il punto esatto in cui il game feel si fa o si rompe.

Ho passato tre sessioni intere a debuggare botti che attraversavano le scale come fantasmi, che si bloccavano a metà, che cadevano nel vuoto, che invertivano direzione. Ogni fix ne rompeva un altro. La collision grid delle scale doveva allinearsi pixel-perfect con la hitbox della botte, e ogni scala ha dimensioni leggermente diverse.

La soluzione finale: trattare ogni botte come una state machine con tre stati. Rolling (sulla rampa), descending (sulla scala), falling (caduta libera alla fine della scala). Ad ogni frame, la botte controlla se si trova sopra una scala e tira un dado. Se esce il numero giusto, transiziona in descending, allinea il suo centro X all'asse della scala, e scende a velocità costante. Quando tocca la rampa successiva, torna in rolling.

Scritto così sembra ovvio. Arrivarci ha richiesto dozzine di iterazioni e una quantità imbarazzante di console.log.

«Le cose che sembrano semplici quando giochi sono quasi sempre quelle che richiedono più lavoro quando sviluppi. La botte che scende dalla scala in modo naturale? Tre giorni.»

Dal diario di sviluppo di PixelPrompt

L'AI è lo scalpello, non lo scultore

Usare l'AI per riscrivere un gioco da zero non è chiedere “fammi Donkey Kong” e ricevere un prodotto finito. È più simile a fare pair programming con un collega che conosce ogni API esistente ma non ha mai messo una moneta in un cabinato.

L'AI eccelle con la struttura: game loop, gestione delle sprite, boilerplate del canvas, collision detection base. Tutto ciò che è pattern noto e documentato. Dove fatica è sul game feel. La velocità giusta di una botte, il peso del salto di Mario, il momento esatto in cui la botte deve decidere se scendere dalla scala. Questi sono valori che trovi solo giocando, testando, aggiustando di mezzo pixel alla volta. L'AI genera tre alternative in cinque minuti; io scelgo quella che “si sente giusta”. Io decido il design, l'AI scrive il boilerplate.

Il risultato finale è un Donkey Kong che rispetta il feeling dell'originale. Le botti rimbalzano come devono, Mario ha il peso giusto, e i quattro schermi insegnano a giocare senza una sola parola. Puoi provarlo adesso: gioca a Donkey Kong gratis nel browser.

Se questo pezzo ti ha fatto venire voglia di smontare altri classici, su PixelPrompt lo facciamo ogni settimana. Riscriviamo giochi retro con l'AI, li analizziamo pezzo per pezzo e raccontiamo cosa abbiamo imparato. Entra nella crew: zero spam, solo pixel e codice.