Bomberman: regole semplici, caos perfetto.
Cosa insegna il multiplayer più puro mai creato

La prima partita di Bomberman finisce in tre secondi. Piazzi una bomba, non ti sposti in tempo, muori. La seconda partita dura cinque secondi: hai capito che devi scappare, ma non hai capito dove. La terza partita è quella in cui il gioco si accende. Perché è alla terza partita che inizi a guardare l'altro giocatore e non più la tua bomba. Su PixelPrompt riscriviamo classici arcade per il browser con l'AI, e Bomberman è il gioco che ci ha fatto capire una cosa fondamentale: le regole migliori sono quelle che i giocatori usano in modi che il designer non ha previsto.

Hudson Soft pubblica il primo Bomberman nel 1983. Il concept è già tutto lì: un labirinto a griglia, muri distruttibili, bombe che esplodono a croce dopo un timer fisso. Il giocatore si muove su quattro direzioni cardinali. Non c'è salto, non c'è attacco diretto, non c'è inventario. Il vocabolario di azioni è il più ridotto nella storia dei videogiochi: cammina e piazza.

Tre regole, complessità infinita

Bomberman funziona per sottrazione. Prendi tutto ciò che un gioco di azione potrebbe avere (salto, attacco, schivata, armi, abilità) e togli tutto tranne il movimento e un singolo verbo: piazza. Il risultato non è povertà ludica. È concentrazione.

La bomba esplode in quattro direzioni dopo tre secondi. Questo vincolo temporale trasforma ogni piazzamento in una previsione: dove sarà il mio avversario tra tre secondi? Dove sarò io? Quali corridoi si apriranno? Quali si chiuderanno? Non stai giocando il presente: stai giocando tre secondi nel futuro. È scacchi compressi in un arcade.

L'esplosione a croce crea un altro vincolo geniale: le diagonali sono zone sicure. Due giocatori separati da un muro distruttibile sanno entrambi che la bomba colpirà in linea retta. Quindi entrambi pensano di fuggire in diagonale. Ma se entrambi fuggono nella stessa direzione, si ritrovano faccia a faccia. La bomba diventa uno strumento di posizionamento, non di danno diretto.

«Non ho progettato la strategia del multiplayer. L'ho scoperta guardando i tester giocare.»

Shinichi Nakamoto, lead designer della serie Bomberman

Il Prisoner's Dilemma a 60 fps

C'è un momento in ogni partita di Bomberman che è teoria dei giochi pura. Due giocatori si trovano ai lati opposti di un corridoio stretto. Ciascuno ha una bomba disponibile. Se uno la piazza e l'altro no, chi ha piazzato può controllare l'uscita. Se entrambi la piazzano, entrambi restano intrappolati. Se nessuno la piazza, lo stallo continua.

È il Prisoner's Dilemma in tempo reale. Cooperare (non piazzare) sarebbe la scelta razionale per entrambi. Ma il gioco non permette comunicazione. E il timer della partita scorre. Quindi la pressione temporale rompe l'equilibrio e qualcuno piazza. Sempre.

Questo pattern non è stato progettato. È complessità emergente: comportamenti sofisticati che nascono da regole semplici. Gli scacchi hanno lo stesso fenomeno (poche regole, complessità combinatoria enorme), ma Bomberman lo comprime in partite da novanta secondi giocate con un solo tasto di azione.

Meno feature, più profondità

Se dovessi portare Bomberman in una riunione di prodotto, lo userei per dimostrare un principio che vedo violare ogni settimana: aggiungere feature non aggiunge valore. Lo sottrae.

Bomberman '93 per PC Engine ha introdotto i power-up: più bombe contemporaneamente, esplosioni più lunghe, la capacità di calciare o lanciare le bombe. Ogni power-up aggiunto ha reso il gioco più caotico ma meno strategico. Il punto di forza del Bomberman originale non era la varietà: era la parità. Tutti hanno le stesse capacità, tutti hanno gli stessi vincoli. La differenza la fa il cervello, non il loadout.

Nel product management c'è un termine per questo: feature creep. Ogni funzionalità aggiunta ha un costo nascosto in complessità cognitiva. Un'app con venti opzioni dove nessuno sa cosa fa il bottone in basso a destra è peggio di un'app con tre funzionalità che tutti padroneggiano. Bomberman è l'app con tre funzionalità: muoviti, piazza, scappa.

Il corollario è che i vincoli generano creatività. Non puoi saltare? Allora impari a usare le diagonali. Non puoi attaccare direttamente? Allora impari a prevedere dove sarà il tuo avversario tra tre secondi. La limitazione costringe il giocatore a trovare soluzioni che il designer non ha previsto. E quelle soluzioni sono il gioco vero.

Developer insight: il timer è tutto

Quando ho iniziato a lavorare sull'interpretazione di Bomberman per PixelPrompt, pensavo che la parte difficile sarebbe stata la griglia distruttibile. In realtà la griglia è la parte facile: un array bidimensionale dove ogni cella è vuota, muro fisso, o muro distruttibile. La bomba piazzata occupa una cella e dopo N frame esplode, cambiando lo stato delle celle adiacenti lungo le quattro direzioni.

Il problema vero è il timer di esplosione e la propagazione a catena. Quando una bomba esplode e la fiammata raggiunge un'altra bomba, quella bomba deve esplodere immediatamente, a prescindere dal suo timer residuo. Questo crea le reazioni a catena che sono il cuore del Bomberman avanzato: piazzi tre bombe in sequenza, la prima innesca la seconda, la seconda innesca la terza, e la fiammata arriva dall'altra parte della mappa dove il tuo avversario si sentiva al sicuro.

Far funzionare la propagazione senza loop infiniti è stato il bug più persistente. Se bomba A innesca bomba B e bomba B si trova nella traiettoria di esplosione di bomba A, rischi un ciclo. La soluzione è un set di bombe “già processate” nel frame corrente: ogni bomba può essere innescata una sola volta per ciclo di propagazione. Sembra ovvio scritto così, ma ci sono volute tre iterazioni con Claude prima di convergere su questa logica. La prima versione non gestiva il caso, la seconda usava un flag booleano sulla bomba (che non si resettava correttamente tra turni), la terza ha usato il Set e ha funzionato al primo tentativo.

Il secondo problema tecnico è stato il movimento sulla griglia. In Bomberman originale il giocatore non si muove pixel per pixel liberamente: è vincolato alla griglia, ma con un sistema di “snap” che lo allinea alla cella più vicina quando cambia direzione. Senza questo snap, il giocatore si blocca costantemente contro gli angoli dei muri. Con troppo snap, il movimento sembra magnetico e artificiale. Il valore giusto? Circa 6 pixel di tolleranza. Abbastanza da perdonare un allineamento impreciso, poco abbastanza da non sentirsi assistito.

«Sei pixel di tolleranza. La differenza tra un gioco che si sente fluido e uno che si sente rotto è un margine che non riesci nemmeno a vedere a occhio nudo.»

Dal diario di sviluppo di PixelPrompt

Il caos perfetto non si progetta, si scopre

La lezione definitiva di Bomberman è che i sistemi migliori non sono quelli con più regole: sono quelli con le regole giuste. Tre vincoli (griglia, timer, esplosione a croce) generano un sistema che i giocatori esplorano da quarant'anni senza esaurirlo. Nessun aggiornamento, nessuna patch di bilanciamento, nessun DLC ha mai migliorato la formula base del Bomberman a quattro giocatori su una griglia 13×11.

Se lavori su un prodotto, la prossima volta che qualcuno propone di aggiungere una feature, chiedi prima: possiamo ottenere lo stesso risultato con un vincolo? Bomberman non ha aggiunto un tasto per attaccare i nemici. Ha messo un timer su una bomba e ha lasciato che i giocatori inventassero il resto.

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