Rapport deuxième soutennace SUP C1 Douté Damien Dumais Christophe Chane-Ching Sébastien Malatrasi Jean-Baptiste 1
Table des matières 1 Introduction 4 2 Objectif 4 3 Répartition des tâches : 5 4 Réalisation 5 4.1 Création du menu.............. 5 4.2 Gestion des touches............. 7 4.3 Système de jeu et de combat....... 8 4.4 Gestion de la carte............. 12 4.5 Affichage graphique............ 16 5 Conclusion 20 2
1 Introduction Après la première soutenance, nous avons estimé que notre investissement dans le projet n était pas assez important. Nous avons alors monté la barre très haut en fixant des objectifs conséquents en espérant que cela nous ferait travailler d avantage. De plus, des séances de travail en commun ont été imposées ( le jeudi après-midi ). Cependant les horaires et la disposition du groupe sont un facteur limitant que nous avons du mal à éliminer et qui nous empêche d être performant. 2 Objectif Pour la deuxième soutenance nous avions comme objectifs de réaliser une démonstration jouable du projet avec néanmoins une version simplifié des combats. Cela implique que le système de combats est géré ainsi que l affichage graphique, la gestion des entrées de données (clavier, manette) et quelques paramètres de la carte. De plus, l éditeur de carte doit être utilisable et le site Web en bonne voie.
3 Répartition des tâches : Damien : - Système de jeu et combats JB : - site Web - Input Chris : - Gestion Carte et éditeur de carte Seb : - Affichage graphique 4 Réalisation 4.1 Création du menu. Nous avons décidé de faire le menu en delphi pour cette deuxième soutenance puisque nous utilisons divers objets de delphi tel que le menu déroulant que nous ne maîtrisons pas très bien avec direct draw... On a utilisé des bases de donnés comme on l a appris en TP afin de pourvoir géré plus facilement le choix des équipes pour chaque joueurs, et aussi des vecteurs pour la gestion des touches. Le menu marche avec du son qui est géré par DirectX ; il possède trois grandes parties : - Multiplayer - Practice - Options
Dans la partie Multiplayer on choisit le nombre de joueurs, ensuite chaque joueur entre son nom et choisi son équipe, les équipes varient en fonction du prix maximum choisit par le joueur. Le prix maximum correspond à la valeur de chaque équipe, plus il est haut, plus les Equipes sélectionnées posséderons de meilleures compétences. Le joueur aura la possibilité de sélectionner la carte sur laquelle il veut jouer et aussi créer de nouvelles équipes où il définira la composition des équipes : - Choix du pilote - Choix du robot en fonction du pilote - Choix de l équipement du robot. Dans la partie Practice sera géré un mode solo contre l ordinateur. Le joueur pourra comme dans la partie Multiplayer choisir une équipe, la carte sur laquelle il affrontera l ordinateur qui sera géré avec une intelligence artificielle que le joueur ne pourra pas définir, mais par contre il aura la possibilité de choisir l équipe de son adversaire!!! Dans la partie Options il y a la gestion des touches (chaque joueur à la possibilité de modifier ses touches pour un meilleur confort!). Cette gestion est faite pour le clavier et pour la manette (dans le cas de la manette le joueur ne pourra pas modifier les touches directionnels). Il y aura aussi la gestion du son avec la possibilité de modifier le volume de la musique et des effets sonores, et quelques paramètres de jeux. Mais seulement deux parties sont gérées à ce jour : Multiplayer et Options puisque la partie Practice n a aucune utilité tant que
l intelligence artificiel n est pas gérée. 4.2 Gestion des touches. En ce qui concerne les touches le joueur peut choisir entre une manette ou le clavier, il peut aussi changer la configuration des touches comme dit ci-dessus. Lorsque le joueur choisit deux fois la même touche pour deux boutons différents une couleur rouge apparaît pour le prévenir, lorsque la couleur est verte c est que tout est bon! Cette gestion des touches a été créé grâce a direct input et une librairie qui s appelle diutil sauf pour la manette qui est gérée avec Windows car ceci nous convient très bien. Le joueur à la possibilité de sauvegarder sa configuration des touches ainsi que de la charger, grâce à des bases de données et des vecteurs qui créent des fichiers textes. Donc chaque joueur pourra avoir sa propre configuration, mais attention si un joueur modifie les touches par exemple du joueur 1 et que celui-ci sauvegarde alors l ancienne configuration enregistrée sera effacée par la nouvelle. Création du site Web. La réalisation du site Internet a été réalisée grâce à Macromédia Dreamweaver (presque l original) en HTML puis complété par des scripts PHP pour la construction des news... En entrant sur le site on peut accéder aux news en entrant le mot de passe administrateur, ainsi chaque membre du groupe peut envoyer ce qu il veut mettre en ligne sur le site sans rentrer dans le code d où un gain de temps. Ce site possède plusieurs parties comme Accueil, Liens, Contacts dont deux grandes Project et Univers.
Dans la partie univers il y a comme sous partie : - Présentation où l on explique ce qu est le jeu et le projet. - Avancement où sera présent un historique du projet. - Documents, tout ce qui est fichiers textes comme par exemple cahier des charges... - Download tout les téléchargement tel que le jeu... Dans la rubrique Univers il y a : - Série : description des dessins animés où apparaissent les robots. - Pilotes description de tous les pilotes apparaissant dans le jeu. - Robots description de tous les robots du jeu. 4.3 Système de jeu et de combat L objectif pour la deuxième soutenance est de rendre le système de combat opérationnel. Avant de commencer à programmer le système de jeu, un bref récapitulatif de son fonctionnement est nécessaire : Tout d abord, c est un jeu de stratégie au tour par tour. Chaque joueur dirige une équipe de robots et chaque robot a un ou plusieurs pilotes, des caractéristiques de combat, une liste d armes et une liste d équipement supplémentaire qu il peut porter. Les pilotes ont des caractéristiques de combat, une liste de sort et une liste de robots qu ils peuvent piloter. Les armes possèdent leurs propres caractéristiques et on en déduit si l arme
est opérationnelle en fonction de toutes des caractéristiques du pilote et du robot.
Ainsi pour réaliser tout cela j ai d abord créé des enregistrements : TPilot, TRobot, TWeapon. Ces enregistrements ont pour champs toutes les caractéristiques nécessaires pour le combat. Pour relier le TWeapon et le TRobot, j ai ajouté un champ vecteur de TWeapon dans TRobot. Cette liste est bien évidement géré dynamiquement car chaque robot n a pas le même nombre d armes. Ensuite pour lier les enregistrements TRobot et TPilot un autre enregistrement s est révélé nécessaire : TUnit. Il a pour champs : un robot, une liste dynamique des pilotes du robot. Puis l enregistrement TTeam fut créé, avec comme champs important : une liste dynamique de TUnit. TTeam correspond à l équipe de robot d un joueur. Cependant un problème est apparu concernant les enregistrement TTeam et TUnit. Il est important de leur attribuer les procédures qui leur permettent de choisir quelle unité est sélectionnée dans la liste, quel est le pilote sélectionné pour lancer un sort, etc. Seulement les enregistrements ne permettent pas cela. Il a donc fallut transformer TTeam et TUnit en classe pour créer toutes ces procédures. Aussi, un autre problème a fait surface lors de la gestion des sorts. En effet, chaque magie correspond à une procédure différente, mais je ne voyait pas comment gérer les différentes procédure et les intégrer au TPilot, car tous les implémenter dans TPilot, qui serait devenu une classe, ne parait pas être la solution. Pour résoudre cette inconvénient, un APD m a montré comment déclarer un type procédural qui sera ensuite implémenté à TPilot sous la forme d une liste de TSpell, où TSpell est un enregistrement le type procédural. Après il a fallu gérer toute la création des instances de classe
et d enregistrement pour le système. Pour avoir une gestion flexible de tous ces enregistrement, c est à dire pouvoir supprimer ou ajouter une équipe, un robot... j ai créé la procédure LoadTeam qui comme la procédure assignfile (qui associe un type file a un fichier réel sur le disque) associe a une TTeam une instance de classe à partir d un fichier texte. Cette procédure fait appel à d autres qui attribuent des valeurs voulues pour chaque champ d instance de classe. Par exemple : elle fait appel à une procédure LoadRobot qui charge un robot. Aucun problème n est apparu de ce coté-là puisque j ai repris le TP sur les bases de donnée. Enfin il restait à faire les procédure qui manipulent tous ces objets suivant les règles de combat du jeu. Tout d abord, il y a la fonction Aiming qui calcule le pourcentage de réussite,qu a le robot attaquant, de toucher sa cible. Cette fonction prend bien évidemment en compte toutes les caractéristiques de l attaquant et de la cible pour le calcul nécessaire. La procédure Battleresult qui verifie d abord si, effectivement, il a touché la cible, calcule la quantité de dégât infligé à la cible, si elle est touchée, en fonction de tous les flags pris en compte. Par exemple : si un sort a été lancé ou pas, sans oublier la gestion de la contre-attaque de la cible si elle désir le faire. Pour finir, une procédure Newturn fut créé pour rendre tous les robots sélectionnables, et aussi la procédure Updateaction qui met à jour la liste des action possible du robot pendant le tour : se déplacer, attaquer...
Conclusion : L objectif pour cette partie a été atteint, les combats sont opérationnels. De plus, on pourra éditer ses propres équipes de robots et pilotes en utilisant les bases de donnée pour créer les applications permettant de faire facilement les robots et les pilots. Une dizaine de magie fonctionne et une quinzaine d équipement pour robot sont gérés. Il reste maintenant à intégrer tous cela à l application graphique. Certaines fonctions seront améliorées pour prendre en compte les paramètres de la carte ; et d autres seront créés pour appliquer les objets à la carte pour ainsi avoir au final, un jeu jouable, et ensuite commencer à mettre en place une intelligence artificielle. 4.4 Gestion de la carte Objectifs deuxième soutenance : Les Objectifs de la deuxième soutenance étaient à la base d avoir une pseudo démo jouable. Pour cela, je devais gérer la carte parfaitement, c est à dire me débrouiller pour avoir un type case (Tile) contenant toutes les informations relatives à cette case (son type de terrain, sa représentation à l écran, son cout de déplacement,... ). Il me fallait aussi gérer la possibilité de changer de carte facilement et donc d avoir plusieurs cartes différentes, c est à dire notamment ayant des tailles différentes ce qui était impossible avec le code actuel. En effet, ma carte s affichait pour la première soutenance grâce à une matrice (un tableau) directement implémentée dans le code ce qui rendait le code très lourd et ne permettait aucun changement de carte. La
matrice était composée d entiers qui représentaient le numéro du bitmap à afficher tout ceci grâce à un case of qui devint vite ingérable. A tout ceci s ajoutait la création d un éditeur de carte que je du reprendre a zéro lors du changement du code de la première soutenance.
Travail réalisé : Pour remédier à tout ces problèmes, j ai commencé par définir un type Tile (record) contenant tout les champs nécessaires à son identification comme le bitmap qui lui est associé, son cout, son nom, sur quel layer il se trouve et d autres caractéristiques. C est en entrant tout ces champs que je me suis rendu compte du nombre considérables de case qui avaient les mêmes propriétés à ceci près que leurs représentations (bitmaps) et leurs nom étaient différents. J ai donc crée un type de terrain générique inclus dans le type Tile. Ces deux types ont allégés mon code mais m ont posés un problème lorsque j ai essayé de gérer ma carte en externe dans un fichier texte. En effet, ne pouvant inclure toutes les caractéristiques de chaque Tile dans ce fichier ceci m a conduis à n écrire que l index de l image à charger et à initialiser tout le reste dans une procédure au démarrage. Il m a fallut aussi créer les procédures de lecture, de chargement des Tiles dans un buffer et d affichage, le tout en delphi. Une fois tout ceci fait, il ne restait plus qu à mettre notre code en commun... Pour ma part, j ai aussi fait plusieurs cartes de test en format texte ainsi que l interface de l éditeur de carte mais devant certaines grosses difficultés, je me suis aussi attelé à l interface de l éditeur de pilotes prévu pour la soutenance d après. Problèmes rencontrés : - Lors de la création de la procédure d initialisation des paramètres des tiles, la longueur de l initialisation de chaque caractéristique m a posé un petit problème de temps qui m a décalé
dans l avancement de ma partie (l avance prise c est transformée en léger retard). - L éditeur de carte : J ai rencontré un GROS problème d affichage d images dans un list box (Qui ne peut contenir que des strings) qui m empêche d aller plus loin car le transfert des images dans un paint box en dépend ainsi que tout le reste. - L éditeur de pilotes : La difficulté de cet éditeur reste la gestion d une base de données qui est encore à définir. Problèmes persistants : - Le problème de l éditeur de pilotes : la gestion et la définition de la base de données. - L éditeur de carte : L affichage d images (mes Tiles) dans un list box qui ne contient que des strings reste LE GROS problème à résoudre. En effet, pour le moment personne n a encore réussi à me répondre et même les ACDs ne savent pas comment y remédier. Conclusion : Devant les difficultés de l éditeur de carte, je me tourne vers les éditeurs de pilotes et de robots (???) tout en essayant d y remédier. Le problème de la base de données ne devrait pas me prendre trop de temps et sera résolus au plus tôt ( Il faut que je récupère le système utilisé par le Battle System ). L état actuel d avancement de ma partie me permet d envisager la fin des éditeurs pour la troisième soutenance.
4.5 Affichage graphique A faire pour la deuxième soutenance : Afficher la carte en direct draw (moteur 2D) Ce que j ai fait : J ai fait les procédures qui permettent l initialisation de direct draw avec la création de différents buffers : le principal qui est affiché à l écran,le buffer associé Fback, celui de l arrière plan, et différents buffer qui vont contenir les images du jeu.pour afficher les différents bitmaps à l écran, il faut faire une procédure qui charge un bmp dans un buffer, lui associe une clé de transparence (au cas où), puis une procédure de rafraîchissement de l écran qui affiche le buffer associé Fback à l écran : c est le flipping. J ai du aussi fabriquer une procédure qui coupe les images dépassants des bords de l écran.sans cette fonction de clipping les images qui chevauchent une bordure de l écran ne sont pas affichée. Elle peut s utiliser aussi à l intérieur de l écran en définissant une zone de clipping, c est à dire : les images affichée à l intérieur de cette zone ne vont pas dépasser les bords du clip. Afin d alléger le chargement de sprites, on a créé une palette de sprites ; ce qui nous économise en terme de nombre d images, et on a une gestion complètement différente des sprites. J ai incorporé l input de la manette fait par Jean-baptiste et l affichage de la map de Christophe dans les procédures d affichage. Avec la map, j ai donc pu commencer à afficher des icônes sur la map, travailler sur le scrolling et sur les interaction entre les éléments
de la map.
Différents problèmes rencontrés : Au début, j ai eu des problèmes de compatibilité pour traduire les fonctions d affichage de la carte et le système de chargement de la map, du delphi en DirectX. De même, il m a fallu du temps pour intégrer la partie input de la manette (différents problèmes de directions).la gestion des coordonnées de la carte sont différentes de celles de l écran, pour acquérir les coordonnée monde du jeu, j ai du créer un nouveau record. La gestion de palettes m a obligé a revoir tout le code et à redéfinir les paramètre des procédures principales d affichage. J ai aussi un gros problème de lag en utilisant massivement le clipping pour l affichage de la map dans un cadre et pour les interaction avec les personnage sur la map (sélection et déplacement d un personnage a l écran) Problèmes persistants : Mon problème de lag, j ai une solution temporaire : j affiche d abord la map puis la barre de menu par dessus. La sélection et le déplacement d un personnage a l écran : la sélection du personnage ne reste pas active donc il n y a pas de déplacement possible (problème d input?- manette?). Problèmes Résolus : La gestion de palettes optimise le chargement de bitmaps,
grâce à plusieurs procédures, des types et des enregistrements : pour toutes les images la création d un enregistrement donne la position de chaque sprite dans le set, sur l écran et sur la map. On a eu un affichage de map inverse ou de map qui s affiche aux trois premiers quart puis encore le premier quart, quelques problèmes de clipping : marge trop grande sur certains bords, ce qui étais du à des inversions multiples de paramètres. Pour la sélection et le déplacement d un personnage à l écran, lors de la sélection le personnage choisi par le joueur est déterminé mais il ne reste pas actif. Ce qui est prévu pour la troisième soutenance : Gérer le problème de lag de la map Gérer différents effets graphiques : - la translucidité - Les animations de combat - L affichage du texte à l écran
5 Conclusion De manière globale, les objectifs de chacun ont été atteints : la carte s affiche, les entrées de données sont gérées et les combats fonctionnent. Mais il nous reste toujours le problème de la mise en commun du travail de chacun. En effet, il nous aurait fallu un peu plus de temps pour mettre tout le code dans le même projet car il y a eu quelques problèmes de compatibilité de code ainsi que d emploi du temps ( Deux des membres du groupe étaient partis en vacance ). Malgrés cela, le projet avance bien et nous ne subissons pas de gros retard, la motivation semble revenue et nous reprennons un rhytme de travail adéquat, ce qui nous permet d envisager pour la troisième soutenance, une démonstration jouable avec de vrais combats, une interface finie ainsi qu un menu avec la majorité des options disponibles.