Contenu du renducontact(at)guillaumelevieux.com :: « Home

Horace Ribout

Programmeur Enjmin

Le projet travaillé durant la semaine avait pour but de générer une IA sachant faire marcher un pigeon. Le but n'était pas d'écrire l'IA, mais de la générer en laissant le logiciel tenté différents mouvements aléatoire et ne garder que les meilleur. Le projet rendu ne marche pas.

De manière générale, l'objectif fixé était un peu trop gros et je n'ai pas assez préparé en amont la réflexion sur la structure ou même sur où seraient les difficultés. Ce qui fait que : j'ai ajouté en cours de route de grandes features et que le code a fini par être un beau plat de spaghetti mal rangé, donc, encore plus difficile à corrigé. Je m'en excuse par avance.

L'idée de base : prendre des modèles de "pigeons" avec des formes très simplifiés, et des pieds décomposés en 4 parties (cuisse, jambes, orteil avant, orteil arrière) et donc 4 point de rotation. J'ai commencé par utiliser le système de "joint" présent dans Unity mais j'ai eu peur que si il y avais des problèmes, je ne sache pas comment ceux ci sont programmés. J'ai donc codé la limitation de rotation moi même en l'intégrant dans la génération de mouvement.

J'ai décidé de décomposé la marche ainsi : il y a 2 membres (Limbs) , une jambe gauche et une jambe droite . Dans une marche (nommé Data), il y aura une liste de mouvement pour chaque membre. Un mouvement (movement) est composé d'un id et de "RotationForThisJoint". Il y a autant de RotationForThisJoint que de point de rotation (ici, 4). Un RotationForThisJoint contient simplement une liste de rotation a effectué les uns après les autres.

Cette imbriquement de liste dans des listes était nescessaire mais hélas trop peu réfléchis et mal posé sur le papier, rendant difficile la création de la première "IA" : une IA qui va créer des mouvements aléatoirement et les jouer.

Après quelque jours, j'ai pris le recul pour voir qu'il ne s'agissait non pas d'une IA mais d'un automate car il ne jouais qu'une Data précise, sans prendre en compte l'environnement, et sans prendre de décision. J'ai donc pensé à une amélioration assez simple : j'ai modifier le premier IA pour qu'il regarde avant de jouer un mouvement, la rotation que l'objet dans sa globalité a ainsi que sa position, et une fois le mouvement fini, qu'il stocke son score (distance parcouru) et le compare au score pour les autres mouvements qui partait d'une rotation aussi proche.
Ainsi, un second IA aller regarder sa poosition actuel et chercher quel mouvement semble le plus approprié dans sa position. Si sa rotation actuel ne semble proche d'aucune stocké en mémoire, il va agir comme le premier automate.
Si un précédent mouvement était joué, il mettais alors à jour le score en faisant la moyenne et en incrémentant le nombre de fois que ce mouvement a été testé.


Autour de ça, j'ai créer un manager qui s'occupe de générer les IA dans la scenes, les positionner et leur donner le départ. Il s'occupe aussi d'afficher une UI assez simple et de stopper la course (10 secondes) avant de s'occuper de regarder quel Data a été assez performante au cas où je voudrais faire rejouer cette Data à une IA (les automates pouvant relire une Data pré-existante si besoin).

Malheureusement, de nombreux problèmes sont survenues : déjà, les listes imbriqués complexifies énormement le debug. De plus, même si le projet fonctionne de manière optimal, il faut une quantité assez immense d'information pour espérez avoir une IA qui marche (mes pigeons ont plus tendance à roule, même si c'est une stratégie optimal normalement) et cela rend aussi plus dur le fait de savoir si mon algorithme échoue pour mieux apprendre de ses erreurs ou si il n'apprend rien et est persuadé de s'améliorer selon les critères que j'ai posé. De plus, le grand nombre de donnée signifie aussi qu'il faut optimisé un minimum le parcours de ses listes et les algorithmes. je n'ai pas réussi à régler certains soucis (garder en mémoire la liste des mouvement via leur id, et non via leur place dans le tableau + détruire les mouvements qui ne sont plus utiles). C'est lorsque je travaillais sur cette partie là que je me suis rendu compte que le système remplaçant les joints ne fonctionnais pas non plus, ajoutant une couche de problème.

Au final, le projet n'est même pas extrêmement intéressant en terme d'apprentissage même si j'y ai découvert les scriptable object me permettant de stocker les Data et mouvement et meilleurs score de chaque course.

J'ai donc ajouté dans les Assets du projet contenu dans le drive, un dossier VR-LD, qui est bien plus complet et intéressant : c'est le résultat de la Game jam précédant la semaine sur Unity. J'y ai travaillé pour la première fois la VR (casque Occulus Rift pour être précis) et j'ai réalisé un "0 button game" où vous devez remuer la tête pour manger des miettes. La consomation de miette va engendrer la modification de l'environnement entier. J'ai voulu m'amuser avec la simplicité du changement de texture sur un terrain ou de la skybox, pour créer différente atmosphère de manière très rapide (peu d'asset et peu de calcul). C'est de ce projet que vient le modèle de pigeon utilisé pour l'IA. J'y ai put travaillé la lumière, les ombres (notamment celle dans les lampadaires) et les skybox, la VR, le système de terrain de Unity mais du point de vue du code, etc. J'ai donc ajouté ce jeu de jam au projet à rendre car j'ai réfléchi à quoi travailler la semaine suite à cette jam (elle se suivait directement) et pour moi, le projet unity est donc une continuité direct de ce jeu. Je présente aussi ce jeu car je me sens très mal de rendre un projet cassé et pas particulièrement intéressant.

PS : je me suis rendu compte après l'upload que j'avais laissé un dossier "VisualTestOn2018.3" dans Asset. Il s'agit de test effectué sur les prefabs nest suite à la mise à jour de Unity. Il n'y a qu'une seul ligne de code (permettant une rotation avec une légère accélaration au démarrage) et c'est juste fait pour être joli.