Les écueils à éviter

Les nuisances

Un jeu web n'a pas l'attention constante et totale de ses joueurs (qui papillonnent sur d'autres sites ou d'autres programmes en même temps). Donc, évitez de générer des nuisances qui perturberaient le reste de leur activité

Musique/bruitages/sons, notifications à outrance, lags à cause d'un jeu trop lourd (graphiquement ou en calculs), capture de la souris, plein écran etc n'ont pas leur place dans un jeu web: ce sont des pratiques de jeux "AAA". Si vous estimez en avoir besoin, dites-vous que vous sortez du cadre des jeux web, et que vous devriez alors vous tourner vers un SDK de jeu AAA (unity, NeoAxis, Unreal Engine, etc).

Up, et Nerf

Si votre jeu est déjà en ligne et qu'une unité est trop forte ou trop faible, alors vous serez tenté de faire respectivement un "nerf" (baisser les statistiques) ou un "up" (gonfler les performances) de cette unité pour ré-équilibrer le jeu. Attention toutefois car un "up" va créer un sentiment de "favoritisme" (les joueurs qui avaient cette unité faible seront contents, mais les autres les considèreront comme des "privilégiés") et un "nerf" va créer un sentiment de frustration chez les joueurs qui possédaient cette unité (car celle-ci sera moins forte qu'avant).

Un "nerf" peut donc faire partir les joueurs, de frustration. En revanche, lors d'un "up", vous risquez de voir les autres joueurs se "venger" sur ceux à qui le ré-équilibrage a bénéficié.

Une autre idée consiste à interdire la production (voire la réparation) de l'unité déséquilibrée, et de rajouter une nouvelle unité à la place (une sorte de "version 2" de cette unité). Progressivement, l'ancienne unité mal équilibrée disparaitra, sans frustrer d'un coup les joueurs.

Gameplay d'abord, réalisme ensuite

Un jeu n'a pas à être aussi "réaliste" que possible: il doit avant tout être amusant et divertissant.

Il n'est donc pas utile de chercher à résoudre les équations réelles d'un jeu (web). Dans VariiSpace par exemple, les équations de la gravitation ne sont pas forcément celles du monde réel. De même pour les durées de voyages entre les objets célestes. On s'en fiche. Dès l'instant où cela aide à la jouabilité (et si les joueurs sont éventuellement au courant), alors, tout va bien.

Ne pas se forcer à utiliser les équations de la physique réelle vous aidera à les modifier si vous avez besoin d'équilibrer votre jeu, alors qu'utiliser les équations de la physique réelle vous restreindra énormément quand vous attaquerez l'équilibrage de votre jeu web.

L'apparition de ressources: la spéculation

Prenez garde à la spéculation qui apparaitra dans votre jeu à partir du moment où vous ferez apparaitre des ressources sans raison. Par exemple, si vous créez un RPG et que vous donnez 5 pièces d'or au joueur lors de son inscription, alors vous risquez de voir des "petits malins" créer des milliers de comptes bidon, générant ainsi des milliers de pièces d'or, qu'ils voleront alors aux personnages de ces comptes bidons (et inactifs).

Ou encore, si vous insérez un "Marchand" dans votre space opera et que vous lui donnez la capacité d'échanger une ressource contre une autre, à des taux variables, alors certains joueurs pourraient se mettre à spéculer. Par exemple, si votre marchand échange 3 métal contre 1 cristal (qui seraient 2 ressources de votre jeu), alors le joueur va lui donner 100k cristal, et le marchand redonnera 300k métal. Le lendemain, le taux du marchant est de 1 métal = 1 cristal, alors, le joueur lui redonne les 300k métal de la veille et récupère 300k cristal: le joueur a gagné 200k cristal!

Si cette spéculation est voulue et intégrée dans l'ensemble du gameplay, alors elle peut devenir une intéressante fonctionnalité. Elle pourrait, par exemple, se substituer à l'extraction de ressources, et permettre l'apparition de joueurs au profil "commercial", en plus des habituels "mineurs" (qui avancent dans le jeu en extrayant des ressources) et "raideurs" (qui progressent dans le jeu en attaquant les autres).

Le danger ne vient pas de la spéculation (que ce soit via le marchant ou via la création de compte), mais du fait qu'elle n'était pas prévue dans le gameplay et qu'elle déséquilibre alors ce dernier.

Le bashing

Quand vous définissez les règles de votre jeu web, faites attention au bashing qui peut apparaitre. En d'autres mots, évitez les gameplay qui poussent un joueur A à attaquer plusieurs fois de suite et sans contrepartie (= "basher") un joueur B, souvent bien plus faible.

Il faut donc trouver un équilibre dans le gameplay, pour ne frustrer aucun joueur: les plus forts ne doivent pas être dépités de voir des "vaches à lait" leur échapper, et les plus faibles ne doivent pas être dégoûtés de jouer car ils ne peuvent pas progresser n'ayant jamais 5 minutes de paix.

Incompatibilité avec certains supports

Votre jeu doit être compatible sur tous les supports du web.

Votre jeu est un jeu web: vous le faites pour le web, et il tournera donc sur tous les supports (PC, tablette, smartphone, voiture, etc) grâce au navigateur (qui l'adaptera). Vous ne devez pas cibler un support spécifique: vous ne "codez" pas votre jeu pour un navigateur, ni pour un support, mais par rapport à un standard, le web. Les navigateurs qui respectent ce standard feront alors parfaitement tourner votre jeu.

L'intérêt d'un standard (web) est le même que l'intérêt d'une interface en POO: au lieu de gérer toutes les combinaisons entre deux groupes d'objets (10 sites web devant tourner sur 5 navigateurs génèrent 50 combinaisons à gérer), on ne gère plus que les combinaisons entre chaque groupe et l'interface (10 combinaisons site web+standard et 5 combinaisons navigateurs+standard = seulement 15 combinaisons!).

Evitez les frameworks obligeant les visiteurs à activer Javascript (Polymer, Angular, etc) car cela viendra forcément avec beaucoup de maintenance supplémentaire inutile.
Si vous avez besoin d'un tel niveau de programmation impérative, envisagez plutôt d'utiliser un SDK.

Héberger chez soi

Si c'est une bonne expérience personnelle, cela n'aidera pas votre jeu web. Les risques sont très (trop) nombreux:

Balancer le projet en ligne

Vous devez assurer un vrai suivi de votre jeu avant, pendant et après sa mise en ligne, puis tout au long de sa durée de vie.

La vie du jeu web ne démarre pas lorsque vous en avez l'idée: elle démarre à sa mise en ligne. Donc, préparez-la correctement, faites-la éventuellement au plus tôt pour éviter les surprises (et ne pas noyer vos premiers joueurs), construisez une communauté-noyau autour du jeu, soyez attentif à leurs retours (même si cela ne va pas dans le sens que vous vouliez!) et tenez dans le temps (prévoyez plusieurs années de durée de vie du jeu)

Bloquer les robots

Les captchas sont à proscrire, car ils ne bloquent pas tous les robots, ils bloquent parfois les humains, et ils ne luttent pas directement contre le spam.

En mettant des captchas pour bloquer les robots, vous vous trompez de cible. En fait, vous ciblez le spam et les indésirables. Mais un humain peut faire autant de dégâts qu'un robot en matière de spam! Et un robot peut être bénéfique pour votre jeu web (indexation, checks de sécurité, etc).

Obliger les visiteurs à s'inscrire

N'obligez pas les visiteurs à s'inscrire pour découvrir le jeu: permettez à tout visiteur de se faire une idée du jeu sans rencontrer d'obstacle.

Vous iriez sur un site marchand s'il vous disait "inscrivez-vous avant de voir le contenu de notre magasin"? Alors pourquoi obliger les visiteurs à s'inscrire avant de découvrir le jeu?! Faites en sorte d'avoir un mode "spectateur", permettant à n'importe quel visiteur d'entrer dans le jeu sans même devoir être inscrit (comme on peut être spectateur dans un FPS ou un RTS ou une partie d'échecs en ligne).

Un mode spectateur vous évitera de maintenir une page d'accueil, et vous permettrez aux nouveaux arrivants de facilement comprendre le jeu en les laissant voir les autres jouer. Personne n'a vraiment lu les règles du UNO, du Tarot, du Monopoly ou du Mille Bornes: vous avez souvent appris à jouer à ces jeux en regardant les autres, et c'est très efficace. Essayez de reproduire ça dans votre jeu web.

Créer un "mur" sur le parcours des joueurs

Le parcours d'un joueur à travers votre jeu web doit être fluide, et sans obstacle.

Savoir que le jeu existe est la première étape: vos joueurs doivent être au courant que votre jeu est en ligne! Ils doivent également le trouver digne d'intérêt, donc présentez-le sous son meilleur jour (cette présentation peut dépendre de la communauté à laquelle vous présentez votre jeu!)

Ensuite, ils doivent pouvoir accéder au jeu facilement et rapidement. Bannisez les écrans de chargement, les spécificités à un support, les jeux trop lourds pour la connexion des joueurs, etc.

Une fois sur le jeu, la première impression doit être réussie: il ne doit pas y avoir de bug, de truc "pas/mal fini", et le joueur ne doit pas se sentir perdu. Cela passe par une interface sobre mais claire, avec l'essentiel uniquement.

Le mode "spectateur" aidera beaucoup à l'immersion rapide du joueur.

Après, ils doivent entrer dans le jeu en lui même: l'inscription doit être simple, rapide, et sans contrainte (on oublie donc les restrictions incongrues sur les pseudos, les mots de passe et les emails).

A partir de là, le "visiteur" est devenu "joueur" et il doit avoir une direction claire dans sa tête. Ne le lâchez pas dans le jeu sans but! Guidez-le, aidez-le, et donnez-lui un sentiment de progression.

Le joueur ne restera pas éternellement: il mettra, à un moment, fin à sa "session de jeu" . Cette fin doit être facilité par le design de votre jeu, de sorte que le joueur ne soit pas frustré de terminer cette session trop tôt. Egalement, ne forcez pas la session à être trop longue, car plus elle durera, plus vous risquez le ragequit!

Si le joueur ne fait qu'une session de jeu, alors votre projet mourra vite! Vous devez donc maintenant le faire revenir, pour recommencer le cycle. Ce retour doit être régulier, et durer dans le temps.

Enfin, vous pouvez pousser faciliter le partage de votre jeu par le joueur auprès des gens qu'il connait (amis, famille, communautés dont il fait parti, etc). Ne forcez jamais ce partage! Facilitez-le uniquement, et rendez-le intéressant.

Non, le parrainage n'est pas une bonne idée: rendre le partage intéressant ne signifie pas "donner des bonus ingame" (cela poussera aux faux comptes). A la place, le design même du jeu doit donner de l'intérêt au joueur de jouer avec ses amis (par exemple, un Tarot ou un Monopoly seul, c'est nul…).

Faire attendre les joueurs

Evitez les gameplay où le joueur doit toujours attendre. Favorisez les gameplay dynamiques, et faites en sorte que le temps d'attente soit placé entre les sessions de jeu plutôt que pendant.

Ne faites pas attendre deux fois les joueurs façon Ogame (une fois pour produire les ressources, et une fois pour les dépenser en construction). Envisagez de supprimer l'une des deux attentes (en envoyant les ressources produites directement dans les constructions, ou en rendant les constructions instantanées).

La première session de jeu ne doit se heurter à aucune attente, sinon, le joueur partira.

Baisser la rentabilité des actions

Un vétéran doit avoir autant si ce n'est plus de possibilités et de rentabilité qu'un nouveau joueur. Ne rendez pas le jeu de plus en plus lent/de moins en moins rentable à mesure qu'on y joue.

Les problèmes de "multi-comptes" sont souvent liés à cette baisse de rentabilité: pour palier à cette baisse, les joueurs créent de nouveaux comptes!

Masquer des infos

Ne planquez pas des données aux yeux des joueurs: afficher-leur toutes les informations nécessaires pour qu'ils prennent les bonnes décisions de jeu.

Inutile, par exemple, de vous amuser à masquer les prix des propriétés si vous faites un Monopoly virtuel: c'est une information qu'il vaut mieux donner aux joueurs. En revanche, vous pouvez masquer tout ou une partie des informations des autres joueurs (combien l'adversaire a en banque par exemple).

⇇ Le blog de Xenos