Mon premier travail, que j’ai programmé dans mon planning, après la seconde soutenance fut de gérer les collisions des unités au sol, étant donnés l’algorithme de déplacement que je connaissais sur le bout des doigts ainsi que la structure des Tiles. En fait le principe fondamental est de prendre la direction de l’unité en cours de déplacement regarder si elle va collisionner avec une unité en la faisant avancer virtuellement. L’intersection du groundRect de l’unité et d’une autre unité permet de voir si deux unités sont prévisibles de collisionner. Dans ce cas on prend la direction de l’unité en cours de déplacement et on rajoute en tête de la liste des coordonnées de l’unité (cf. rapport de la 2° soutenance) les points étant prédéfinis autour du groundRect de l’unité collisionnée. Mais cette méthode doit inclure de regarder si l’on a un point de changement de direction en dessous de l’unité collisionnée car il faut remplacer le point de changement de direction par le nouveau point prédéfinis autour de l’unité en collision. Un grand nombre d’autres cas particuliers étant à gérer, l’algorithme de collision devenait très vite lourd et de plus tous ces cas particuliers faisait que les unités ne contournaient pas les unités en collision. Je ne voyais qu’une seule autre solution qui était de recalculer le chemin en mettant les tiles en dessous de l’unité collisionnée en non walkable. Mais le défaut est vu que l’on travail sur un système de tiles mais que chaque tiles est de 32*32 pixels le problème est plus graphique qu’autre chose. Donc Guillaume a regardé s’il n’y avait pas d’autres systèmes pour la collision des unités terrestres.
Principe simple du tir
Les unités pour le tir se sont vues attribuer
Lorsqu’une unité est en état de tir alors toujours avec le système de délai, expliqué par Guillaume à la 2° soutenance, on fait afficher un frame(9) où l’unité est en train de lever son arme puis on crée une impression de tir en faisant animer deux frames identiques(10 et 11) avec l’un des deux sur lequel il y a une flamme au bout du canon de l’unité permettant l’illusion de tir.
Un système de rechargement a été mis en place. Pendant le rechargement, l’unité ne tire pas.
Explication de nouveauté dans l’enregistrement unitst
attacking: boolean;
agress: boolean;
TargetType: char;
UTarget: UnitPointer;
BTarget: BatimentPointer;
attackers: UnitListPointer;
followers: UnitListPointer;
attacking permet de savoir si l’unité est en train de tirer
agress permet de déterminer le tempérament des unités, agressivité des joueurs comme indiqué dans le cahier des charges
TargetType permet de déterminer si l’unité attaque un batiment ou une unité
Utarget et Btarget sont le pointer sur la cible (c’est l’un ou l’autre)
Attackers sont toutes les unités qui tirent sur l’unité actuelle
Followers sont toutes les unités qui ont pour cible l’unité actuelle (il contient les attackers)
Explication plus approfondie
La procédure qui fait tout un engrenage dans le tir est DoDamage elle engrange elle-même le fait de riposter…
Avant de tirer sur une unité, l’attaqueur va vérifier si sa distance entre lui et l’unité sur laquelle il tire est inférieure à la portée efficace de ses armes.
Elle remplit les valeurs précédemment énoncées(dans la définition des types de unitst) donc l’unité se faisant tirer dessus prend en paramètre l’autre unité lui tirant dessus. Les dommages que subit l’unité sont fonction de la puissance de l’arme qui tire dessus, de la distance à laquelle il est du tireur et si l’unité et en déplacement on a moins de chance de subir des dommages(, et peut être même la hauteur des unités les unes aux autres).
Comme l’unité qui s’est fait tirer dessus est maintenant au courant qu’elle se fait tirer dessus(unitP^.attackers <> nil) alors en fonction de son agressivité(agress), elle va avoir différentes réactions.
La riposte: Si une unité se fait attaquer elle prend en compte tous les paramètres de l’unité qui lui tire dessus, et se met à l’état 6, état de tir, alors on assiste à un duel sans merci.
if TmpUnitP^.agress then
if TmpUnitP^.attackers <> nil then
begin
TmpUnitP^.state := 6;
TmpUnitP^.attacking := true;
TmpUnitP^.TargetType := 'u';
TmpUnitP^.UTarget := TmpUnitP^.attackers^.unitP;
TmpUnitP^.follow := TmpUnitP^.attackers^.unitP;
end ;
La fuite : Une unité qui se fait tirer dessus et qui est peureuse (UnitP^.agress = false) prend la direction entre lui et l’unité qui l’attaque et par dans la direction opposée. La figure si dessous est pratique pour se représenter la direction que l’unité prend.
Pendant un certain temps les unités qui se déplaçaient étant agressives et perdant de l’énergie terminaient leur déplacement avant de riposter donc quand elle marche elle vérifie si elle n’est pas attaquée pour riposter de suite.
Attaque spontanée : lorsqu’une unité est en attente, il regarde dans un cercle de vision autour de lui de façon concentrique pour trouver la première unité ennemie autour de lui car dans la procédure DoDamage on a une plus grande chance de perdre de l’énergie si on est proche de l’ennemi.
Un délai est utilisé pour faire toutes ces vérifications pour éviter les ralentissement.
Pour l’instant de gros problèmes sont notés sur la mort des unités. Bien que les enregistrements followers et attackers nous permettent d’arrêter l’unité. Si elle est dans les attackers, les attackers étant en train de tirer sur l’unité qui viens de mourir, alors on arrête cette unité. Les followers sont par contre eux les unités à la poursuite de l’unité morte donc on passe donc leur valeur de attacking de vrai à faux ce qui permet de conserver leur parcours jusqu’au lieu où l’unité est morte.
Lorsque le Bunker principal est sélectionné et que l’on clique sur l’icône représentant le soldat, un soldat est créé autour de la base.
Pour ce faire, on prend le tile du centre du bâtiment et on fait une recherche autour de ce tile en forme de cercle concentrique et dès qu’il en trouve un de libre, il regarde s’il peut, pour un soldat, le mettre au centre du tile pour éviter que la création des unités ne se fasse de façon artificielle. Un problème survint encore, sans gestion des surfaces closes, comme ce fut le cas au début, les bâtiments créant des unités tandis qu’ils étaient sur des high-grounds ou dans une forêt au bout d’un moment on, dans leur recherche, trouver le premier tile libre qui malheureusement était en surface ouverte.
Si l’on veut créer un batiment, il faut sélectionner au moins une unité. Pour l’instant il y a un système de créateur de bâtiments que l’on a mis au point avec Guillaume, ce système sera abandonné par la suite pour donner place aux camions de construction, un seul camion permet de créer un bâtiment mais on peut en mettre plusieurs camions ensemble pour favoriser la rapidité de la construction. Les unités vont jusqu’au lieu de création du bâtiment, à ce moment, il le crée (une phase de construction devrait être prête pour la soutenance finale, c’est juste une image). La création est prévue pour être faite en pleine période de guerre donc elles peuvent quitter le chantier de construction ou si les ressources sont insuffisantes alors la construction s’arrête et pourra être reprise quand bon vous le semble. Pour diminuer le temps de construction, on peut faire aller une unité sur la construction pour aider le constructeur. Pour la réparation des bâtiments il faut juste renvoyer une unité sur le bâtiment endommagé.
Au démarrage du projet, j’ai fait une interface pas très compliquée à utiliser. Ce menu permet de choisir la carte de jeu sur laquelle on veut développer une partie de jeu que l’on sauve dans ‘carte.ini’. On peut configurer le matériel graphique pour que l’utilisateur choisisse s’il veut avoir de l’alphablending en Hardware ou en Software. Il est possible que l’on fasse une vérification par la suite de la carte graphique pour déterminer automatiquement si on travaille sur une carte supportant l’alphablend. De même on peut choisir d’avoir du son ou non des fois que l’on ne l’aime pas, on ne sait jamais. On enregistre les données dans un fichier nommé ‘42conf.ini’.