Beaucoup de jeux web tirent avantage de la persistance de leur univers en proposant des parties qui ne finissent, en gros, jamais. Ces MMOs ont alors une gestion différente du par rapport aux classiques RTS.

Le temps dans un MMO

Déjà, sachez que l’on parle, dans cet article, du temps du joueur et non du temps du créateur du jeu (qui est l’objet d’un autre article). Sa bonne gestion consiste à mettre en place un gameplay dans lequel ce temps n’est pas une contrainte pour le joueur, mais un élément de jeu appréciable. Or, de nombreux MMOs web font défaut de ce point de vue-là: les joueurs ont souvent tendance à lutter contre les contraintes de temps que le jeu leur impose, et cela débouche sur du multi-compte, ou sur de la frustration suivie du départ définitif des joueurs, et parfois sur le paiement d’une micro-option pour contourner cette contrainte.

Les paiements sont rares sur les jeux amateurs, et mieux vaut éviter de concevoir un mauvais gameplay pour espérer commercialiser des options payantes de contournement: vous risquez plutôt d’avoir juste 0 joueur.

Les temps d’attente

Le problème du “poireautage”

Dans l’une de mes réponses à propos du jeu Pyromagnon, j’ai rapidement parlé du problème du temps d’attente dans les jeux web. Dans beaucoup de jeux web, le joueur se retrouve obligé d’attendre avant de continuer à jouer. Par exemple, si je veux jouer à la Confrérie des Pirates, alors je me connecte et je lance une action: se déplacer, pêcher, etc. Mais, pour être menées à bien, ces actions nécessitent… d’attendre! Or, je suis venu pour jouer… Il y a donc un décalage entre le jeu et l’attente du joueur, qui génèrera de la frustration (certains créateurs espèrent que cette frustration poussera le joueur à payer une option pour ne plus attendre: ce n’est jamais le cas sur un jeu qui démarre!).

Autre exemple avec Ogame, et de nombreux jeux de stratégie web en général: les usines de mon compte de jeu produisent des ressources pendant que je ne suis pas connecté. Quand je veux jouer, je me connecte, et je lance la construction de nouvelles usines grâce à ces ressources. Or, la construction de ces usines demandent encore une fois d’attendre! On a, de nouveau, un décalage entre un joueur qui veut jouer et un jeu qui veut le faire patienter.

Obliger un joueur à attendre revient à lui créer une porte de sortie pour quitter le jeu. Si cette porte de sortie n’est pas volontaire, alors vous avez un soucis de gamedesign.

Le double-poireautage

Dans le second exemple, le joueur attend même deux fois pour une même action! Il attend d’abord une première fois que les ressources s’accumulent puis une seconde fois lorsqu’il se connecte pour jouer. La première attente (que j’appellerai “offline”) n’est pas un soucis, puisque le joueur n’est pas sur le jeu. En fait, il ne pense même pas à jouer. Il attend donc sans le savoir, et c’est un excellent moyen pour “réguler” la vitesse de progression des joueurs dans le jeu. Le vrai problème est donc bien le second temps d’attente (que j’appellerai à l’inverse “attente online”), qui empêche le joueur de jouer: il se détournera rapidement de votre jeu web, qui se doit d’être immédiatement disponible et jouable, au profit d’autres jeux (qui sont immédiatement jouables).

Solution: la session de jeu

Pour régler le premier problème de l’attente mal venue, vous devez appliquer le principe suivant: je ne dois faire attendre mon joueur que lorsqu’il veut arrêter de joueur pour la journée. Si je le fais attendre trop tôt, on l’a vu, il partira. Si je le fais attendre “trop tard”, alors il progressera trop vite dans le jeu. Vous devez donc déterminer la durée moyenne de vos sessions de jeu (5 minutes? 20 minutes? 1 heure? le plus long n’est pas forcément le mieux!) et vous assurer que le joueur n’aura pas à attendre avant la fin de cette session et ne pourra pas (trop) excéder cette durée de session (ou alors, s’il l’excède, il ne progresse pas tant que cela).

Par exemple, dans VariiSpace, je proposerai aux joueurs des constructions instantanées. Ainsi, ils attendront offline que les ressources s’accumulent, pour plafonner leur vitesse de progression, mais ils n’auront pas à attendre que les “actions” de jeu autres se terminent: construire un vaisseau sera instantané. Dans l’exemple précédent d’Ogame, cela reviendrait à supprimer le second temps d’attente (construction des bâtiments) pour ne garder que le premier (accumulation des ressources). Dans la Confrérie des Pirates, cela pourrait passer de même par des actions instantanées (pêcher est instantané) qui coûteraient un certain nombre de points d’action: quand ces points tombent à zéro, on doit attendre le lendemain pour jouer de nouveau.

Une autre possibilité, utilisée cette fois dans ECLERD, consiste à ne pas attendre l’accumulation des ressources: le joueur a la possibilité de lancer le chantier qu’il veut, sans avoir nécessairement les ressources qu’il faut, et ce chantier avancera au fil du temps (à mesure que les ressources arrivent). Dis autrement, le jeu fonctionne “par flux”: le joueur a un flux de production de ressources (disons, 1000/jour réel) et un flux de consommation de ces ressources (ses chantiers consomment 1000 ressources/jour réel). Le joueur peut donc jouer en lançant ses chantiers à sa guise, et il attendra offline qu’ils se finissent. La régulation de la vitesse de progression dans le jeu se fait alors dans l’équilibre entre ces flux.

Cette méthode de flux est originale, mais sa résolution mathématique est complexe. Vous devrez soit avoir une solution analytique générique et l’appliquer (très difficile!) soit définir K rendements possibles pour chacun des N usines du joueurs et calculer les K*N combinaisons possibles pour ne garder que “la plus proche” de l’équilibre, soit tenter de faire un calcul récursif, en priant pour qu’il converge vers une valeur potable.

La solution du “jeu par flux” permet d’éviter qu’un joueur ne stocke trop de ressources d’un type, se les accaparant par la même occasion (ou déséquilibrant le jeu): la notion même de stock ayant disparue, le joueur ne peut rien stocker et doit consommer toute sa production immédiatement.

La baisse de rentabilité

Plus on avance dans le jeu, plus il est lent

L’autre gros travers dans la gestion du temps d’un MMO web réside dans “l’explosion exponentielle du temps d’attente”. Dans la plupart des jeux, plus on avance dans le jeu, plus les unités coutent cher mais surtout, moins elles sont rentables (ce qui est totalement idiot quand on y réfléchit: jamais ce cas n’arriverai dans le monde réel!). Ainsi, une usine niveau 1 d’un jeu de stratégie peut couter 1000 ressources par année “in game” (1 an dans le jeu = 1 jour dans le monde réel), et son prix pourrait doubler à chaque nouveau niveau (façon Ogame), alors que la quantité de ressources produite augmente de façon linéaire (+1000 par niveau). Dans cette situation, le niveau 1 coute 1000 unités, et en rapporte 1000 par jour IRL. Le niveau 2 en coûte 2000 et en rapporte 2000 (jusqu’ici, ça va). Le niveau 3 coûte 4000 et en rapporte 3000 (cela commence à se gâter)… Le niveau 10 coûte au final 512000 et en rapporte 10000… Vous aurez donc besoin d’attendre près de 2 ans pour “rentabiliser” le coût de ce niveau! La plupart des joueurs n’arriveront d’ailleurs même pas à accumuler assez de ressources pour le construire, et ils se seront lassés avant de l’atteindre.

Le départ des joueurs au fil de leur progression dans un jeu n’est pas forcément un problème si votre taux de renouvellement arrive à suivre: de nouveaux joueurs remplaceront les anciens, ou les anciens recréeront un compte. Mais ce modèle n’est pas forcément viable à long terme.

Solution risquée: améliorer la rentabilité

Une première piste pour régler ce problème consiste à ne pas baisser la rentabilité de chaque niveau mais au contraire, à l’augmenter. Par exemple, au lieu de doubler le prix de l’usine à chaque niveau pour n’augmenter sa production que de 1000 unités, vous pourriez faire l’inverse: augmenter le prix de l’usine de 1000 unités et doubler sa production par niveau. Mais le risque est alors un emballement général de la production: le niveau 1 nécessitera 1000 ressources par année in-game pour en produire 1000 (donc, 1 an ingame d’attente) alors que le niveau 10 coûtera 10000 unités et en produira 512000, il sera donc rentable en 1 semaine in-game, ce qui peut être très rapide!

Pour palier au problème de l’emballement, vous pouvez faire en sorte que cette ressource ne soit plus utile au joueur passé un certain niveau. Ou encore, vous pouvez l’obliger à choisir entre différents types de ressources au même potentiel mais au gameplay différent.

Par exemple, imaginons que la somme des niveaux de toutes les usines du joueur ne puisse pas dépasser 100 (c’était le cas pour Ogame) alors le joueur devra faire un choix: veut-il construire une seule usine niveau 100, et avoir une quantité de métal quasi infinie? Ou préfère-t-il répartir les ressources entre métal et cristal? Et si la construction d’une usine de métal nécessitait aussi du cristal? Le joueur serait alors obligé d’avancer les deux de front, et ne pourrai plus dépasser le niveau 50 pour chacune d’elles!

Autre exemple, imaginons un RPG sur la préhistoire. Supposons que le joueur puisse produire des silex. S’il met toutes ses ressources dans l’amélioration de son “usine de silex”, alors il en aura une quantité quasi infinie. Mais si un autre joueur invente la lance, alors le silex pourrait devenir inutile: l’autre joueur aura tué vos personnages avant que ceux-ci n’aient pu utiliser le moindre silex! En plus, chacun de vos personnage n’ayant que deux mains, vous n’avez que faire des silex en trop…

Solution: l’accélération du jeu

L’autre piste consisterai à accélérer le jeu au fil du temps. Conservons le même exemple que précédemment, avec un système où le joueur produit +1000 de ressources quand il monte d’un niveau, mais où monter d’un niveau coûte 2x le prix du niveau précédent. L’idée serait alors d’accélérer le jeu au fil du temps. Au début, 1 an dans le jeu serait ainsi égal à 1 jour réel. Mais arrivée à la 10e année dans le jeu, cette vitesse pourrait doubler (d’un coup, ou progressivement, peu importe). Ainsi, le joueur doit effectivement attendre de plus en plus d’années in-game pour construire les niveaux les plus élevés, mais comme le jeu accélère, cela correspond à moins de jours réel: le temps d’attente se stabilise.

DateInGame(Treel, Tsortiedujeu) = (Treel - TsortieduJeu)*k
DateInGame(Treel, Tsortiedujeu) = pow(Treel - Tsortiedujeu, A)*k
L’ancienne formule d’écoulement du temps, et la nouvelle formule, où A sera à régler au cours de vos tests

Cette approche peut aussi être bénéfique pour les nouveaux joueurs: le jeu allant plus vite, ils progression bien plus rapidement que leurs aînés ne l’ont fait, leur permettant éventuellement de les rattraper ou au moins de s’en rapprocher.

L’effet mémoire

Le temps a aussi un autre impact sur le gameplay vus par les joueurs: l’effet mémoire. Ce terme désigne l’idée (mauvaise!) selon laquelle l’évolution du joueur (sa production de ressources par exemple) dépend non pas de son seul état actuel, mais de son passé. Imaginons par exemple un jeu dans lequel le joueur incarne un personnage politique qui doit se faire élire. Deux gameplay sont possibles: soit le score du joueur à une élection ne dépend que de “caractéristiques” actuelles (est-il digne de confiance? a-t-il de bonnes idées? est-il charismatique? etc) ou dépend-il aussi du passé de ce joueur (a-t-il trahi un autre personnage politique? a-t-il respecté ses engagements? de quel pays/ville/quartier vient-il?). Si le premier cas peut s’assimiler à “un système d’état” (la suite du jeu ne dépend que de l’état dans lequel ce jeu se trouve actuellement), le second s’apparente à un “effet mémoire” (la suite du jeu dépend de son état actuel mais aussi de la façon dont on y est parvenu). Dans ce dernier cas, vous devez mettre cet historique en avant, de façon claire et explicite pour vos joueurs. Si vous ne le faites pas, alors les joueurs n’auront pas toutes les informations nécessaires pour bien comprendre le jeu, et leur progression leur semblera chaotique (ce qui n’est jamais bon pour l’expérience de jeu!).

Tout ce qui peut influencer le jeu doit être explicitement présenté au joueur: si son passé influence son avenir, alors ce passé doit être clairement accessible au joueur. Si vous avez du mal à gérer ce genre de gameplay, passez pas une statistique intermédiaire (par exemple, le “niveau de trahison” du joueur”): les évènements passés modifient alors cette statistiques, et seule cette statistique (pas les raisons de sa modification!) sont utiles pour la suite du jeu.