Trois façons dont j'ai vu des projets de jeux amateurs partir en vrille, et chacune vous montre à quoi ressemble la bonne configuration en laissant un beau désordre derrière elle.
Erreur numéro un : faire confiance au navigateur pour garder le score
La plus courante, et la plus évitable. Quelqu'un construit un jeu avec classement, branche un WebSocket pour les fonctionnalités multijoueur, et laisse le client calculer le score final avant de le POSTer au serveur. Aucune validation à l'entrée. J'ai vu ça se produire en direct — il a fallu environ quatre minutes à un joueur qui s'ennuyait pour ouvrir les DevTools, trouver l'onglet réseau, et commencer à soumettre des scores à neuf chiffres. Pas parce que c'était un hacker. Parce que le jeu lui a tendu le stylo en lui demandant de corriger sa propre copie.
La solution n'est pas subtile, juste fastidieuse : ne jamais faire confiance au client, point final. Chaque action est revalidée côté serveur, chaque tick de physique est réconcilié avec ce que le serveur considère comme vrai, et on accepte le coût de latence des allers-retours d'état plutôt que de faire du rendu local en espérant que personne ne regarde sous le capot. C'est pourquoi l'autorité côté serveur n'est pas ici une option secondaire — c'est la norme. Un jeu qui peut être battu depuis la console du navigateur est traité comme cassé, avec la même gravité qu'un plantage, parce que fonctionnellement, c'en est un.
Erreur numéro deux : un élément canvas et un bip, qu'on appelle un jeu
Celle-ci fait une superbe démo et s'effondre après quatre-vingt-dix secondes de jeu réel. Quelques transitions CSS, une vérification de collision, une onde sinusoïdale qui tient lieu de bruit de coup de poing — ça s'enregistre bien à l'écran, et puis le premier vrai joueur dit que le mouvement semble bizarre sans pouvoir dire pourquoi. C'est la physique. Un code de collision artisanal du type « si chevauchement, rebond » ne gère jamais correctement la masse, la friction et la réponse aux collisions, et les joueurs sentent l'écart même s'ils ne peuvent pas le nommer.
Les jeux construits ici utilisent un vrai rendu moteur à la place :
- Physique et rendu — three.js avec une véritable simulation physique pour le web, du vrai Unity 6 dans le lab pour tout ce qui est plus lourd.
- Art — vient du directeur artistique, pas d'un pack d'assets tout fait.
- Audio — instruments échantillonnés, pas un oscillateur qui fait de son mieux pour imiter un bruit de pas.
L'argumentaire complet sur le caractère non négociable de ce point se trouve dans Real engines, real builds.
La chaîne de vérificateurs détecte les échecs qu'une capture d'écran ne révèle pas :
- Appuie sur des touches.
- Vérifie que le score change réellement.
- Écoute la sortie audio.
Ça semble presque trop basique pour être utile, jusqu'à ce qu'on réalise combien de projets affichent une première image parfaite puis se figent silencieusement parce qu'un écouteur d'événement n'a jamais été attaché. Une image statique ne peut pas vous le dire. Un vérificateur qui doit survivre à trois manches de jeu, si.
Erreur numéro trois : demander à votre ami de faire tourner un serveur pour jouer à votre jeu
Les bons prototypes multijoueur meurent constamment à cette étape — pas parce que le jeu est mauvais, mais parce que « d'abord, fais un npm install du serveur, puis définis ces trois variables d'environnement » en demande trop à quelqu'un un mardi soir. Vous avez construit quelque chose d'amusant et l'avez enterré derrière un guide d'installation.
Les jeux solo se publient ici comme n'importe quel site — un clic vers un sous-domaine en ligne, sans flux séparé à apprendre. Le multijoueur, c'est différent, car il y a un vrai processus serveur qui doit rester actif quelque part, donc ceux-là se publient sur une page de jeu publique avec l'hébergement pris en charge pour vous. Le but est précis : « envie de jouer ? » devrait être une URL collée dans un chat de groupe, pas un README.
Ce que le contraste met en lumière
Remarquez ce qui manque dans les trois erreurs ci-dessus : le deux-joueurs en local. Un clavier, deux personnes, généralement ZQSD contre les flèches, coudes qui se cognent — c'est le mode que tout le monde sous-estime parce qu'il n'a aucun problème de diffusion. Pas de lien, pas de serveur, pas d'ami qui doit cliquer sur quoi que ce soit à 23h. Juste quelqu'un assis à côté de vous et trente secondes de « non attends, tu es le joueur deux, utilise les flèches ».
| Deux joueurs en local | Multijoueur en ligne | |
|---|---|---|
| Prise en main | « Non attends, tu es le joueur deux, utilise les flèches » — trente secondes | Matchmaking, écrans vides « en attente d'un adversaire » |
| Diffusion | Zéro — pas de lien, pas de serveur, personne n'a besoin de cliquer sur quoi que ce soit à 23h | Nécessite une page de jeu publique et quelqu'un d'autre en ligne au même moment |
| Conversion | Pratiquement 100% — la seule friction, c'est "tourne ta chaise" | Abandonne en attendant un adversaire |
Les builds air-hockey et arena-brawler de la vitrine s'appuient exactement sur ça.
Combinez les trois correctifs — autorité côté serveur, vrais moteurs, pages de jeu publiques hébergées — avec l'avantage intrinsèque du deux-joueurs local, et vous obtenez la véritable étendue que ça permet :
- Solo — la base.
- Deux joueurs local — la victoire gratuite.
- Multijoueur en ligne — conçu pour survivre à un ado désœuvré avec DevTools ouvert.
Chaque jeu s'ajoute à une bibliothèque Mes jeux avec un statut de publication par jeu, donc pas besoin de fouiller de vieilles discussions pour retrouver quelle version était la bonne. Et si vous avez packagé quelque chose pour Android, ça continue directement vers le chemin vers la boutique au lieu de repartir de zéro dans un second processus.
