Le Biais Des Jeu Asynchrone, (réaction au blog)

Je viens de lire le 2ème message d'Oelita sur les jeux asynchrones, et voici mon analyse de la situation : nous nous trouvons en réalité devant un problème technique, assez difficile à résoudre dans le cadre du jeu amateur.

Je m'explique.

On peut dire qu'au départ de la discussion, nous avons Oelita qui critique un aspect des jeux PHP asynchones à actions immédiates, type TopDélire - appelons les "jeux PHP" pour faire court, même si tous ne sont pas en PHP, et que des jeux qui ne correspondent pas à ce profil sont codés en PHP.

Oelita observe que les jeux PHP présente des biais (des inégalités structurelles) dues
- à l'effet immédiat des actions entreprises
- à l'optimisation de jeu offerte aux seuls joueurs qui peuvent se connecter à une heure précise

En réalité, ces deux causes sont liées : c'est parce que les actions sont immédiates que celui qui peut se loguer à heure fixe aura un avantage massif.

On pourrait appeler cela un effet de rendez-vous, que le rendez-vous se fasse avec le maître du jeu, pour profiter d'une enchère, avec les joueurs alliés, pour combiner des attaques massives, ou avec soi-même, pour jouer deux tours à 5 minutes d'intervalle (tactique du Berzerk à Nord vs Sud, et surtout connu sous le nom de cumul, par exemple sur Delain).

Pour ma part, à côté de l'idée de rendez-vous actif (je me logue à l'heure prévue pour un événement connu), je voudrais distinguer le rendez-vous passif (je me logue toutes les 5 minutes pour chopper la super occase qui va bientôt arriver, mais je ne sais pas quand). Je pose cette distintion maintenant, au cas où, elle pourra peut-être me servir plus tard.


En attendant, je lis les commentaires du blog de Oelita, et j'en retire une idée forte, c'est qu'il y a des jeux où l'effet de rendez-vous est absent :

- nojhan donne l'exemple d'E-Sub "où il n'y a pas les problèmes de synchronisations décris par Oelita".
- Corentin dit : "je crois que la seule solution est le système de résolution de tours : on donne ses ordres, qui seront résolus à un moment précis"
- C'est ce que Kalan appelle le jeu "totalement asynchrone" (et il donne pour exemple Nébula, Daifen ou Gloire et Pouvoir).

Prenons Nébula, e-sub et G&P, et regardons ce qui leur manque par rapport aux jeux comme taupe Délire :
- Nébula, il faut télécharger Nébutil (nostalgie, nostalgie, le temps où on rédigeait les ordres à la main)
- G&P se fait sur un plateau très ouvert : on ne connaît pas toutes les infos sur les armées adverses, mais connaît la situation globale. On en sait suffisamment pour avoir du mal à s'identifier fortement à un camp (dans e-sub, le joueur ne voit que ce que voit ses sous-marins, et idem avec Nébula).
=> Il manque à G&P une dimension "exploration". Le jeu reste trop proche de Diplo ou de Risk.

Et surtout, surtout, il manque une fluidité, qui rend le jeu finalement très dur à suivre. On fait des ordres. OK. Mais le temps que tout le monde ait fait les siens, on a eu le temps d'oublier où on en était. Que se passe-t-il si X ou Y oublie de faire ses ordres ? Soit on bloque le jeu pour attendre le retardataire, soit on déséquilibre le jeu en laissant les unités du joueur absent à la dérive : bonus pour les voisins hostiles, malus important pour les alliés, en particulier à Nébula.

Les jeux PHP à résolution immédiate offre la fluidité : le joueur qui ne joue pas est rapidement éliminé. le jeu continue naturellement sans lui. On n'a pas besoin de définir un point de rendez-vous d'arbitrage : l'unité temporelle de base (la durée d'un tour de jeu) peut alors être réduite. En réduisant cette unité temporelle de base, on peut segmenter les actions (il y a moins d'actions par unité temporelle de base, mais sur une semaine, on a plus joué). De là vient la fluidité.

Bref, on voudrait supprimer l'effet de rendez-vous, mais on voudrait garder la fluidité, c'est-à-dire garder la possibilité de jouer quand on veut. La première solution, c'est de donner des points d'actions de manière continue. Mais ce n'est pas suffisant : dans les jeux qui utilisent cette solution, il est toujours possible d'économise ses points d'action pour les dépenser d'un seul coup, en donnant un rendez-vous aux copains.

Ce qu'il faudrait, c'est supprimer l'arbitrage à date fixe, qui est une contrainte lourde et qui fige le jeu, mais garder le principe d'une résolution équitable pour tous les joueurs. La solution facile à imaginer, c'est l'arbitrage en continu : je donne des ordres à mes unités pour quinze jours. Les ordres sont résolus petit à petit, chacun à son tour, avec un long délai entre chaque action.

Si je me logue au bout de 2 semaines, je vois le résultat de mes ordres sur 2 semaines. Mais si je ne me logue au bout de 2 jours, je peux voir le résultat des 2 jours passés. Je peux laisser mes ordres tels qu'ils sont, ou bien les modifier, et repartir pour 2 jours ou pour 10 jours.

Facile à imaginer, mais très difficile à mettre en place. Les difficultés sont de trois ordres :
- jouabilité : si à chaque instant je peux me loguer pour changer mes ordres, certes je ne peux plus profiter d'un rendez-vous actif, mais je peux profiter de l'effet de rendez-vous passif, en me loguant toutes les 5 minutes, pour mettre en place une réaction foudroyante dès que je détecte une bonne occasion (arrivée d'un ennemi). On conserve ici un biais entre celui qui peut se loguer souvent et celui qui ne peut pas.
La solution contre ce biais serait de mettre un délai entre la réaction de 2 séries d'ordres. Si je rédige un ordre maintenant, je ne pourrais plus le faire avant demain.

- programmation : pour avoir la connaissance de ce qui s'est passé depuis mes derniers ordres, je dois "dérouler" le film des différentes actions échues. Avec un jeu PHP, les actions sont journalisées : on peut consulter les actions passées. Ce n'est pas difficile de faire la même chose avec une résolution en continue. Avec une nuance toutefois, car la cohérence du journal n'est pas importante dans un jeu PHP. Ce qui compte, c'estla situation présente. Mais si on veut dérouler le film des événements, il faut que le journal soit cohérent, et parfaitement complet, sinon le film des événements ne permettra pas de retomber sur la situation actuelle.

- programmation (2) : Par ailleurs, si la journalisation permet de reconstruire le film des événements, la question se pose de savoir comment on reconstruit ce film chez le client. Le format du journal doit être suffisamment complet pour qu'il n'y ait pas besoin d'entretenir un moteur des règles sur le client.

- programmation (3) : Mais si le format est très complet, sur le client, ca risque de ramer. Vous connaissez javascript ? Déjà qu'une automap de Delain, au niveau 0, peut mettre un PC un peu ancien à genou. Alors avec une journalisation des actions, si on ne fait pas très attention à ce qu'on fait, on va dans le mur.

- ergonomie : la reconstruction du film chez le client doit se faire de manière simple et intuitive. Mais en même temps, le joueur peut avoir envie d'avoir plusieurs sortes de films : celui depuis la dernière fois qu'il a rendu ses ordres. Celui depuis une semaine. Celui de toute la partie, une fois que cette dernière est finie.

Le seul exemple de film que je connaisse se trouve sur Morne Plaine (fonctionnalité offerte aux seuls abonnés). La fonction est pourtant basique, puisque le jeu est en tour par tour, alternée, avec actions à effet immédiat, en PvP, et que le film se fait par état successif, sans journalisation des actions.


Dernière chose, j'ai l'air de dire que la question posée par Oelita est purement technique. Ce n'est pas tout à fait vrai : la jouabilité, la conception des interactions entre joueur tient une place particulière, mais cela fera l'objet d'un autre post.

En attendant, dans mon jeu idéal, il y aurait :
- un système d'ordres et de résolution en continu
- un film des événements, visualisable à volonté
- un plateau fermé (i.e. je ne connais que la zone où je me trouve), pour entretenir le suspens, avec une ouverture à la fin, pour l'analyse post-mortem
- et tout cela sur un serveur PHP et un client HTML/javascript standard.

Je rêve ?

Archeboc.

PS - les URL vers les sites cités, et d'abord le blog d'Oelita avec ses commentaires :
http://www.tourdejeu.net/blog/index.php?20...gne-2eme-partie
http://www.jdr-delain.net/
http://www.nordvssud.com/
http://nebula.ludimail.net/
http://www.gloireetpouvoir.com/
http://openesub.org/jeu/asynchrone/site/pa...eil/accueil.php
http://www.morneplaine.com/

Une idée que j'avais pour un gros projet qui commencera peut être un jour.

Bon, première chose, ce sera un jeu à PA, avec un stock de PA cumulable assez énorme.
Pour les combats, ou toute action se faisant sur un autre joueur, on fait appel à un script basique d'IA que le joueur a choisi. Celui-ci peut être géré par le joueur en utilisant un système d'API.
Donc, actions subie => "I"A.

Du genre :
- Si je suis attaqué, sortir armes.
- Si blessures trop graves, tenter de fuir dans telle direction.

Je vous laisse imaginer les possibilités annexes que pourrait donner un tel système (pensez sorts d'altération de l'esprit).

Je ne pense pas comprendre super bien le débat, donc je m'excuse si je "poste faux", mais je cherche à comprendre l'essence du truc.

Actions synchronisées favorisées, c'est ça ?
Dans mon jeu, j'ai peut être réussi sans le faire exprès à contourner ça m(ais les enjeux étant peut être maigres, ça n'a rien de faramineux)

On gagne 1 Point d'Action (PA, sic) par heure, avec un maximum de 28, on peut difficilement faire moins original, je crois ? ^^
Cela impose de jouer au moins une fois par jour, certes, mais ne provoque déjà pas le "zerk", puisqu'avec 1 ou 2 PA, on va pas loin, et avec 28, on fait des actions significatives, mais jamais définitivement importantes.

Bourse ? J'en ai pas, donc pas de soucis là dessus.

Regroupement de joueurs à heure donnée ? Mon jeu est un jeu de siège de castels médiévaux (en gros), donc y'a deux façons de voir la chose :
- l'attaque groupée à heure donnée sera puissante, en fonction du nombre de joueurs, mais rarement déterminante. Certes, dans une situation critique, ça peut facilement faire pencher la balance, mais comme le rythme de mon jeu est assez lent et que le fondement est plutôt stratégique, on peut sans trop de difficultés s'assurer une sécurité face à ce genre d'actions de masse.

- le harcèlement : typique des connexions "toutes les 5 minutes" : d'une efficacité très laborieuse, mais cela permet de miner de manière définitive toute riposte adverse, en empêchant ses productions, ravitaillement, recrutement, et la plupart des actions possibles du jeu (je détaille pas, mais cela pousse au jeu stratégique, et non à une interdiction frustrante de jeu). Mais c'est excessivement long ^^

L'un dans l'autre, on voit de tout : les groupes de joueurs spécialisés dans l'attaque de masse, les double groupes qui attaquent à deux heures données de la journée, et les groupes internationaux (aussi efficaces, ni plus ni moins) du style vietnam-france-canada, qui peuvent harceler joyeusement.
Les joueurs indépendants ne sont pas en reste, puisqu'il contribue forcément à la diversité stratégique, en jouant simplement comme ils ont envie de jouer au moment où ils ont envie de jouer.
Enfin bon, tout cela fonctionne assez bien pour qu'on est jamais vu ce soucis "d'asynchronisme optimisé".

(de plus, l'imposition de la gestion du ravitaillement empêche les joueurs de librement "économiser" ou "dépenser" trop leurs PA : chaque armée doit se nourrir, très régulièrement, et pour cela, il faut un petit lot de PA dépensé de manière quasi-quotidienne)


J'ignore donc si mon exemple fait avancer le débat, puisque je le comprend mal, mais j'espère que ça apporte un son de cloche pas totalement inutile.

Au-delà de ça, je voulais aussi dire que le "zerk" se pratique aussi très bien sur les ordres : dans ogame ou battlecorps, les attaques de masse fonctionnent parfaitement, d'après ce qu'on m'a dit, une fois que l'algo de "temps de résolution d'un ordre" est familier des joueurs. Quand on sait quand notre ordre va être résolu, en gros, on peut "grosbilliser" ses assauts.

Mais sinon j'apprécie pas mal l'idée des ordres en cascade, car tu as alors une gestion de la "réactivité" des joueurs qui peut très facilement t'immerger dans un vrai rôle de commandeur d'armée (médiévale, moderne, futuriste, peu importe), vu que tes ordres peuvent être faux, partiellement bons ou très chanceux quand à leur interactions avec le jeu des autres.
Et ça n'impose pas une connexion très régulière (hebdomadaire suffirait) tout en faisant quand même vraiment vivre le jeu de manière quotidienne.

Sans vraiment revenir sur le post de L_abruti (quel pseudo !) cela pourrait quand même effectivement se relier sur l'idée d'IA, si on poussait le raisonnement dans ses retranchements, non ?

Ma question n'est pas tant de savoir si un système est mieux qu'un autre, finalement. C'est de constater que la techno PHP a permis de nouvelles règles de jeux qui jouent sur le temps, et s'éloignent du jeu par correspondance "originel".

Après, bien ou mal, chacun ses goûts, et il y a en effet plein de variantes différentes. Mais il faut en effet que le créateur du jeu soit conscient de ça, et prenne en compte les éléments dont je parle, qu'il intègre ça dans le gameplay. Qu'il pense à mettre des limites et des garde-fous dans certains cas.

Et le but de l'article était aussi de revenir sur ce choix du terme "asynchrone" qui me parait de moins en moins adapté à nos jeux, alors qu'il plaisait pas mal à une certaine époque.

Excellent article, bonne analyse et tout et tout.

Merci de cette contribution d'une grande valeur à mon avis.

Je crois que tu as mis le doigt sur les éléments clés à analyser lors de la conception d'un jeu "asynchrone" sans point de synchronisation.

Kalan

Le probleme du joueur qui ne joue plus, il est le même qu'on soit au tour par tour ou par un autre système de jeu.

Sinon, forcément, le tour hebdomadaire n'est pas bien adapté à un jeu où on fait peu d'ordres et pas de diplomatie, et où il ne se passerait rien entre deux tours !
Mais à Nebula, la diplo t'occupe largement pendant ta semaine (sauf au début de la partie, mais à ce moment-là, justement, on fait plutot 2 tours par semaine pour accélérer).
A ATM, on avait les résultats du tournoi qui arrivaient avec suspense chaque jour.

Ca ne me semble pas moins fluide qu'un jeu à PA où tu fais péniblement une pauvre action un peu conséquente chaque jour avec un manque de vision globale. C'est souvent très court-terme, et peu stratégique. Na.

Les séries d'ordres qui s'enchainent, c'est un autre mécanisme qui peut être rigolo, on se rapproche un peu de la programmation, en effet :-)
Dans Ultraball, jeu de sport par équipe, tu définis ainsi toute ta tactique de jeu en précisant la suite d'actions de chacun de tes joueurs, avec des temporisations, des passes... et puis après, quand le tour est passé, le match entier se déroule sous tes yeux (via un outil téléchargé), où tu vois les actions de l'adversaire qui intérfèrent avec les tiennes, et le hasard qui intervient aussi sur les tirs et les passes, et c'est très rigolo (même si on s'arrache les cheveux assez souvent).
Par contre, c'est quand même un jeu à tour fixe.

Combat Mission (jeu de stratégie réaliste, commercial par contre) semble utiliser un système proche d'UltraBall (que je ne connais pas), mais incorpore une autre petite chose sympa :

On donne ses ordres pour la minute qui vient, pour ça, on est dans une phase spéciale, le temps n'avance pas. Après, on passe à la résolution, qui comme dans UltraBall est simultanée, c'est là qu'on se rend compte que le petit bosquet inoffensif devant lequel passe notre panzer sert de refuge à un bazooka et que notre tank qui devait pourtant sauver ce front va se faire exploser sous nos yeux. La différence dont je parlais plus haut est cette surprise supplémentaire : on ne sait pas ce que va faire l'autre joueur, mais en plus, on ne sait que ce que notre armée voit, et parfois elle se trompe. Parfois on croit avoir entendu un bruit de tank alors qu'il ne s'agit que d'une jeep (vaut mieux ça que l'inverse, remarquez). Parfois on croit un pâté de maison abandonné alors qu'il est truffé de lance-flammes. Et on ne sait pas non plus ce que l'ennemi a vu, parfois l'attaquant pense avoir fait toute une progression cachée dans les bois, mais le défenseur connait déjà la composition exacte de ce groupe.

Voilà j'apporte pas grand chose au débat, mais c'est un tellement bon jeu que je devais en parler

Tout cela est intéressant cependant il manque à mon avis une distinction fondamentale entre trois catégorie de jeux pour lequel il ne peut y avoir un modèle unique. Et cette distinction porte essentiellement sur le nombre de joueurs qui jouent.

A - Le jeu à partie infinie (univers persistant ou assimilé) massivement multi-joueur.
NORD vs SUD, IDEO, CONTINENT, ARCHIPELS online, Les O-Game like, ...

B - Le jeu à partie finie multi-joueur.
Gloire et Pouvoir, Comtes et Conquêtes, ...

C - Les jeux à partie finie non multi-joueur.
Morne Plaine, ...

- un système d'ordres et de résolution en continu
... Peut s'appliquer pour A mais pas pour B, où par définition la résolution se fait en simultanée à un moment donné.

- un film des événements, visualisable à volonté
... Peut s'appliquer pour B, C, mais difficilement pour A.

- un plateau fermé (i.e. je ne connais que la zone où je me trouve), pour entretenir le suspens, avec une ouverture à la fin, pour l'analyse post-mortem
... Peut s'appliquer pour A mais pas pour B, ni C.

- et tout cela sur un serveur PHP et un client HTML/javascript standard.
... Cette remarque sort du cadre car la technologie est un moyen et non une fin, le principe étant que nous créons tous des jeux qui se jouent à l'aide du navigateur (du moins dans une très grande majorité...).

Le concept se rapproche à mon avis du temps réel, mais avec une vitesse de jeu très faible. Du temps réel lent, en somme.
Je connais des trucs du genre, mais en client lourd :Artifact par exemple.
J'ai plusieurs projets basés là dessus mais outre le manque de ressources (humaines = du temps), le système est quand même un peu bancal puisque ni du temps réel (je me fais une petite partie vite fait en 2h), ni de l'asynchrone (je joue 1 fois par jour/semaine)

PS : message à déplacer dans "Règles de jeu" à mon avis

Je le pense aussi.

Je vais prêcher pour ma paroisse mais puisqu'on est jamais mieux servit que par soit même

Sur Babylon 5 nous avons un rythme qui est de 1 tour par semaine.

Nous utilisons le php comme interface pour les joueurs et le java pour le moteur qui résout le tour et il n’y a aucun client d’aucune sorte à télécharger, juste besoin du navigateur.

Les joueurs qui sont inactifs sans avoir averti l’équipe de gestion sont effacé au bout de 3 tours.

Il n’y a donc pas d’inégalité, chacun à une semaine pour faire ses ordres et celui qui les rendra à la dernière minute sera traiter comme celui les rendant dès la fin du tour précédent.

Donc je serai plus dans la catégorie A de Welldone tout en ayant un système de jeu complètement différent d’un Ogame par exemple puisque nous sommes tout les deux dans l’univers space opéra.