Un jeu Pixi.js que vous pouvez jouer

J’ai déjà écrit quand je prendrais Pixi.js plutôt que Three.js, et pourquoi un canvas sur une URL métier est une facture, pas un décor. Puis j’ai livré l’objet 3D qu’on peut orbiter. Cette page est l’autre surface : une scène 2D qui doit tenir 60 fps pendant que vous jouez. Le jeu au-dessus de ce paragraphe est le schéma que je livrerais pour un drop de lancement, un stand ou une boucle de fidélité : une île, paresseuse, destructible. La phrase que vous lisez reste dans le document.

Déplacez le panier. Attrapez pommes, poires, tranches. Évitez les pourris. Calme, arcade, tempête. C’est le job commercial : quelques dizaines de sprites, un ticker, des particules qui meurent quand il faut. Pas d’atlas. Pas de pile de scènes Phaser. Graphismes procéduraux, un HUD en HTML, une boucle qui cède dès que vous quittez le viewport.

1. Ce que vous regardez vraiment

Pixi.js est un renderer 2D. Une display list, des primitives Graphics, un ticker. Les pommes, poires et tranches ne sont pas des PNG. Ce sont des polygones sur le GPU, batchés, tournés dans la boucle. Le verger derrière est un objet Graphics — ciel, collines, arbres — plus quelques nuages qui dérivent. Attrapez un fruit : une poignée d’étincelles naît et meurt. C’est le job où Pixi est fort : beaucoup d’objets 2D bon marché, chaque frame, sans nœud DOM par sprite.

Il n’y a pas de moteur physique. La gravité est un nombre que j’ajoute à vy. La collision est une boîte autour du collecteur. Le combo est un timer dans le même tick. Phaser donnerait des scènes, de la physique arcade, de l’audio. Ce produit n’avait pas besoin de cette facture. Il avait besoin d’une scène chaude dans un article Next.js. Je plafonne devicePixelRatio. Je coupe le nombre d’étoiles quand hardwareConcurrency est bas. La tempête, c’est plus de sprites, pas un shader plus lourd. C’est la différence entre un mini-jeu qui survit au laptop d’un recruteur et un qui fait cuire un Android milieu de gamme dans le métro.

2. L’île, pas la home

Il n’y a pas de WebGL sur le serveur. Cette page est un static export. Le HTML de l’article est dans le first paint. La scène est une île client : IntersectionObserver avec root margin, puis un import dynamique de pixi.js, puis Application.init. Si vous ne scrollez jamais ici, vous ne téléchargez jamais le renderer. Si vous partez, le ticker saute la frame. Au unmount je détruis l’application, le canvas et le contexte GPU. Naviguez ailleurs dans cette app : l’article suivant n’hérite pas d’une session WebGL vivante.

Je n’ai pas mis ça sur la home. Un hero canvas impatient se bat avec le LCP puis vole l’INP. Un recruteur peut attendre un scroll. Un client sur une URL de lancement peut attendre le jeu qu’il est venu jouer. Il ne peut pas attendre une scène qui a bloqué le titre. Le score, les vies, le « rejouer » sont dans le HTML à côté du canvas — pas peints dans une texture. Reduced motion ralentit le ticker et coupe les étincelles ; la scène se joue encore, parce que c’est un choix, pas une animation.

• Texte, score et titre dans le HTML serveur. Le canvas n’est pas une surface crawler.
• Démarrage à l’intersection, pas au chargement de la route.
• Destroy au unmount. Sauter les ticks hors écran. Respecter prefers-reduced-motion.

3. Ici du Pixi.js brut. Dans l’app produit, @pixi/react

Sur cette page j’ai branché le renderer moi-même pour que l’île reste un chunk et que la boucle soit évidente : init, tick, destroy. Dans une app Next.js où la scène doit parler à un panier, un flag de campagne ou un wallet, je prendrais @pixi/react. Même GPU, une display list dans l’arbre React, moins de pièges au unmount. L’erreur, c’est d’adopter le wrapper pour faire tourner un cercle, ou de l’éviter quand vingt sprites doivent rester sync avec Redux. Prenez le wrapper quand le produit pense déjà en composants.

4. Quand je livrerais ça pour un client

Un mini-jeu de marque sur un drop produit. Un stand qui doit tourner sur un laptop bon marché. Un tableau pour enfants, une boucle de fidélité, un rouleau de pièces que CSS ne tiendra pas. Une mini app Telegram qui est déjà une webview et ne doit pas faire pousser un second moteur. Pas une home marketing qui devait « faire premium » — ce brief reste CSS et GSAP. Pas un SKU bijou à orbiter : c’est Three.js. Pas un platformer avec des niveaux et un monde physique : partez de Phaser ou d’un vrai moteur de jeu. Si WebGL ne démarre pas, la page a encore les règles en HTML. Le canvas est le meilleur chemin vers le jeu, jamais le seul.

Conclusion : jouez sur le GPU, gardez le document

Les équipes prennent Pixi.js quand le client reste parce que la scène est fluide, pas parce que le titre est malin. Elles doivent quand même prendre un document : titre, règles, score, une phrase de repli. Je livre cette coupure en ingénieure web senior — îles Next.js, budget GPU plafonné, GSAP là où la page est encore une page. Si le brief est une scène 2D qui doit tenir 60 fps sur une URL métier, écrivez via le formulaire le nombre de sprites, si c’est un vrai jeu ou une boucle de marque, et si la même URL doit se classer. On ne commencera pas en posant un canvas sur la home « pour que le portfolio joue ».