Bonjour mes Petits

Nous nous retrouvons donc réunis une nouvelle fois dans mon atelier pour mener à bien ce deuxième épisode de notre série de tutos. On va pousser un peu le bazar sur le côté, souffler un peu la poussière, déplacer la camomille sur le coin du bureau pour ne pas la renverser sur le clavier, là juste à côté du verre à dents et reprendre notre petit projet là où nous l'avions laissé.

Liens vers l'ensemble des articles de la série

Cliquer pour enrouler

Pour rappel, les liens qui vont bien pour la série [c'est du WIP, donc ce sera complété au fur et à mesure] :

- Introduction de la série
- Tuto #1 - Présentation du fxSDK et du wording associé
- Tuto #2 - Présentation en détail du jeu et premier prototype
- Tuto #3 - On entre dans le vif du sujet, un premier truc qui ressemble vraiment à un jeu
- Tuto #4 - Quand ça va mal, qu'est ce qu'on fait ? Car ça arrive toujours à un moment ou à un autre
- Tuto #5 - On ajoute quelques features avancées

Donc après un longuissime premier tuto qui nous a permis de mettre en place notre base de projet avec le bon paramétrage pour travailler sereinement en C++ et après avoir longuement explicité le rôle des divers outils présents dans fxSDK, nous allons donc pouvoir désormais entamer les choses sérieuses au cours de ce second volet.
Nous allons donc commencer par une rapide première partie destinée à montrer notre cible en termes de gameplay puis poser les bases de la structure de notre jeu en identifiant les différents éléments à mettre en place ainsi que leurs possibles interactions.
Ensuite, nous donnerons une structure à notre projet en créant les fichiers qui contiendront le code source puis nous mettrons en place la boucle principale de jeu avec un début de rendu.
Enfin, nous ferons notre première compilation afin de vérifier que tout fonctionne bien.

Donc aujourd'hui le mot d'ordre est "Réflexion" pour bien architecturer notre projet et ensuite pouvoir avancer à un bon rythme. Cela peut paraître rébarbatif, mais un bon projet commence souvent par cette étape, qui fait gagner énormément de temps par la suite et évite de s'embarquer dans de mauvaises pistes.

Allez, on est partis ?!? ...

Présentation en détail du jeu et premier prototype

Donc comme explicité dans l'article d'introduction, notre objectif est de programmer un jeu de type Tower Defense en C++. Voici une image représentant approximativement la cible que je vous propose de copier

(Crédit image - The Tower - Idle Tower Defense par Tech Tree Games LLC )

Afin de montrer le fonctionnement du jeu, je vous invite à regarder cette très courte vidéo qui vous montre le principe de jeu (attention c'est très très rapide).



Nous allons donc commencer à décortiquer ce que nous devrons mettre en place pour coder ce jeu (en version simplifiée bien entendu, le but n'étant pas de faire un jeu complet dans le cadre de cette série tuto).

a. On liste les différents items du jeu (joueur, ennemis, attaques, niveau de vie, score, ... )

En analysant la vidéo précédente, on peut noter la présence d'un certain nombre d'entités :
La tour et son périmètre à défendre (entité que nous appellerons Tower)
Les ennemis qui foncent vers la tour (entités que nous appellerons Enemy)
Les tirs de la tour vers les ennemis (entités que nous appellerons Bullet)

Donc la base du jeu se fait sur ces 3 entités qui faudra faire interagir. Il y a bien entendu tout un lot de propriétés associées à chacune de ces entités que nous listerons et que nous pourrons faire évoluer au fur et à mesure du développement, mais dans un premier temps, focalisons nous sur ces trois éléments. Si on résume de manière graphique, avec ces 3 entités, on devrait arriver à un truc du genre :



Donnons-nous donc comme objectif du jour de parvenir à obtenir ce résultat sur fxCG et sur fx9860G.

b. On pose la structure du projet avec des fichiers aux bons endroits.

Pour commencer, nous allons créer une structure de fichiers/répertoires propre dans le sous-répertoire source. Créons donc un sous-répertoire entities dans lequel nous déposerons les fichiers nécessaires à la définition des entités vues précédemment. Ensuite, pour chacune de ces entités, nous créons dans ce sous-répertoire un fichier header (format .hpp) et un fichier source (format .cpp) tel que présenté par la capture suivante :



Il nous faut, pour que tout cela soit pris en compte lors de la compilation, ajouter dans le fichier CMakeLists.txt les noms des fichiers source .cpp afin de les compiler. Ceci est réalisé en modifiant les lignes dans la section set(SOURCES) de la manière suivante :

On ajoute donc simplement le lien relatif des fichiers .cpp. Il est à noter que les headers (.hpp) n'apparaissent pas ici mais seront liés au projet directement dans le code que nous écrirons.

Donc désormais, nous avons positionné dans notre arborescence l'ensemble des fichiers nécessaires pour construire notre premier prototype de jeu.

Bien entendu, on va expliciter un peu le rôle de chacun. Voici ce que nous mettrons en place dans chacun des fichiers:
fichier main.cpp : il s'agit du fichier qui contient le point d'entrée de notre programme. Il contient notamment la fonction principale qui gèrera la boucle de jeu principale (ou GameLoop()) que nous allons détailler dans la partie suivante,
fichiers entities/tower.hpp et entities/tower.cpp : il s'agit respectivement des fichiers qui décriront l'entité Tower sous forme d'une classe avec ses propriétés et ses méthodes pour le fichier header et de l'implémentation du code de ses méthodes pour le fichier source,
fichiers entities/enemy.hpp et entities/enemy.cpp : fichiers de description de la classe Enemy et d'implémentation de ses méthodes,
fichiers entities/bullet.hpp et entities/bullet.cpp : vous l'aurez deviné, idem pour la classe Bullet.

Donc d'une manière globale, on aura beaucoup de similitudes dans la structure de ces divers fichiers. Détailllons un peu en prenant l'exemple de l'entité Bullet :
Les fichiers headers .hpp: ils contiennent la description des classes relatives à chacune des entités. Celles-ci contiennent à la fois des propriétés (par exemple les points de vie, le score, la puissance, la position et la vitesse, ...), mais aussi des méthodes (Constructeur et Destructeur, fonctions de dessin et de mise à jour, divers tests de collisions, ...). Pour la classe Bullet le fichier header ressemble à ceci :

Les fichiers source .cpp: ils contiennent le code relatif à chacune des méthodes décrites dans le fichier header de l'entité. Il est usuel (et plus propre de ne jamais mettre de code dans le fichier header, mais de toujours déporter le code dans le fichier source correspondant). C'est donc dans ce fichier que l'on va implémenter les lignes de code qui vont permettre de rentrer dans le concrêt. Pour la classe Bullet le fichier source ressemble à ceci :


Avec tous ces éléments, nous avons donc en tête la structure de notre projet ainsi qu'une vision claire du contenu de chacun des fichiers. Nous allons donc passer à la description du contenu de la boucle principale de jeu et du fichier main.cpp.

c. On met en place la "Game Loop" la plus simple possible mais fonctionnelle.

Comme explicité très rapidement dans le précédent chapitre, le but du fichier main.cppest de mettre en place la boucle de jeu principale, ou Game Loop. Il s'agit de la boucle qui sera répétée de manière continue jusqu'à l'ordre de sortie et qui aura pour but d'organiser le bon séquencement des diverses actions à exécuter dans le jeu.

Vu d'un niveau très macroscopique, la boucle de jeu peut se traduire par une boucle tant que (ou boucle while):


Nous allons donc créer diverses méthodes qui seront appelées en boucle par la fonction main et dont le rôle individuel sera de réaliser chacune des trois opérations de la Game Loop:
intercepter les interactions du joueur avec le clavier et lancer les sous-actions correspondantes. Nous appellerons cette fonction GetInputs.
lancer les mises à jour de l'ensemble des entités (changement de position, vérification des collisions, ...). Cette fonction appellera donc entre autres les méthodes Update() de chacune des entités.
lancer les mises à jour de l'ensemble des entités (changement de position, vérification des collisions, ...). Cette fonction appellera donc entre autres les méthodes Render() de chacune des entités.

Il existe deux techniques principales pour effectuer cette boucle de jeu, soit on fait une simple boucle while sans se poser de question, et dans ce cas le processeur va tourner à fond et on aura des FPS qui peuvent être très élevés dans le cas de jeux simples, soit on peut limiter le FPS et mettre le processeur au repos via une commande sleep() lorsque l'on a du temps non consommé entre deux frames. Cette solution est nettement meilleure d'un point du vue consommation des piles, mais il faut néanmoins faire attention au temps alloué pour les opérations entre 2 frames.
Prenons par exemple une cible de fonctionnement à 30FPS, cela signifie qu'entre 2 frames on a 33ms. Toutes les 33ms, on va demander un rendu de la nouvelle frame. Autant dire que si les opérations intermédiaires à exécuter prennent 40ms par exemple, on passera notre temps à être aux fraises et on va faire du grand n'importe quoi. Donc, pour résumer, il faut bien pondérer le plus et le moins de chacune des 2 options.

Boucle sans limitation de FPS

Boucle avec limitation de FPS

#include <gint/cpu.h> #include <gint/display.h> #include <gint/keyboard.h> bool ExitToOS = false; // Function which will call render methods of entities void Render(void) { dclear(C_WHITE); // TODO : add rendering stuff here !!! dupdate(); } // Function which will call update methods of entities void Update(void) { // TODO : add update stuff here !!! } // Function which will check user inputs void GetInputs(void) { cleareventflips(); clearevents(); // EXIT KEY is pressed so we change the flag to quit if (keypressed(KEY_EXIT)) ExitToOS = true; // TODO : add more inputs } // Main function int main(void) { // While loop : begining of the Game Loop // we stop when the flag ExitToOs becomes true while (!ExitToOS) {     GetInputs();    // Call to Inputs management function     Update();       // Call to Update management function     Render();       // Call to Render management function } return 1; }

#include <gint/cpu.h> #include <gint/display.h> #include <gint/keyboard.h> #include <gint/timer.h> bool ExitToOS = false; #define FRAME_RATE 30 // The variable that will be triggered when next frame is necessary volatile int frame_tick = 1; int timer_id; // ID of the timer (to be saved to close it later) // We define the parameter of the timer // here we will change the value of frame_tick every 33ms (1 000 000 µs / FRAME_RATE) void SetTimer(void) { timer_id = timer_configure(TIMER_ANY, 1000000 / FRAME_RATE, GINT_CALL_SET(&frame_tick)); if (timer_id >= 0) timer_start(timer_id); } // Function to close the timer void CloseTimer(void) { if (timer_id >= 0) timer_stop(timer_id); } // Similar to other option void Render(void) { dclear(C_WHITE); dupdate(); } // Similar to other option void Update(void) { } // Similar to other option void GetInputs(void) { cleareventflips(); clearevents(); if (keypressed(KEY_EXIT)) ExitToOS = true; } // Main function int main(void) { // We initiate the timer SetTimer(); // While loop : begining of the Game Loop // we stop when the flag ExitToOs becomes true while (!ExitToOS) {     // We have now an internal loop that will put the CPU in sleep mode as long as the value of frame_tick is 0     // every 33ms, frame_tick will be set at 1 and then the following actions (GetInput(), Update() and Render())     // will be performed     while (!frame_tick)       sleep();     GetInputs();    // Call to Inputs management function     Update();       // Call to Update management function     Render();       // Call to Render management function } // We close the timer CloseTimer(); return 1; }

On peut donc voir que les modifications sont assez limitées pour limiter (ou caper) le framerate d'un jeu. Il suffit de passer par un timer que l'on configure de manière adéquate pour changer le contenu d'une variable. Ensuite dans la boucle principale, il reste à mettre le CPU au repos tant que cette variable n'est pas à la valeur demandant le rendu de la prochaine frame.

La boucle de jeu principale est donc désormais terminée. On va rajouter un peu de code dans les méthodes des diverses entités (je vous laisse le lire et me poser des questions si besoin) et complèter les fonctions du fichier main.cpp. Ce dernier devient :


Nous allons désormais peupler le corps de nos diverses méthodes et fonctions. Je ne reviendrai pas sur l'intégralité du code mais me focaliserait sur l'entité Bullet. Les entités Tower fonctionnant globalement de la même manière, vous vous y retrouverez très facilement.

d. On ajoute du code dans les méthodes des entités et dans la boucle principale

Commençons donc à examiner de plus près les méthodes de la classe Bullet. Nous avons les deux méthodes Render() et Update() que nous retrouvons sur l'ensemble des entités ainsi qu'une méthode HitDone() spécifique à cette classe. Les attributs (ou propriétés) de la classe on été vus au tout debut de cet article, je ne les reprendrai donc pas ici et vous invite à relire le paragraphe b.

Allez, nous sommes partis ...

Commençons par les constructeurs et destructeurs de classe.



Le constructeur doit être appelé avec 2 paramètres de type float correspondants aux coordonnées de la cible (TargetX, TargetY). Sachant que le point d'émission est le centre de la Tour situé au centre de l'écran, on va donc pouvoir affecter ou calculer l'intégralité des valeurs des atttributs avec seulement ces 2 paramètres supplémentaires précisés lors de l'instanciation d'un objet de type Bullet. Les coordonnés de départ (BulletX, BulletY) sont calculées avec les valeurs de taille d'écran issues de gint (DWIDTH et DHEIGHT), la vitesse est donnée à une valeur de 1.0f et la puissance vaut 2. On choisit la taille Size identique à Power dans ce cas, mais on pourrait aussi ajouter des paramètres au constructeur pour paramétriser cela plus finement. Enfin, on calcul les valeurs de DX et DY qui représentent la modification des coordonnées BulletX et BulletY respectivement à chaque appel de la méthode Update().

On remarque une section un peu particulière que vous retrouverez souvent dans vos add-ins fxSDK si vous visez un support multiplateforme :

Les directives préprocesseurs #if ( ) .. #else .. #endif permettent de modififier des pans de code avant la compilation au niveau de l'étape de préprocessing. Le préprocesseur a connaissance de la machine cible (FX9860G si monochrome et FXCG50 si couleur) et saura donc censurer les morceaux de code ne se rapportant pas à telle ou telle architecture. Dans notre cas, on se sert de cela pour affecter une couleur verte aux balles si on est sur Prizm ou sinon, on dessine en noir. Malin, n'est il pas ?

Pour créer un objet Bullet, il nous suffera donc de faire par exemple dans notre boucle principale


Pour le destructeur, c'est vraiment très simple ici, car il n'y a que des membres "statique" (pas de pointeur, pas de "containers", ...) donc pas de variables à libérer manuellement. On peut donc laisser cette fonction vide :

Mais attention, ce n'est pas toujours le cas.

Pour appeler le destructeur, il suffit de faire appel dans la boucle principale à delete:


Nous arrivons désormais aux deux méthodes "génériques" appelées par la boucle principale à chaque rotation :
la méthode Render():

Il s'agit juste d'un appel à la fonction de dessin d'un cercle plein fournie par gint, cercle centré en (BulletX, BulletY), de rayon Size et de couleur Color (bordure + remplissage).

la méthode Update():

Pas beaucoup plus complexe, cette méthode sert à mettre à jour la position de la balle à chaque tour de boucle de jeu. Son rôle est donc de mettre à jour les coordonnées (BulletX, BulletY) avec les incréments calculés dans le constructeur. On a juste 2 tests suplémentaires, le premier qui vérifie si la balle a été marquée précédemment pour destruction et si oui shunte le calcul et enfin, un test de vision pour savoir si la balle est en dehors de l'écran visible et si oui la marque pour destruction au prochain tour.

La dernière méthode HitDone() est appelée si la balle touche un ennemi. Il s'agit en cas de contact de marquer la balle pour destruction tout simplement :


Voici pour la description exhaustive des méthodes de la classe Bullet telles que l'on peut les trouver dans le fichier bullet.cpp. Je vais juste détailler une méthode intéressante de la classe Enemy, à savoir la méthode TestImpact :

Tout d'abord, on doit tester l'impact entre l'ennemi courant et une balle, il faut donc préciser l'objet Bullet en paramètre de cette fonction (Ne pas oublier de mettre un #include "bullet.hpp" dansle fichier enemy.hpp sinon ça va hurler à la compilation). On cherche ensuite à vérifier si les coordonnées de la balle (qui s'appelle "Shot" dans ce contexte) se superposent à celle de l'ennemi. On fait donc un simple test AABB. Si celui-ci échoue on renvoie false, à savoir pas de contact, sinon on retire de la vie à l'ennemi en fonction de la puissance de la balle et on retourne true à savoir il y a contact.

Si on regarde du côté de la boucle principale, il s'agit désormais de bien piloter ces entités avec les bons calls aux bonnes méthodes et aux bons moments.

On commence par initialiser le jeu via une fonction dédiées :

On crée un objet de type Tower puis 25 objets de type Enemy que l'on place dans un containers de type std::vector<Enermy *>. Il s'agit d'une feature offerte par le C++ et la librairie standard du C++. Ceci nous permet d'avoir un tableau dynamique donc la taille est automatiquement gérée.

En toute fin de programme, on a le pendant de cette fonction:

où on appelle le destructeur de l'objet MyTower et pour le tableau d'Enemy. Attention dans ce cas, il y a une petite subtilité, on commence par détruire tous les objets un par un avec un delete, et ensuite on fait un appel à la méthode clear() du container std::vector<Enermy *>.

Pour la fonction de rendu, rien de compliqué, mais regardons la fonction Update():


Il y a quelques petites portions de code qui sont un peu plus velues, notamment pour retirer les éléments qui ont été marqués pour destruction qui utilisent des fonctions lambda. Ne vous posez pas trop de questions, et considérez ces quelques portions comme des boîtes noires. Il s'agit de morceaux de code destinés à retirer les projectiles et les enemis marqués pour destruction des containeurs de type std::vector< >. La synthaxe du C++ pouvant être parfois un peu rustre, ne vous tracassez donc pas avec cela.

Pour le reste, il s'agit de calls aux méthodes Update() de chaque entité.

On regarde aussi si il y a collision entre les balles et les ennemis dans cette partie :

et si contact il y a, on marque la balle pour destruction.

Enfin, les balles et ennemis marqués pour destruction sont retirés des containers C++ afin de ne plus avoir à les traiter au tour suivant.

Nous avons donc désormais vu l'ensemble du code utile et on va vérifier que tout fonctionne correctement.


e. On fait notre toute première compilation et quelques premiers tests

La compilation se fait comme explicitée lors du premier volet via un fxsdk build-cg ou fxsdk build-fx selon si vous viser de faire une version fxCG ou fx9860G. Logiquement tout devrait se passer sans encombre et vous pourrez obtenir le résultat de cette vidéo (test du fichier add-in en g3a sur l'émulateur de fxCG50 de Heath123) :



Voici le résultat détaillé de la compilation pour fxCG en mode verbeux. Même pas un petit warning, on est bons là les amis



Voilà qui en termine donc avec ce deuxième épisode de notre série de tutos. On commence d'avoir une base qui ressemble à quelque chose de propre. On poursuivra dans les prochains volets en mettant un peu plus d'automatisme, en ajoutant quelques menus et en affinant un peu le gameplay.

Vous trouverez comme d'habitude dans le fichier ZIP attaché une copie du projet dûment configuré et fonctionnel. N'hésitez pas à poster vos questions et/ou vos commentaires. Je tâcherai de répondre à tous vos posts.

On se retrouve donc très rapidement pour le prochain épisode de cette série de tutos, gardez un œil bien ouvert sur la page d'accueil et guettez bien le retour de Papy Sly.

C'est pas tout ça, je vais retourner me faire ma camomille du soir et mettre mes charentaises avant de m'installer dans mon rocking chair ...



A très bientôt mes Petiots

Papy Sly


Edit du 28/01/2023 : Ajout d'un paragraphe détaillant le contenu des méthodes + boucle principale.

Fichier joint