Zachary Gauthier

C’est quoi ?

Ragdoll Rampage est un jeu de combat où deux personnes s’affrontent sur le même clavier. Les personnages sont des ragdolls (des « poupées de chiffon ») : leur corps est mou et réagit de façon réaliste à chaque coup, ce qui rend chaque combat imprévisible et drôle.

Le défi et mes objectifs

C’était le TP3 du cours de développement de jeux vidéo, et je l’ai réalisé seul. Je voulais :

• Créer un jeu complet de A à Z : menu d’accueil, guide, combat, fin de partie, musique et sons.
• Faire de la physique le cœur du jeu. Je m’étais inspiré du jeu Stick Fight: The Game, où les combattants tombent, glissent et se font projeter.
• Permettre à deux joueurs de jouer sur un seul clavier, chacun avec ses propres touches.

Ce que j’ai fait

J’ai avancé une fonctionnalité à la fois, sur six semaines :

1. Les bases (semaine 1). J’ai intégré un pack d’assets (un ensemble de ressources prêtes à l’emploi) qui fournit un pantin articulé. Je l’ai ensuite programmé pour qu’il marche et saute.
2. Le combat (semaines 2 et 3). J’ai ajouté les coups de poing, une hache, la possibilité de ramasser une arme et d’attaquer dans toutes les directions.
3. La défense (semaine 3). J’ai ajouté les dégâts, puis un bouclier hologramme qui bloque la moitié des dégâts et qui a sa propre jauge d’énergie. J’ai aussi ajouté la mort des joueurs et une minuterie de 5 minutes.
4. La lisibilité (semaine 4). La caméra suit les deux joueurs en même temps et chacun a sa barre de vie.
5. Les menus et la finition (semaines 5 et 6). J’ai fait un menu d’accueil où l’on peut attraper le titre et le lancer contre les murs, un guide « Comment jouer ? », des contrôles séparés pour chaque joueur, une carte, de la musique et des effets sonores 8-bit.

Mon choix technique principal : d’habitude, dans un jeu, on joue une animation puis on déplace le personnage. Ici, j’ai fait l’inverse : j’applique des forces sur les membres du pantin, et c’est la physique qui produit le mouvement. Un coup de poing, c’est littéralement un bras projeté vers l’avant par une force. C’est ce qui donne au jeu son côté chaotique.

Action	Joueur 1	Joueur 2
Se déplacer	W A S D	Flèches
Attaquer	F	J
Bouclier	G	K
Prendre une arme	H	L

Pause : P

Le résultat

Le jeu est complet et jouable : on lance une partie depuis le menu et les deux joueurs se battent jusqu’à ce que l’un tombe à zéro point de vie (« Joueur X remporte le combat ! ») ou que la minuterie atteigne zéro (égalité). Des armes apparaissent au fil du combat. J’ai aussi préparé une version web du jeu et rempli le formulaire de publication demandé dans le cours. Le jeu n’est pas publié en ligne pour l’instant.

Ce que j’ai appris

Techniquement :

• Utiliser un pack d’assets : comprendre du code écrit par quelqu’un d’autre, l’intégrer et l’adapter à mon jeu au lieu de tout refaire.
• Programmer la physique pour produire les actions, plutôt que de faire une action qui modifie ensuite la physique. Ça demande de penser en forces, en poids et en articulations.
• Gérer deux joueurs sur un seul clavier avec le système de contrôles de Unity (Input System).

Personnellement :

• [À COMPLÉTER : ce que ce projet seul t’a appris sur toi, ex. organiser ton temps, rester motivé sans équipe, prendre des décisions seul.]

C’est quoi ?

SoS Neige est un site web de déneigement sur demande. Un client crée un compte, inscrit sa cour et commande un déneigement en quelques clics. Un déneigeur voit, dans son tableau de bord, les commandes en attente près de chez lui, en accepte une, puis la marque comme terminée.

Le défi et mes objectifs

C’était le projet final de mon cours de développement d’applications web, réalisé seul pendant toute la session d’hiver 2026. Je voulais :

• Construire un vrai site dynamique, où les pages changent selon les informations enregistrées dans une base de données (un grand classeur organisé où le site range les comptes, les cours et les commandes).
• Gérer deux types d’utilisateurs qui n’ont pas accès aux mêmes pages.
• Protéger les comptes correctement : mots de passe, sessions et double authentification.

Ce que j’ai fait

J’ai construit le site par étapes, du début février jusqu’à la mi-mai :

1. Les pages publiques. L’accueil, « Comment ça fonctionne », « Devenir déneigeur », la connexion et l’inscription, avec une barre de navigation et un pied de page réutilisés sur toutes les pages.
2. La base de données. Des tables pour les comptes, les clients, les adresses (les cours à déneiger) et les commandes. J’ai séparé le code en couches : les modèles (la forme des données), les repositories (le seul code qui parle à la base de données) et les pages qui affichent le résultat.
3. L’inscription. Le formulaire vérifie le format du code postal et du téléphone, et demande au serveur en direct (avec fetch, sans recharger la page) si le courriel est déjà utilisé.
4. La connexion sécurisée.
   • Les mots de passe ne sont jamais enregistrés en clair : ils sont hachés (transformés en une empreinte impossible à inverser) avec password_hash.
   • Après le mot de passe, un code à 4 chiffres est envoyé par courriel : c’est la double authentification.
   • La session (ce qui permet au site de se souvenir qu’on est connecté) expire après une heure d’inactivité, et son identifiant change à chaque page pour éviter qu’on la vole.
   • Chaque tentative refusée est notée dans un journal avec la date et l’adresse IP.
5. Les rôles. Un client est envoyé vers la page de commande ; un déneigeur, vers son tableau de bord. Une personne qui n’est pas déneigeur ne peut pas ouvrir le tableau de bord, même en tapant son adresse.
6. Les commandes. Le client choisit sa cour, des options (épandage de sel, escaliers, urgence en moins de 4 h) et voit le total se calculer. Le déneigeur accepte la tâche, puis la marque « Terminée ». Le client reçoit un reçu et peut consulter son historique.
7. Docker. J’ai préparé un conteneur PHP + Apache pour faire tourner le site sur mon ordinateur de la même façon que sur le serveur.

Le résultat

Le site est en ligne sur le serveur du cégep et fonctionne de bout en bout : inscription, connexion avec code par courriel, commande d’un déneigement, acceptation et fin de la tâche par un déneigeur. J’ai documenté mes tests (mauvais mot de passe, courriel déjà utilisé, champ manquant, inscription valide) avec des captures d’écran.

Ce que j’ai appris

Techniquement :

• Organiser un projet web en couches, pour que l’affichage, la logique et l’accès aux données ne se mélangent pas.
• La sécurité de base d’un site : hacher les mots de passe, utiliser des requêtes préparées avec PDO (pour bloquer les injections SQL, une attaque qui glisse du code dans un formulaire), gérer les sessions et vérifier le rôle de l’utilisateur sur chaque page protégée.
• Faire communiquer le navigateur et le serveur sans recharger la page avec fetch et le format JSON.

Personnellement :

• [À COMPLÉTER : ce que ce projet t’a appris sur toi, ex. mener un long projet seul sur toute une session, déboguer un problème de serveur, persévérer.]

C’est quoi ?

Donjon Escape est un jeu d’action vu de dessus : on choisit un héros (barbare, archer, sorcier…) et on doit survivre à 11 vagues de monstres en battant le boss de chaque vague. Le jeu est relié à un site web où l’on crée son personnage et où l’on dépense, dans une boutique, l’or gagné en jouant.

Le défi et mes objectifs

Le cours demandait de programmer un jeu avec Windows Forms, un outil de Microsoft qui sert normalement à créer des fenêtres de logiciels, pas des jeux. Avec mon coéquipier Xavier Trudel, nos objectifs étaient de :

• Relier trois morceaux : le jeu, un site web et une base de données (un classeur géant et organisé où l’on range les informations).
• Garder la progression du joueur : l’or gagné et les objets achetés devaient être sauvegardés d’une partie à l’autre.
• Nous répartir le travail pour avancer en parallèle sans nous marcher sur les pieds.

Ce que j’ai fait

Xavier s’est concentré sur le cœur du jeu (ennemis, boss, vagues, classes de héros). De mon côté, je me suis occupé du site web, de la base de données et d’une partie du jeu :

• Le site web, en entier. Je l’ai fait avec Blazor, un outil qui permet de créer un site en C#, le même langage que le jeu. J’ai fait la page d’accueil, la création de personnage, la boutique (choisir une quantité, acheter avec son or) et l’inventaire, protégé par un mot de passe pour que personne d’autre ne dépense notre or.
• Le lien avec la base de données. J’ai écrit les repositories (le seul endroit du code qui a le droit de parler à la base de données) et les mappers (des « traducteurs » qui transforment une ligne de la base de données en objet utilisable dans le jeu). J’ai aussi fait la sauvegarde des personnages et des objets.
• Les fenêtres du jeu. J’ai fait les fenêtres pour créer un personnage, le choisir et lancer une partie.
• Des morceaux du jeu. J’ai programmé la caméra qui suit le joueur, les collisions avec les murs (le joueur ne traverse plus les murs), les éléments de décor, un outil qui découpe une feuille de sprites (une grande image qui regroupe tous les dessins d’un personnage) et la potion de vie.

Mon choix technique principal : nous avons placé la logique commune (personnages, objets, accès aux données) dans un projet partagé. Le jeu et le site utilisent ainsi exactement le même code : un objet acheté sur le site existe aussitôt dans le jeu.

Le résultat

• Le jeu compte 14 classes de héros, 11 boss avec chacun sa propre attaque, des ennemis qui contournent les murs pour traquer le joueur et un système de vagues de plus en plus difficiles.
• Le site web fonctionne : on y crée un héros, on achète des objets (potions, bottes de vitesse, tomes de force…) et on consulte son inventaire.
• La progression est sauvegardée dans la base de données MySQL : l’or et les objets restent d’une partie à l’autre.

[À COMPLÉTER : ajoute ici la vidéo de démo ou des captures du jeu et du site web.]

Ce que j’ai appris

Techniquement :

• Connecter une application C# à une base de données MySQL et organiser le code en couches (affichage, logique, accès aux données).
• Créer un site web interactif avec Blazor.
• Travailler à deux sur le même code avec Git : récupérer le travail de l’autre, fusionner nos changements et régler les conflits. Le projet compte plus de 280 sauvegardes (commits).

Personnellement :

• Communiquer et se diviser le travail : chacun son domaine, avec des points de rencontre clairs entre le jeu et le site.
• S’adapter à une contrainte. Windows Forms ne fonctionne que sur Windows, alors je ne pouvais pas faire tourner le jeu sur mon Mac. [À COMPLÉTER : comment tu as contourné ce problème.]