Intelligence Artificielle de Combat : un nouveau système

Répondre
Partager Rechercher
Pas de Windows Seven parce que la librairie xp_utils qui est chargée de "tokenizer" une chaîne ne fonctionne pas sans installer visual basics. Merci pour la rétrocompatibilité, Mr. Microsoft.
Je viens d'aller voir sur le site de microsoft, c'est marqué compatible seven.

Je ne connais du tout VB, y a un vice caché ?

En tout cas, dommage si ça ne marche pas...
Je n'en doute pas !

Je suis passé à 7 en OS principal, et j'en suis assez content (mais là n'est pas la question !)

J'espère qu'ils sortiront bientôt un VB seven compatible ^^
J'en suis qu'il faut que je l'intègre à Khalidine dans l'immédiat.

Je sais que Lv m'a demandé pas mal d'explications sur le fonctionnement déjà.

Et sinon je bosse sur une IA sociale, j'ai quasi les documents de conception prêts.
Je sais pourquoi LV a posé beaucoup de questions . Je suis en train de tapé tout un tas de variables sur des trigger d'ailleurs ces temps-ci.

Il se pourrait qu'un serveur français profite du talent de Laban . (si je me trompe pas, Khalidine est un serveur anglophone non ?)
Thumbs up
Ok.

Merci Laban mais en fait je voulais surtout te demander si tu y travaillais encore ou si la version disponible sur le vault est une version que tu estimes de "finale" et que l'on peu importer et paramétrer sur nos persistants qui verront peut être le jour finalement (pas vrai Charlouloute qui réponds pas aux messages privés! )
(Beuh.... j'ai pas eu de MP moi... pas de toi en tout cas... *a revérifié* )

J'imagine que si l'outil va être utilisé sur son serveur c'est sûrement que c'est une première version suffisamment aboutie pour être intégrée et donc sûrement une version "finale" (même si à tous les coups, il est possible qu'un jour le truc s'améliore encore )
Charlouloute: super, tenez moi au courant. Et oui, Khalidine est anglophone.

Je ne dirais pas finale mais solide.

Les structures changeront peu, donc une nouvelle version n'obligera pas à changer les variables.

Par contre, j'ai corrigé le comportement de fuite qui était planté par rapport à ce que je voulais.

Mais c'est juste la librairie de scripts à changer / recompiler, rien de majeur.

De plus, le plugin xp_utils pour nwnx fait appel à une librairie qui n'est ni distribuée ni fonctionnelle et GF doit me le recompiler.

Dès que j'ai fini mon boulot de nettoyage / séparation du code standalone / khalidine je mets une nouvelle version sur le vault.
Des nouvelles de nos premiers jours avec ce script d'AI, avec problèmes, remarques et tout ça.

Problèmes :

1 - On a diminué la valeur delay en laissant la variable à 1 sur les triggers mais en diminuant l'équivalent IG. Avant il aurait fallu attendre 20 min IRL pour que ça spawn à nouveau ce qui nous embêtait.

Du coup, (je pense) le "rappel" des monstres ne se fait pas à temps. En fait notre problème, c'est qu'une fois un trigger activé et les mobs spawnés, ça peut respawner par dessus ! Du coup on se retrouve avec des zones à 60 mobs et les gens bloquent à la transition (ou meurent de toute façon).


2 - Mauvaise gestion de ma part sûrement : parfois les mobs voient de bien trop loin (l'autre bout d'une map 16*16) alors qu'on ne les voyait pas nous et qu'ils n'ont même pas d'alliés proches. Mais cela ne marche pas pour tous les mobs... à examiner de mon côté évidement.


Remarque :
C'est finalement assez dur de bien peser les variables. J'aurais aimé savoir (textuellement les scripts ne me parlent pas à moi) :

- comment est géré la peur ? nombre de point de vie perdu par le groupe / nombre de point de vie total ?

- comment est géré la difficulté ? Elle augment l'intelligence du mob, sa fuite, les chances de spawner ?

- comment est géré l'XP ? Il arrive qu'on reçoive 4 fois de l'XP pour un mob. Pourquoi ? Sur quelle base se fonde-t-il (je pensais les tables XP de never de base, mais j'ai des 300 XP au lieu de 10 XP limite pour certains mobs (ce ne sont pas des chiffre réels, je pourrai donner des valeurs plus précises si besoin est)) ?

Sinon --> PERSONNELEMENT JE SUIS FAN ! C'est énorme de voir les mobs bouger, attaquer en groupe, fuir, etc... c'est vraiment un super boulot ! Me reste plus qu'à maîtriser l'outil.

En plus la difficulté a eu un bon impact sur le module, d'habitude lors d'une ouverture, les gens vont pexer/explorer en solo, là les mobs sont trop durs/intelligents alors je vois des groupes partout ! C'est super !

Merci Laban pour ce travail super et énorme ! J'adore !

Voilà !!!
__________________
http://image.noelshack.com/fichiers/2012/46/1353252187-foret-bleue.png
La seconde version est arrivée : http://fanelya.fr !
IP : fanelya.no-ip.org

Liste de tous les serveurs : http://nwnlist.com
Tout d'abord, merci, ça me fait très plaisir de savoir que ça sert finalement à quelque chose.

Voici tes infos.

Problèmes :

1. En fait, j'utilise l'heure de jeu comme base. Ça peut effectivement constituer un souci si une heure ingame = 20 minutes réelles. Il suffirait de refaire le script pour qu'il produise un timestamp ( échantillon de temps ) en minutes et non en heures.
Pour ce qui est du respawn, il faut nettoyer la zone lorsque les joueurs la quittent.
Mais le fait d'éviter que les mêmes créatures puissent réapparaître deux fois fait partie des évolutions souhaitables, en effet.

2. La distance de détection est différente selon qu'un mob est "scout" ou pas ( ça fait partie des tags qu'on peut leur coller ). Un scout détecte jusqu'à 60m je crois, sinon à 30. Dans tous les cas, ça se paramètre dans les variables.
Ça fait aussi partie du design de cet intelligence de combat que les mobs soient plus vifs à ce niveau là.

Questions :

- La peur / fuite se calcule comme suit pour chaque créature à chaque tour : un jet de dés (d20) contre la variable de Moral du Groupe déduction faite de la variable de Moral de la Créature.
Le moral du groupe est calculé au départ : Base de 20 + chaque mob apporte un montant dépendant de son rôle hiérarchique. Le moral du groupe et le moral du mob décroissent durant le combat. Celui du groupe en fonction des morts ( idem, différence pour les rôles ) et des PdV totaux du groupe. Celui de la créature en fonction de ses PdV propres.
Le Facteur de Peur (FEAR_FACTOR) est utilisé pour évaluer l'importance de la baisse des PdV dans le moral. Plus il est élevé ( 5.0 ) plus les créatures fuiront au premier sang. S'il est bas ( 0.5 ) elles combattront toutes jusqu'à la mort.

- La difficulté : elle augmente le Challenge Rating potentiel de la rencontre. Un calcul se fait lorsqu'un groupe de PJ entre dans le déclencheur, avec une limite de distance pour ne pas compter les PJs qui seraient trop éloignés, permettant d'évaluer le CR du groupe qui sera utilisé pour le nombre de mobs à spawner.
Par exemple :
  1. 4 PJs de niveau 8 ont un CR de 10.
  2. Si le modificateur de difficulté du module est 1.0, le CR de la rencontre est de 10 pour le moment. ( 1.0 * 10 = 10 )
  3. Si le modificateur de difficulté du déclencheur est 0.8, le CR de la rencontre devient 8. ( 0.8 * 10 = 8.0 )
  4. Le déclencheur va alors tâcher de spawner suffisamment de créatures pour atteindre ce CR.
- XP : L'XP est distribué entre les membres du groupe, toujours avec une condition de distance, en fonction du CR de la créature confronté au CR du groupe dans le tableau 2DA. Cet XP est distribué soit lors de la mise en fuite du mob (pourcentage de l'XP total), soit lors de sa mort.
Ceci dit, j'ai l'impression que le tableau 2DA que j'utilise mériterait qu'on se penche sur les valeurs. Et il y a un souci à régler sur le fait que le montant d'XP à distribuer est stocké sur la créature : il faut "refaire" ce calcul en temps réel.

Bref, j'espère qu'au début du mois prochain, je pourrai livrer une version mise à jour.
Et j'ai une nouvelle question : à quoi sert la valeur "unique" dans le comportement du mob ? J'ai l'impression que si je mets cette valeur le mob ne respawnera pas tant qu'il n'aura pas été tué, je me trompe ?

Si c'est ça... ça règle beaucoup de mes soucis !

Si par contre ça veut dire que malgré le nombre minimum et maximum de ce type de mob il n'en spawn qu'un pas top
Cette valeur fait partie du premier design du système, que j'ai revu en cours de route.

Elle n'est utilisée nulle part, donc.

Comme je te dis, il faudrait ajouter du code pour ne pas respawner de créatures pour une rencontre qui n'a pas été nettoyée, soit par un script soit par les joueurs.
Je pensais à une chose qui pourrait être simple (ou pas je sais pas scripter ). Mon problème n'est finalement pas essentiellement que les mobs respawn, mais surtout que cela se faisant à l'infini, les PJs se retrouvent bloqués dans la transition ne pouvant la passer. Le DM doit alors se connecter et tout supprimer manuellement.

J'ai déjà vu des serveurs où il y avait un nettoyage régulier des zones dès qu'un PJ sortait ou tous les X temps... mais cela posait un inconvénient majeur : lorsqu'un pj déconnectait ou sortait de la zone, tous les mobs placés par DMs étaient supprimés.

Ma solution serait peut être tout simplement de poser une limite maximale de mob par zone (disons 30 par exemple), et que le script ensuite ne spawnera que pour compléter. Maintenant... c'est une idée d'un soir de semaine non loin de minuit... il y a encore sûrement des inconvénients que je n'ai pas vu.

Sinon il reste une variante : ne pas spawner un membre de l'équipe définie par le trigger tant qu'il reste au moins disons 10 mobs de cette équipe dans la zone.

Enfin, tout ça doit poser des questions d'optimisations, de réflexion etc...


Merci en tout cas pour ta réponse détaillée ! Je comprends déja beaucoup mieux un bon nombre de chose que je faisais à l'époque au hasard ! Ce sont les joueurs qui vont être content d'apprendre que je fais moins n'importe quoi !

(et désolé, comme on a posté en même temps à la minute même je n'avais pas vu ta réponse ).
Pour commencer, félicitation pour ton travail Laban, et félicitation à Charloulou pour avoir le courage de le tester.

Mon point de vue de joueur du module peut vous aider à orienter les recherches.

Il y a, je pense, 2 problèmes distincts:
- Pour un PJ, on obtient souvent le spawn d'un seul monstre qui se met à fuir et on passe son temps à lui courir après
- Pour un groupe qui entre dans une zone, j'ai l'impression que si il y a un petit délai entre les arrivées dans la zone, le moteur fait un nouveau spawn avec le nouvel arrivant et recalcul sa puissance avec tous les perso dans la place. Ca nous est arrivé hier (groupe de 6 PJ), on s'est retrouvé submergés par une bande de scarabées et charognes
Le problème du 1 mob vient de moi.

Le problème du plein de mob du script. Mais justement si j'augmentais le 1 mob, par exemple en allant à 3, ben le plein de mob faut le multiplier par 3... et là ça plante .

Ca fait un truc vraiment déséquilibré et des MPs aux DMs toute la journée soit pour débloquer soit pour les aider à explorer (alors qu'on devrait plutôt RP... du coup à force on refuse un peu... surtout vu les montées de niveau extraordinaires.
Le problème vient à mon avis d'un temps de respawn trop court éventuellement. Une nouvelle apparition de mobs n'intervient qu'après que le délai défini soit écoulé, donc il est peu probable que les spawns "s'enchainent".

Par contre, le fait d'être 6 joueurs ça peut faire mal au niveau du Challenge Rating, d'où un nombre de mobs importants.

Cette histoire de "limite maximale" du nombre de créatures peut être intéressante : par exemple, on la définit sur le déclencheur ( et pas sur la zone ) ce qui donne plus de souplesse.

Mais bon, je pense qu'il faut vraiment que vous regardiez un script de nettoyage.

Ce n'est pas très compliqué en fait : sur l'événement onPlayerExit de la zone, on vérifie s'il n'était pas le dernier joueur. Là, éventuellement, on peut introduire un délai ( afin de ne pas nettoyer de suite ) couplé à une variable locale ( au cas où un joueur entre entre temps, ce qui annulerait le nettoyage ). On appelle un script qui parcourt toutes les créatures NPC de la zone et on les détruit.

Faut savoir qu'en terme de performances, ça compte.
Etant joueur sur ce fameux module, un des soucis généralement rencontré de mon coté et de ceux jouant avec moi est lié à la fuite.

On arrive assez vite sur un gouffre entre le joueur ayant des attaques à distance (magique ou pas) et celui au cac, qui va voir les mobs s'éparpiller à travers les maps, pour finalement disparaître, avant même de pouvoir commencer le combat.

Résultat, 0 pex, vu qu'on a même pas le temps de commencer à taper un mob.

Remarque au niveau du calcul de la difficulté, comment intégrer les disparités de niveaux inhérente aux modules pw RP et leurs pass level ?

Lorsque par exemple un groupe avec un level 5, 2 level 7 et un level 10 arrive sur une map, ce sont tout un panel de mob pour level 10 qui spawnent. Alors là par contre chapeau, ils sont loin d'être bête, ils foncent sur les bas level, et une fois ceux ci morts, fuite. Sympa en terme de cohérence beaucoup moins en terme de gameplay. M'enfin, on fait avec quand même.
Hé des mobs intelligents ça ! (j'adore le coup des mobs qui ciblent le PJ le plus faible )

J'aurais une question pour ceux qui "vivent" ce système (donc côté joueur) (car sur Arkalym on se tate depuis un bail, 3 mois en fait ^^, d'intégrer ce système à Arkalym4 ) (je suis comme Charloulou, un fan de cette idée d'IA intelligente depuis le début de ce long fil )

Préfèrez-vous ce nouveau système avec ses "petits" inconvénients ou le système de base de NwN2 (en version 1.23 qui avait été revu déjà il parait de ce point de vue) ?
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés