Vous avez parfois l’impression de luter contre le web? De galérer avec des rendus qui diffèrent d’un à l’autre? D’avoir des soucis de compatibilité entre les versions des navigateurs? De craindre les plugins et les scripts des joueurs? Alors essayons de comprendre le rôle du dans un jeu web, pour l’utiliser au mieux.

Client, serveur

L’un des points crucial d’un jeu web est l’architecture même du web: vous avez un serveur, sur lequel vous avez tout contrôle, et un client, sur lequel vous n’avez aucun contrôle. C’est d’ailleurs pour cette raison qu’il vous faut valider correctement tout ce qui entre sur votre serveur. Vous devez donc accepter le fait que le navigateur peut se comporter comme il veut.

De manière générale, un client (navigateur, code PHP, ou autre) et un serveur (web, MySQL, ou autre) sont toujours découplés: l’un ne sait rien de l’autre, et vice-versa.

Cette abstraction du client vu par votre serveur est figurée par la notion de “Device Independence Principles” du W3C: votre jeu web (niveau serveur) n’a pas à se soucier du terminal qui sera utilisé pour y jouer théoriquement). Ainsi, non seulement vous êtes implicitement compatible avec tous les navigateurs (pour peu qu’ils suivent les standards du web), mais vous êtes en plus compatible avec tous les supports, présents et à venir (PC, tablettes, smartphones, montres, lecteurs d’écran, voiture, etc).

J’aime illustrer ce principe par la demande It must fit my screen qu’un chef de service informatique peut parfois donner à ses développeurs. Cette question n’a en effet pas de sens: faire tenir le site (ou le jeu) dans l’écran de son chef ne signifie pas qu’il tiendra dans l’écran d’un autre utilisateur… Et on ne sait même pas si cet utilisateur aura un écran! Cette demande est donc totalement injustifiée, et très souvent irréaliste.

Un écran rempli de barres de plugins: 'fit my screen' sera compliqué!
It must fit my screen: la demande en elle-même est aberrante dans le monde du web

Eduquez vos joueurs

Partant de là, comme vous n’avez aucun contrôle sur le navigateur des joueurs, vous avez tout intérêt à les éduquer, pour qu’ils aient eux-même le contrôle sur leur propre navigateur. Ainsi, en vous assurant que vos joueurs savent bien se servir de Firefox/Chrome/Opera/Edge/etc, vous vous éviterez de nombreux problèmes de navigation, de design, d’ergonomie, et de code en général. Par exemple, si vous apprenez à vos joueurs qu’un navigateur doit être tenu à jour pour bénéficier des nouveautés récentes (fonctionnalités et ergonomie améliorées) pour tous les sites de la planète, y compris votre jeu, alors vous vous épargnerez les montagnes de polyfill buggés que les vieux navigateurs vous obligeraient à utiliser. Jouez éventuellement sur l’argument de la sécurité (qui est vrai!) pour les encourager à faire cette mise à jour.

Si vous vous surprenez à “lutter” contre un navigateur, alors cela signifie soit que vous essayez de coder une préférence de navigation dans votre jeu web. Abandonnez-la.

Apprenez aussi à vos joueurs que votre jeu web n’est pas que de votre ressort: c’est aussi du leur! Ainsi, s’ils veulent des fonctionnalités de customisation avancées (pour changer l’apparence du jeu par exemple), aiguillez-les vers des extensions capables de modifier n’importe quel site comme TamperMonkey. Ne pas développer ces fonctionnalités dans votre jeu mais les laisser au navigateur vous épargnera du code lourd, et vous évitera de plomber d’autres joueurs qui ne voulaient pas de ce comportement.

En tant que créateur de jeu, si vous rêvez d’une fonctionnalités “pour tous les sites”, alors il s’agit d’une préférence de navigation. Sinon, il s’agit d’un élément de jeu à coder dans votre site à vous (uniquement).

Enfin, en faisant comprendre aux utilisateurs (et à vous-même) le rôle d’un navigateur, vous comprendrez pourquoi il en existe autant: chacun vient avec un lot d’habitude et de features différent, et chaque utilisateur a donc légitimement le droit de préférer l’un ou l’autre des navigateurs: l’expérience utilisateur n’est volontairement pas la même d’un navigateur à l’autre, et passer du temps à vouloir trop l’uniformiser vous sera préjudiciable.

Votre jeu sera différent d’un navigateur à l’autre: c’est normal, c’est cette différence qui pousse les utilisateurs à préférer l’un ou l’autre des navigateurs.

Chacun ses préférences

Pour ces raisons, je vous recommande de ne pas essayer de “pourrir” les préférences personnelles et les habitudes de vos joueurs. Par exemple, sur certains site, la notion même de lien a littéralement été réinventée: ce ne sont plus des ancres a mais des div , sur lesquels du javascript vient se greffer pour simuler le comportement de “je clique gauche, le lien s’ouvre”. Mais ce n’est pas toujours le clic gauche qui sert à cela: le clic central, le contrôle molette, ou l’inversion des boutons gauche-droite sont des comportements dont le joueur aura peut-être l’habitude, et qui ne seront plus fonctionnels dans votre jeu!

Ne recodez pas un navigateur dans votre jeu: soyez le plus déclaratif (HTML) que possible, et évitez tout code Javascript (qui est un langage impératif). Le code déclaratif sera alors traité par le navigateur selon les préférences du joueur.

Touches et clics customs

Un bon exemple de ce genre de problématique du navigateur dans un jeu web concerne les touches et clics customs dans un jeu. Dans ce genre de cas, le créateur d’un jeu web veut assigner un raccourcis clavier à une commande du jeu (par exemple, F1 pour avoir l’aide du jeu, ou Ctrl+i pour accéder à l’inventaire. Il se retrouve alors à gérer du javascript (onkeyup onkeydown onkeypress) pour cela… Mais ces touches ont d’autres fonctions dans le navigateur du joueur! Par exemple, dans Firefox, Ctrl+i affiche les favoris. Votre jeu va donc casser ce comportement, et pourra frustrer le joueur. Mieux vaut donc ne pas le faire, ou le déléguer à un script TamperMonkey par exemple.

L’attribut accesskey vous permet d’assigner un raccourcis à un élément de la page de façon déclarative et non-invasive. Les préférences associées de chaque navigateur seront alors respectées.

Les snooze tab

Un autre exemple intéressant de cette méthode réside dans les “snooze tabs”. Un joueur m’avait demandé, un jour, d’implémenter un système dans Eclerd qui permettrait de remettre l’onglet au premier plan, quand une action est terminée (la construction d’un bâtiment par exemple). De cette manière, le joueur voulait lancer une action de jeu, laisser l’onglet “dormir” en arrière-plan le temps qu’elle se fasse, puis être remis automatiquement dans le jeu quand l’action est terminée. C’est typiquement ce que les “Snooze Tabs” permettent aujourd’hui dans Firefox: un clic droit sur l’onglet fait apparaitre l’option “mettre en sommeil jusqu’à”, et l’utilisateur peut régler la durée qu’il désire (une heure spécifique, ou “demain”, ou “dans un mois”, etc). Je n’ai donc pas eu besoin de développer cette fonctionnalité, mais juste d’aiguiller l’utilisateur dessus.

Les plugins de triche

Comme je parle de plugins, l’une des craintes des créateurs de jeu est alors la présence de “plugins de triche” chez le joueur. Mais cette crainte est en fait hors de propos! Rappelez-vous: tout ce qui est hors de votre serveur est hors de votre contrôle et hors de votre jeu web. En conséquence, s’il existe des plugins “d’aide à la décision” (que ce soient de vrais plugins, des scripts TamperMonkey, ou une simple feuille de calcul Excel), alors vous ne pourrez pas lutter de front contre eux (idem pour les bots jouant tout seul).

une feuille Excel d'aide à la décision
Les fichiers Excel d’aide à la décision existent depuis Ogame, et le principe date de bien avant l’informatique

La vraie façon de contrer ce problème consiste soit à accepter le fait que certains seront assez à fond dans votre jeu web pour y recourir, et les laisser faire si cela ne nuit pas trop à l’équilibre du jeu, soit d’étoffer votre gameplay pour que ces plugins ne soient plus essentiels à la victoire d’un joueur. Par exemple, le jeu d’échec est assez “pauvre” pour que, de nos jours, n’importe quel programme informatique puisse battre la plupart des grands maîtres. Mais le jeu de Go est bien plus complexe! Les décisions stratégiques sont si fines qu’il aura fallu attendre des décennies avant de voir le même genre de programme pour ce jeu. Donc, dans le cas de votre jeu web, si toutes les réponses stratégiques sont assez évidentes et simples pour être prises par une machine, alors vous devriez plutôt remettre votre gameplay et votre jeu en question au lieu d’essayer de lutter (vainement) contre ces plugins.

Si de tels plugins finissent par apparaitre, je pense que vous pouvez en être flatté: cela signifie que des gens ont assez apprécié le jeu pour passer du temps à les réaliser. N’hésitez pas à vous inspirer de ces plugins pour trouver les défauts de votre jeu web.