Stage ICube² : Motion Capture

Début : Mai 2014
Durée : 3 mois
Langage : MEL (Maya Embedded Language)
Bibliothèques/Outils : Maya, Blade

Lien vers une démonstration de la première version du script

Cet été, j’ai eu la chance de pouvoir refaire un stage au laboratoire ICube de Strasbourg, avec grand plaisir étant donné le nombre de connaissances que m’avait apporté le précédent. Cette fois-ci j’ai notamment un sujet en rapport direct avec le jeu vidéo, puisque mon travail servira à la réalisation du projet de Serious Game « Eveil 3D ». J’ai eu pour tuteur M. Arash HABIBI, que je remercie pour m’avoir proposé cette offre de stage.

Mon but lors de ce stage était de créer plusieurs scripts, qui permettraient d’appliquer des mouvements relevés grâce à la Motion Capture à n’importe quel modèle 3D créé avec Maya. La capture de mouvements se fait grâce au logiciel Blade.  Cette étape de « traduction » est très importante, et devra être réalisée pour n’importe quel type de modèle 3D (ayant donc potentiellement un squelette très différent de celui généré par Blade).

La première partie du stage aura été une phase d’apprentissage du fonctionnement de Maya et de son langage de scripting : le MEL. Après m’être familiarisé avec le logiciel, je commençais à élaborer quelques scripts me permettant de transcrire le mouvement, ne prenant alors en compte qu’un modèle 3D bien spécifique.

La seconde partie aura été de transposer mes résultats pour les appliquer sur n’importe quelle structure de modèle 3D. J’ai ainsi pu créer plusieurs outils, afin qu’un utilisateur puisse transposer les mouvements du squelette Blade. La fin du stage aura d’ailleurs été une longue période de peaufinage, afin de rendre ces outils accessibles et simple d’utilisation.

Ce stage m’aura pas mal appris concernant le fonctionnement du logiciel Maya, mais aussi des modèles 3D et de leur structure. Le langage MEL m’aura parfois donné un peu de fil à retordre, notamment pour débugger les scripts, mais sa présence dans le logiciel s’avère très pratique. J’ai aussi pu assister à quelques captures de mouvements, me permettant de comprendre l’utilisation de Blade et des multiples phases de traitement que la Motion Capture entraîne.  J’espère en tout cas avoir l’occasion de travailler à nouveau avec ce type de technologies.

Eurographics 2014

En Avril 2014, j’ai eu la chance de pouvoir assister à une des conférences les plus prestigieuses en termes d’Informatique graphique : Eurographics. Cette conférence a lieu tous les ans dans un pays européen différent. Cette année, elle avait lieu au Palais des Congrès de Strasbourg, et était organisée par le laboratoire ICube (dans lequel j’ai la chance de refaire un stage cet été). Je n’aurais normalement pas eu le droit d’y assister sans payer une inscription onéreuse, mais nos professeurs nous ont généreusement permis de nous y rendre en tant que visiteurs.

J’ai premièrement pu en apprendre beaucoup plus sur le projet de Serious game du laboratoire ICube, auquel je vais pouvoir participer pendant mon stage d’été. Ce projet, appelé Eveil-3D, présente de nombreuses problématiques puisqu’il s’agit de créer un jeu utilisant la réalité virtuelle permettant au joueur d’apprendre la langue Allemande ou Française (projet en partenariat entre les 2 pays). De nombreuses recherches sont donc effectuées quant à l’immersion du joueur dans le monde, l’analyse des mots prononcés par le joueur, la motion capture, etc.

Une autre présentation très intéressante traitait du « Procedural Modeling » et était en rapport avec les problématiques de certains jeux vidéo. Il y était question de génération de villes via calcul GPU, de diverses accélérations permettant l’affichage de ces villes lorsqu’elles s’avéraient très grandes. Un sujet abordé était aussi la génération aléatoire de niveaux de jeu, incluant des formes de salles relativement hétérogènes et permettant des configurations très originales.

Enfin, la présentation qui s’est avérée la plus impressionnante était tenue par de grandes firmes : NVIDIA, Crytek et Disney. L’aspect technique était forcément moins développé ici, et la présentation était surtout centrée sur les résultats obtenus au cours des dernières années. J’ai donc pu voir de nouvelles techniques d’illuminations indirectes développées par NVIDIA, déjà implémentées dans l’Unreal Engine 4. Enfin j’ai pu découvrir CinéBox, la technologie de Motion Capture de Crytek, et découvrir le processus de création et de rendu des cheveux des animations Disney.

Je n’entre ici que peu dans les détails car toutes ces présentations auront été très denses et qu’il était difficile de comprendre tout le fonctionnement des diverses technologies dévoilées. Il était pourtant très intéressant pour moi de voir l’état des recherches effectuées dans un domaine aussi intéressant et innovant que l’informatique graphique. Certains résultats sont d’ailleurs très impressionnants et laissent présager de nombreuses autres innovations pour les années à venir.

Haunted Chase

Début : Mars 2014
Durée : 1 semaine
Langage : C#
Bibliothèques/Outils : Unity

Lien vers le jeu (WebPlayer)
Lien vers une vidéo test du jeu (par FancyPanda)

Haunted Chase est un projet de jeu créé lors de la Procedural Death Jam, qui a eu lieu sur la semaine du 8 Mars 2014. Le but était alors de créer un jeu appartenant au style « Rogue-like-like » (définition dérivée de la nouvelle vague inspirée du « Rogue-like », tels que The Binding Of Isaac, Spelunky, etc.). Ainsi, il fallait créer un environnement labyrinthique, généré aléatoirement, où la mort permanente obligerait le joueur à recommencer la partie.

Stan Wilhelm et moi-même avons donc décidé de participer ensemble à la PDJ, cette dernière étant notre toute première expérience de Game Jam. Nous n’avions que peu d’idées originales au départ, mais nous savions que nous souhaitions jouer sur une masse importante d’ennemis à l’écran. Le joueur devait à la fois se sentir oppressé par le labyrinthe et par les entités ennemies affluant vers lui.

Stan commença donc par s’occuper de la génération aléatoire des niveaux, tandis que je m’occupais pour ma part de régler le problème de l’algorithme de Pathfinding. Il était clair que pour gérer une quantité importante d’ennemis, la seule utilisation de l’algorithme A* ne serait pas suffisante. Un court test me révéla qu’en effet, le nombre d’ennemis ne pouvait dépasser la cinquantaine sans optimisation. C’est en retrouvant cet article très intéressant que j’eus l’idée de contourner le problème en appliquant le Pathfinding aux Tiles du niveau, plutôt qu’à chaque ennemi. Ainsi, l’algorithme est propagé depuis le joueur (rendant le calcul plus long), mais n’est fait qu’une seule fois (plutôt qu’une fois par ennemi). La population de chaque Tile est d’ailleurs aussi prise en compte dans l’algorithme, afin que les ennemis s’évitent dynamiquement.

Nous voulions ensuite que la visibilité du joueur soit quelque peu réduite par les éléments l’entourant, rendant le niveau d’autant plus labyrinthique. Encore une fois grâce à un article très instructif, je décidais plutôt de prendre une approche nettement moins coûteuse que de calculer directement le champs de vision du joueur. Les murs sont donc extrudés en direction de la caméra, provoquant un effet ressemblant à d’immenses colonnes bloquant la vision alentours. Bien que je m’attendais à une approximation plus proche du champs de vision, l’effet reste très intéressant et donne une certaine ambiance au donjon.

Une fois ces éléments mis en place, nous pensions alors réaliser un jeu où le joueur devrait s’approcher du maximum d’ennemis possible (les motivant ainsi à le suivre), tout en évitant leur contact. Le jeu aurait donc été principalement basé sur l’esquive, mais après quelques tests il s’est avéré que l’expérience restait relativement pauvre et nous avons donc décidé d’implémenter attaques et bonus. Ainsi, un shotgun (clic gauche) permet de tenir les ennemis éloignés et d’en éliminer, tandis qu’un bouclier (clic droit) permet de se sortir de certaines situations délicates. Pour survivre, le joueur est aussi motivé à explorer le niveau pour trouver divers bonus augmentant ses capacités (ou en les réduisant si la chance n’est pas avec lui).

Nous avons réussi à terminer la plupart de ce que nous voulions entreprendre dans les délais. Avec le recul, le jeu souffre tout de même d’une difficulté trop élevée, et ce principalement parce que nous n’avons pas pu beaucoup y jouer (les dernières fonctionnalités étant implémentées tard dans le développement). Avec plus de temps, j’aurais aussi aimé fluidifier le mouvement des ennemis qui se contentent de bouger du centre d’un Tile à l’autre, trahissant légèrement le fonctionnement du  Pathfinding. Je suis tout de même ravi du retour qu’ont donné les autres développeurs sur le jeu, votant pour nous et classant Haunted Chase en 5ème position de la catégorie « Best Game », parmi plus d’une centaine de participations !

Au final, cette première Game Jam aura été une incroyable expérience. Bien qu’on m’en parlait beaucoup, je crois que je sous-estimais l’intensité de ce type d’événements et la difficulté de développer avec une contrainte de temps. De plus, le fait de concilier les cours à l’Université en plus du développement le soir aura rendu cette semaine très éprouvante. Cependant, cela m’aura aussi montré à quel point ce type d’événement est formateur et vous pousse à réagir à la contrainte du temps. J’ai vraiment hâte de pouvoir retenter l’expérience dès que l’occasion d’une prochaine Game Jam se présentera.

Wander Shader

Début : Janvier 2014
Durée : 1 semaine
Langage : Shaderlab
Bibliothèques/Outils : Unity

Lien vers une démonstration basique du shader (Webplayer)

J’ai commencé cette petite expérimentation en me basant sur le jeu Wander, développé par des étudiants de l’Enjmin. J’avais suivi l’actualité autour des projets des étudiants du master JMIN et m’était toujours intéressé à l’effet visuel saisissant opérant dans ce jeu. On incarne en effet un personnage aveugle, l’affichage consistant donc en une propagation d’ondes sonores. Je me décidais donc à tenter de recréer un effet visuel similaire.

Je décidais alors de m’imposer les mêmes contraintes que le programmeur de ce projet, tel qu’il le décrivit dans un article :

• Effectuer le rendu normal
• Appliquer un effet de contour
• Appliquer un effet de propagation de son

Ainsi, le programmeur s’assure alors qu’un unique rendu 3D est effectué, permettant d’optimiser les performances et de réaliser les effets visuels par un traitement d’image en post-rendu. Unity ne permettant d’ailleurs pas d’effectuer ce type d’effet dans sa version gratuite, il m’aura fallu utiliser mon mois d’essai d’Unity Pro.

Avant de m’y confronter moi-même, j’avais du mal à comprendre le problème sur lequel le programmeur de Wander s’était heurté, à savoir retrouver les coordonnées 3D de chaque pixel, à partir d’une image 2D. Il aura donc fallu utiliser la composante de profondeur de chaque pixel, pour recréer les coordonnées 3D en fonction du frustum de la caméra, ce qui fut en effet une étape très délicate.

Après quelques temps j’ai enfin réussi à obtenir l’aspect désiré. L’effet n’est pas sensiblement le même, et nécessiterait évidemment un peu de peaufinage supplémentaire : par exemple, quelques modifications seraient à apporter sur l’effet de contour pour que chacun des contours modifie la valeur de profondeur du pixel et évite cet effet disgracieux :

Cependant mon but ici n’était pas d’obtenir une version finie, mais bien de comprendre le fonctionnement de cet effet. Au final, je suis content d’avoir réussi à  le recréer, car je trouve cette idée très ingénieuse. L’expérience de Wander se base beaucoup sur ce très bon effet, et j’avais vraiment envie de m’y essayer.

2D Engine + Tetris AI

Début : Octobre 2013
Durée : 2 mois
Langage : C++
Bibliothèques/Outils : SDL2

Lien vers une vidéo du jeu
Lien vers une vidéo de l’IA

Lien vers le code source
Lien vers la documentation du code
Lien vers le dossier complet

Dans le cadre d’une matière de Programmation Orientée Objet à l’université de Strasbourg, nous avons reçu pour travail de développer le jeu Tetris et d’en réaliser une intelligence artificielle. Notre premier but était donc de réaliser le jeu, puis de concevoir une IA originale capable de tenir le plus longtemps possible en ne connaissant aucune pièce à l’avance. Une des contraintes importante était que le programme de l’IA devait être complètement indépendant du programme gérant le jeu, il nous fallait donc nous assurer de créer une communication entre les deux composants.

Ayant acquis de nombreuses connaissances pendant l’été en travaillant avec le livre Game Coding Complete, j’ai décidé de profiter de ce projet pour m’essayer à la création d’un petit moteur de jeu 2D. J’ai donc passé un mois et demi à développer exclusivement des outils qui permettraient ensuite la création du jeu. Le moteur se base sur les principes suivants :

• Un système de Process permettant la création de tâches qui se déroulent sur plusieurs frames. Chacun de ces Process est mis à jour à chaque frame en lui donnant la valeur du temps écoulé depuis la dernière frame et permet donc la création d’animations, de processus de gameplay, etc. La force de ce système réside surtout dans le fait de pouvoir créer des chaînes de Process, qui s’exécuteront alors successivement.
• Un système d’Event permettant de créer des événements et de les propager dans le système. Une classe EventManager gère une liste d’objets attachés à chaque type d’événement et appelle les méthodes de ces objets via un système de callback lorsqu’un événement est propagé (utilisation de la bibliothèque fastdelegate).
• Un système d’affichage graphique gérant le chevauchement des éléments graphiques grâce à une valeur de layer. Il est ainsi possible d’afficher du texte, des images avec ou sans transparence, et d’effectuer de multiples transformations et changement de couleurs (utile pour les animations).
• Un système de communication utilisant les sockets et le protocole TCP/IP pour dialoguer. Ce système permet de sérialiser des événements et de les envoyer à un programme distant. Ces événements seront ensuite propagés dans le programme d’arrivée (par exemple, le programme IA peut propager des événements d’inputs au programme du jeu Tetris).

Tous les détails ne sont pas donnés ici, tels qu’un système d’allocation de ressources, de debugging, etc.

Une fois la conception du moteur terminée, j’ai travaillé de pair avec Stan Wilhelm pour réaliser le gameplay du jeu, ainsi que les différentes animations que nous tenions à implémenter. Le moteur s’est alors révélé très pratique à utiliser, le découpage en Process rendant le travail facile. Au final, les conseils donnés dans Game Coding Complete étaient d’une grande pertinence et je fus impressionné du résultat. Ainsi, coder le gameplay n’aura pris que peu de temps et nous nous sommes ensuite attaqués à la partie IA.

Bien que l’affichage du jeu révèle une pièce d’avance au joueur humain, l’IA ne dispose pas de cette information et doit trouver la meilleure action à effectuer pour chaque nouvelle pièce. Une fois qu’il reçoit l’information de la grille du Tetris et de la nouvelle pièce, le programme de l’IA teste toutes les positions possibles et attribue un score à ces configurations. Il effectue ensuite simplement l’action qui aura obtenu le meilleur score et attend la pièce suivante.

La partie la plus importante de l’IA réside donc dans la façon dont le score de chaque position est déterminé. Il s’agit de vérifier différents critères et d’attribuer un poids à chacun d’entre eux. Les critères utilisés pour cette IA comprennent donc entre autres la hauteur résultante de la grille, le nombre de trous générés (nombre de cases rendues inatteignables pour d’autres pièces), etc. Au final, notre IA aura présenté les meilleurs résultats de notre classe, réussissant à éliminer jusqu’à 15000 lignes avant de perdre.

Ce projet aura été extrêmement enrichissant. Le développement du moteur m’aura permis de mettre en pratique les connaissances que j’avais pu acquérir tout au long de l’été et de vérifier leur utilité. De plus, nous avons pu nous essayer à la programmation d’une IA pour Tetris, et réussir à obtenir des résultats satisfaisants. Au final, de nombreuses améliorations peuvent être apportées au moteur comme au jeu. Je n’ai par exemple pas eu le temps de développer un système sonore, le jeu se trouvant donc sans aucune musique ou bruitage. De plus, l’utilisation du moteur pour coder le jeu m’aura donné des idées d’améliorations, telles que des possibilités de propagation d’événement lorsqu’une animation se termine, par exemple. En tout les cas, j’ai pris un réel plaisir à développer ce jeu, surtout la partie moteur dont je pourrais reprendre certaines parties dans des développements futurs. Le jeu est certes loin d’être abouti mais reste, en termes de code, une des architecture les plus intéressante qu’il m’aura été donné de réaliser.

Reading time !

L’année 2013 m’aura permis de découvrir de nombreux livres très intéressants et j’ai pensé qu’il serait pertinent de les présenter ici. Je commencerais donc par présenter le livre qui m’a servi de référence lors du stage avec OpenGL, avant de vous présenter deux autres livres plus en rapport avec le développement de jeux.

Avant mon stage de l’été 2013, j’avais beaucoup de mal à comprendre les versions OpenGL modernes et c’est pour cette raison que je me suis muni de ce livre. Je ne l’ai pas parcouru dans son intégralité mais de nombreux chapitres m’auront été très utile. Il présentait notamment l’avantage d’être un des seuls livres traitant de fonctionnalités très récentes comme les shaders de Tesselation. Il n’est peut-être plus le seul à l’heure qu’il est, cependant il reste pour moi un livre très instructif et fourni d’exemples très pratiques.

 

 

Ce second livre m’aura énormément appris sur le C++. Il est très bien écrit et très détaillé sur toutes les fonctionnalités qu’offrent le langage. Je m’attendais à ce que certains sujets relatifs à la programmation de jeux soient abordés plus en détails, et c’est peut-être mon unique reproche. Cependant, il reste très centré sur le jeu vidéo car il décrit chaque fonctionnalité du langage avec diverses anecdotes et en restant orienté sur les objectifs de développement d’un jeu : mémoire, performance, astuces de développement dans un studio… C’est un livre qui m’aura donné de bons réflexes et qui aura grandement amélioré ma connaissance du langage et de la programmation orientée objet.

 

Ce dernier livre aura été le plus enrichissant de tous et je le considère comme une véritable mine d’or. Il traite de très nombreux sujets du développement de jeux (graphisme, physique, langages de script, etc.) en détaillant la mise en place d’un moteur de jeu. Un code source de ce moteur est d’ailleurs disponible afin de permettre au lecteur de suivre les différents chapitres tout en comprenant l’implémentation en C++. J’ai passé la plupart de mon temps libre à lire ce livre lors de l’été 2013 et ç’aura été une incroyable découverte. J’ai d’ailleurs suivi le livre tout en reprenant moi-même le code afin d’être certain de ne perdre aucune subtilité dans l’implémentation des divers composants. J’ai aussi adoré l’approche des auteurs qui consiste à ouvrir le lecteur au travail en équipe et ainsi aux divers métiers du jeu vidéo (un programmeur ayant nécessairement besoin de communiquer avec artistes, game designers, etc.). Ce livre aura clairement changé mon approche dans la programmation de jeux. J’ai adopté la plupart des recommandations des auteurs et je ne saurais trop les remercier de partager leur expérience.

Au final, chacun de ces livres m’aura été d’une aide précieuse. Je pensais éprouver des difficultés à lire de tels ouvrages (qui plus est en Anglais) mais j’ai au contraire trouvé beaucoup de plaisir pour ce genre de lecture. J’espère avoir l’occasion de lire des livres tout aussi intéressants à l’avenir.

Stage ICube

Début : Mai 2013
Durée : 2 mois
Langage : C++
Bibliothèques/Outils : OpenGL 4

Lien vers le rapport de stage détaillé

À la fin de ma seconde année en Licence à Strasbourg, j’éprouvais le besoin de trouver un stage afin d’acquérir des connaissances utiles à la création de jeux vidéo et d’obtenir une expérience professionnelle. J’en parlais alors à l’un de mes professeurs qui me conseilla de regarder les offres de stage du laboratoire ICube, situé à Illkirch, non loin de Strasbourg. C’est en discutant avec un des chercheurs, M. Thery, que je décidais d’y faire un stage, le sujet traitant de programmation 3D en utilisant OpenGL « moderne ».

Avant d’entreprendre ce stage, j’avais déjà passé beaucoup de temps à l’apprentissage d’OpenGL. J’avais pour cela suivi plusieurs tutoriels, expérimenté la création de quelques scènes 3D basiques et lu plusieurs articles sur l’utilisation des dernières versions d’OpenGL.

Le but du stage concernait « l’évaluation et le rendu de surfaces de Bézier via calcul GPU« . Il m’était alors demandé d’utiliser plusieurs fonctionnalités d’OpenGL afin de proposer plusieurs versions du calcul de surfaces. J’ai donc pu réaliser 4 versions différentes :

• Une version « standard » n’utilisant aucune fonctionnalité avancée d’OpenGL. Cette version était nécessaire pour effectuer une comparaison avec les autres techniques.
• Une version utilisant un calcul effectué grâce au Vertex Shader.
• Une version utilisant un calcul effectué grâce au Tessellation Shader.
• Une version utilisant le « Transform Feedback« .

Il m’aura aussi été demandé de réaliser plusieurs méthodes de rendu comme le Gouraud Shading ou Phong Shading. Plus de détails concernant mon travail et les descriptions complètes des diverses versions développées sont disponibles dans mon rapport de stage.

Ce stage m’aura énormément apporté. J’ai pu largement consolider mes connaissances en programmation 3D, découvrir des méthodes de rendu ainsi que des fonctionnalités avancées d’OpenGL. Je garde un très bon souvenir de ce stage, qui m’aura permis d’éprouver mes limites et de m’améliorer en programmation 3D et orientée objet.

Filtre de Sobel

Début : Mars 2013
Durée : 2 semaines
Langage : Assembleur MIPS
Bibliothèques/Outils : MARS MIPS Simulator

Lien vers le code source

Ce travail a été réalisé dans le cadre du cours « Architecture des Ordinateurs » que j’ai pu suivre à l’université de Strasbourg. Stan Wilhelm et moi-même avons travaillé en binômes sur ce projet. L’objectif était de réaliser un programme en langage assembleur permettant d’appliquer un renforcement des contours sur une image. Celle-ci devait avoir un format BMP et ses couleurs devaient être codées sur 8 bits.

Afin de renforcer les contours d’une image,  il est nécessaire d’utiliser des matrices de convolution. Ces matrices servent à obtenir deux gradients, qui sont en fait deux images contenant des informations concernant la dérivée horizontale et verticale en chaque point. L’addition de ces deux images et un seuillage des couleurs permet d’obtenir le résultat suivant :

                    

Nous avons fait en sortes que ce programme fonctionne aussi avec les images dont les couleurs sont codées sur 4 bits et 1 bit. Nous avons aussi réalisé d’autres filtres rapides, qui n’impliquaient qu’une légère modification des matrices de convolution.

Ce projet aura vraiment été très intense. Nous n’avions en effet que 2 semaines pour appliquer ce que nous apprenions du cours sur le langage MIPS donné dans le même laps de temps. Ainsi, nous avons appris à correctement structurer notre code en blocs de fonctions au milieu du développement, ce qui nous a forcé à reprendre certaines parties du code plusieurs fois. Débugger le programme aura aussi été plus difficile qu’à l’accoutumée, bien que l’utilitaire MARS se soit avéré d’une grande aide.

Au final, je suis content d’avoir pu découvrir un code beaucoup plus bas niveau afin de mieux comprendre le fonctionnement des programmes en général. De plus, j’ai appris quelques bases sur le traitement d’images, via les divers filtres et matrices de convolution. Ce projet aura été vraiment difficile mais s’est avéré être un défi plaisant à relever.

Moon

Début : Décembre 2012
Durée : 2 mois
Langage : C#
Bibliothèques/Outils : Unity

Lien vers le jeu (WebPlayer)

« Moon » est un petit projet de jeu que j’ai créé dans le but de découvrir Unity. J’avais alors beaucoup de retours sur ce moteur de jeu et tous m’encourageaient à l’essayer. Un premier plaisir aura été de constater le grand nombre d’informations disponible en ligne, en plus d’une documentation très soignée qui m’aura facilité le travail.

Dans le jeu, on contrôle un petit personnage muni d’un jetpack qui vient d’atterrir sur la surface de la Lune. On sait alors peu de choses, sinon qu’un autre personnage nous demande d’aller récupérer un trésor. S’ensuit alors un parcours où le but est de trouver des clés pour progresser dans le niveau tortueux. Il faudra cependant éviter des pics et des astéroïdes qui blesseront notre personnage, le renvoyant au début du niveau s’il n’est pas assez habile.

Le joueur dispose d’une barre de vie ainsi qu’une barre de mana (voire essence) qui représente le temps d’utilisation du jetpack. La barre de mana se régénère automatiquement lorsqu’on touche le sol, permettant de ne limiter l’utilisation du jetpack que sur la durée d’un saut.

Ce projet tire quelques inspirations des jeux Zelda,aussi bien dans le graphisme que dans certains effets sonores issus de Zelda 3. J’ai modestement créé les différents dessins et animations tandis que Stan Wilhelm a composé les 2 musiques du projet. Je le remercie encore pour son aide !

Ce qui est certain, c’est que ce moteur de jeu m’aura clairement convaincu de sa puissance. Les différentes possibilités sont vraiment impressionnantes et tout est très accessible et bien documenté. Depuis, je l’utilise assez fréquemment, que ce soit pour envisager des projets plus longs ou pour rapidement créer des prototypes. Sans parler du fait qu’il est possible de publier ses créations sur une dizaine de plateformes différentes…

Finalement, je ne regrette pas du tout de m’être essayé à Unity. Concernant le projet, j’aurais aimé essayer de développer des outils permettant une création de niveaux plus facile. Je crois aussi avoir rendu le jeu relativement difficile, avec une inertie surement trop importante, même sur la Lune ! Le fait d’avoir trop longtemps joué au projet pendant son développement aura rendu le paramétrage difficile. En tous les cas, cela m’aura permis de découvrir de toutes nouvelles choses et d’aborder une approche différente du développement d’un jeu avec l’utilisation d’un moteur.

Super Mario Tower

Début : Août 2012
Durée : 2-3 mois
Langage : C++
Bibliothèques/Outils : SDL

« Super Mario Tower » est ma toute première expérience dans la programmation de jeux vidéo. C’est à partir de cette période que mon envie de développer des jeux m’est apparue et que je décidais d’en commencer l’étude. Ce travail avait aussi pour but de me familiariser avec le paradigme objet, en apprenant le langage C++, et l’utilisation de la bibliothèque SDL.

L’objectif que je me suis fixé était de reproduire le gameplay des premiers jeux de plateforme Super Mario Bros. Le joueur doit donc atteindre la fin du niveau représentée par un drapeau, en se frayant un chemin en sautant et en évitant les pics. La différence avec un Mario classique est que le niveau propose une progression strictement verticale, plutôt qu’horizontale. De plus, une étendue de lave dont le niveau augmente oblige le joueur à grimper rapidement sous peine de mort immédiate.

Un soin particulier aura été apporté afin de donner la sensation de contrôle et la physique d’un personnage issu des premiers épisodes parus sur NES. En effet, il est possible de courir pour augmenter sa vitesse, cette dernière influant sur la hauteur du saut effectué. Le personnage est d’ailleurs soumis à une forte inertie, caractéristique classique de ces jeux de plateforme.

Afin de faciliter la création de niveaux, un petit éditeur aura été développé. Il est ainsi possible grâce au tiling de sauvegarder un niveau créé dans un fichier texte, puis de le charger dans le jeu.

Au final, ce projet m’aura beaucoup apporté car il m’aura fait découvrir l’envers du décor et la plupart des systèmes permettant de faire fonctionner un jeu. Il m’aura aussi initié au plaisir du développement d’un jeu et aura renforcé ma détermination à évoluer dans ce milieu. Cependant, il est loin d’être exempt de défauts et il ne me viendrait plus du tout à l’esprit de programmer ce jeu de la même façon. Par exemple, l’architecture du code est assez naïve et témoigne du peu d’expérience dont je disposais à ce moment. Cela reste toutefois comme un très bon souvenir et demeure mon premier vrai projet de jeu.