[Projet perso] Mon appli de jeux basée sur l'IA générative en cours de dev

Hello les kheys

Il y a quelques temps, je me suis retrouvé au chomage.
Le temps de retrouver un taff et étant donnée que j'avais pas mal de temps libre à l'époque, je me suis dis que c'était le bon moment de tenter quelque chose en surfant sur la hype de l'IA générative.

De base je suis data scientist, mais j'ai un profile assez orienté "full stack": je me débrouille pas trop mal en software developpement et j'ai quelques notions de front. Bref, avec l'aide de chatgpt et de ma motivation, je me suis lancé dans la création d'une webapp, avec comme idée folle de la commercialiser peut être un jour.

Aujourd'hui mon prototype, même si loin d'être parfait, commence à prendre forme. J'ai moins de temps pour bosser dessus car j'ai retrouvé du boulot depuis, mais je me garde quand même le projet sous le coude et petit à petit j'espère arriver à un produit fini (surtout si je considère tout le temps que j'y ai déjà investit )

Je voulais profiter de ce topic pour échanger sur mon projet et vous raconter les différentes étapes de développement (passées et futures) pour ceux que ça intéresse. J'espère que poster ici me motivera aussi à aller au bout du projet, parce que mine de rien, c'est difficile de se motiver soir et week-end quand on dev en solo

Dans les prochains messages, je vous détaillerais mon concept ainsi que les choix de design que j'ai pu prendre en cours de route pour arriver où j'en suis actuellement et j'essayerais de tenir par la suite un carnet de route des progrès que j'ai pu faire.

Je vais découper les étapes de développement en plusieurs messages histoire de rentre le tout un peu plus digeste. N'hésitez pas si vous avez des questions ou des commentaires.

Partie I: Le concept + v0

Alors comme dit précédement, l'idée de départ était de proposer une application basé sur l'IA générative qui propose une aventure façon jeu de rôle papier tout en ayant un cadre bien défini avec un début, un milieu et une (ou plusieurs) fin pré-établie tout en donnant un sentiment de liberté au joueur.

On serait donc quelque part entre un AI Dungeon (beaucoup trop libre, l'IA improvisant l'histoire au fur et à mesure) et un jeu Telltale (beacoup trop restrictif, car limité dans les choix multiples). Au début j'étais parti pour laisser pas mal de liberté à l'IA, mais je me suis vite rendu compte que ça serait impossible à cadrer correctement

J'ai rapidement orienté ma réflexion autour d'un MVP (qui a un peu évolué par la suite, mais finalement pas tant que ça). En fouillant dans mes notes début août je me disais:
"MVP: Un lieu et un personnage avec lequel interagir + une quête très sommaire (trouver un équipement dans une pièce en interagissant avec le personnage)", le tout, évidemment, en laissant l'opportunité au joueur d'écrire n'importe quoi dans l'interface utilisateur (contrairement aux jeux du genre actuellement). J'ai un peu complexifié cette idée initiale en essayant d'établir une série d'actions avec une suite logique et des possibles non-linéarités.

Parlons de ce fameux MVP (qui est encore aujourd'hui la base de mon travail). Je suis partie sur l'idée d'un mini escape game où le joueur est coincé dans une pièce. Il doit intéragir avec l'environnement pour trouver des indices et déclancher plusieurs mécanismes déterministes pour arriver à la fin.

Je voulais inclure plusieurs contraintes à ce MVP:
1. Non linéarité: le joueur doit pouvoir effectuer certaines actions dans le désordre
2. Causalité: certaines actions ne peuvent être réalisé que lorsque certains évènements ont eu lieu (par exemple trouver une clef avant d'ouvrir une porte).
3. Type d'interaction: le joueur doit pouvoir intéragir avec les personnage (pour commencer uniquement le narrateur/game master) et avec l'environnement.
4. Avoir un début / milieu / fin bien défini
5. Eviter au maximum les halucinations (le plus gros problème)
6. Sentiment de liberté: même si le cadre est dirigiste, le joueur doit pouvoir faire ce qu'il veut, quitte à être recadré par le game master.
et par la suite:
7. Interagir avec plusieurs personnage / plusieurs environnement
8. Interface dynamique en fonction du context
9. Gestion d'interactions plus complexes
etc...

Il faut savoir que rien que ce petit MVP papier m'a pris pas mal de temps à définir, c'était loin d'être immédiat à conceptualiser

Lors de la toute première version, je me contentait d'interagir avec l'API de GPT (3.5 ou 4) en lui fillant un prompt prédéfini:

Bon c'était pas ouf, et j'ai par la suite structuré ça un peu plus proprement avec plusieurs template que je mergeais les uns avec les autres: pour le narrateur et l'environnement notamment.

Côté code, c'était pas jolie jolie, et j'avais tout fait en me servant de Streamlit (python) pour aller plus vite et avoir un premier truc "a voir" en moins de 24h après que je me soit officiellement lancé.

Voilà à quoi ressemblait la première itération:

Partie II: Restructuration et premiers choix tech

A ce moment là, on est toujours dans la première semaine de developpement du projet. Je voulais passer le moins de temps possible sur Streamlit et structurer un peu mieux le projet. Je voulais garder le backend en Python, parce que c'est le language que je maitrise le mieux, mais je voulais commencer à construire les bases du front en utilisant le framework React avec lequel j'avais déjà eu l'occasion de jouer par le passé.

L'archi de base est assez simple:
- Un server API (FastAPI) pour gérer les requêtes du front (login, messages)
- Un server front basé sur React
- Le "game engine" qui prendra la forme d'une lib python pour gérer les logiques "métier" (gestion des templates pour l'IA, interaction avec l'API du modèle LLM, etc...)
- Une petite DB postgres, simulé dans un premier temps dans un container Docker, pour gérer les utilisateurs et leurs sessions

En allant un peu plus loin dans les choix technique:

Côté DB user

Je n'avais aucune expérience, donc je me suis laissé guidé par ChatGPT.
Au final, je suis partie sur une DB custom classique avec stockage d'un hash "salté" représentant la paire mail/password. Lorsqu'un utilisateur se login, on vérifie que le hash généré correspond, puis on génère un token temporaire qui sert à identifier l'utilisateur.

Pour limiter les problèmes éventuels de spam, l'utilisateur doit valider l'adresse mail utilisé pour s'enregistrer sur l'appli avant de pouvoir se connecter. J'ai implémenté le mécanisme simplement en ajoutant une colonne "is_verified" qui est set à False par défaut. A la création d'un compte, le back génère un lien présigné avec un token envoyé par mail à l'utilisateur, qui va déclancher une requête pour set is_verified à True.

Par la suite, j'aimerais proposer l'authentification via Google/Facebook, mais c'était un peu chiant à mettre en place pour mon POC donc j'ai laissé ça de côté pour l'instant.

Côté Front/UX
J'ai commencé par poser mon premier design sur papier en me servant de Miro. Je ne suis pas UX designer, je sais que ma "vision" était très moche et que Miro n'est probablement pas l'outil le plus adapté pour ça, mais j'avais rien de mieux sous la main étant donné mes compétences et puis il faut bien commencer quelque part

Admirez le chef-d'oeuvre de ma première maquette (si on peut appeler ça comme ça )

En gros on a deux page: la landing page, et la page de jeu. Pas encore de gestion de login à ce moment là mais on s'en fou ça tourne en local seulement.
Dans l'interface de jeu, l'utilisateur doit pouvoir avoir accès aux informations essentielles à savoir: les règles du jeu, l'historique des messages et les actions importantes accomplies (idée laissé tombépar la suite, puis reprise encore plus tard, j'y reviendrais). Et une interface permettant d'écrire des messages. A ce moment du développement il n'y a qu'un seul personnage (le game master), mais l'utilisateur peut choisir de lui parler ou d'effectuer une action en utilisant l'un des deux boutons à disposition. Côté backend, on va simplement ajouter le template "Action" ou "Question" au preprompt qu'on passe à l'api.

Après quelques heures de travail et quelques itérations, voilà le premier "vrai" résultat fonctionnel:

A ce moment là du dev, les historiques de conversation sont simplement stockés en local dans des fichiers textes.

C'était un bon début, mais j'ai du faire face à pas mal de problème.
1. Déjà le coût. J'ai commencé à utiliser naivement GPT4 pour avoir les meilleurs performances possibles en terme d'interpretation de mes promptes. Problème: même si le prix par token semble assez correct, les prix grimpent très vite, surtout lorsqu'on met en cascade plusieurs templates qui peuvent être assez conséquents. J'ai du me rabattre donc rapidement vers l'api GPT3.5, quasiment 20 fois moins cher.
2. Le fait d'utiliser GPT3.5 m'a posé d'autres difficulté: le modèle étant beaucoup moins performant, il avait plus facilement tendance à raconter n'importe quoi et à partir dans tous les sens. J'ai passé pas mal de temps à essayer d'améliorer mes prompts "statics" mais sans obtenir de résultats satisfaisants. Et honnêtement, j'avais énormément sous estimé les problèmes que les hallucinations pouraient me causer par la suite.
3. Ca marche, mais l'UX est moche, très moche. Et bon à ce moment il était même pas question de proposer un design responsive qui s'adapte au mobile. Donc il y aurait un énorme travail à faire côté front.

Le 05 février 2024 à 19:27:31 :
il y a un monde entre une bonne idée et la réalisation de celle ci.

Je confirme, j'ai passé 2 bons mois quasi full time sur mon proto, il y a eu plusieurs moment où j'ai failli tout arrêter soit par flemme, soit à cause d'un problème technique qui me paraissait insurmontable sur le moment. Au final je commence à voir la lumière au bout du tunnel là, mais je marche encore sur un fil et je peux laisser tomber à tout instant

Partie III: Amélioration des templates pour l'IA et Chain of Thought

A la fin du chapitre précédent, j'en suis à peu prêt à 2 semaines de projet à bosser quasi tous les jours. J'ai déjà fait plusieurs début de projets par le passé, et c'est en général à ce niveau là que je lache l'affaire.

Cette fois, j'ai du temps libre, donc c'est un peu différent, et j'ai pas mal d'améliorations en tête à tester.

D'un côté au niveau de la logique de jeu. J'essaye de paufiner les prompts statiques qui donnent vie aux personnages et à l'histoire que j'essaye de mettre en place. Ca passe par la mise en place de meilleurs prompts et d'un projet plus structuré. A ce moment là je commence aussi à experimenter avec du "chain of thought". Ca consiste en gros à faire plusieurs calls à des IA qui vont se spécialiser sur des parties précises du raisonnement, puis à les assembler dans un prompt final qui servira à générer une réponse finale.

Prompt user + template specialisé 1 -> output + prompt user + template 2 -> ... -> outputs + prompt user + personnalité -> réponse final

Par exemple, je vais passer le prompt du joueur à un "expert checker"

Puis je vais passer l'output de cet expert à l'IA suivante qui va, elle, décrire l'action de manière (on espère) cohérente (et avec sa personnalité de NPC prédéfinie) puis qui va modifier le fichier joueur avec les actions importantes réalisées.

En utilisant cette méthode, j'ai réussi à obtenir des trames d'histoires un peu plus cohérentes, mais j'avais toujours de gros problèmes d'hallucinations. En gros il y a toujours un moment dans l'aventure ou l'IA décroche complètement, induit le joueur en erreur et part dans des délires qui étaient absolument pas prévu.

Dans les autres problèmes récurrent, on peut aussi noter des oublies ou des destructions d'informations importantes: par exemple, une clef qui disparait alors que le joueur l'a récupéré, ou des éléments clefs de l'environnement qui sont supprimé.
(A ce moment du projet je laisse carte blanche à l'IA pour réecrire certains fichiers en cours de route).

Enfin, un dernier gros soucis c'est le spoil. Comme je passe toute la trame en prompt à l'IA, elle a tendance à donner directement les informations importantes au joueur, gachant complètement l'experience de jeu.

Bref, petit pas, mais clairement, si je ne réussi pas à fixer ces soucis, le projet est bon pour la poubelle.

En parallèle, je continue à améliorer l'UX.

Chapitre IV: Amélioration de l'UX (appelons la v2)

Bon.. Parlons un peu de la mocheté que j'avais pondu à ce moment là. C'était rigolo pour commencer, mais j'avais pour ambition de faire un truc qui pique un peu moins les yeux.

Un truc qui manquait clairement, c'est des images. Et ça tombe bien, il y a aussi des modèles d'IA génératives d'images, alors pourquoi s'en priver ?

J'y connaissais rien, donc je me suis lancé 2-3 tutos pour utiliser stable diffusion avec les modèles pré-entrainés disponibles sur CivitAI. J'ai une petite GPU sur mon PC, elle fait parfaitement l'affaire pour générer des images en local.

Dans un premier temps, je me dis que ça pourrait être cool de laisser la possibilité à l'utilisateur de générer lui même son personnage, du coup j'ai ajouté une page intermédiaire qui permet à l'utilisateur de faire son propre avatar.

D'un point de vue technique, ça passe par une API qui tourne avec une instance local de stable diffusion qui tourne via le framework huggingface dans un container dédier. Lorsque l'utilisateur passe un message, il est envoyé au modèle via un template statique pour ajouter d'autres détails, puis l'image générée est réencodé en base64 et envoyé au client.

Pour le proto, j'envoyais l'image directement au client, mais dans une version plus avancée, j'aurais pu aussi sauvegarder l'image dans un bucket dédié dans le cloud, puis renvoyer un lien présigné au client. Ca aurait permis de pouvoir se reservir de l'image d'une session à l'autre.

Bon.. Par la suite j'ai laché l'affaire avec cette feature (au moins temporairement) parce qu'il aurait fallut hoster le modèle dans le cloud, et louer une GPU, ça coute cher. Ca reste une feature que j'ai mis du temps à développer et qui était cool sur le papier sur le moment. Mais c'est aussi ça un projet, des idées qu'on met en place, puis qu'on met à la poubelle.

Côté interface de dialogue, j'ai fait aussi pas mal de changement.
Déjà, on vire tout ce qui est superflu (les rubriques "quest" et "success") qui de toute façon sont complètement buggés à cause des hallucinations de l'IA.

Ensuite, parmis les gros changement:
1. J'ajoute des "photos de profiles" à côté des messages pour personnalisé un peu les conversations
2. J'ai bougé la logique action/dialogue en haut à gauche de la fenêtre de chat
3. J'ai ajouté les onglets personnages en haut à droite.
4. J'ai aussi ajouté quelques animations/évènements dynamique comme le fait de bloquer la fenêtre de message en attendant la réponse de l'IA.

Côté logique logique métier, cliquer sur un onglet va changer les prompts statiques qui contiennent la personnalité/les connaissances de l'IA au moment où on passe le message de l'utilisateur.

Je trouve cette version déjà plus intéressante, et combiné avec les améliorations faites sur la partie backend avec le chain of thought, je commence à avoir un projet sympa. Reste à fixer la logique du backend pour corriger les problèmes indiqués plus haut pour éviter que tout ce travail parte lui aussi à la poubelle.

Le 05 février 2024 à 21:40:57 :
Très intéressant khey, j'ai pas mal d'idées de ce genre et les compétences pour les réaliser mais je suis trop un flemmard

Merci pour le message !

Oui ça demande beaucoup de motivation et de régularité. Ajoute à ça le syndrome de l'imposteur où on se dit à chaque fois que ce qu'on fait est jamais assez bien. Je suis plutôt un bosseur, et je commence à cumuler les années d'expériences, mais en général, à la moindre difficulté, je fini par tout laisser tombé. J'ai commencé plusieurs micro-projets par le passé, à chaque fois que j'ai laissé tombé en cours de route.

Par contre, j'ai remarqué que plus le temps passe, plus je vais loin dans mes projets. A chaque fois j'apprends de mes erreurs et je vais un peu plus loin. Peut être que cette fois ça sera la bonne

Quand tu va devoir mettre au placard ton projet pour retourner au boulot et faire des services CRUD , des pages web ou des interfaces bidons tu va pleurer et regretter ton chômage toi..

C'est ptêt l'occasion pour toi de devenir auto-entrepreneur et de lancer réellement ton projet non ?

Le 05 février 2024 à 21:50:21 :
Quand tu va devoir mettre au placard ton projet pour retourner au boulot et faire des services CRUD , des pages web ou des interfaces bidons tu va pleurer et regretter ton chômage toi..

C'est ptêt l'occasion pour toi de devenir auto-entrepreneur et de lancer réellement ton projet non ?

Mon taff est intéressant, j'ai la chance de pas faire que du CRUD Mais oui, c'est le risque.

J'avoue que jusqu'à il y a pas très longtemps j'avais commencé à laisser pourrir le projet. Mais là je me suis remotivé et le fait d'en parler ici me remotive aussi.

J'ai encore plusieurs chapitres en préparation, il y a encore pas mal de rebondissement pour en arriver où j'en suis aujourd'hui. J'essaye de les sortir dans la soirée.

Topic en FAV pour ma part, j'espère que tu trouvera la déter de mener à bien ton projet khey

Continues à partager qqs détails techniques comme tu le fais, ça permet de rendre tes actions plus visibles et compréhensibles pour les codeurs en carton comme moi

Chapitre V: la traversé du desert

Bon, à ce niveau du projet, je commence à avoir un proto bancale, mais un proto quand même. C'est déjà pas trop mal.

Avant de continuer sur l'UX, il faut absolument que je règle les problèmes dont je parlais dans la partie 3 et qui constituent un véritable project killer: à ce stade du projet, je peux certes, trouver un enchainement de prompts côté joueur qui vont me permettre d'aller jusqu'à la fin de la mystery room telle que je l'ai imaginé, mais dès qu'un autre joueur va essayer, ça va faire n'importe quoi 95 fois sur 100.

Si j'avais montré ce proto à ce stade là c'était typiquement un cas flagrant de cherry picking et ça j'en voulais pas.

Pour ceux qui connaissent pas, le cherry picking c'est l'art de choisir l'example parfait quand on fait une démo pour obtenir un effet whaouh. Le dernier en date auquel je pense c'est Google Bard 2, pour lequel on a eu droit à une démo incroyable. Mais quand les gens ont commencé à jouer avec le modèle...

Bref.

Pour revenir à mes propres problèmes, le plus gros défaut à ce moment là c'est les problématiques liés à l'avancé de l'histoire. Et plus l'action est subtile, plus l'IA va coincer pour détecter l'action. Ce truc, c'est le cauchemard de quiquonque à essayer de faire un vrai POC à partir d'IA générative. Comment controler l'IA et être sure qu'on reste dans un cadre d'utilisation bien défini ?
Et à ce moment là, ma trame est censé être plutôt simple: récupérer un objet, utiliser l'objet, réaliser une action, et finalement résoudre l'énigme final. Essayer de lancer une histoire plus ambitieuse ça aurait été du suicide

Mon système de chain of thought et mes promptes statiques ne suffisent clairement pas, et toutes mes tentatives pour améliorer mon système (en améliorant les promptes ou en faisant des chain of thoughts plus complexes) se terminent en échecs.

Du coup, je me dis qu'il faut que je reprenne mon système à 0.

A ce moment là, je découvre une feature de l'API GPT que je ne connaissais pas: les fonctions.
En gros l'idée, c'est de passer un template de fonction avec une description et des paramètres. Ces fonctions peuvent être appelées par GPT si il a besoin d'information ou de contexte supplémentaire.

L'example qui est donnée par OpenAI, c'est une IA qui donne la méteo: L'utilisateur va demander quel météo demain ? L'IA n'a pas de contexte, elle va donc générer un template de fonction avec des paramètres du style la localisation de l'utilisateur et le jour du call. Le template peut être utilisé ensuite par le backend (pour faire un call API vers un provider de météo) et les informations peuvent ensuite être renvoyés par le backend à un nouveau call vers GPT qui va cette fois pouvoir répondre à la question posé par l'utilisateur.

Ce truc des fonctions ça m'a fait tilt. A partir de ce moment là, j'ai compris que je devais muscler mon backend et laisser moins de liberter à l'IA pour générer n'importe quoi.
Et ça passerait par l'utilisation de ce système de fonction dans un chain of thought boosté aux hormones.

Au lieu de passer tout l'environnement avec les actions importantes, on va créer un graph de causalité entre les différentes actions "importantes", et le backend se chargera de passer en contexte seulement les actions faisables à un instant T à l'IA.

Par exemple:
"action1: ouverture de la porte scellée" ne sera accessible que si "action0: découverte de la clef" a été effectuée.

Où interviennent les fonctions à ce moment là ? A plein d'endroit, et je vais garder une partie de ce système secret. Mais la grosse idée, c'est de forcer l'IA a call une fonction avec un action ID lorsque celle ci a été detectée. Le backend se charge ensuite de mettre à jour le state de la partie avec la liste des actions ids effectué et de remettre à jour le graph de causalité, ce dernier servant à générer automatiquement le prompt des évènements possible.

Et si l'utilisateur propose des actions randoms ou HS ? L'IA improvise une réponse qui n'aura pas d'impacte sur l'histoire, puisqu'aucune action_id ne sera modifié.

Ce système présente plusieurs avantages: réduction des tailles de prompts, suppression des spoils (puisque l'IA a accès uniquement partiellement à l'information), et réduction dans les hallucinations (même si le problème persiste parfois).

Cette idée ça a vraiment été le second souffle dont j'ai eu besoin, et après plusieurs itérations, m'a permis de déboucher sur une version plus stable du game engine.

Il faut voir que tout ça parait évident maintenant, mais à l'époque, ça m'a pris plusieurs semaines d'itérations et d'échecs pour enfin progresser.

Le 05 février 2024 à 22:10:27 :
Topic en FAV pour ma part, j'espère que tu trouvera la déter de mener à bien ton projet khey

Continues à partager qqs détails techniques comme tu le fais, ça permet de rendre tes actions plus visibles et compréhensibles pour les codeurs en carton comme moi

Hésite pas si tu as des questions plus précises (histoire de faire vivre un peu le topic )

A la base j'étais pas Data Scientist, encore moins dev. J'ai un background d'ingésclave, je me suis reconverti il y a 5 ans environ.

Chapitre VI: GPT le beta-testeur

On est à environ 1 mois - 1 mois et demi depuis le début du projet. J'ai eu chaud plusieurs fois et j'ai failli laché l'affaire au moins 3 fois depuis le début. Mais mes progrès sur le game engine m'ont reboosté.

A ce moment là, il y a un autre facteur qui commence à me motiver: le gap technologique. Jusqu'à maintenant, ce que je faisais c'était assez simple et n'importe qui pouvait rapidement aboutir plus ou moins aux mêmes résultats que moi.

Mais la structure du game engine et mon framework pour gérer les prompts utilisateurs s'est largement complexifié à ce moment là et quelqu'un qui voudrait copier mon idée aurait probablement beaucoup de mal, même ici avec toutes les informations que je vous ai dévoilé au dessus.

Maintenant c'est bien beau tout ça, mais comment on test les différentes itérations ? Parce que ça marche bien de bidouiller à l'aveugle au début, mais le modèle progressant, il faut trouver un moyen plus robuste de vérifier si mes idées améliorent l'experience de jeu, et j'avais pas encore envie de faire appel à des beta-testeur (parce que je vous ai peut être hypé avec la partie précédente, mais ça pue encore un peu la merde )

Après quelques itérations, j'ai fini par mettre en place 2 systèmes pour évaluer mon framework:
1. Un fichier avec un ensemble de prompts utilisateur statics. En gros pour chaque configuration de jeu, j'ai plusieurs prompts que je vais envoyé à mon framework: certains doivent déclancher un call avec une action_id précise, d'autre pas. Pour chaque cas de figure, je peux évaluer si la réponse du framework est conforme à mes attentes, et dériver un score de succès global. J'ai utilisé GPT4 pour m'aider à structurer des examples pour chaque cas de figure, et j'ai fini avec une 50ene de "messages" types sur lequel évaluer mon framework.
2. Faire jouer GPT4 directement. En gros, GPT envoit un message, je le copie dans mon front, et je colle dans GPT chat la réponse de mon framework. Et je regarde si l'IA arrive à aller au bout de l'histoire

Ca ressemblait à ça:

Avec ce framework, j'ai pu apporter plusieurs améliorations à mon backend et j'ai pu commencé à avancer sur d'autres parties du projet (le cloud et le front).

Dans la prochaine partie, on va reparler un peu front et UX parce qu'il y a eu pas mal de changement, et ça fait longtemps que j'ai pas fait des beaux screenshots de l'application.

Le 05 février 2024 à 22:51:45 :

Le 05 février 2024 à 22:10:27 :
Topic en FAV pour ma part, j'espère que tu trouvera la déter de mener à bien ton projet khey

Continues à partager qqs détails techniques comme tu le fais, ça permet de rendre tes actions plus visibles et compréhensibles pour les codeurs en carton comme moi

Hésite pas si tu as des questions plus précises (histoire de faire vivre un peu le topic )

A la base j'étais pas Data Scientist, encore moins dev. J'ai un background d'ingésclave, je me suis reconverti il y a 5 ans environ.

Je doute de pouvoir être précis dans des questions, c'est absolument pas mon domaine, j'ai plus approché l'informatique par le front et j'ai bifurqué dans un domaine qui n'a plus rien à voir mais c'est toujours intéressant de lire les process et les réflexions derrière un projet

Plus, on nous rabâche l'IA à toutes les sauces mais c'est pas forcément facile d'en comprendre un peu le fonctionnement ou comment déployer ça sur des projets annexes sans tomber sur des tutos indiens éclatés ou des documentations imbitables donc ton topic est pas mal bienvenu je trouve

Chapitre VII: New front

L'expérience de jeu commence à être correcte, il est temps d'améliorer le front. Et cette fois on va passer aux choses sérieuses.

On reste sur l'idée de deux pages (la page d'accueil et la page de jeu) mais cette fois, on a commencer à ajouter les éléments manquant notamment:
- Login Page
- Register Page
- Validation du mail
- Pop ups diverses...

J'ai aussi décidé de reprendre l'UX et repartir d'une feuille blanche. J'en ai profité pour rendre l'application réactive et adapter le layout pour les utilisateurs mobiles.

GPT4 a été un allié redoutable ici: que ce soit pour brainstormer, pour penser le layout ou pour m'aider sur le CSS (je dis aidé, mais concrêtement, c'est GPT qui m'a pondu tout le CSS).

Cette version du front m'a pris vraiment pas mal de temps à coder, au moins deux semaines je pense, et ça a été vraiment compliqué d'intégrer tous les petits détails qui rendent le tout ergonomique. Par exemple:
- Gérer les erreurs et les exceptions quand un utilisateur utilise une mauvaise combinaison mail/mot de passe, ou si le compte n'existe pas
- Gérer l'expiration du token d'authentification
- Gérer la redirection de la page de validation de mail
- Gérer la déconnexion, etc..

Côté style, suivant les conseils de GPT j'ai épuré les couleurs pour faire moins kitch et adopté le style "néomorphisme".

En plus de ça, j'ai essayé de structurer ma code base pour éviter les problèmes de developpement par la suite, particulièrement quand je voudrais rajouter d'autres features. Bref j'ai du muscler un peu mon jeu.

Voici à quoi ressemble la page d'accueil, elle n'évoluera pas beaucoup plus ensuite.

La page principale de jeu ressemble à ça à ce moment du développement:

Elle est composé de 3 zones:
- A gauche, des boutons de navigations qui fonctionnent sur le principe de pop-up.
- Au milieu, l'interface de dialogue
- A droite, des informations / illustrations secondaires

Exemple de popup:

A noter: à ce moment du développement, la page et les illustrations sont statics et sont pré-enregistrés dans les assets du front. Par la suite, je vais améliorer ça pour rendre le tout plus dynamique.

Par rapport à la version précédente, on peut aussi noter certains changements fondamentaux, notamment l'abandon des options actions/dialogues au profit d'une interface unique. C'est maintenant le back qui se charge de comprendre si l'utilisateur veut simplement dialoguer ou réaliser une action en jeu.

A ce niveau de développement, il n'y a également qu'un seul interlocuteur, le narrateur. J'ai fait ce choix pour simplifier le travail de refonte (assez compliqué comme ça!), et je comptais intégrer l'ajout de personnages dans la suite du développement.

Petit bonus, comme précisé au départ, l'ajout d'un front "réactif", le mobile a donc sa version dédiée, plus ergonomique.

Bon, avouez, il commence à avoir de la gueule mon petit front bricolé à ce moment là ? Je vous laisse contempler le chemin parcouru depuis la v0 posté en haut du topic. Et c'est pas encore fini.

Chapitre VIII: Road to the cloud

Maintenant que j'ai un front qui tappe à l'oeil, on va s'attaquer à une autre partie du projet, l'hebergement cloud. Parce que je vais pas aller loin avec ma version qui tourne en local.

Avant d'attaquer, j'ai commencé par restructurer tout mon projet sur gitlab en plusieurs repos: pour le front, pour l'api, pour le game engine et pour la DB. Le projet dans son ensemble commence à devenir pas mal touffu, donc faut commencer à adopter des best practices niveau dev. Donc on arrête de tout push n'importe comment sur la branche de prod. Je me crée une branche dev et une branche local.

Même si le repo est privé, j'évite de faire le foufou avec les variables d'environnement codé en dur (genre le token GPT). C'est peut être basic pour beaucoup de monde, mais c'est fou le nombre de token que j'ai pu voir trainer dans des pages webs en regardant juste le code source ou les flux.

Parlons rapidement de la DB: à ce moment là du projet, elle me sert à plusieurs choses:
- Gérer les utilisateurs
- Gérer les sessions de jeu (via des uuids propre à chaque partie)
- Gérer l'historique des messages pour chaque session

Jusqu'à maintenant ça tournait sur une version local sur une DB Postgres que je simulais à l'aide de docker, je vais maintenant migrer ça dans le cloud. J'ai choisi AWS parce que c'est un cloud provider que je connaissais déjà, mais en dehors de ça je n'ai pas particulièrement d'autres arguments en sa faveur.
Pour ceux qui ne connaissent pas, le service associé sur AWS c'est RDS. Pour les prolos comme moi, il y a une offre free-tier qui permet de faire tourner une petite DB gratuitement.
Par contre il faut bien choisir les options minimales quand vous configurez ça parce que sinon, vous allez raquer.

J'ai aussi mis en place dans mon repo DB le framework allembic, qui permet de réaliser facilement (enfin ça c'est la théorie) les data migrations (genre ajouter de nouvelles colonnes).

Une fois la DB en place, elle est facilement accessible depuis l'extérieur avec l'aide de l'host/username/password, par contre pour être accessible depuis d'autres services EC2, il faut bien faire attention de configurer un VPC, sinon vous allez vous manger des messages d'erreurs à droite à gauche. Evidemment, tout ça je l'ai appris sur le tas et dans la douleur, si il suffisait de cliquer sur trois bouttons, ça aurait été trop facile.

L'étape d'après c'est la mise en place dans le cloud de l'API. Je voulais passer par le service AWS Lambda au début, mais flemme, et je me suis tourné temporairement simplement vers le service EC2. Pour les rookies, EC2 permets de louer une machine virtuel sur le cloud et d'y mettre ce que vous voulez. Il y a aussi une option free-tier donc profitez en si vous voulez essayer. Une fois mis en place, je me connecte en SSH sur le server, clone mon repo API et lance l'image docker qui fait tourner le server.

A partir de là il suffit théoriquement de call l'ip du server avec le bon port et on a accès à l'API.
Encore une fois plusieurs subtilités sur lesquelles je me suis cassé les dents, mais j'en reparlerais tout à l'heure.

La dernière étape c'est la mise du front en ligne. Pour ça, j'ai utilisé le service AWS Amplify. Pour le coup c'est facile, il "suffit" d'indiquer à AWS le repo git à regarder, et il se charge automatiquement de monter l'image docker et la met en ligne. C'est normalement possible de gerer également la partie backend/db avec amplify de ce que j'ai compris, mais bon, j'avais configuré tout le reste manuellement, donc je suis resté sur mon bricolage maison.

Une fois le front mis en ligne, normalement c'est gagné, toute la stack est en ligne !
On essaye de se co à l'IP du front eeeeet.... Evidemment, rien ne fonctionne comme ça devrait.

Pourquoi ? Parce que mon EC2 est servit en HTTP, et ça, certains browser aiment pas trop

Dans la prochaine partie, on va donc devoir parler DNS, mais aussi Loadbalancer, les deux derniers éléments qu'il me manquait pour que mon bricolage tourne à peu près correctement.

Bon il est tard et je bide sérieusement.

Je vous laisse sur mon cliffhanger et je reprendrais mon monologue demain

Bonne nuit aux kheys qui m'ont lu jusque là, j'espère que mon épopée vous plait.