Portfolio 2026: un portfolio che si gioca

Perché

Il portfolio classico ha un problema di fondo: chi lo apre di solito ha fretta e ha già visto decine di griglie con le solite card identiche. Volevo creare qualcosa di memorabile, ma senza costringere chi ha i minuti contati a dover "giocare" per trovare un'informazione.

Una città in pixel art, porte da aprire, un contatore che ricorda tanto un Pokédex... Tutto bellissimo, certo, ma la verità è molto più semplice: i portfolio tradizionali mi annoiavano da morire. Questo, invece, no.

Come si gioca

Ci si muove su una griglia, sedici pixel alla volta, a una velocità di sedici centesimi di secondo per passo. Ci si sposta con le frecce direzionali e, con il tasto A, si interagisce con ciò che ci si trova davanti: porte, insegne, abitanti. Le porte sono solide come muri: ci sbatti contro ed entri solo premendo A, esattamente come funzionavano i giochi retrò a cui mi sono ispirato.

Esplorando la mappa si incontrano otto abitanti e una decina tra insegne e cartelli, sparsi per i vari quartieri. C'è un turista in piazza che ti aggiorna su quanti progetti ha scovato lui, e un bagnino che nega con insistenza l'esistenza di un edificio nascosto sulla spiaggia... pur fissando ostinatamente verso sud-est.

Nell'erba alta capita che salti fuori qualcosa, e dal molo è persino possibile pescare: ci sono sette prede diverse, ma solo quattro sono pesci. Le altre tre sono un vecchio stivale, un'ombra misteriosa a cui nessuno crede e un messaggio in bottiglia. E no, nessuna di queste sette prede sblocca alcun segreto.

I sette progetti

Gli edifici da esplorare sono sette, e al loro interno si nasconde sempre un progetto reale. Entri, leggi la scheda, raccogli la medaglia e il contatore nella barra avanza di uno. Premendo il tasto P si apre l'inventario con l'elenco di ciò che hai scoperto e di quello che ti manca (che rimane segnato con dei «???»).

L'ultimo edificio non ha un'insegna ed è nascosto tra gli alberi della spiaggia a sud-est, superato il ponte di legno. È quasi impossibile trovarlo per caso: ci si arriva di solito dopo aver parlato con il turista, capendo che lui ha trovato sei progetti ma il contatore totale ne richiede sette.

Raggiunto il "sette su sette", il gioco si ferma e parte la schermata finale: pioggia di coriandoli, un ringraziamento e quattro modalità diverse per contattarmi. È letteralmente l'unico punto dell'intero sito in cui chiedo all'utente di fare qualcosa.

Due corsie, un sito solo

Questo progetto offre due esperienze parallele. Il "percorso veloce" è quello tradizionale: pagine web vere, testi indicizzabili, lista dei lavori, CV e contatti. Il "percorso lento", invece, è la città da esplorare.

Non si tratta però di due siti slegati: entrambi pescano dagli stessi dati. Se modifico una riga nella descrizione di un progetto, il cambiamento si riflette ovunque in tempo reale, inclusa questa pagina.

Persino all'interno del gioco, i testi non sono "disegnati" nel canvas. Dialoghi, schede e contatore sono puro codice HTML sovrapposto alla grafica: questo li rende perfettamente accessibili agli screen reader e indicizzabili da Google. Il canvas fa il suo lavoro da canvas, il documento HTML fa il documento.

La mappa, tile per tile

La mappa è una griglia di 112x52 (5.824 caselle totali), dove ogni casella corrisponde a un carattere all'interno di un file di testo. Il fiume attraversa l'area come una spina dorsale e ha un solo ponte; il bosco recintato si trova a nord-est, gli orti a nord-ovest, il molo a sud-ovest e la caletta nascosta a sud-est.

I tile grafici non li ho disegnati io: fanno parte di un pack creato da Ismael Garcia (in arte Scarloxy). Li ho scelti perché gli elementi come la costa, il fiume e le terrazze si integravano già alla perfezione tra loro. I crediti sono riportati nel footer.

Assemblare la mappa, invece, è stato compito mio. A un certo punto ho capito che farlo a mano nel codice era folle, così mi sono programmato un editor dedicato. Si avvia in modalità sviluppo e permette di "dipingere" il terreno usando diciassette pennelli diversi, piazzare uno qualsiasi dei cinquantotto tile disponibili e trascinare edifici, cartelli e NPC esattamente dove servono. Premendo "Salva", il sistema riscrive il file di testo della mappa: di conseguenza, spostare una collina equivale a veder cambiare delle righe di testo nel diff del codice.

Sia l'editor che il gioco utilizzano la medesima funzione per calcolare il tile da mettere sotto i piedi del personaggio: il risultato è che quello che vedi mentre costruisci la mappa è esattamente ciò che calpesterai giocando.

Come l'ho scritto

Il codice l'ho scritto facendomi affiancare da un assistente IA, il che è ben diverso dal fargli fare tutto da solo. Non funziona scrivendo un prompt come «fammi un portfolio» e mettendosi a guardare: assegno un compito specifico alla volta, analizzo il diff delle modifiche proposte, e tutto ciò che non capisco alla perfezione non finisce mai in produzione.

Il segreto sta nell'impostare regole chiare a monte. Nel repository ho inserito due file che l'assistente virtuale deve leggere prima di mettere mano a qualsiasi riga di codice: il primo descrive l'architettura del progetto e fissa le decisioni inderogabili; il secondo definisce lo stile di scrittura del sito, basandosi sul copy che avevo già redatto in precedenza. Parliamo di oltre settecento righe di istruzioni testuali, scritte interamente da me.

Tra queste direttive c'è, ad esempio, la regola del trattino lungo (em dash): in questo sito non se ne usa nemmeno uno, e c'è un controllo pre-pubblicazione apposito per contarli. Se ne dovesse spuntare fuori uno, saprei subito che non si tratta di una scelta stilistica, ma di un testo generato in autonomia dall'IA.

A tutto il resto ci pensano i controlli automatici: il processo di build si ferma se c'è un link interno rotto, e una suite di test simula l'intero flusso dell'editor per assicurarsi che, nel sovrascrivere un file di dati, il sistema non cancelli per errore i commenti al codice.

Come è fatto

Lo stack è semplice: React per l'interfaccia, Kaplay per il mondo di gioco, TypeScript ovunque. Il motore di gioco viene scaricato dalla pagina in modo asincrono, con un import separato. Kaplay, da solo, pesa quasi la metà dell'intero sito; lasciarlo nel caricamento iniziale voleva dire bloccare la home in attesa di un gioco che l'utente, magari, non avrebbe nemmeno mai aperto.

Per ottimizzare le prestazioni, il terreno viene prerenderizzato una sola volta su un canvas off-screen e poi disegnato come un'unica grande immagine: settemila elementi singoli condensati in un solo sprite. Gli unici elementi che restano "vivi" da calcolare sono alberi, palme e massi: 1.749 oggetti che ordinano la loro profondità in relazione al personaggio e svaniscono dalla memoria non appena escono dall'inquadratura. Senza questo passaggio, il sistema doveva ridisegnare oltre seimila oggetti a ogni singolo frame, facendo crollare il gioco a quindici fotogrammi al secondo.

Al mare ho dedicato la stessa cura: originariamente le animazioni di onde e schiuma pesavano per 735 oggetti distinti, ciascuno con il suo ciclo di aggiornamento. Ora si tratta di un unico disegno globale che si applica solo ai tile visibili sullo schermo. Su mobile, inoltre, la risoluzione interna viene abbassata: trattandosi di pixel art, calcolare il quadruplo dei pixel non migliora la resa visiva, ma uccide le prestazioni.

Il risultato

L'obiettivo è rimasto fedele alla premessa di partenza: accontentare sia l'utente frettoloso che l'esploratore curioso. Chi ha i minuti contati trova subito portfolio, case study, curriculum e contatti, senza dover guardare un singolo pixel; chi ha voglia di svagarsi entra in città e si perde per tutto il tempo che desidera.

L'intero sito è statico: le pagine vengono generate durante la build e servite da Cloudflare, perciò non ci sono database che possano andare offline nel cuore della notte. Se stai leggendo questo paragrafo significa che hai optato per la corsia veloce, ed è giustissimo così.