Bonjour à tous.
Dans le monde merveilleux du boot Dofus, le bot Pixel apparait en général comme le parent pauvre du bot, le bot récolte codé par les débutants en Autoit. Une sorte de rite initiatique avant de pouvoir évoluer vers des choses plus sérieuses : le bot Sockets.
Peut-être un peu par esprit de contradiction, j'ai voulu tenter une approche visiblement peu mise en oeuvre, consistant à partir d'un bot pixel et l'enrichir par des informations en provenance des paquets échangés.
C'est pourquoi j'ai passé pas mal de temps à peaufiner mon bot pixel (j'y suis encore en fait), et je voulais vous faire partager quelques idées pour aller plus loin avec l'approche pixel. J'aborderai ici uniquement le thème du pur bot pixel (sans rien du socket, vu que je n'ai pas encore terminé de connecter les deux modes).
Déjà, un petit comparatif des approches pixel / socket :
- simplicité de mise en oeuvre : il est beaucoup plus simple d'obtenir de premiers résultats avec un bot pixel. Un débutant peut, en quelques heures, automatiser des tâches simples. A l'inverse, obtenir de premiers résultats en bot Socket est fastidieux, car nécessite un apprentissage plus conséquent et passer les phases de connexion. Une fois atteint un certain stade, la complexité du bot pixel augmente rapidement pour devenir du même ordre que pour l'approche Socket. Surtout que passer à un langage type C++, VB ou C# (ou pire : Java ^_^ ) n'est pas anodin : il faut trouver ou écrire une bibliothèque conséquente pour disposer de fonctions graphiques (et clavier/souris) utilisables.
- debuggage : pour un débutant, le bot pixel est beaucoup plus parlant, car il est proche de l'utilisation "normale" du jeu. Les problèmes rencontrés dans le bot sont le plus souvent visibles et compréhensible. Sur des projets d'ampleur cependant, le bot pixel peut devenir complexe à maîtriser et débugger. Notamment (quand on laisse tomber Autoit pour passer à un environnement plus complet), le debuggage pas à pas n'est que rarement utilisable (environnement graphique).
- multicompte : c'est beaucoup plus simple (et naturel) de faire du multicompte en socket. C'est néanmoins tout à fait faisable avec une approche pixel, mais cela n'est pas possible (enfin, pas viable) en mode "maître/esclave" : le bot doit contrôler entièrement tous les comptes. Et, disons-le clairement, gérer les combats en multi-compte dans ce type de bot n'est pas simple (un challenge intéressant) !
- risque de ban, sensibilité aux changements de versions : c'est là le principal avantage du bot pixel à mon sens. Un bot pixel bien conçu à peu de chances de se faire ban (= un bot qui ne clique qu'à bon escient, évite les actions trop rapide et répétitives ainsi que les sessions ininterrompues trop longues). Lors d'un changement de version, le plus souvent le bot pixel continue à fonctionner (surtout si il recherche les couleurs de l'interface tout seul). Le plus souvent (et dans le meilleur des cas), le bot socket ne marchera plus sans que les adaptations nécessaires soient effectuées. Et au pire, il se fera bannir si les changements nécessaires ne sont pas faits...
Sur le fond, je trouve le bot pixel plus "rassurant" vis à vis des risques de ban. En ce sens que l'on tente de reproduire au plus près le comportement d'un joueur. A l'inverse, il est aisé (voire inévitable) avec un bot socket de faire des choses qui ne seraient pas faisable avec le vrai client, et ainsi rendent la détection du bot socket théoriquement faisable de façon automatique.
Certes, Ankama semble se soucier assez peu des bots et ne fait plus grand chose pour lutter réellement contre leur utilisation. Cependant, si ils se réveillent un matin en décidant de lutter vraiment contre les bots, cela pourrait faire des ravages sur les bots sockets et les bots pixels les plus simples.
A remarquer que l'approche "Man in the Middle" est aussi intermédiaire entre le bot socket et le bot pixel, sauf qu'elle part du monde Socket et peu grapiller un peu du monde pixels.
Un autre avantage du bot pixel, c'est que les outils pour le mettre en oeuvre sont génériques et réutilisable pour de nombreuses autres utilisations (bots pour d'autres jeux et autres types d'applications). D'ailleurs, la plus grande partie du temps que j'ai consacré à mon bot l'a été en fait au développement de la bibliothèque graphique FastFind et d'un outil de recherche et de gestion des couleurs des pixels (FFShowPixels) ne sont pas du tout spécifiques aux bots.
Après ce long préambule, passons au coeur du sujet : quelques idées (non, pas de code) pour faire un meilleur bot pixel.
Tout d'abord, le matériel nécessaire :
- pour commencer (maquettage ou bot simple), Autoit peut convenir. Sinon, un environnement ouvert que vous maîtrisez et qui supporte les DLL.
- FastFind : permet d'effectuer des recherches à l'écran. Un must pour un bot pixel qui tient la route (à défaut, vous pouver aussi refaire l'équivalent)
- FFshowPixel (ou outil équivalent, si ça existe) : permet de gérer les listes de couleurs pour chaque ressource, de voir sur les maps les couleurs identifiées, faire des stats, et générer du code.
Remarque générale : le bot pixel est très dépendent des options du client. Il faut donc bien passer toutes ces options en revue, regarder IG l'effet de chacune d'entre elles, et choisir le jeu d'options qui vous parait le plus adéquat. Notamment, désactivez l'anti-aliasing.
Bot récolte
-> pour un bon bot récolte, il faut environ une trentaine de couleurs pour chaque ressource recherchée (30 couleurs pour le blé par exemple).
Pour certaines ressources, on peut se contenter de moins. Et pas n'importe quelles couleurs : il faut uniquement les couleurs les plus représentatives. L'utilisation de FFShowPixels simplifie énormément cette tâche. En gros, il faut que sur 4 ou 5 maps de récolte, vous êtes OK si vous avez plus de 50% de la surface identifiable des ressources qui est couverte. Et ne vous contentez pas d'une seule map, les résultats seraient très décevants en passant sur d'autres maps.
-> vous pouvez partir du code généré par FFShowPixels comme base pour votre bot récolte. Il n'y a que 4 lignes de code Autoit à ajouter pour en faire un bot récolte simple (ne gérant pas les combats). L'idée est la suivante :
1/ rechercher le spot le plus proche du joueur contenant N pixels avec les couleurs identifiées dans un carré P x P (paramètres à affiner en fonction des couleurs que vous avez et de la ressource recherchée.)
2/ vérifier que le spot est bien une ressource :
a/ vérifier que la couleur change bien quand la souris vient près du point (permet de ne pas cliquer bêtement dans le décors)
b/ vérifier qu'un menu s'ouvre quand on clique
c/ vérifier que le menu n'est pas trop long (ce pourait être un PC ou un NPC).
d/ vérifier que la ligne passe bien en orange quand la souris passe dessus (outil équipé, ressource non déjà prise...)
3/ Lancer la récolte, et attendre environ 90% du temps attendu pour la récolte (en vérifiant le début d'un combat de temps en temps), puis guetter l'affichage du nombre de ressources récoltées.
4/ Ajouter le spot (concluant ou non) dans la liste des rectangles d'exclusion (pour qu'il ne soit pas proposé à nouveau dans la même map pour la même ressource).
5/ Faire les tests d'usage (inventaire plein, passage de niveau, combat...).
6/ => 1
Combats
-> Localisation PC et monstres
C'est un point assez délicat, car la couleur des cercles bleu/rouge peut varier, et ils peuvent être cachés (partiellement ou en totalité).
C'est cependant nécessaire de connaitre précisément la position du monstre (le plus proche en général) et du PC pour pouvoir gérer les déplacements.
1/ activez l'affichage des cercles seuls (sans les persos). C'est plus simple.
2/ Avec "Shift+é", vous pouvez afficher les PC/monstres en transparence. L'avantage de ce mode, c'est que les cercles bleus et rouges sont entièrement et systématiquement visibles. L'inconvénient, c'est que leur couleur s'éloigne du bleu pur et du rouge pur (donc aléa de détection plus grand). L'astuce ici consiste à utiliser la détection des changements de FastFind :
a/ Faites un SnapShot de la zone de combat
b/ envoyez un Shift+é
c/ effectuez un nouveau SnapShot, et demandez la recherche des changements.
=> vous obtenez un nouveau SnapShot qui ne contient plus que les cercles rouges et bleus et rien d'autre (tout le reste est noir). Ainsi il n'y a plus aucun risque de confusion avec le décors, et vous pouvez localiser de façon fiable la position du monstre le plus proche et du PC.
3/ Comment s'assurer que le cercle rouge correspond bien au PC (et non une invoc ou un autre PC si combat multi-joueurs) ?
Pour cela, utilisez les mini-portraits (la barre rectraclable en bas à droite). Si c'est à votre tour de jouer, un petit triangle orange apparait sous votre portrait. Si vous passez la souris sur votre portrait, votre perso change de couleur sur la map de combat. Avec la détection des changements, vous pouvez là encore identifier sans erreur possible la position de votre perso (idem pour n'importe quel allié ou monstre).
4/ Gestion du déplacement
Selon votre style de jeu, vous pouvez choisir de venir au contact ou au contraire de rester à distance. Le plus simple étant de chercher le contact. Le mieux est de définir dans la configuration de chaque personnage une "distance idéale", dont vous tenterez de vous approcher par rapport au monstre le plus proche (pour simplifier, en première approche on considèrera que le monstre le plus proche, même si ce n'est pas toujours correct).
Une fois la position du monstre le plus proche et de PC connues, c'est facile de faire le déplacement : placez pour cela le curseur sur le PC (mini-portrait ou cercle rouge), et recherchez, dans la zone vert/bleu montrant les déplacements possibles, la position la plus proche de la distance idéale recherchée.
Pour les attaques, j'ai constaté qu'il est intéressant de tenter les attaques (dispo) avant puis après déplacement :
- si les attaques sont possible, lancer les attaques sur le monstre le plus proche
- tenter de se déplacer à distance "idéale" du monstre
- tenter à nouveau (si disponibles) les attaques sur le monstre le plus proche
5/ Listes d'actions
Pour ma part, dans la configuration de chaque personnage je lui associe 4 listes d'actions. Chaque liste contient un nombre illimité d'actions, qui sont lancées dans l'ordre si elles sont disponibles :
- boosts prioritaires : si dispo, ils sont lancés en premier (maîtrises par exemple)
- attaques : l'ensemble des actions offensives possibles. Il peut être intéressant de mettre en dernier une attaque, si dispo, sans ligne de vue. Comme vu au-dessus, cette liste est prise en compte avant et après déplacement.
- invocations : lancées après déplacement
- boost non prioritaires : les actions à lancer sur le PC en dernier recours, si il reste des PA inutilisés en fin de tour (soin ou mot de regen pour l'eni par exemple).
Chaque action n'est tentée que si elle est possible (non grisée = PA suffisant + disponible) et si le ciblage est autorisé (en regardant si le curseur est barré ou non).
Cela ne couvre pas tous les usages (glyphes, sorts de zone et pièges par exemple, ou encore les sorts de téléportation), mais permet déjà un comportement tout à fait correct dans bien des situations.
Bot xp :
-> pour trouver les monstres et les attaquer, vous pouvez là encore utiliser l'analyse des changements avec Fastfind afin d'identifier les mouvements. Ensuite, suffit de placer la souris sur la zone en mouvement, et vérifier si il y a bien des pixels oranges dans le tooltip apparaissant avec la composition du groupe. Ainsi, pas besoin de faire des listes de couleurs pour chaque monstre à cibler.