Shiryo

Shiryo est un jeu de réflexion mobile développé avec Unity, construit autour de déplacements sur une grille et de modificateurs combinables. J’y ai occupé un double rôle de programmeur gameplay et de Producer, en contribuant au développement tout en participant à la coordination de l’équipe et au suivi du projet. L’architecture contrôle explicitement les mouvements, les sauts et les interactions entre les personnages, sans dépendre du moteur physique de Unity. L’objectif est de rendre les comportements prévisibles et de faciliter l’évolution des mécaniques.

Type de projet

Jeu de réflexion mobile — Unity

Date

2025

Emplacement

Paris

Architecture modulaire

La grille, les personnages, le budget de modificateurs et les phases de jeu sont gérés par des systèmes distincts. La logique de jeu est séparée de l’affichage, de l’interface et de l’audio. Cette organisation vise à faciliter la maintenance, les tests et l’évolution des fonctionnalités.

Déplacements sur grille

La position logique des personnages est calculée case par case. Leur déplacement à l’écran est interpolé séparément pour conserver une animation fluide. Les sauts, les chutes et les mouvements verticaux sont contrôlés par des états explicites, sans Rigidbody. Cette approche permet de maîtriser les transitions et de synchroniser les deux personnages.

Sauts et interactions verticales

Le système prend en charge les sauts, la glissade et l’escalade contre les murs, les sauts muraux et la propulsion par des pistons. Les trajectoires dépendent de la vitesse, des obstacles et des modificateurs actifs. Les arcs de saut sont calculés avec une courbe parabolique paramétrable.

Modificateurs combinables

Des modificateurs placés sur les cases solides accélèrent, ralentissent ou font sauter les personnages. Ils peuvent se combiner pour produire plusieurs effets ; accélération et ralentissement peuvent aussi s’annuler. Le système détecte le modificateur déjà présent, gère son remplacement et ajuste le coût de la combinaison.

Budget de modificateurs

Un budget configurable par le game designer limite les modificateurs disponibles. Le système centralise les dépenses, les remboursements et le coût des combinaisons. L’interface est actualisée par événements et fournit des retours visuels au joueur. Ce budget constitue une ressource de gameplay.

Phases de jeu

Une machine à états organise les phases de visualisation, d’exécution et de résultat. Elle contrôle les interactions autorisées, les transitions vers la victoire ou la défaite et le déroulement des nouvelles tentatives.

Réinitialisation des tentatives

La réinitialisation replace les personnages, restaure leur direction initiale, réactive les personnages absorbés et remet les pistons à leur état de départ, tout en conservant les modificateurs placés. Les états temporaires sont effacés pour éviter qu’une tentative influence la suivante.

Collisions entre personnages

Les collisions aériennes sont détectées à partir de rayons simplifiés. Un verrou évite les rebonds répétés et déclenche une chute contrôlée. Selon la situation, la chute peut être libre, décalée horizontalement par la vitesse ou contrainte à une colonne.

Audio séparé du gameplay

Un gestionnaire central pilote les effets sonores. Un composant intermédiaire observe les états des personnages et transmet les événements audio. Cette séparation permet d’ajouter ou d’ajuster les sons sans modifier le cœur de la logique de déplacement.

Rôle

Programmeur gameplay et Producer