|
|
Publié par Nob Proudfoot
Respectivement, 8 mois, 6 mois, 3 ans, 1 an.
Et oui UO est très profond mais même trop c'était vraiment le bordel monstrueux car il y avait trop de libertés mal utilisées par les player.
SwG j'ai eu l'impression de jouer à Lost Eden. Super beau, super vide. Et les factions étaient super mal gérées, à aucun moment je n'ai eu l'impression de vraiment participer à un vrai conflit.
Cette avis n'engage que moi, il y a même des gens qui trouvent que daoc est vachement fournis en PvE comme quoi...
Enfait je ne parlais pas de l'intérêt ou de la qualité des MMORPGs cités mais uniquement de la liberté d'action. Et de ce point de vu là, le modèle Ultima Online/SWG pré NGE sont loin devant le reste.
Enfin ne te formalise pas, j'avais fais ce reply sur un coup de tête, je m'en excuse.
Sinon j'avais un peu de temps à perdre et vu qu'il était vraiment tendu à traduire, je me suis essayé au texte posté par Felagund. Normalement le sens est conservé mais il est possible qu'il contienne des lourdeurs syntaxiques, dites moi ce que vous en pensez:
La perte de connexion est quelque chose que nous ne pouvons pas gérer; vous devez maintenir votre connexion pour d’évidentes raisons (au moment de mourir, débranchez la prise !)
La latence internet est quelque chose totalement à part, et c’est un domaine sur lequel nous avons passé un temps considérable, nous concentrant sur la notion de temps réel. En fait, une grande partie du modèle de combat est dérivé de solutions aux problèmes de latence, tout comme le langage dans lequel nous l’avons écrit.
Dans un modèle de latence des MMPs (Ndt : MMPs = MMORPGs) traditionnels, le client initie une action, qui est envoyée au serveur pour être résolue. Le serveur renvoie les résultats, et l’utilisateur voie l’action se dérouler au niveau du client. Cela créer un délai considérable entre le moment où vous appuyez sur le bouton, et le moment où l’action se déroule. Parfois, cela peut être caché par des actions autonomes (comme une animation de substitut jouée jusqu’au retour du message serveur), mais généralement cela donne un sentiment de lenteur.
Dans l’idée, vous pourriez comparer notre approche à une compensation de la latence par l'IA. Je ne vais pas rentrer dans les détails techniques maintenant. (Je vais garder cela pour la (GDC ?) de l’année prochaine), mais fondamentalement si vous avez un ping compris entre 0 et 500 ms, la majeur partie des actions peuvent se synchroniser correctement au niveau du réseau sans se soucier de ce temps de latence.
Travailler avec le modèle de latence requière un état d’esprit différent pour concevoir et programmer. L’information envoyée par le client ne sera pas reçue avant un certain temps après qu’elle ait été traité; et l’information envoyée par le serveur ne sera pas reçue par le client avant un certain temps après qu’elle ait été traité.
Cependant, le serveur peut décider, de manière préventive, l’action des monstres et envoyer cette information au client en avance; dans le latency buffer (Ndt : Je vois ce que c’est mais je n’arrive pas à trouver une expression française satisfaisante), cela permet au monstre d’être représenté correctement au niveau du client. Si le serveur maintient un historique de ce qu’il se passe, il peut remonter le temps pour vérifier les actions du client et reproduire les mêmes résultats au niveau du serveur.
C’est pour cela que parfois je dis que la latence a été compensée par l’IA, parce que l’IA doit décider quoi faire 500ms avant vous.
Maintenant prenons un exemple simple:le blocage. Si nous voulons que les joueurs soient capables de bloquer, nous pouvons le permettre, parce que nous pouvons remonter le temps coté serveur et voir s’ils étaient en train de bloquer au moment où le monstre avait prévu d’attaquer (une seconde après que l’attaque ait été décidé par l’IA).
L’utilisateur a appuyé sur le bouton pour bloquer juste a temps et a envoyé le message au serveur. Le serveur peut remonter le temps et vérifier le blocage, parce qu’il sait a quel moment vous avez bloqué, et à quel moment le monstre a attaqué.
La rétroaction est un cas intéressant, du coté client, vous voyez le monstre réagir quand il est touché. C’est la représentation du fait que vous ayez physiquement touché le monstre, mais vous ne savez pas s’il a subi des dégâts tant que le serveur n’a pas lancé les dés ; donc le nombre des dégâts apparaît un petit temps après. Si les règles de D&D étaient plus simples, nous pourrions probablement avoir, également, cette synchronisation parfaite; donc parfois la complexité des règles rentrera en conflit avec le modèle. (Ndt:Le modèle de latence étudié). Mais pour la majorité des cas, c’est une bonne chose que le monstre réagisse quand il est touché sans prendre en compte les dégâts.
Maintenant, attardons nous au cas des monstres. Disons que nous voulons qu’il bloque. Il ne peut pas réagir aux actions du joueur, parce qu’il prend la décision une bonne seconde avant que l’action du joueur ne soit connue. Mais au lieu de concevoir l’IA pour qu’elle réagisse à une attaque individuelle, nous avons conçu l’IA pour qu’elle prenne des décisions préventives au sujet de ce qu’il va faire. Au lieu de bloquer une attaque individuelle, l’IA va se mettre dans un état qui dit de manière efficace : « Si je suis attaquée maintenant, je vais bloquer ». L’IA n’a plus besoin de réagir aux attaques individuelles ; elle va simplement joueur une animation de blocage pour toute attaque réalisée durant cette état, et tout est parfaitement synchronisé de nouveau.
Donc, pour que les choses se synchronisent correctement, différents mouvements doivent être programmés différemment pour les monstres et pour les joueurs parce nous avons besoin de les penser dans des paradigmes de latence différents. Certaines actions ne peuvent être réalisées que dans le sens monstre -> joueur, ou joueur -> monstre, ou doivent être revues de manière a garder une bonne latence. Par exemple, je ne peux pas initier un knock-down dans le sens joueur -> monstre avec une attaque de corps à corps, parce que pendant que je suis en train d’exécuter cette attaque, le serveur est occupé à communiquer à tous les clients où le monstre sera dans une seconde. Avant que le serveur reçoit les informations concernant les différents évènements, le monstre a déjà bougé du coté client.
Dans l’idée, vous feriez l’action, et une seconde plus tard le monstre s’écroulerait.
Je peux, cependant, utiliser d’autres moyens, respectant la latence, pour obtenir le même effet. Si le joueur verse de la graisse sur le sol (Ndt : Le sort dans D&D), et qu’une demie seconde plus tard le monstre glisse et tombe, c’est tout à fait acceptable.
Donc parfois la métaphore utilisée peut rendre la latence acceptable.
Maintenant, dans ce cas, des joueurs peuvent parfaitement se faire knocked down, donc faites attention à ces charges de minotaures.
Le point est, que la gestion de la latence peut être fait de manière bien plus efficace que dans les MMPs précédents; pour nous, cela était vital.
L’inconvénient est que presque tous les éléments conçus doivent être construits en gardant la latence à l’esprit, ou vous risqueriez de briser l’illusion de la non latence.
C’est également une raison importante a la non présence de PvP au lancement du jeu; les combats joueurs contre joueurs requièrent une approche totalement différente de la synchronisation, et c’est une énorme R&D (Ndt : Recherche et Développement) tache en elle-même. La latence ne peut pas juste être cachée grâce a des subterfuges du serveur parce qu’il n’y a pas d’IA avec laquelle la compenser.
Nous devrons revoir la façon dont nous résolvons certaines actions, comme celles listées ci-dessus, pour que cela fonctionne dans un environnement PvP. Le PvP n’est pas aussi simple que de vous permettre de vous toucher les uns les autres, parce que, au moins dans ce modèle, chaque action doit être synchronisée avec précaution.
Ceci étant dit, la différence de game play vaut l’excès de travail, c’est certain.
|
28/11/2005, 01h30
