Nous découvrir

Et si on parlait d’IA maintenant ?

Il n’est pas forcément chose aisée de donner une intelligence à des poules.
Dans le jeu ChickenPods, le joueur doit s’occuper d’un groupe de poules grâce à des pouvoirs qui agissent seulement sur l’environnement. Par conséquent, il faut doter chaque poule d’une certaine intelligence. Plusieurs méthodes existent pour réaliser cet objectif. Notre choix s’est porté pour la réalisation d’un algorithme de type réseau de neurones.

Comme un cerveau humain qui nous permet de prendre des décisions rapides grâce aux informations concernant notre environnement ou notre expérience, les poules dans ChickenPods prennent des décisions en fonction de leur propre analyse des choses qui les entourent et de ce qu’elles ont vécu auparavant. Elles ont donc chacune un programme leur permettant de faire différentes actions (se déplacer, manger, pondre, …) de façon indépendante. De plus, ce programme doit être aussi suffisamment optimisé pour permettre à nos joueurs d’avoir plusieurs centaines de poules qui évoluent ensemble dans un environnement.

Enfin, ce choix d’algorithme d’intelligence artificielle est aussi motivé par les possibilités d’amélioration futures prévues pour la sortie définitive du jeu.

Un environnement, c’est bien. Une infinité, c’est mieux !

Pour ajouter un aspect d’adaptation de stratégie dans le jeu ChickenPods, nous avons réalisé un développement approfondi pour avoir une génération d’environnement aléatoire. Cet environnement est composé de deux objets de type différent : les zones de graines et les barrières. Les zones de graines permettent aux poules de se nourrir pour survivre et les barrières empêchent leurs déplacements. Notre générateur d’environnement place d’abord les zones de graines puis ajout les barrières autour de façon aléatoire.

Mais une contrainte supplémentaire s’ajoute à la répartition. Le but est aussi d’avoir un environnement qui ne favorise pas la croissance de l’une des populations de poules par rapport à l’autre sans pour autant avoir un environnement généré symétriquement.

L’une des options utilisées est de ne pas avoir une génération d’environnement aléatoire uniforme mais d’avoir une répulsion entre les zones de graines pour qu’elles recouvrent au maximum la carte. Le programme implémenté est donc un programme basé sur le principe des processus ponctuel déterminants de taille fini, k-DPPs.

Le tout repose sur …

L’objectif de la plateforme de support de ce type d’activité est de permettre l’accès au jeu de façon libre via internet à partir de tout type de média (ordinateur, tablette, smartphone …) . Plusieurs options s’offraient à nous dans cette recherche de solution. Soit développer une solution monolithique qui abriterait l’ensemble des jeux, la gestion des comptes et les informations de communication. Le problème de ce type de solution est sa flexibilité et sa capacité à évoluer lors d’ajout de nouveaux jeux ou de fréquence de connexion grandissante. De plus le cloisonnement entre les différentes parties (web communication, jeux, …) est moins garantie ce qui peut présenter des effets de bords. Exemple de l’ajout d’un nouveau jeu qui dégrade les performances ou perturbe l’ensemble.

Pour anticiper sur ces problèmes et les réduire, nous avons opté pour une solution plus modulaire et plus flexible. Nous nous sommes donc diriger vers une solution de type micro service. Notre architecture est composée d’éléments indépendants (services) qui communiquent entre eux et s’échangent des informations. On va distinguer trois types de micro-services ainsi déployés :

Un micro-service de type site web bâti avec une solution de type CMS WordPress. Sa fonctionnalité est d’assurer la communication avec le public, les mécanismes d’inscription et éventuellement de paiement en ligne et aussi, de permettre également de choisir le jeu sur lequel on désire jouer. Cette partie peut-être interchangeable si besoin.

Un micro service de jeu. Ce service est déployé (approvisionner) à la demande sur une infrastructure de containers à partir d’un dépôt docker interne. Il est connecté et exposé pour être accessible par les joueurs. A la fin de la partie, il sera détruit au bout d’un laps de temps de non utilisation ou reconditionné pour être utilisé par d’autres joueurs.

Un micro-service de communication. Ce troisième service assure les relations entre les différentes parties de l’architecture. Il est bâti exclusivement sur une solution de type MoM.

Des services de stockage qui permettent de garantir la persistance des données de l’ensemble de l’architecture. Ces services de stockage sont construits sur des solutions SQL et NOSQL pour répondre à des exigences spécifiques.

L’ensemble de ces services est déployé sur un orchestrateur de containers qui nous permet de répondre à des exigences de consommation de ressources limitées, de disponibilité et de continuité de service.