Un gioco Pixi.js che potete giocare

Ho già scritto quando prenderei Pixi.js al posto di Three.js, e perché un canvas su un URL business è un conto, non un decoro. Poi ho consegnato l’oggetto 3D che si può orbitare. Questa pagina è l’altra superficie: un palco 2D che deve tenere 60 fps mentre giocate. Il gioco sopra questo paragrafo è lo schema che consegnerei per un drop di lancio, uno stand o un loop di loyalty: un’isola, pigra, distruttibile. La frase che state leggendo resta nel documento.

Muovete il cesto. Prendete mele, pere, fette. Schivate quella marcia. Calmo, arcade, tempesta. Questo è il lavoro commerciale: qualche decina di sprite, un ticker, particelle che muoiono quando devono. Niente atlas. Niente pila di scene Phaser. Grafica procedurale, un HUD in HTML, un loop che cede appena lasciate il viewport.

1. Cosa state guardando davvero

Pixi.js è un renderer 2D. Una display list, primitive Graphics, un ticker. Mele, pere e fette non sono PNG. Sono poligoni sulla GPU, accorpati, ruotati nel loop. Il frutteto dietro è un oggetto Graphics — cielo, colline, alberi — più qualche nuvola che deriva. Prendete un frutto e una manciata di scintille nasce e muore. Questo è il lavoro in cui Pixi è forte: tanti oggetti 2D economici, ogni frame, senza un nodo DOM per sprite.

Non c’è un motore di fisica. La gravità è un numero che aggiungo a vy. La collisione è un box intorno al collettore. Il combo è un timer nello stesso tick. Phaser darebbe scene, fisica arcade, audio. Questo prodotto non aveva bisogno di quel conto. Aveva bisogno di un palco caldo dentro un articolo Next.js. Tappo devicePixelRatio. Taglio il numero di stelle quando hardwareConcurrency è basso. Tempesta è più sprite, non uno shader più pesante. Questa è la differenza tra un minigioco che sopravvive al laptop di un recruiter e uno che cuoce un Android di fascia media in metro.

2. L’isola, non la home

Sul server non c’è WebGL. Questa pagina è uno static export. L’HTML dell’articolo è nel first paint. Il palco è un’isola client: IntersectionObserver con root margin, poi un import dinamico di pixi.js, poi Application.init. Se non scrollate mai qui, non scaricate il renderer. Se ve ne andate, il ticker salta il frame. All’unmount distruggo application, canvas e contesto GPU. Navigate via in questa app e l’articolo successivo non eredita una sessione WebGL viva.

Non l’ho messo in home. Un hero canvas impaziente lotta col LCP e poi ruba l’INP. Un recruiter può aspettare uno scroll. Un cliente sull’URL di lancio può aspettare il gioco che è venuto a giocare. Non può aspettare un palco che ha bloccato il titolo. Punteggio, vite, «di nuovo» stanno nell’HTML accanto al canvas — non dipinti in una texture. Reduced motion rallenta il ticker e taglia le scintille; il palco si gioca comunque, perché è una scelta, non un’animazione.

• Testo, punteggio e titolo nell’HTML server. Il canvas non è una superficie per il crawler.
• Avvio all’intersection, non al load della route.
• Destroy all’unmount. Saltare i tick fuori schermo. Onorare prefers-reduced-motion.

3. Qui Pixi.js crudo. Nell’app prodotto, @pixi/react

In questa pagina ho cablato il renderer io, così l’isola resta un chunk e il loop è ovvio: init, tick, destroy. In un’app Next.js dove il palco deve parlare con un carrello, un flag di campagna o un wallet, prenderei @pixi/react. Stessa GPU, una display list nell’albero React, meno trappole all’unmount. L’errore è adottare il wrapper per far girare un cerchio, o evitarlo quando venti sprite devono restare in sync con Redux. Prendete il wrapper quando il prodotto pensa già in componenti.

4. Quando lo consegnerei a un cliente

Un minigioco di brand su un drop di prodotto. Uno stand che deve girare su un laptop economico. Una lavagna per bambini, un catch di loyalty, un rullo di monete che CSS non tiene. Una mini app Telegram che è già una webview e non deve far crescere un secondo motore. Non una home marketing che doveva «sentirsi premium» — quel brief è ancora CSS e GSAP. Non uno SKU di gioielleria da orbitare: quello è Three.js. Non un platformer con livelli e un mondo fisico: partite da Phaser o da un vero motore di gioco. Se WebGL non parte, la pagina ha ancora le regole in HTML. Il canvas è il percorso migliore verso il gioco, mai l’unico.

Conclusione: giocate sulla GPU, tenete il documento

I team prendono Pixi.js quando il cliente resta perché il palco è fluido, non perché il titolo è spiritoso. Devono comunque prendere un documento: titolo, regole, punteggio, una frase di fallback. Consegno questa spaccatura da senior web engineer — isole Next.js, budget GPU tappato, GSAP dove la pagina è ancora una pagina. Se il brief è un palco 2D che deve tenere 60 fps su un URL business, scrivete dal form il conteggio sprite, se è un gioco vero o un loop di brand, e se lo stesso URL deve posizionarsi. Non partiremo buttando un canvas in home «perché il portfolio giochi».