Tower Defense, projet de fin dâannĂ©e SUPINFO
Jâai Ă©tĂ© plutĂŽt discret ces derniers temps, pris pas mal dâoccupations, dont la finalisation de nos projets de fin dâannĂ©e Ă SUPINFO.
Nous venons juste (mes 3 collÚgues et moi) de passer notre soutenance orale, ce qui met enfin un terme à plusieurs mois de développement.
Notre prĂ©sentation sâest trĂšs bien passĂ©e, et dans lâeuphorie de la victoire, je vais vous prĂ©senter un peu plus en dĂ©tail le projet sur lequel jâai le plus travaillĂ© : un jeu de Tower Defense dĂ©veloppĂ© entiĂšrement en C#, avec lâaide de la bibliothĂšque graphique SFML (plus prĂ©cisĂ©ment, son binding .net).
Le sujet Ă©tait imposĂ© mais nous avions le champ libre pour le langage de dĂ©veloppement, et nous nous sommes demandĂ© ce que pouvait donner un petit jeu en C# đ
Le jeu original, RAMPART, dont nous nous sommes inspiré, date des années 1990 et a été développé en assembleur. Il est téléchargeable ici, et est jouable en utilisant DosBox.
Passons au notre maintenantâŠ
1. Gameplay
Une petite explication pour commencer : la carte se prĂ©sente sous la forme dâune ile, avec plusieurs chĂąteaux. Le but du jeu est de se construire une sorte de forteresse autour des chĂąteaux, ce qui permettra de placer des dĂ©fenses contre les vagues de bateaux ennemis qui vont arriver.
Tous les chĂąteaux doivent ĂȘtres capturĂ©s par le joueur pour que la partie soit gagnĂ©e.
Le jeu se divise en 3 phases de gameplay :
- CrĂ©ation Ă lâaide de murs de forme alĂ©atoire, dâune zone fermĂ©e, contenant un ou plusieurs chĂąteaux.
- Placement de canons/tours Ă lâintĂ©rieur des zones sĂ©curisĂ©es.
- Combat contre les vagues de bateaux ennemis. Il faut en couler en maximum le plus vite possible pour ménager les murs.
Le gameplay de base est trĂšs rapide, dĂ©coupĂ© en phases dâenviron 15 secondes, ce qui conserve un rythme soutenu.
Il existe Ă©galement un mode multi-joueur, que nous nâavons finalement pas eu le temps de commencer.
Nous avons par contre intĂ©grĂ© un prototype de mode de jeu âstratĂ©giqueâ, plus orientĂ© gestion de ressources que le jeu de base.
Le joueur doit alors rĂ©partir des ressources de base limitĂ©es pour construire des murs, des tours, des munitionsâŠ
Un screenshot du jeu en cours de partie :
2. Conception
Comme nous nâavions pas une grande expĂ©rience du dĂ©veloppement de jeux, qui est trĂšs diffĂ©rent dâune application classique, le projet sâest construit de lui mĂȘme, Ă partir de ce que nous voulions atteindre, des problĂšmes que nous avons rencontrĂ©, et beaucoup de refactoring. đ
Jâai essayĂ© dâimposer une architecture cohĂ©rente et efficace le plus possible, luttant contre mon binĂŽme et sa programmation parfois anarchique đ et bien que jâai du faire quelques concessions Ă la vue de la deadline qui se rapprochait, je suis plutĂŽt content du rĂ©sultat.
Nous avons beaucoup utilisĂ© les avantages de lâorientĂ© objet, ce qui me permet de vous prĂ©senter ces magnifiques diagrammes UML :
JâespĂšre que vous avez apprĂ©ciĂ©. ^^
Concernant le code pur, nous nous sommes fait plaisir (surtout mon binĂŽme cette fois).
Nous avons notamment dĂ©veloppĂ© un gĂ©nĂ©rateur de maps alĂ©atoires, un systĂšme de pathfinding pour les bateaux, ainsi quâun moteur de particules.
Ce moteur de particules, il faut bien lâavouer, est en grande partie responsable de lâaspect graphique attrayant du jeu.
Il permet de générer feu, fumée, et explosions du plus bel effet, en prenant en charge le type de cible que le boulet atteint.
Il permet aussi de tirer des boulets enflammĂ©s, nettement plus attractifs visuellement pour le joueur đ
En parlant de graphismes, nous avons des textures assez immenses (256*256 par bloc), ce qui permet un zoom impressionnant, bien que peu pratique pour jouer.
Tous les sprites du jeu proviennent de rendu 3D haute dĂ©finition (tours, bateaux, arbresâŠ)
3. Vue dâensemble du jeu
Jâai volontairement simplifiĂ© cet article pour ne parler que de ce qui mâintĂ©ressait, mais Ă©tant donnĂ© que câest le rĂ©sultat de plusieurs mois de travail, il est Ă©videmment bien plus complexe : 6646 lignes de code Ă la derniĂšre rĂ©vision, sans compter la SFML que nous avons lĂ©gĂšrement modifiĂ© pour nos besoinsâŠ
Je nâai pour lâinstant pas lâintention de publier le code ou/et une version binaire du jeu.
Ce nâest de toute façon dans son Ă©tat actuel quâune version beta amĂ©liorĂ©e⊠qui sera peut ĂȘtre terminĂ©e un jour, on ne sait jamais đ
Et pour terminer, une petite vidéo de démo.
Ecrit un soir dâorage, en Ă©coutant Dope Star Inc.
This is the interesting article! Many thanks for the idea! Along with sincerely Luke aka couchgool.
TrÚs trÚs beau travail ! Le jeu est superbe (pour un jeu étudiant) et il a l'air d'avoir pas mal de trucs sympas (pathfinding, cartes random, etc ...)
Petite question : Pourquoi les interfaces possĂšdent elles des attributs dans le diagramme de classe ? o.O
Merci du compliment !
Concernant le pourquoi y a-t-il des attributs dans des interfaces :
parce que j'en avais besoin ? ^^
Plus sérieusement :
En C#, on a un truc magnifique qui s'appelle les properties, en fait c'est simplement un getter/setter présenté d'une façon un peu plus esthétique et pratique.
Donc ce qui ressemble Ă des attributs est en fait un tas de fonctions (mĂȘme si on ne s'en rend pas forcĂ©ment compte, puisqu'une property s'utilise comme un attribut đ )
Et c'est donc tout Ă fait possible dans une interface... Vive le C# o/
Ouais c'est sur mais disons que j'ai pas l'habitude de voir ça sur un diagramme de classe (Normalement, c'est indépendant du langage et blablablablabla :p) donc ça m'a un peu hérissé les poils.
L'explication ne m'Ă©tait pas venue naturellement đ
il suffit de se dire que ce sont des fonctions, la diffĂ©rence avec les autres langages est juste cosmĂ©tique đ
Bon boulot !
L'architecture a l'air bien pensée, et le jeu est bien réalisé.
Si avec ça vous n'avez pas vos crĂ©dits đ
Merci !
ça fait plaisir d'avoir des commentaires comme ça đ