Avantage d'un jeu asynchrone par rapport à un jeu en temps réel

[janeo]

Bonjour,

La plupart des jeux PHP sont souvent limités techniquement et sont donc obligatoirement asynchrones. Ça peut sembler n'avoir que des inconvénients mais il se trouve que c'est en partie ce qui fait la force des jeux PHP : les joueurs n'ont pas besoin d'être connecté en même temps pour jouer ensemble.

Quels sont selon vous les avantages des jeux asynchrones et surtout comment peut-on exploiter au maximum cette caractéristique avec le gameplay ?

Pour plus d'informations je vous renvoie à un article de lichen, un game designer : http://eteule.blogspot.com/2008/04/les-m...oniss.html

Merci d'avance de vos réponses.

[Seren]

Je trouve l'article un peu fourre tout et mal structuré (et très influencé par Wow).

Par contre je ne pense pas que les jeux webs sont forcément asynchrones parce que limité "techniquement". La vraie limite c'est plutôt d'avoir assez de joueurs pour qu'ils soient connecté en même temps. Je me souviens sur Tour de Jeu, de quelqu'un qui avait créer un jeu synchrone : il fallait être au moins deux pour jouer une partie.

Bien qu'il ait créé tout un système d'agenda, de messagerie entre ces joueurs, impossible d'avoir assez de joueur en même temps. Et c'est un effet domino, si il y a jamais personne connecté, ça donne pas plus envie de se connecter...

Par contre dans l'article, il y a au moins un élément intéressant : c'est de permettre aux joueurs de façon asynchrone, de pouvoir vendre/acheter, des objets ou des services. C'est certain que d'implémenter ce genre de fonctionnalité ça permet plus d'intéractions entre les joueurs.

Quelque chose que j'ai rarement vu, et qui pourtant est une fonctionnalité géniale (de mon point de vue), c'est d'employer un autre joueur pour une tâche quelconque :
- porter un message
- protéger quelqu'un
- attaquer/assassiner quelqu'un d'autre.

Ce n'est pas facile d'implémenter ce genre de contrats, parce qu'il y a pas mal de possibilité, et qu'il faut prévoir le cas où le contrat n'est pas rempli et comment dédommager l'employeur ou l'employé.

Un cadre rigide n'est pas obligatoire, on peut se reposer sur la "bonne foi" d'un autre joueur, mais le problème c'est que trop souvent on ne peut pas faire véritablement confiance à un autre joueur, la trahison est souvent plus facile, et il n'y a pas de pénalité.

[Kasparov]

Pour moi, l'obligation d'être connecté en même temps que quelqu'un pour pouvoir jouer est un frein. J'aime bien pouvoir me connecter n'importe quand et pouvoir réaliser mes actions comme et quand bon me semble, sans avoir besoin de me soucier de la présence d'une tierce personne. Voilà donc l'intérêt principal que je trouve aux jeux asynchrones

[keke]

La plupart des jeux PHP sont souvent limités techniquement et sont donc obligatoirement asynchrones.

C'est pas parce que la technologie est asynchorne que le jeu l'est lui aussi ^^. C'est pas du temps réel non plus, mais avec AJAX, tu fais des trucs de l'ordre de la demi-seconde près, ce qui est largement suffisant pour donner de la fluidité à un jeu.

Après, je pense que ça vient de la mentalité du jeu. Si on devait refaire Wow en PHP, je crois qu'on serait perdant ... Les jeux en PHP font preuve d'originalité là où les grands studio peuvent se permettre de faire preuve de technicité.

Quels sont selon vous les avantages des jeux asynchrones et surtout comment peut-on exploiter au maximum cette caractéristique avec le gameplay ?

En mon sens, les jeux temps-réel peuvent avoir les mêmes avantages que les autres ... Il n'y a pas d'aspect plus positif à être asynchrone.

La gestion du déplacement par groupe sur Hordes est un clin d'oeil sur les tentatives quasi temps réel ^^. Le but étant de se déplacer dans un désert, case après case, en restant groupé au maximum pour pas se faire bouffer par les zombis. C'est floklo à mener, mais c'est une franche partie de rigolade de se voir courir autour des zombis en se disant que si l'un des joueurs se vautre, c'est tout le groupe qui en pâti.

L'aspect synchronisation a donc 2 significations bien distinctes :
- à opposer au temps réel : lorsque 2 joueurs sont connectés en même temps, qu'elles intéractions peuvent-ils mener ? Voient-ils les actions de l'autre ?
- à rajouter à la notion de service par correspondance : lorsque l'autre n'est pas là, quelles actions puis-je faire en interaction avec lui ? (on parle de monde persistant : le joueur est absent mais son personnage vaque à ses occupations tout seul.)

En prenant mon jeu comme exemple, voici des idées qui pourraient aller dans les 2 sens :
- Voir sur la carte le déplacement des autres joueurs (une table histo, une requête AJAX, un peu de graphisme ... c'est pas sorcier je pense).
- Un système de ventes aux enchères à prix caché.(Un joueur y inscrit l'objet à vendre et un délai ; les acheteurs indiquent le prix qu'ils souhaitent payer en cachant leur réponse. Le jour J, l'acheteur ayant donné un prix le plus élevé remporte la vente.)
- Un système de compétence passive. Le joueur A est forgeron et se trouve en ville. Il est déconnecté. Le joueur B arrive en ville voit le forgeron, négocie de manière automatique le prix de réparation. A bien qu'étant déconnecté va travailler pour réparer l'objet de B.
- ...

Les idées sont multiples et peuvent s'appliquer à tout type de jeu ^^. Sur Dinoland (je joue pas mal aux jeux de la Motion Twin ces temps ci ^^), il est possible de combattre des joueurs déconnectés. C'est la raison pour laquelle je vais abandonner ce jeux car il est pas assez bien équilibré ^^.

Voilou, mes 2 centimes ^^

Kéké

[Ebe]

Je trouve l'article un peu fourre tout et mal structuré (et très influencé par Wow).

Oui non mais attendez, il ne faut pas croire que l'auteur parle de jeux web. Il s'agit du lead game designer de Dofus, donc ce jeu parle de MMORPG. Et Lichen est davantage fan d'Eve online que de Wow. Ça ne veut pas dire que la problématique ne peut pas être discutée sur un cadre jeu php, simplement que c'était pas du tout son sujet initial.

[Zamentur]

En prenant mon jeu comme exemple, voici des idées qui pourraient aller dans les 2 sens :
- Voir sur la carte le déplacement des autres joueurs (une table histo, une requête AJAX, un peu de graphisme ... c'est pas sorcier je pense).

Sauf que faut pas oublier qu'AJAX ne permet pas une connection bidirectionnelle avec le serveur.
Dans le sens que le serveur ne peut pas prévenir un client qu'il y a du nouveau. C'est au client de demander.

Tant que le client fait quelques chose, il est possible de demander si il y a du nouveau au passage, çà coute pas grand chose

Mais si le client ne fait rien, il faut alors faire des demandes toutes les x secondes. En prenant en compte que les demande ne mettent pas la même vitesse à parvenir au serveur. Et qu'il y a aussi le temps de réponse. Tant que le x est assez important pas de soucis, mais je ne pense pas que ce soit viable de vouloir du temps semi-réel plus précis qu'à 10 seconde prés avec ce système.
Sans compter les performances serveur plus élevés nécéssaire...

Bref techniquement, AJAX ne semble pas la meilleur solution, il vaut mieux se tourner vers des solutions par connexion socket. Autrement dit utilisation d'un plug in.

[keke]

[spoil]
10 Secondes de latence, c'est largement au dessus d'Ultima On Line, qui sait pas privé pour prendre des parts de marchés dans les jeux en lignes Temps Réels ^^
[/spoil]

Même sur les grands jeux, la latence est un facteur qui est important. La distribution des datas est énorme sur certains jeux comme Diablo ... Après, la manière employée pour donner l'impression qu'on joue en local est plus ou moins poussée et se base principalement sur du recalcule théorique de donnée ... on peut ainsi voir des joueurs qui marchent contre les murs, des sorts dont l'effet est produit avant que l'animation du lancement du sort ne se fassent ...

Je pense qu'il est possible de faire de très belles choses avec AJAX ... et pour la suite du sujet je pense que même une latence de 10 secondes permet à un jeu PHP d'être considéré comme du temps réel. Par contre, ça n'empêche pas d'évoquer les avantages des actions asynchrones.

Kéké qui va se battre avec les transports en commun ... (45% de RER Bassuré, puis 50% de RER A ... bouh ^^ ... je vais passer 3h30 pour rentrer)

[Seren]

Je trouve l'article un peu fourre tout et mal structuré (et très influencé par Wow).

Oui non mais attendez, il ne faut pas croire que l'auteur parle de jeux web. Il s'agit du lead game designer de Dofus, donc ce jeu parle de MMORPG. Et Lichen est davantage fan d'Eve online que de Wow. Ça ne veut pas dire que la problématique ne peut pas être discutée sur un cadre jeu php, simplement que c'était pas du tout son sujet initial.

Je ne savais pas qu'il travaillait pour Dofus, mais pour autant ça change pas mon avis sur la forme de l'article. Il n'y pas de progression, d'articulations logiques entre les différentes parties, c'est plutôt une suite de digressions et de parenthèses qui sont vaguement reliées.

Et j'ai parcouru le dernier article sur l'économie des MMOs, il y a vraiment des idées naïves, notamment des comparaisons avec l'économie réelle.

Ca m'étonne vraiment qu'il soit lead designer, je pensais que c'était plutôt un blog d'enthousiase un peu brouillon.

PS : je ne dis pas qu'il n'est pas compétent professionnellement, c'est certainement le cas, mais les postes de son blog sont très destructurés. C'est plutôt des idées écrites en coup de vent que le fruit d'une reflexion poussée.

[Ebe]

C'est effectivement son truc, d'écrire ce qui lui passe par la tête. Il me semble qu'il explique sa démarche sur son premier billet.

Pourquoi naïves ? L'économie de Dofus a fait l'objet de quelques thèses sur le sujet. On y trouve une réellement bonne représentation de marchés, très vivant et assez passionnant à étudier (même simplement dans le but de jouer).

Je n'aime pas tous les systèmes de ce jeu, mais en soi globalement c'est du bon boulot. Après je ne sais pas si c'est réellement le premier mmo joué en France (c'est ce qu'Ankama dit), mais c'est au moins le deuxième et il doit bien y avoir une bonne raison à ça.

Enfin on tombe à coté du sujet. ^^ A la base je voulais juste dire qu'il parlait d'éléments asynchrones dans un tout qui ne l'est pas (enfin si, mais on se comprend).

[janeo]

Bonjour et merci à vous pour vos réponses. Comme l'a dit keke il faut distinguer deux types d'interactions dans un jeu en partie ou totalement asynchrone.

1 - Interaction entre un joueur en ligne et un personnage automatisé de joueur hors ligne

Comme certains l'ont évoqué, un grand intérêt des mécanismes sociaux désynchronisés est de permettre aux joueurs de configurer leur personnage pour que quand ils sont hors ligne celui-ci continue à vaquer à ses occupations, donnant ainsi vie à l'univers du jeu et permettant aux autres joueurs d'interagir avec lui.

Avantages :

- Tous les joueurs ont du poids en jeu, même les joueurs occasionnels. Par exemple lors d'une guerre de longue durée le personnage d'un joueur déconnecté peut continuer à combattre. Pas besoin d'être un nolife pour défendre sa patrie ^^.

- Aucun délai d'attente lors de l'interaction car le personnage du joueur hors ligne est automatisé donc il réagit de manière très rapide. Ou dans le cas des hôtels de vente l'achat d'un objet est immédiat, pas besoin de négocier.

- Ça ajoute un élément de jeu supplémentaire : le joueur doit configurer les actions de son personnage quand il sera hors ligne. Il peut par exemple créer des dialogues automatiques pour son personnage.

Intégrer cela dans un MMORPG en "temps réel" est une mauvaise idée selon moi car la confusion possible entre les personnages des joueurs en ligne et les personnages automatisés des joueurs hors ligne pourrait devenir agaçante. L'interaction entre les joueurs en ligne serait mise à mal par les personnages automatisés. Par contre dans un jeu exclusivement asynchrone ce problème ne se pose pas, donc l'idée est bonne.

2 - Interaction entre deux joueurs en ligne mais à des temps différents

Le délai entre l'action du premier joueur et celle du deuxième joueur peut avoir des avantages :

- Le gain de temps pour le premier joueur : celui-ci envoie une requête à un joueur puis passe à autre chose. A sa prochaine connexion il connaîtra tout de suite la réaction/réponse de l'autre joueur.

- Le temps de réflexion offert au deuxième joueur : il est plus facile de répondre intelligemment à un message privé que quand on répond au tac au tac dans un chat en temps réel.

Le problème de ce mode de fonctionnement est le ralentissement de l'action qui peut se révéler ennuyeux.