Etant arriver à l’EPITA avec un bagage en programmation nul, mon premier travail fut celui d’apprendre le langage Pascal à l’aide du manuel Programmer en Turbo Pascal 7 de Claude Delannoy (édition Eyrolles). L’apprentissage des bases de l’algorithmique a du se faire rapidement afin de comprendre le début de code du projet. Une fois ceci fait cela m’a permis de pouvoir réaliser des petits exercices du type de ceux en TP d’informatique et de TD d’algorithmique.

De la même manière en me mettant dans le livre Delphi 3 de Dick Lantim (édition Eyrolles), j’ai pu réaliser des petits programmes en programmation orientée objet comme un programme d’installation de fichier. Pour avoir une utilisation efficace de ce langage, il faut régulièrement regarder l’aide logicielle. Pour une aide plus complète, il est tout de même utile d’utiliser l’aide on-line, comme le site : http://inner-smile.com/qui regroupe une grande collection de site sur des points de programmation en Delphi.

Le planning me demandant de faire les déplacements des unités au mois de février, j’ai commence par faire le déplacement simple des unités(rotation et déplacement). Là on commençait mes premières joies en programmation : voir ses unités se déplacer sur la carte, ça donne l’envie d’aller plus loin dans le code. N’étant pas encore assez bon pour me lancer dans des gros algorithmes de recherche de chemin le plus court, j’ai commencé pour voir ce que donner mon algorithme, j’ai décidé de faire un algorithme en Turbo Pascal nommé Simple Trace d’après un programme de Brian Stout : http://www.gamasutra.com/features/programming/19990212/sm_01.htm

Cet algorithme était parfait au niveau de sa complexité nulle car lorsque l’unité était bloquée par un espace où elle ne devait pas marcher, elle tournait pour faire le contour de l’obstacle mais dans les coins elle se bloquait. L’unité était encore loin de prendre le chemin le plus court. Une fois que j’eus compris comment fonctionner les pointeurs, j’ai pu implémenter un algorithme similaire à A*, se nommant Best First avec un système d’arbre. L’unité regarde autour d’elle et développe son arbre en prenant le point le plus proche de l’arrivée à chaque fois. C’était franchement un grand pas de franchi dans mon apprentissage de programmation. Mais lorsque l’on demandait à une unité d’aller sur un lieu qu’elle ne pourrait pas rejoindre comme une surface close(surface où les unités sont enfermées dedans et étant inaccessible de l’extérieur) ou une surface non walkable(lieu où il y a un bâtiment ou des arbres, rochers) alors l’unité parcours toute la carte pour sa recherche et ne trouve pas en plus le lieu d’arrivée. Pour remédier à ce problème j’ai procédé à une gestion complète des surfaces closes en non walkable c’est la partie qui m’a pris le plus de temps dans mon emploi du temps. La structure de notre jeu étant le tile de dimension 32*32 pixels, les tanks dépassaient amplement cette dimension, graphiquement ils coupaient les décors, une version spéciale a donc été réalisée pour ne pas négliger le côté graphisme du jeu. Une fois que le déplacement des unités a été fait, le projet a pris une tournure qui devenait intéressante.

On crée une liste de tiles ouverts (tiles explorés mais non développés).

On les trie par ordre croissant par rapport à la distance entre le nœud développé et l’arrivée.

Pour tous les tiles voisins du nœud développer,

On supprime le nœud qui vient d’être développé de la liste des tiles ouverts.

On réitère ces opérations jusqu’à ce que l’on trouve l’arrivée.

On renvoie à l’unité une liste chaînée de tiles qu’elle va franchir.

Si l’on a demandé à l’unité d’aller sur une surface non walkable ou close on garde la distance minimale que l’on a eu de tout point de la recherche et l’arrivée. Dès que la distance entre le premier tile de la liste des tiles ouverts et l’arrivée dépasse n fois la distance minimale, dans ce cas on arrête la recherche et juge que le point d’arrivée est le point où l’on a eu la distance minimale dans notre recherche.

J’ai eu un problème que je n’ai résolu que depuis peu de temps, il n’était pas très grave jusqu’à ce que l’Intelligence Artificielle spontanée soit mise en place. Les tanks qui tentaient d’aller dans les tiles de d’ordonnée y=0, cela arrêtait tout le jeu pendant une seconde. En fait par leur taille importante, il faut faire plusieurs tests pour éviter que graphiquement ils ne passent au travers des décors, et en fait mes tests empêcher l’accès aux tiles d’ordonnée 0, il suffisait simplement de mettre la bordure de la carte à surface close pour chercher le chemin pour un tank.

Lorsque le Main 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 Main Bunker et on fait une recherche autour de ce tile en forme de cercle concentrique et dès qu’il en trouve un tile de libre donc le plus proche de la base, 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. Il en est de même pour créer des tanks, camions de construction et camion de pétrole. Pour créer un hélicoptère, il faut posséder le bâtiment SOL, à la sortie de ce bâtiment, les hélicoptères regarde juste s’il n’y a pas de collisions entre eux sinon ils se décalent.

Au démarrage du projet, j’ai fait une interface simple à 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 le fichier ‘carte.ini’. On peut configurer le matériel graphique, l’utilisateur choisit s’il veut que l’alphablending soit rendu en matériel ou en Logiciel ou même encore qu’il n'y en ait pas du tout(dans ce cas il n’y a pas d’ombres et les frames d’explosions sont simplement blités sur la carte). 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’.

Si l’on veut créer un bâtiment, il faut sélectionner au moins un camion 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. 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 un camion de construction sur le bâtiment endommagé. Chaque camion de construction consomme du pétrole et de l’électricité lors de la construction donc si l’on a peu de ressource, il vaut mieux n’envoyer qu’un seul camion pour être sûr de finir cette construction.

Auparavant dès qu’un camion partait pour construire, il mettait le lieu de construction en non walkable dès qu’il partait, donc s’il mourait lors de son déplacement vers la construction, la surface restait en non walkable, de plus les unités constructrices prenaient la liste de tous les camions qui partaient pour créer, et dès que le premier camion commençaient la construction, il donnait à tous les autres camions le pointeur sur lequel ils doivent travailler. Mais ca fait un tas de parcours de liste et de changement à effectuer pour que l’unité soit susceptible de mourir ensuite.

Le système est maintenant plus élaboré : Tous les camions partent individuellement sur le lieu de construction, dès qu’ils sont à proximité de la zone de construction, s’ils peuvent construire, ils lancent la construction sinon ils regardent s’il y a un bâtiment et si c’est le même type de bâtiment que celui qu’il a à construire alors il aide à la construction du bâtiment.

Lorsqu’ils partent, ils ont une variable construct qui passe à true, ils se mettent dans la liste des followers du bâtiment. Construct permet d’éviter les plantages lorsque le bâtiment est détruit comme cela on peut dire aux unités de continuer leur chemin mais que une fois arrivées elles ne fassent rien, car construct détermine à la fin de son déplacement si elle doit effectuer une tâche particulière. De même si le camion meurt, il se retire de la liste des followers du bâtiment car sinon on travaille sur des pointeurs qui sont maintenant inexistants.

Pour pouvoir avoir les extracteurs de pétroles j’ai dû changer le chargement de la carte quand il crée l’extracteur, il est attribué à l’unité à laquelle il a été attribué dans l’éditeur mais en le mettant à neutre il à fallu changer certaines structures pour pouvoir avoir des bâtiments neutres.

Lorsque l’on charge une carte, les extracteurs de pétrole sont par défaut des bâtiments neutres. Dès qu’une unité terrestre ne passe pas trop loin de l’extracteur elle l’acquiert. Mais après, on peut développer des stratégies différentes car l’extracteur peut changer de camp si aucune unité ne défend l’extracteur, et qu’une unité ennemie arrive, elle l’acquière à son tour. Les unités volantes ne peuvent pas détourner d’extracteur car comme c’est l’unité la plus rapide, il serait trop facile de conquérir tous les bunkers en envoyant tous ses hélicoptères sur les extracteurs. Les soldats et les tanks peuvent se battrent pour détourner un extracteur et les camions extracteurs peuvent eux prendre le contrôle d’un extracteur qui était auparavant neutre.

Une fois que l’intégralité des bâtiments était définie, il manquait la connexion entre l’extracteur de pétrole et le niveau de pétrole des joueurs donc avec Guillaume on a désigné le Main Bunker comme réceptionniste du pétrole. Cédric a juste eu à remplacer la benne de sable du camion constructeur et mettre une citerne pour faire la distinction entre les camions. Une fois que l’on envoie un camion de pétrole sur un extracteur on met le pointeur de l’extracteur dans batcreate pour qu’il y aille jusqu'à celui-ci et lorsqu’il arrive à proximité de l’extracteur il s’arrête et au lieu de passer à l’état 1, comme on lui a mis sa variable construct à true, il est envoyé à l’état 8 il prend le pétrole que l’extracteur lui donne, recherche le Main Bunker le plus proche pour vider sa citerne. De nouveau une fois arriver au Main Bunker il prend l’extracteur le plus proche mais on a constaté avec Guillaume que c’était un début d’Intelligence Artificielle et surtout la fin de la gestion de sa base. Ce qui fait que les camions prennent dans leur variable batcreate le pointeur de l’extracteur comme ça ils retournent bien à l’extracteur où on leur a demandé d’aller.

Mais les extracteurs n’ont pas de ressources infinies, c’est comme dans la réalité : si on use toutes les ressources naturelles no en a plus et de plus les extracteurs ont un certain débit. Donc j’ai ajouté dans un tableau nommé ravxy des armées les caractéristiques pour les ravitaillements dont je parlerai plus tard, et aussi celle de l’extracteur. Donc au départ les extracteurs contiennent l’équivalent de 5000 barils de pétrole et au cours du jeu les unités diminuent la réserve de l’extracteur jusqu’à épuisement. Comme pour tout élément du jeu, les extracteurs contiennent un délai que l’on incrémente modulo 500 et à chaque fois que le délai et égal à zéro on incrémente les barils de pétrole qui sont prêt à partir. Les camions attendent que le pétrole extrait soit égal au maxpetrole contenu dans ravxy ou sinon il attend qu’il est épuisé toutes ses réserves dans ce cas là il prend le maxpetrole mais on fait bien attention que le camion ne puissent pas transporter plus du maxpetrole pour éviter que l’on construise un seul camion et que l’on clique plusieurs fois sur l’extracteur comme ça cela éviterait de construire plusieurs camion.

Si l’on clique sur le Main Bunker avec un camion sélectionné on laisse extract à nil comme cela le camion reste à la base une fois qu’il a déposé tout le pétrole qu’il avait dans sa citerne.

On peut augmenter le maxpetrole pour chaque joueur mais Guillaume vous en parlera.

J’ai fait de telle sorte que lorsque l’on construit un réservoir de pétrole, notre quota maximum de pétrole n’augment qu’une fois la construction terminée, et quand on en détruit un, notre quota maximum diminue et notre niveau de pétrole diminue uniquement si celui ci a dépassé le nouveau quota maximum actuel.

Dans 42 minutes pour vivre, on a bien évidemment besoin d’avoir de la nourriture pour les unités. Elle est obligatoire pour la création d’unités et de bâtiments. Au début on avait pensé donner des points de dommage aux unités quand la réserve de nourriture était nulle mais dans un souci de jouabilité il n’était pas très bon de faire cela car si l’on ne le remarque pas tout de suite, c’est la mort lente des unités(même trop rapide). J’ai implémenté un système pour que l’on ait un camion de ravitaillement qui arrive du bord de la carte qui va au Main Bunker dépose une réserve de nourriture en échange de pétrole : la gratuité n’existe pas même en temps de guerre.

Dans l’éditeur, on choisit le point de départ de ses convois. Lorsque l’on appuie sur l’icône de nourriture d’un de ses Mains Bunkers, dans le tableau ravxy précédemment cité, on met le booléen ravengaged à true pour éviter que l’on appelle en permanence des ravitaillements(on pourrait lorsque l’on possède beaucoup de pétrole appelé plusieurs ravitaillement pour ne pas s’en occupé pendant un certain moment), une nouvelle unité est créée au point de ravitaillement. Le camion de ravitaillement cherche son chemin, sa variable construct est elle aussi à true comme les unités de construction et de pétrole, pour lui permettre de passer à l’état 9, si le Main Bunker existe toujours, il donne dix fois le nombre de rations mangés par les unités au dernier prélèvement des ressources, pour ce faire dans la procédure ressourceupdate on fait une sauvegarde du dernier prélèvement de nourriture, un message apparaît pour prévenir le joueur, qu’il fasse sortir son camion en le menant sur un bord de la carte. Quand le transfert a été effectué dans le tableau ravxy, on met une variable ok a true pour éviter que les petits malins fassent un petit stock de nourriture. Si le Main Bunker a été détruit avant que le camion est pu faire son dépôt il cherche le Main Bunker le plus proche. Quand il arrive sur le bord de la carte, pour éviter de le faire disparaître comme un tour de magie on le fait bougeait plusieurs fois pour donner une impression qu’il quitte la carte comme s’il continuer sa route.

Si une unité est à l’état 1, donc si elle ne fait rien elle regarde dans la liste des unités qui sont en train de lui tirer dessus, elle prend l’unité la plus proche et si celle si ne vient pas de mourir juste avant alors elle prend tous les paramètres lui étant nécessaires

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 part dans la direction opposée. 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.

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.

J’avais commencé à implémenté un système de masques mais Guillaume trouvait que c’était un système trop simple et surtout qui n’offrait pas assez de possibilités aux joueurs, il a donc pris la direction d’un système de masques(C’est lui le leader après tout :) ).Il a dû modifié certaine de ces fonctions pour appliquer les masques pour gérer les comportement des unités.

Comme les bâtiments sont des bâtiments miroirs pour les deux nations(ils sont identiques), je me suis mis à la recherche de drapeaux pour que l’on différencie les bâtiments des différentes armées. Au bout d’un petit temps de recherche sur le net, j’ai trouvé un site sur lequel il y avait les drapeaux animés de toutes les nations. J’ai donc téléchargé les drapeaux français et états-uniens. A l’aide de Adobe ImageReady j’ai pu extraire les fichiers gif et les disposer dans un fichier bitmap à l’aide de Adobe PhotoShop pour les faire animer dans le jeu. J’ai donc créé une nouvelle surface pour les drapeaux mais je ne savais pas où les positionner, donc j’ai du rechercher l’endroit au pixel près le plus favorable pour les faire afficher. Après j’ai donc mis dans les types des bâtiments les coordonnées que j’avais trouvées. Et j’ai mis dans un tableau les nations de chaque joueurs pour déterminer le drapeau à afficher. On avait une impression bizarre de voir tous les drapeaux flotter au vent en permanence on ne voyait que ça à l’écran, donc l’affichage des drapeaux a été réduit à la seule possibilité qu’il y ait un bâtiment sous le curseur de la souris. On prend l’armée de ce bâtiment on regarde dans le tableau et on met le drapeau correspondant à son armée. Si ce bâtiment est un extracteur encore neutre, on n’affiche pas de drapeau.

Au départ j’avais pensé à faire une fonction qui retirent de l’énergie qui retire de l’énergie aux unités qui détruisent un camion de pétrole ainsi que les réserve de pétrole et l’extracteur dû à l’explosion de leur contenu. On donne le centre de l’explosion, et le périmètre de déflagration. Elle touchait uniquement les unités terrestres et les bâtiments. Les points de dommage étaient donnés par le périmètre maximale auquel on retire la distance entre le centre et l’unité. Un problème se posaient : les unités de grandes tailles recouvrent plusieurs tiles il prenaient donc plusieurs fois les points de dommage. Le résultats étaient la mort quasiment systématique des unités. J’ai donc procédé à la création d’une liste dans laquelle les unités déjà touchées s’y inscrivaient et on regarde si l’unité que l’ont va endommagé n’a pas encore subit les effets de l’explosion. Elle s’applique de la même façon aux bâtiments. On donne en même temps à la fonction un booléen pour savoir si la fonction est appelée pour l’explosion nucléaire si c’est le cas, on prend en compte que les unités volantes prennent aussi des points de dégât. Du fait de donner à la fonction le périmètre de déflagration cela permet de moduler le champs d’action de l’explosion et par la même occasion le dommage à affecter aux unités. On donne par le dommage engrangé par une explosion encore un peu plus de réalisme au jeu.

Au départ je pensait dirigé l’IA à partir de notre procédure DoUnitAction mais Guillaume m’a dissuadé de faire cela dans un souci de clarté et de complexité : si l’on dirige les unités qui sont à l’état 1, on perd de la puissance dans notre implémentation. Donc j’ai fait une procédure dans laquelle on appelle toutes les procédures et fonctions de l’IA générale.

L’IA est événementielle : c’est-à-dire que lorsqu’il arrive certains événements, l’ordinateur réagit pour contrer ce qu’il est prévu de se passer.

Pour faire moins ralentir le projet, je fais faire à l’ordinateur une procédure à la fois de plus cela limite sa rapidité par rapport à l’humain. Toutes les dix boucles l’ordinateur fait quelque chose pour développer ses unités et ses bâtiment tout autant pour l’attaque que pour la construction de sa base. Dans des soucis d’optimisation lors des passages dans les procédures DoUnitAction et DoBuildingStuff, l’ordinateur prépare ce qu’il a à faire pour l’IA, cela évite de temps en temps de faire des parcours de listes d’unités en plus. Pour garder les informations que l’on a voulu obtenir dans ces deux procédures j’ai créé un tableau ia contenant les informations de toutes les armées. Elle est composée de Pointer sur une unité, sur un Bâtiment, un word pour des résultats de calculs et enfin x, y des coordonnées.

Je me suis occupé de la construction de la base et de son développement. On remplit le tableau ia dans DoUnitAction et DoBuildingStuff et ensuite on traite le résultat dans DoIAGen qui est la procédure traitant les unités de l’ordinateur, et on réinitialise ia à la fin de cette procédure pour préparer la suite des événements que l’on va avoir à traiter.

Pour limiter les calculs et les parcours de listes trop conséquentes, j’ai fait une structure, nb, qui regroupe pour chaque armée le nombre d’unités attaquantes, le nombre de toutes les unités du même type, le nombre de tous les bâtiments du même type ainsi que les listes chaînées des bâtiments et unités par types. Par exemple si l’on veut regarder la quantité de pétrole qu’il reste dans nos extracteurs alors on parcourt la liste nb[team].extractP dans laquelle il peut y avoir que deux ou trois extracteurs contre Buildings[team] où il y peut y avoir des vingtaines de bâtiments.

Le lieu de création est l’endroit le plus proche du Main Bunker. On prend le Centre du Main Bunker comme centre des cercles concentriques (rectangles concentriques serait pus appropriés), pour le côté droit, on décale de la moitié de la largeur du Main Bunker et on ajoute la largeur du bâtiment à construire, on le fait tourner autour de la base de cette façon jusqu’à ce que l’on trouve un emplacement pour construire, si on ne trouve pas de place sur le premier rectangle. Dès le test, ça marchait mais ils créaient les bâtiments trop proche les uns des autres ce qui faisait que l’on arrivait à coincer les unités de l’ordinateur. Donc au lieu de tourner en testant tous les tiles, on teste tous les trois tiles ce qui laisse un passage de deux tile pour faire passer les unités.

Lors du parcours de la liste des unités, on note le nombre de camion de pétrole en train d’extracter pour dans DoIAGen faire une évaluation des réserves de pétrole. On ajoute au quota maximum de pétrole le lastOilDelta qui est la valeur lors du dernier prélèvement de pétrole(peut être négatif) auquel on ajoute le nombre de camion de pétrole en train d’extracter multiplié par le maxpetrole. Si l’on constate que les réserves vont se faire juste on demande de construire une nouvelle réserve.

Lors de DoBuildingStuff, on arrête de vérifier qu’il y ait des bâtiments endommagés dès que l’on en a trouvé un bâtiment dont son énergie n’est pas au maximum, on le met dans le tableau ia et ensuite dans DoUnitAction on cherche un camion constructeur qui ne fait rien pour le moment. Si l’on a trouvé un bâtiment endommagé et un camion de construction libre alors DoIAGen on envoie le camion réparer le bâtiment.

Dans DoUnitAction on cherche une unité qui est à l’état 42(lorsqu’elle est morte), comme les unités ne restent pas très longtemps à cet état avant d’être supprimé totalement de la carte, il est peu fréquent que des unités soient à l’état 42 en même temps que le IADelay désigne la construction de bunker. Le lieu de la construction est le lieu de la mort donc cela permet de donner du changement dans le combat : si l’unité était proche de la base on construit plus la défense, mais si l’unité était proche de la base ça permet une tactique plus offensive. Bien sûr il faut qu’il y ait un camion constructeur à l’état 1 pour permettre une construction.

Dans DoBuildingStuff, on cherche un bunker qui n’ait n’ai pas plein. S’il n’est pas plein, on regarde dans les followers le nombre de soldats qui sont dans la même armée. Si on a bien quatre soldats pour remplir le bunker, on met le pointer du bunker dans le tableau ia sinon il faut en chercher un autre. Quand on arrive dans DoIAGen on regarde si l’on a un bunker qui n’est pas tout à fait plein, on cherche dans ses soldats pour savoir s’il y en a assez à l’état 1 pour les envoyer au bunker.

Uniquement lors de l’appel dans DoBuildingStuff, si l’on a un extracteur, on fait un calcul pour connaître le nombre maximal de camions de pétrole à envoyer sur un extracteur. Il peut y avoir entre 2 et 10 camions de pétrole sur un extracteur. Il regarde s’il y a autant de camions que prévu, si ce n’est pas le cas, il cherche d’autres camions de pétrole pour extracter du pétrole.

Dans DoIAGen on appelle une fonction on regarde s’il est utile de créer des camions de pétrole en regardant s’il manque des camions par le même calcul que précédemment énoncé, s’il y en a assez alors on empêche la création de camions de pétrole, on empêche tout le temps la création de camion de ravitaillement car cela ferait faire des erreurs dans les ravitaillements. On regarde la proportion d’unités attaquantes, s’il n’y en a pas assez on crée directement une unité attaquantes, puis on cherche un Main Bunker ne créant pas d’unité si l’on souhaite construire une unité terrestre sinon on regarde sur le bâtiment SOL s’il ne construit pas d’hélicoptère. Donc si on a trouvé un bâtiment ne créant pas d’unités souhaité, on lance une construction de cette unité.

Dans DoIAGen on regarde si le niveau d’électricité actuel plus trois fois lastElecDelta (dernier prélèvement peut être négatif ou positif). Si la prévision est négative, on cherche un camion de construction libre pour créer un power generator.

Si un camion de ravitaillement est présent sur la carte et qu’il est à l’ état 1 on lui donne les coordonnées les plus proche de sa position actuelle, sinon avec le même calcul que pour l’électricité mais en prenant la nourriture si le résultat est négatif, on appelle un ravitaillement par le Main Bunker le plus proche des coordonnées définies dans l’éditeur de carte.

On considère qu’il faut avoir un équilibre entre les unités et SOL, un bâtiment SOL suffit pour cent unités, ce qui fait que si on a plus de bâtiment SOL un camion de construction libre va trouver une place avec le même système de cercles concentriques par rapport au Main Bunker le mieux placé par rapport aux extracteurs de pétrole.

Comme pour SOL, il faut cent cinquante unités pour avoir besoin de recréer un Main Bunker. Il faut si l’on souhaite créer un nouveau Main Bunker comme pour toute création un camion de construction à l’état 1. Mais pour un Main Bunker on ne définit pas le centre de la construction comme étant le centre d’un Main Bunker mais on prend pour centre, le centre de l’extracteur ayant le plus de ressource.

Pour éviter qu’une armée dirigée par l’ordinateur soit bloquée dans son développement parce qu’elle n’a plus de camions pour extracter le pétrole et que qu’elle n’a plus de pétrole, elle supprime une construction en cours sur un Main Bunker pour créer un camion de pétrole qui ne consomme pas de pétrole lors de sa construction. Mais si elle n’a plus de Main Bunker elle est en mauvaise posture pour continuer une longue partie.

Comme j’avais réussit à faire un bon algorithme de cheminement et que j’avais bien en tête un système pour gérer les collisions, je me suis lancé dedans. 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 déplacement, de l’unité 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.

Lorsque j’ai eu un close compte de la part de Delphi je me suis mis à faire des graphismes. J’ai extrait de Starcraft (du fichier StarDat.mpq) des explosions et des flammes. Les couleurs différaient totalement de celles du jeu, une fois PhotoShop pris en main j’ai positionné les images comme on le fait à l’habitude pour faire animer nos frames. J’ai changé les couleurs une à une et j’ai testé en modifiant le code mon explosion pour les tanks. J’étais entièrement satisfait de moi, je trouvais que mon explosion rendait bien dans le jeu mais l’avis de Guillaume était contraire au mien. Donc j’ai repris le code qui est plus important que les graphismes.

Pour l’expansion et le développement de notre projet, la compression peut s’avérer beaucoup plus sympathique, cela permet de distribuer le projet sur deux disquettes au lieu de le mettre sur une vingtaine de disquettes ou sur CD, on aurait pu faire des archives spéciales pour éviter d’avoir toutes les images un fichier images aurait suffis, on aurait au début du jeu décompressé l’archive mis en mémoire les images et effacé les fichiers temporaires. J’ai réussi à compresser les images à l’aide de la librairie Zip32.dll mais il m’a été impossible de les décompresser, vu la minime importance des archives, j’ai essayé d’autres librairies, ça n’a pas marchait j’ai donc arrêté pour passer à faire du code plus utile pour le projet.

Le projet est un très bon instrument d’apprentissage, pour la mise en pratique de l’algorithmique. Mais à mes regrets il est trop court dans le temps car avec un cahier des charges ambitieux comme nous l’avions fait, nous aurions presque du être quatre ou sinon trois mais tous avec un acharnement au travail..