Worldedit

[Dracorb]

Testée au Medlay.

En multi y'a carrément pas la même fluidité qu'en solo avec tout les ordis, du coup on en est réduit à utiliser l'action avancer pour pas se planter, et ça avance pas vite.

Après est-ce que ça vient de la map ou de Bnet ...
_________________

Le spotlight de Sivlyna

[Ayane]

Ok, merci d'avoir testé.
Il n'y a pas eu de message d'erreur rouge qui est apparu?
Je vais faire des testes en réseau local et voir ce qui ne va pas.
_________________

[kungfu-sheep]

j'pense qu'il doit y avoir un problème de delay également ?
_________________

22:27:43<Seiraw> Bah y a deux genre de personnes
22:27:57<Seiraw> les soumis et les soumises

[Vladadamm]

J'ai pas encore noté la map, comme il y aura surement des nouvelles versions d'ici la fin du concours.

Petite chose pour améliorer : mettre un nombre de tours réglables ( si au bout de x secondes rien n'est choisi, 5tours est paramétré ) ? -tours 3, -tours 5, -tours 4, -tours 97, ...
_________________

[Ayane]

Version ALPHA3 publiée.
Elle corrige principalement la gestion de l'ordinateur (qui pouvait tourner en rond) et retire la compétence de déplacement.
Un grand nombre de données ont été calculées pour la gestion de l'ordinateur mais ne sont pas prises en compte, son amélioration n'est pas une priorité, son niveau actuel étant satisfaisant.

La prochaine version essayera d'améliorer le réseau.
_________________

[Ayane]

Pour résoudre les problèmes réseaux j'ai étudié le protocole réseau de Warcraft au lieu d'échafauder des théories à tester.
Il en ressort plusieurs choses, premièrement l'architecture est conçut avant tout P2P, c'est à dire que s'il le peut un client ouvre une connexion avec chaque autre client (joueur); s'il ne le peut pas, c'est à dire si aucun des deux joueurs devant s'interconnecté ne dispose du port 6112 (par défaut) ouvert alors ils feront passé leurs paquets via l'hôte (qui lui a forcément une connexion ouverte avec chacun des joueurs). Il en résulte que le mieux n'est pas de disposer d'un bon hôte mais que chaque joueur (un joueur peut faire exception) soit capable d'héberger une partie Warcraft, chaque joueur aura donc une connexion directe au lieu de passer par un intermédiaire ce qui améliora la latence.

En ce qui concerne la carte elle est constitué de deux principaux type de déclencheurs s'exécutant régulièrement: Le premier est une boucle de rendu qui s'exécute toutes les 40ms, le deuxième est l'ensemble des déclencheurs sur les touches directionnelles.
Mon hypothèse de base était que la boucle de rendu était synchronisée à chaque exécution ce qui nécessiterait une latence inférieure à 40ms pour fonctionner correctement... Mais en fait après étude du protocole ce déclencheur ne subit aucune synchronisation car les timers sont réglés sur le temps de jeu qui lui est synchronisé entre les clients.
Le problème vient en fait des déclencheurs sur les touches directionnelles, ceux-ci sont synchronisés entre les clients et pour toute action de jeu de ce genre le client n'effectu aucun action jusqu'à ce tous les clients aient synchronisés l'action du déclencheur. Avec la réactivité demandée par le gameplay de cette carte cela fait beaucoup d'évènements fréquents qui interrompent la boucle de rendu.

Pour conclure il s'agit donc d'un problème inhérent au protocole de Warcraft et de l'utilisation que j'en fait (le moteur de jeu de la carte), il est donc insoluble; je vais néanmoins faire une gestion de ces arrêts dans la boucle de rendu, cela rendra la carte jouable en multijoueur mais la qualité des connexions influencera tout de même grandement la qualité de jeu.
_________________

[Vladadamm]

[Ayane]

Pour le medlay je conseille que chaque participant configure correctement son routeur afin de pouvoir héberger une partie Warcraft3, pas besoin alors d'un logiciel qui améliore la latence de l'hôte puisqu'au lieu d'avoir une architecture Client-Serveur (qui renvoie aux autres clients) cela devient entièrement Client-Client ce qui évite un intermédiaire et assure donc une latence bien meilleure.
_________________

[kungfu-sheep]

de toute façon j'vais mettre mon bot à disposition car il y a besoin d'un mon dr pour ma map.
_________________

22:27:43<Seiraw> Bah y a deux genre de personnes
22:27:57<Seiraw> les soumis et les soumises

[Ayane]

Justement, ton bot a beau être des plus performant, ce ne sera jamais aussi performant que si tous les joueurs configurait leur routeur.
Prenons un exemple: Les joueurs A,B,C n'ont pas configuré leur routeur, il utilisent un bot appelé H pour héberger la partie. Le client de chaque joueur se connectent donc à H puis essayent de se connecter au client des autres joueurs sans succès.
A envoie le message "hello" à tout le monde, cela envoie donc le message à H qui lui renvoie à B et C.
Maintenant si l'on considère que les joueurs A et B ont configuré leur routeur correctement; il en résulte que chaque joueur de la partie est interconnecté avec chaque autre joueur. A envoie le message "hello" à tout le monde, il envoie donc le message directement à B et C, sans passer par un intermédiaire quelconque.

H joue le rôle de proxy, avoir un proxy optimisé est mieux, mais ne pas avoir d'intermédiaire est souvent beaucoup plus rapide. Le système de proxy n'est dans l'architecture du protocole réseau de Wc3 qu'un substitut pour éviter d'imposer à tous les joueurs de configurer correctement son matériel. Ce n'est qu'une solution de secours qui est forcément moins performante que le fonctionnement normal.
Dans le cas où l'on connait tous les participants comme au medlay, il vaut mieux demander à tous les participants de configurer correctement son matériel que de mettre en place une bonne solution de secours.

Une dernière chose: je parle d'un hôte pour simplifier, en réalité il n'y a pas forcément un hôte, chaque client calcule en fait le chemin le plus court pour atteindre chaque autre client, prenons un exemple:
On a les joueurs A,B,C,D,E;
A,B,C,D sont interconnectés;
E est connecté uniquement à C et D;
A veut envoyer le message "salut" à E, il doit donc choisir entre C et D lequel est le plus rapide pour envoyer le message.
Si B veut faire de même il ne choisira par forcément le même intermédiaire que A car il peut disposer d'un meilleur ping avec D par exemple alors que A a un meilleur ping avec C.
C peut se déconnecter, E sera toujours là grâce à D. Si par contre D se déconnecte également alors E n'aura plus de connexion à A et B et sera donc déconnecté également.
_________________

[kungfu-sheep]

mais qu'appelles tu par "bien configurer son routeur" ?

je pensais que tu parlais de pouvoir host tout simplement, mais apparemment non.

tu parles de connexion entre ordi comme si ils étaient en réseau local, j'ai du delay moi en réseau local. je ne peux pas faire de slide en réseau local.

mais en même temps ça ressemble vachement "à tout le monde est le bot de tout le monde" car il n'y a aucun intermédiaire (comme entre le bot et le possesseur du bot si j'ai bien compris)
_________________

22:27:43<Seiraw> Bah y a deux genre de personnes
22:27:57<Seiraw> les soumis et les soumises

[Ayane]

Je parlais de bien configurer son routeur parce que dans la plupart des cas les joueurs n'arrivent pas à héberger de partie à cause de cela. Pouvoir héberger une partie montre que Warcraft3 accepte les connexions entrantes, et c'est donc cette capacité qui est nécessaire.

Voici l'architecture client-serveur:

Si seul l'ordinateur qui a créé la partie est capable d'héberger, alors le réseau sera comme cela. Un bot est un fait un programme où l'on a codé le protocol de WC3, sur WC3 c'est géré dans une boucle qui s'occupe également de géré les graphismes et autres ce qui augmente le temps de traitement des paquets reçut. Le bot lui ne fait que cela et traite donc immédiatement les paquets. Dans une telle architecture on voie donc tout l'intérêt d'améliorer l'ordinateur central qui joue le rôle de serveur puisque c'est lui qui reçoit et retransmet tous les messages.

Et voici l'architecture pair à pair

Sauf que sur ce schéma tous les ordinateurs ne sont pas interconnectés, ce qui implique que certains ordinateurs passent par des intermédiaires.
Cette architecture permet de supprimer l'intermédiaire.

Pour ton réseau local tu dois y avoir un problème.
_________________

[kungfu-sheep]

d'accord, je trouve le raisonnement parfaitement logique, mais les faits ne sont pas la :

je suis tout à fait capable d'héberger une partie, je l'ai fait des milliers de fois, mais lorsque je suis dans une partie hostée par quelqu'un d'autre, j'ai un max de delay.

quand au delay sur réseau local, il est pour moi comme pour toutes les personnes que je connais (à part toi apparemment) égal à celui que l'on a dans une partie bnet (je parle du jeu de base de war3)

j'ai également du delay en solo, mais légèrement inférieur. Cependant il est toujours la.

en faite la capacité de sensibilité au delay n'est pas la même pour un joueur jouant à des maps comme maze ou slide nécessitant, si on désir jouer à des conditions optimales, un delay proche ou égal à 0. J'ai toujorus joué avec ces conditions, ayant au par avant joué avec le logiciel vck puis ensuite avec un bot. (la différence est incroyable, moi qui pensait avoir delay 0 avec vck aujourd'hui je ne peux plus jouer avec)
le bot étant réglé sur dr 10, j'ai 10ms de delay, qui m'est actuellement imperceptible. (je connais personne qui le remarque)

ce que je ne sais pas expliqué mais qui me semble logique sont que les autres joueurs ont plus de delay que moi (comme quand j'utilisais un dr ou vck)

l'inverse est vrai également, lorsque je joue sur un bot pas à moi j'ai sensiblement plus de delay (ça varie en fonction du bot)

j'ai toujours cru que c'était en fonction de la connexion du possesseur du bot, et j'y crois encore. (les faits démontre la chose) et la réciproque marche également. Si un joueur qui a une mauvaise connexion joue sur mon bot, il aura plus de delay qu'un autre avec une bonne connexion.

ton deuxième schéma m'explique enfin pourquoi, lorsque l'host de ma partie s'en va, je deviens host.

pour finir, je dirais que lorsque je rejoins une partie et que j'y joue, j'ai entre 2.5 secondes et 1 seconde de delay (si l'host n'utilise aucun logiciel)

lorsque le logiciel est bien utilisé, (certains ne savent pas s'en servir et ça empire....) je peux avoir jusqu'à 0.3 seconde de delay.

pour ma map, on a encore plus besoin d'un delay proche de 0 que pour un maze ou un slide, le jeu étant basé sur la rythmique (béta à venir).

saurais tu me donner la raison scientifique de tout ça ? ^^" (si se n'est pas abuser)


ps : qu'elle est la relation entre le ping et le delay ?
_________________

22:27:43<Seiraw> Bah y a deux genre de personnes
22:27:57<Seiraw> les soumis et les soumises

[Ayane]

Tu parle de délais comme un synonyme de latence mais en même temps tu parle de délais en solo...
Tu mélange un peu tout on dirait, il y a deux notions à différencier:
- Lorsque le jeu est saccadé, notamment en solo, cela provient de la limitation des capacités de l'ordinateur (d'un autre point de vue c'est souvent parce que le programme n'utilise pas au mieux les capacité de l'ordinateur); on dit alors que le jeu rame.
- Lorsque le jeu manque de fluidité à cause de la latence réseau alors on dit qu'il lag (anglicisme de latence).
Par définition le premier est aussi un lag et le second est appelé netlag.
Si tu as des problèmes en solo, ce n'est alors pas du côté du réseau qu'il faut voir.
_________________

[Ayane]

La version ALPHA4 est publiée.
Cela devrait être mieux en réseau bien que je n'ais pas put y faire grand chose, l'architecture de WC3 ne permet pas de faire mieux.
Le jeu est par contre bien plus fluide bien que cela demande plus de puissance processeur, j'ai néanmoins calculé qu'un processeur de 1.2Ghz était suffisant mais cela peut être plus en fonction des performances de la mémoire vive (et du processeur). C'est à dire que sur un Core i7 920 cela utilise un coeur au maximum à 40% (avec 11 ordinateurs en difficile).
Cette fluidité, outre le fait de rendre la maniabilité un peu différente, permet un rendu satisfaisant de la caméra de poursuite, je l'ais donc ajoutée dans le menu mais attention: elle y est seulement à titre expérimentale, il y a plusieurs chose à y régler pour qu'elle soit jouable.

Je vous invite à donner vos suggestion pour cette dernière version ALPHA si elle se révèle stable, comme par exemple votre avis sur la caméra de poursuite. Les prochaines versions seront donc des versions BETA, au programme de la première:
- Ajout de quelques compétences.
- Configuration du nombre de tours.
- Bilingue.
- Captures d'écran.
_________________