Un système d'amélioration coûtant des points, et pouvant être amélioré pour augmenter l'efficacité. Actuellement : il y a 37 améliorations disponibles. La progression linéaire est assurée par des améliorations "Débloquantes" permettant de débloquer les prochaines suites d'améliorations (Permet au joueur de se concentrer sur les améliorations en cours, et lui oppose un "nombre obstacle" à dépasser pour accéder au contenu suivant).

L'affichage des améliorations est géré par un widget GridView construisant la grille . Chaque items de la grille est un widget custom "Rounded Box" qui affiche , dans une colonne, le titre de l'amélioration, sa description dans un Expanded Scrollable, et l'ensemble Niveau/Bouton d'achat/Prix de maniere conditionnelle.

Au fur et a mesure de la partie, les ballons apparaissent plus vite. Chaque ballons toujours présent sur la grille au moment de l'apparition d'un nouveau ballon inflige des dégâts, selon leur couleur (rouge : 1, bleu : 2, vert: 3, jaune : 4...). De plus, éclater un ballon ne le fait pas disparaitre automatiquement : il le fait passer au niveau inférieur (éclater un ballon jaune le fait devenir vert, éclater un vert le fait devenir bleu, etc). Des améliorations basés sur le temps, le regain de vie, les périodes d'invincibilités, la défense, la résurrection, permettent cependant de mitiger cette difficultée afin de rester en vie plus longtemps et de gagner plus de points.

Flutter et Dart permettent déja de faire des softwares utilisables sur de nombreuses plateformes. Pour rendre le jeu utilisable sur une en particulier, il suffit d'adapter le code aux spécificités de la plateforme visée. Par exemple, sur ios, il faut que le passage entre les différentes pages de l'application se fassent dans un controleur asynchrone. Mais dans ce cas, je voulais simplement le faire marcher sur Windows et Android. Et la spécificité a adapter, c'est la base de donnée. J'ai donc crée une interface...

... que j'ai fait implémenter par une classe contactant les bdd sqlite, et une autre contactant les bdd sqflite (version flutter "phone friendly" de sqlite). Ainsi, en passant par un service d'aide de contact des bases de données, je peut changer la manière de contacter les bdd selon la plateforme sur laquelle je me trouve. Maintenant , a chaque fois que je veut accéder a la bdd (pour sauvegarder l'état du joueur ou le charger par exemple), je passe par ce service et tout se fait automatiquement. On est dans le design pattern Adaptater. A noter qu'en passant par ce pattern, le code a du s'adapter à la méthode de contact de bdd la plus exigeante. De ce fait, tout les contacts à la bdd sont asynchrones.

Les professeurs demandent à l'admin un compte (demande du client) à partir de son email. Le mot de passe n'est pas directement donné, c'est au professeur de se connecter d'abord uniquement avec son adresse mail. Le système reconnait alors la nature de l'utilisateur et lui propose de mettre en place un mot de passe. Le même système est utilisé entre le professeur et son élève (professeur crée un compte élève, élève se connecte avec son mail, système propose à l'élève de mettre un mot de passe).

Le panneau administrateur permet de gérer les professeur, prendre le rôle des professeurs pour voir leurs panneaux en cas de problèmes, et gérer les chapitres, de leur création/modification à leur accès par les users.

Le panneau professeur permet de gérer des classes d'élèves, et de donner des droits d'accès aux différents chapitres , par classe (droits ne supplantant pas l'accès mis en place par l'admin).

L'utilisateur a accès à une navigation par chapitres, dont l'affichage change selon la disponibilité du chapitre (selon si le chapitre est disponible, non disponible à cause du professeur, non disponible à cause de l'administrateur).

Les accès aux différentes routes sont sécurisés par middleware, eux mêmes gérés par un singleton instancié au début.

Les Routes de base (panneaux, index,...) ont leur définition dans un fichier routes. Mais les routes de chapitres (vu que les chapitres peuvent être rajoutés, supprimés, ...) passent par un overlay qui check d'abord si l'URI correspond à une route stockée en bdd, puis applique un middleware authentification et de droit d’accès au chapitre, avant d'emmener sur un contrôleur spécifique qui affiche le bon fichier de chapitre selon la manière dont ce dernier est stocké en bdd.

Le Backoffice a été pensé de la manière suivante : une page de backoffice "principal" (montre les pages et leur affiliation), une page de backoffice "page" (modifier titre et affiliation de la page, ajout de contenu), une page de backoffice "contenu" (modifier le contenu, y rajouter des images), et un backoffice "image" (modifier une image d'un contenu).

Contient les pages parents (catégories) et leurs pages enfants (sous-catégorie).

Permet de modifier le titre de la page, son affiliation a un parent, et rajouter du contenu (un contenu est un ensemble "texte + image(s)" , et une page peut avoir plusieurs contenus).

Permet de modifier le titre ou la description du contenu, ainsi que d'y rajouter des images (si un contenu à plusieurs images, ces dernières seront affichées dans un carrousel).

Permet de voir, modifier, supprimer une image mise dans un contenu.

Une partie du jeu de la vie de Conway (Conway's Game of Life) a été développée, puis utilisée pour tester les gains de performances du mode kiosk. Avec une grille de 1 Millions de pixels² et 6 Raspberry pi 400 , on atteignait des performances de 430 fps (on aurait pu aller plus haut, mais on a eu des problèmes de saturation réseau, car on utilisait le réseau pour faire communiquer les Raspberries ensemble).

Comme dans le projet puissance 4, on a une page d'information pour le joueur qui est accessible à n'importe quel moment en cliquant sur une case en bas à gauche. La case est disponible en jeu, et un système de pause permet de prendre son temps pour cliquer et comprendre.

Un exemple d'un niveau. Le bas est réservé aux informations du joueur (score, vies, objectif, case pour la page de règles) , et l'écran est composé d'un tableau derrière lequel se trouve un background. Chaque cases du tableau possède une valeur qui correspond à sa nature : 200 pour le rocher, 101 pour un fruit rouge, entre 1 et la taille du joueur pour le corps du snake,... A chaque frame, on calcule la position de la tête du snake (en orange sur l'image) selon la direction du joueur, et on fait "mourir" le corps du snake en diminuant de 1 la valeur de chaque cellules corps . Ainsi, l'ancienne tête prend maintenant une valeur de corps, le corps perd de sa valeur, et la dernière case du snake (son ancien bout de queue) passe a 0, donnant l'illusion d'un snake qui se déplace. En clair : la case tête a la valeur du nombre de fruits mangés par le joueur, le corps jusqu'avant la tête a la valeur score - 1, et ainsi de suite jusqu'au bout de la queue qui a la valeur 1. Et quand on se déplace, on diminue tout de 1, donc l'ancien bout de queue redevient une case lambda et l'ancienne tête devient une case corps.

On reprend le système de nombre donné aux cases du tableau. Selon le nombre, la téléportation intervient quand le snake est sur la case trou d'eau et se dirige dans la bonne direction. Ensuite, dans la fonction de téléportation, on regarde une case trou d'eau dont l'unité a la même valeur que la case trou d'eau de départ, et on y donne la valeur de la tpete du snake pour déplacement. Si le système était aussi simple, passer dans un trou d'eau le supprimerait (on remplace sa valeur par celle du corps/tete du snake), donc le jeu possède une deuxième grille utilisée pour afficher les textures que le snake doit pouvoir emprunter sans supprimer. On pose ainsi le trou d'eau sur cette deuxième grille, et le tour est joué. Cette grille est aussi utilisée pour les orties.

Un menu accessible au clic, en bas à gauche, qui affiche les règles, ainsi que la pléthore de commandes disponibles pour customiser l'expérience de jeu.

Une bibliothèque C qui possède un accès aux périphériques de l'ordinateur pour afficher des choses, jouer des sons, récupérer des inputs de clavier/souris... On l'initialise au début du code, et on l'utilise partout.

SDL est très spécifique dans son utilisation : on gère des coordonnées, des largeurs, des couleurs, et pour afficher le texte il faut aussi jouer avec des caches, tailles et polices d'écriture.

On crée une boucle utilisant SDL_PollEvent pour gérer les événements venant de la souris , du clavier... Pour les boutons par exemple, il faut récupérer la position de la souris et voir si elle se situe dans une zone aux coordonnées précises (correspondant au bouton) au moment du clic.

Le centre de l'étage correspond à un "camp de base" dans lequel on peut interagir avec un marchand, affronter des monstres, un boss, passer à l'étage inférieur, ... Une fois que l'on décide d'explorer l'étage, on affiche une fenêtre turtle qui dessine le layout, et on laisse le joueur se balader librement (la flèche de la turtle représente alors sa position). Une fois dans une salle, le jouer peut décider d'observer la salle ce qui déclenche l'évènement qui y est associé, ainsi qu'un symbole le représentant. Le but de l'exploration est de trouver la clé pour affronter un ennemi puissant (boss) et passer a l'étage inférieur. Pour simplifier la compréhension de l'étage, ce dernier est divisé en quatre cadrants par ces "épines" qui partent du centre et sur lesquelles aucune salle ne peut se générer.

Les étages du Coliseum sont générés aléatoirement, de leur disposition a leur contenu : ça se passe en deux temps. En premier lieu, on génère le layout de l'étage. On laisse un "drone" partir depuis une case déja présente, dans une direction aléatoire. Si la case sur laquelle le "drone" atterrit est valide, alors on ajoute sa position a la liste de positions valides. A noter que les "branches" partant du centre sont la pour décorer, et aucune case ne peut y etre posée. Ça permet de séparer l'étage en 4 cadrans distincts. Une fois le layout terminé, on affecte une valeur de type (le type d’événement contenu dans la case) de manière aléatoire, selon toute une logique dépendant du type de salle, de l'étage actuel, de variables aléatoires... et si toute les salles "spéciales" trouvables dans l'étage actuel ont été associés, alors on remplis le reste avec des cases de combats, de pièges, ou de récompenses. Une fois l'étage généré, on enregistre la liste finale contenant toute les cases de l'étage ainsi que le type d'évènement associé dans un .txt servant de servant de fichier de sauvegarde.

Après l'exploration, l'autre partie principale du jeu est le combat. Développé au tour par tour (une phase d'attaque du joueur, une phase d'attaque de l'ennemi, on recommence jusqu'à la fin), influencé par de nombreuses altérations d'états (brulure, paralysie, ...), de nombreuses statistiques , de nombreux artefacts (ayant des effets simple sur les stats ou conditionnels complexes), de nombreuses actions possibles (sorts, techniques, items, ...) , le choix du modèle MVC s'est imposé. Ce dernier a été implémenté différemment que dans un site web : le modèle ici n'est qu'une grosse bibliothèque de valeurs sans aucune logique.

Pour ce qui est de la vue, on a la encore des méthodes ne servant qu'a afficher des informations selon ce qu'on lui passe en valeur. Il n'y a pas de logique : que de l'interaction entre le système et le joueur au travers de la console.

Enfin, c'est dans le contrôleur que réside toute la logique de combat, les calculs, et autre. Ce dernier ne fait que prendre les informations renvoyées par la vue, ainsi que les informations contenues dans le modèle, puis modifie les informations dans le modèle en fonction d'une logique propre, avant de renvoyer les résultats à la vue par affichage. Cette manière d'implémenter le MVC, apprise sur openclassroom, est différente d'un MVC classique type php dans sa définition des parts : le contrôleur n'est pas un simple système d'aiguillage renvoyant vers la bonne vue selon les informations qu'on lui donne , c'est le véritable cerveau du logiciel.