I. Introduction

Si vous envisagez de vous lancer dans un jeu par navigateur il y a de très fortes chances que votre projet soit sans que vous le sachiez celui d'un jeu dit "asynchrone".

Il y a eu de nombreux débats au sein de la communauté des créateurs de jeux sur ce terme asynchrone et sa définition. Je vais vous présenter dans ce billet ma vision du sujet ainsi qu'une des implémentations possibles et qui a ma préférence : les fameux points d'action ou PA.

Ce billet est assez long alors je vous conseille de vous armer d'un café. Le pire, c'est que j'ai été totalement incapable de trouver un moyen d'illustrer ce billet avec des images en relation avec le thème (asynchronisme et points d'actions).

II. Asynchrone ?

Selon moi, dans un jeu asynchrone les joueurs peuvent jouer ensemble sans être connectés au même moment

Il est ainsi possible de réaliser la même quête, de participer à la même bataille que son collègue, tout en se connectant à des horaires différents. Dans ce sens, un jeu comme World Of Warcraft est qualifiable de synchrone, alors qu'un jeu en navigateur sera asynchrone.

Est-ce un abus de langage ? Peut-être, il est vrai que lorsque l'on regarde la notion de synchronisme et la notion de temps réel (les effets d'une action sont effectifs immédiatement après sa réalisation), on peut arriver à considérer des jeux comme WoW comme étant également asynchrones pour des raisons de limitations techniques (bien que le delta soit pratiquement imperceptible pour l'homme).

Cette notion de synchrone/asynchrone fait débat et il n'existe à ce jour (et à ma connaissance) aucune classification stricte et détaillée des différents mécanismes de jeux.

On retiendra qu'un jeu asynchrone permet à ses joueurs de partager la même expérience tout en jouant à des horaires libres.

Image non disponible
Ceci est un moteur asynchrone triphasé

III. Des actions en temps réel dans un jeu asynchrone ?

C'est à vous de définir quelle expérience vous voulez proposer à vos joueurs. Si vous parcourez un petit peu les jeux déjà existants, vous tomberez sur des choix parfois très différents et cela a un impact direct sur le gameplay.

Si vous mettez en avant le côté asynchrone, vous pouvez mettre en place des résolutions de tours. L'idée ici est que, quelle que soit l'heure à laquelle le joueur réalise une action, l'action ne sera pas tout de suite prise en compte. Par exemple, je donne l'ordre à 12 h 14 d'attaquer le joueur d'à côté, mais l'action ne sera réellement réalisée qu'à 23 heures (heure fixe, commune à tous les joueurs). Dans ce cas tous les joueurs ont donné leurs ordres pendant la journée mais la prise en compte est commune et quotidienne (mise à jour du serveur). Je n'apprécie pas ce fonctionnement, car il manque de fluidité. D'un autre côté, il permet d'assurer un équilibre entre les joueurs : quel que soit le moment où ils jouent, il n'y a pas d'avantage ou de désavantage entre eux.

Je suis pour les actions en « temps réel » à savoir : si un joueur effectue une action, elle est prise en compte tout de suite par le jeu. Donc si j'attaque quelqu'un, il perd de la vie tout de suite. Si j'achète quelque chose, je peux l'utiliser tout de suite après. Je n'aime pas cette sensation d'attente, je ne suis pas patient.

Voici ce que je peux dire de ce modèle « actions temps réel » à partir de ce que j'ai pu constater sur mon jeu (qui dispose de ce modèle) :

Avantages :

  • jeu plus fluide, sensation que le jeu évolue à tout moment ;
  • gameplay plus compétitif : on peut se faire attaquer à tout moment, on n'est pas en sécurité, il faut être réactif ;
  • favorise les actions en commun (joueurs qui se donnent rendez-vous pour jouer « en même temps » : comme pour attaquer la même cible par exemple) ;
  • expérience multijoueur plus riche.

Inconvénients :

  • gameplay plus difficile pour les joueurs ayant une possibilité de connexion limitée et donc moins réactifs ;
  • d'éventuels problèmes techniques lorsqu'il y a beaucoup de joueurs connectés.

La prise en compte des actions en temps réel permet un gameplay très nerveux et compétitif. Sur mon jeu il n'est (ou plutôt n'était) pas rare d'avoir des guerres impliquant plusieurs centaines de joueurs répartis sur seulement quelques cases, ce que l'on appelle des tours de joueurs (les joueurs du même camp se mettant en général sur la même case). 

Les joueurs utilisent des outils de chat en temps réel (MSN, Skype, gtalk, IRC) pour définir une cible et donner un « top » d'attaque, moment où les joueurs vont attaquer en même temps la cible. C'est-à-dire qu'au moment où le leader dit « top », plusieurs joueurs (parfois jusqu'à 10 ou 20) cliquent sur le bouton attaquer

On appelle cela une "synchro" (c'est plus ou moins ce que l'on appelle ganking sur les jeux en ligne : s'attaquer en groupe à un pauvre joueur et le massacrer). La cible n'a que très peu de chance de survivre, car entre le moment où il reçoit le mail de la première attaque et le moment où il se connecte pour se soigner, il a pris une, dix, voire cinquante attaques (et est sûrement mort).

Image non disponible

III-A. Que penser de ce mécanisme ?

Pour certains il décourage les joueurs qui peuvent se sentir impuissants. Il s'agirait alors d'un abus du système puisque l'on mixe asynchronisme et actions en temps réel. En gros, c'est comme si on disait "Vous pouvez jouer à l'heure que vous voulez, vous êtes libre", mais qu'en réalité on ne garantit pas la survie du joueur.

Pour moi, ce mécanisme est un des points forts du gameplay qui est volontairement exigeant et compétitif. Le PvP (joueur contre joueur) est très mis en avant, probablement trop pour certains joueurs…

À noter que 200 joueurs connectés de 18 h à 21 h en période de guerre, et qui rafraîchissent en boucle la page de personnage pour vérifier leurs points de vie, cela fait mal à un serveur et qu'il faut savoir encaisser une telle charge.

Le temps réel favorise la communauté et les actions en commun, car les gens cherchent constamment des joueurs pour les aider contre telle ou telle cible (synchro improvisée). S'ils ne se connaissent pas (pas de chat en temps réel), ils fixent simplement une heure par message du style « On attaque Zozolemoche à 18 h ça te va ? ».

Des actions en temps réel c'est également la joie de recevoir un mail « Attention, vous avez été attaqué ! » en pleine réunion et ne pas pouvoir réagir.

Image non disponible
Ce superbe sèchecheveux rouge est doté d'un moteur asynchrone

IV. Les points d'action (PA)

Qu'est-ce qui se cache derrière tout cela ? Les points d'action. À vrai dire, je ne sais plus quel a été le premier jeu à utiliser ce système, je me suis inspiré de Nainwak auquel je jouais en 2002 et qui avait sûrement remarqué le mécanisme ailleurs.

Le principe est très simple, on distribue les points d'action (ou PA) aux joueurs selon une règle basée sur le temps « réel » (dans la vraie vie). Par exemple on gagne un PA par heure, ou un PA par jour ou un PA par minute… Il est indispensable d'avoir un maximum en nombre de PA stockables (un nombre au-delà duquel on ne gagne plus de PA).

IV-A. Pourquoi des PA ?

La raison de ce fonctionnement est évidente, il faut limiter le nombre d'actions par jour des joueurs. Puisque le jeu n'est pas un jeu synchrone classique comme WoW, on ne veut pas (trop) privilégier ceux qui peuvent se connecter plus qu'un autre. Ainsi grâce aux PA, un joueur qui se connecte deux minutes pourra réaliser le même nombre d'actions qu'un joueur connecté 24/24.

Les mécanismes par PA sont assez intuitifs et assez présents sur la planète jeux web, donc souvent déjà maîtrisés par les joueurs.

IV-B. Combien de PA donner aux joueurs par 24 h ?

C'est à vous de le décider, cela fait partie de la phase de conception. En réalité il ne faut pas penser en nombre de PA mais en nombre d'actions. Inutile de gagner 5000 PA par jour si se déplacer d'une case coûte 4563 PA…

Bon alors, quelle capacité de jeu donner aux joueurs ?

Pour information, sur mon jeu les joueurs disposent toutes les 24 h de 48 PA (avec un maximum de 50) avec un coût moyen par action de 4 PA, soit 12 actions par jour. On gagne un PA par tranche de 30 minutes.

IV-C. Quel coût en PA par action ?

Il n'y a pas de réponse à cette question, car cela dépend (heureusement) des jeux. Je peux néanmoins vous orienter vers l'idée de donner des coûts différents aux actions selon leur type.

Par exemple :

se déplacer = 3 PA ;

manger une pomme = 1 PA ;

attaquer une mouche du démon = 5 PA ;

etc.

Les joueurs pourront ainsi plus facilement gérer leurs PA et vous pouvez orienter le gameplay rien que par le coût de chaque action. Si un soin coûte 20 PA et une attaque 2 PA, attendez-vous à un jeu costaud. À l'inverse, si vous mettez un coût faible en PA aux actions de craft (métiers, création d'objets) ou de diplomatie, le jeu devrait être plus calme.

Penser à faire des projections !

Il y a trois paramètres essentiels :

  • taux de régénération des PA : on gagne 1 PA tous les combien ? (1 heure ? 1 jour ? 1 minute ? 24 minutes et 34 secondes ?) ;
  • nombre maximum de PA que le joueur peut posséder ;
  • coût en PA de chaque action.

Il faut réaliser des simulations pour trouver le modèle correspondant au gameplay que vous cherchez.

Par exemple voici deux configurations de PA possibles et ce que l'on peut en dire :

  • 1 PA par heure, 12 PA max, 2 PA déplacement, 1 PA attaque, 3 PA soin des autres joueurs
    • jeu assez exigeant en présence : nécessite deux connexions par jour car 12 PA au max (donc le joueur doit se connecter une fois par tranche de 12 h),
    • jeu agressif (PvP) car déplacement et soin plus cher que l'attaque : favorise l'attaque de joueur,
    • scénarios pour le maximum de PA (ici 12) :
      • 6 déplacements 0 attaque 0 soin,
      • 0 déplacement 12 attaques 0 soin,
      • 2 déplacements 8 attaques 0 soin,
      • 0 déplacement 0 attaque 4 soins,
  • 2 PA par heure, 100 PA max, 2 PA déplacement, 10 PA attaque, 5 PA soin des autres joueurs
    • jeu souple 100 PA max que l'on peut stocker correspond à 50 heures soit plus de 2 jours : correspondra aux plus occasionnels,
    • jeu pas très agressif à la vue du prix en PA de l'attaque moins intéressante que le soin. De plus le coût assez faible du déplacement facilite la fuite. Si attaquer et soigner rapportent tous les deux un point d'expérience, les joueurs ont une forte tendance à choisir le plus faible coût des deux pour rentabiliser leurs PA, ici le soin !
    • scénarios pour le maximum de PA (ici 100) 
      • 0 déplacement 10 attaques 0 soin,
      • 50 déplacements 0 attaque 0 soin,
      • 0 déplacement 0 attaque 20 soins,

Il est important de savoir quel nombre d'actions pourra être réalisé avec le nombre maximum de PA car beaucoup les stockent : ils attendent 24 h avant de jouer.

Évidemment évitez les trucs bien lourds du style :

261 PA par heure, 789 PA max, 38 PA déplacement, 13 PA attaque, 34 PA soin…

Prenez des nombres avec des multiples simples (1, 2, 3, 4 et 5) vos joueurs vous remercieront de ne pas avoir besoin de sortir une calculette à chaque fois.

IV-D. Techniquement

Techniquement les PA sont faciles à mettre en place, il suffit de stocker les horaires de dernière connexion.

PA actualisés (nouveau nombre) = ancien nombre de PA + (delta de temps entre les deux connexions * nombre de PA par heure).

Si l'on gagne 1 PA par heure :

Dernière connexion 12 h 15, nombre de PA à la déconnexion : 2

Heure actuelle 13 h 45 donc PA actualisés = 2 + (13 h 45 - 12 h 15)*1 = 2 + 1,5 = 3,5 PA

IV-E. Les PA et les joueurs

On peut distinguer deux comportements différents vis-à-vis des PA :

  • « l'impatient » : réalise une action dès qu'il le peut. Dès qu'il a ses 4 PA, il porte un coup à sa cible, se déplace, etc. ;
  • « le patient » : il attend d'avoir le nombre maximum de PA pour optimiser son utilisation comme porter le plus grand nombre de coups consécutifs (avec le maximum de PA) pour avoir plus de chances de tuer la cible. C'est aussi pour cela qu'il faut arriver à gérer l'impact que l'on peut avoir sur le jeu avec le nombre de PA maximums utilisés en une seule fois.

Les PA c'est aussi assez sournois :

Imaginez un joueur dont le personnage est agonisant, au milieu de trois ennemis. Le joueur sait qu'il va mourir si on l'attaque et qu'il perdra l'équivalent en expérience de deux semaines de jeu. Mais il n'a plus de PA et doit attendre trois heures pour pouvoir fuir… 

Le joueur sait aussi qu'il est une heure trente du matin et qu'il a une réunion importante tôt demain matin…

Que faire ? Je dirais que 20 % des joueurs vont quand même mettre un réveil à 4 heures 30 du matin pour essayer de s'en tirer ;-) 

Certains joueurs n'hésitent pas à se réveiller au milieu de la nuit pour achever un joueur, récupérer un objet ou essayer de fuir un combat. Merci les PA !

Image non disponible

V. Remerciements

Merci à DA de nous avoir permis de publier ses articles que vous pouvez retrouver sur son blog .

Merci ClaudeLELOUP pour sa relecture orthographique.