Système d'auto-chasse Metin2 : architecture et équilibre

Un système d'auto-chasse Metin2 est une fonction de confort qui fait farmer automatiquement votre personnage dans une zone définie, gère la vie et la mana, et ramasse les objets tombés au sol. De nombreux serveurs privés le proposent pour garder les joueurs actifs et rendre la boucle de farm moins pénible. Mais cette fonction est une arme à double tranchant : mal conçue, elle peut effondrer votre économie et dévaloriser l'effort des joueurs du jour au lendemain. Dans cet article, j'aborde à la fois l'architecture et les questions d'équilibre.

Que fait réellement un système d'auto-chasse ?

Au fond, un module d'auto-chasse exécute ces tâches en boucle :

• Sélection de cible : Il scanne les monstres dans un rayon autour du personnage et choisit la cible la plus proche/la plus adaptée.
• Attaque : Il applique un coup normal ou des compétences sélectionnées sur la cible.
• Survie : Il utilise une potion ou revient à un point sûr quand les PV passent sous un seuil.
• Ramassage : Il collecte automatiquement le yang, les objets et les fragments de pierre metin tombés au sol.
• Contraintes : Il ne fonctionne que dans une zone/carte définie et s'arrête lorsqu'une limite de temps ou de kills est atteinte.

La règle la plus critique ici n'est pas architecturale mais philosophique : le système doit s'exécuter côté serveur. Tout système d'auto-chasse qui fait confiance au client est une invitation ouverte aux outils de triche.

Côté serveur, pas côté client

La plupart des problèmes de triche classiques de Metin2 viennent du fait d'accorder trop d'autorité au client. Si vous exécutez l'auto-chasse côté client (une interface Python ou du code injecté), un joueur peut détourner cette logique et la plier à son avantage : portée infinie, kills instantanés, ramassage par téléportation. La bonne approche est de prendre toutes les décisions dans le cœur du serveur game. Le client n'envoie qu'une requête « démarrer l'auto-chasse » ; le serveur valide et exécute tout le reste.

En pratique, cela signifie construire la logique principalement via le système de quêtes (lua) et/ou le C++ du cœur. L'approche basée sur les quêtes est la plus courante sur les serveurs communautaires car elle permet d'écrire une logique souple sans recompiler le code source.

Squelette avec déclencheurs de quête

Le système de quêtes offre des minuteries (timer) et des points d'accroche d'événements (par exemple when kill, when login). Vous pouvez maintenir une boucle active avec un timer périodique. Voici un squelette conceptuel ; sur un vrai serveur, vous aurez besoin de fonctions exposées côté cœur pour la sélection de cible et les attaques :

quest auto_hunt begin
    state start begin
        -- Démarré par une commande du joueur
        when "/auto" command begin
            if pc.get_map_index() != ALLOWED_MAP then
                syschat("L'auto-chasse est désactivée dans cette zone.")
                return
            end
            pc.setqf("hunting", 1)
            -- Boucle déclenchée toutes les 2 secondes
            server_timer("hunt_tick", 2, pc.get_player_id())
            syschat("Auto-chasse démarrée.")
        end

        when hunt_tick.server_timer begin
            local pid = get_server_timer_arg()
            if pc.select(pid) == false then return end
            if pc.get_map_index() != ALLOWED_MAP then
                pc.setqf("hunting", 0)
                return
            end
            -- Logique de potion/retour quand les PV sont bas
            if pc.get_hp() < pc.get_max_hp() * 0.3 then
                -- revenir à un point sûr / utiliser une potion
            end
            -- Continuer
            if pc.getqf("hunting") == 1 then
                server_timer("hunt_tick", 2, pid)
            end
        end
    end
end

Le ALLOWED_MAP de cet exemple garantit que le système ne tourne que sur les cartes autorisées. Pour l'étape « trouver une cible et la frapper » proprement dite, vous devez soit ajouter une nouvelle fonction Lua au cœur (enregistrée via CFuncTable côté C++), soit déclencher un comportement de suivi/attaque de type IA. Il est important de ne pas inventer de noms de fonctions ici ; appuyez-vous sur la véritable API de votre propre code serveur.

Sécurité et validation

Même si le système tourne sur le serveur, traitez chaque requête du client avec méfiance :

• Limitation de débit : Vérifiez que le paquet « démarrer l'auto-chasse » n'est pas envoyé des dizaines de fois par seconde ; sinon, les joueurs peuvent inonder le serveur en multipliant les minuteries de boucle.
• Validation de portée : Calculez toujours la distance d'attaque et de ramassage sur le serveur. Ne faites jamais confiance à l'affirmation du client « je suis sur ce monstre ».
• Cohérence d'état : À chaque tick, vérifiez que le joueur est réellement sur une carte autorisée, vivant et connecté.
• Journalisation : Écrivez le yang et les objets gagnés dans une table séparée afin de pouvoir les auditer plus tard.

La partie la plus critique : l'équilibre du jeu

Un système qui fonctionne techniquement peut quand même ruiner votre jeu. Comme l'auto-chasse automatise l'effort du joueur, elle multiplie l'apport économique (yang, objets, pierres). Pour protéger l'équilibre, mettez en place des freins concrets :

• Limite quotidienne de temps/kills : Par exemple 2 heures ou 5 000 kills par jour. Le système s'arrête une fois la limite atteinte.
• Taux de drop réduit : Gardez les drops pendant l'auto-chasse en dessous de la chasse manuelle (par ex. 50 %). Jouer manuellement doit toujours être plus rentable.
• Restriction de zone : N'autorisez l'auto-chasse que sur les cartes de bas/moyen niveau ; gardez le contenu de fin de jeu (boss, metins de haut niveau) en manuel.
• Exigence de présence / contrôles AFK : Ajoutez une vérification périodique simple, ou au moins un arrêt automatique en cas de déconnexion.
• Utilisez une barrière premium avec prudence : Rendre l'auto-chasse payante crée une perception de « pay-to-farm » qui peut éloigner les joueurs gratuits.

La règle d'or : l'auto-chasse doit être un confort, pas un moteur de gains. Un joueur qui joue manuellement doit toujours progresser plus vite.

Test et déploiement

Ne déployez jamais le nouveau système directement en production. Faites-le d'abord tourner sur un serveur de test local avec des données économiques fictives pendant 24 à 48 heures et mesurez la quantité de yang et d'objets produits. Observez ensuite le comportement réel des joueurs avec une bêta fermée limitée. Gardez les limites de drop et de temps configurables depuis un fichier de config afin de pouvoir affiner sans recompiler le serveur.

Questions fréquentes

Ne puis-je pas simplement construire l'auto-chasse côté client ?

Vous le pouvez, mais ce n'est pas recommandé. La logique côté client est facilement manipulée avec des outils de triche. Garder les décisions et la validation sur le serveur est essentiel à la fois pour la sécurité et l'auditabilité.

Dois-je utiliser les quêtes ou le code C++ ?

Les deux ensemble sont les plus robustes. Quest/Lua est souple pour le contrôle de flux et les limites ; le C++ du cœur est plus efficace pour les travaux critiques en performance comme le scan de cible et les attaques.

L'auto-chasse casse-t-elle l'économie ?

Sans freins, absolument. Avec des mesures comme une limite quotidienne, un taux de drop réduit et une restriction de zone, vous pouvez gérer ce risque et garder le système sain.

Vous voulez ajouter un système d'auto-chasse équilibré à votre serveur ? Je peux vous aider de bout en bout, de l'architecture des quêtes au réglage de l'économie. Contactez-moi et discutons de votre projet.