Mécaniques de base et règles système dans un GDD de jeu 2D

Objectif : transformer des idées en règles testables

Dans un GDD, une mécanique n’est pas une intention (“le personnage est agile”), mais une spécification exploitable par l’équipe : quelles entrées déclenchent quoi, dans quelles conditions, avec quels effets, quelles variables sont modifiées, et quelles exceptions existent. L’objectif de ce chapitre est de décrire des mécaniques de base d’un jeu 2D (déplacement, saut, tir, interaction) et les règles système associées (collisions, états, victoire/défaite, feedback) de façon suffisamment précise pour être implémentée et testée.

Étape par étape : méthode de spécification d’une mécanique

1) Définir l’action et son intention de gameplay

Écrivez une phrase simple : Action = verbe + cible + contrainte. Exemple : Sauter = quitter le sol pour franchir un obstacle, uniquement si le personnage est au sol.

2) Lister les entrées (inputs) et leur lecture

Précisez le type d’entrée : pression, maintien, relâchement, double-tap, direction analogique, etc. Indiquez si l’action est déclenchée à l’appui (onPress) ou tant que la touche est maintenue (onHold).

• onPress : déclenche une fois (ex. saut, interaction).
• onHold : continue tant que maintenu (ex. déplacement, tir automatique).
• onRelease : déclenche à la fin (ex. saut variable, charge).

3) Décrire les conditions (garde-fous)

Les conditions sont des booléens ou comparaisons : isGrounded, ammo > 0, cooldownReady, notInState(Dead). Elles évitent les ambiguïtés et définissent les cas limites (ex. “appuyer sur saut en l’air”).

4) Définir les effets et variables impactées

Un effet doit être mesurable : changement de vitesse, création d’un projectile, consommation de ressource, transition d’état, déclenchement de feedback. Listez les variables modifiées (et leur unité) : vx (px/s), vy (px/s), ammo, hp, state, cooldownTimer.

Continuez dans notre application.

Vous pouvez écouter le livre audio écran éteint, recevoir un certificat gratuit pour ce cours et accéder également à 5 000 autres cours en ligne gratuits.

Ou poursuivez votre lecture ci-dessous...

Téléchargez l'application

5) Fixer les priorités entre actions

Quand plusieurs actions sont possibles au même instant, définissez une règle de résolution. Exemple courant : Interaction > Tir > Saut > Déplacement ou l’inverse selon le genre. Sans priorités, vous obtenez des bugs “interagir tire” ou “saut annule tir”.

6) Documenter les cas limites

Listez explicitement les situations problématiques : appui simultané, spam d’entrée, collision à haute vitesse, bord de plateforme, changement d’état pendant une animation, etc. Chaque cas limite doit avoir une règle.

Spécification des actions joueur (2D)

Déplacement (gauche/droite)

Décidez si le déplacement est :

• Instantané (vitesse fixe) : plus arcade, plus simple.
• Avec accélération/décélération : plus “physique”, nécessite des paramètres.

Paramètres clés à noter : moveSpeed, accel, decel, airControlFactor (contrôle en l’air), maxSlopeAngle (si pentes).

Saut

Décidez :

• Saut fixe : une impulsion verticale unique.
• Saut variable : hauteur dépend du maintien (souvent plus agréable).
• Coyote time : tolérance après avoir quitté le sol (ex. 0,1 s).
• Jump buffer : mémorise un appui juste avant l’atterrissage (ex. 0,1 s).

Paramètres clés : jumpVelocity ou jumpHeight, gravity, coyoteTime, jumpBuffer, maxJumps (double saut si applicable).

Tir

Décidez :

• Cadence (coups/seconde) et mode : semi-auto (onPress) ou auto (onHold).
• Portée : projectile (distance/temps de vie) ou hitscan (instantané).
• Précision : dispersion, recul, direction verrouillée ou libre.
• Ressource : munitions, énergie, surchauffe.

Paramètres clés : fireRate, damage, projectileSpeed, range, cooldown, ammoMax, reloadTime.

Interaction

Définissez la cible : objet proche, zone, PNJ, ramassage. Spécifiez la règle de sélection :

• Priorité par distance (le plus proche).
• Priorité par visée (dans un cône devant le joueur).
• Priorité par type (ex. “porte” avant “ramassage”).

Paramètres clés : interactRadius, interactConeAngle, interactCooldown.

Règles de collision (2D) : ce qui doit être explicite

Types de collision

• Sol/murs : collision solide (bloque le mouvement).
• Plateformes traversables : collision seulement si le personnage descend et se pose par-dessus (règles à préciser).
• Triggers : zones qui déclenchent un événement sans bloquer.
• Hitboxes/Hurtboxes : zones de dégâts (attaque) et zones vulnérables (réception).

Règles minimales à écrire

• Résolution : séparation par axe (X puis Y) ou résolution vectorielle (selon moteur). Dans un GDD, indiquez au moins l’intention : “ne jamais traverser un mur” et “se poser proprement sur les plateformes”.
• Priorité des collisions : ex. “solide > plateforme traversable > trigger”.
• Haute vitesse : préciser si vous utilisez une détection continue (raycast/sweep) pour éviter de traverser des murs.
• Invulnérabilité : après un dégât, collisions de dégâts ignorées pendant iFrameDuration.

Cas limites fréquents (à trancher)

• Coin de mur : si le joueur touche un coin en sautant, glisse-t-il ou s’arrête-t-il net ?
• Plateforme traversable : que se passe-t-il si on saute depuis dessous ? (souvent : pas de collision).
• Empilement d’objets interactifs : si plusieurs cibles sont dans le rayon, quelle est la cible active ?

États du personnage : machine à états (FSM) et transitions

Les états rendent les règles lisibles : une action est autorisée ou non selon l’état. Définissez une liste courte d’états, puis les transitions.

Exemple d’états courants

• Idle : au sol, sans mouvement.
• Run : au sol, en mouvement.
• Jump : phase ascendante.
• Fall : phase descendante.
• Attack : tir/attaque en cours (peut être superposé ou exclusif).
• Interact : interaction en cours (souvent bloque le déplacement).
• Hurt : touché, éventuellement avec recul.
• Dead : plus d’inputs, déclenche la défaite.

Règles à préciser

• États exclusifs vs superposés : ex. “tir possible en courant” (superposé) ou “tir bloque le mouvement” (exclusif).
• Transitions forcées : ex. “si hp <= 0 alors Dead immédiatement”.
• Fenêtres d’annulation : ex. “le saut peut annuler Run à tout moment, mais pas Hurt”.

Conditions de victoire/défaite : règles système

Victoire

Définissez des conditions testables, combinées par AND/OR :

• Objectif : atteindre une zone, ramasser un item, vaincre un boss, survivre un temps.
• Contraintes : temps maximum, nombre de vies, score minimal.

Exemple : Victory = (reachExit == true) AND (keyCollected == true).

Défaite

• hp <= 0
• timeRemaining == 0
• fallOutOfWorld == true (chute hors niveau)

Précisez la conséquence : checkpoint, restart niveau, perte de ressource, écran de défaite, etc.

Feedback : rendre la règle perceptible

Chaque mécanique doit définir au minimum un feedback visuel et sonore (et haptique si supporté). Le feedback sert à confirmer l’entrée, l’état, et le résultat.

Checklist de feedback par action

• Déclenchement : son de saut, flash de tir, animation d’interaction.
• Échec (condition non remplie) : clic “vide”, icône grisée, son étouffé, vibration courte.
• Résultat : hit marker, particules d’impact, recul caméra léger, variation de pitch.
• État : couleur/outline en invulnérabilité, animation de chute, poussière à l’atterrissage.

Formalisation : tableaux de règles (format recommandé)

Utilisez un tableau par mécanique ou sous-mécanique. Colonnes recommandées : Entrée, Condition, Effet, Variables impactées, Priorité, Cas limites, Feedback.

Notation des valeurs clés : comment les écrire dans un GDD

Pour éviter les ambiguïtés, notez les valeurs avec unités et plages. Exemple :

• moveSpeed = 220 px/s (plage test : 180–260)
• jumpHeight ≈ 3.2 tiles (si vous raisonnez en tuiles)
• fireRate = 6 shots/s (donc cooldown = 0.167 s)
• range = 9 tiles ou projectileLifetime = 0.8 s
• iFrameDuration = 0.75 s

Astuce : si vous avez un paramètre dérivé, écrivez la formule pour aligner design et code. Exemple : cooldown = 1 / fireRate.

Livrable 1 : fiche “mécanique” réutilisable (template)

Copiez-collez ce gabarit dans votre GDD pour chaque mécanique.

Fiche mécanique (template)

• Nom : …
• But gameplay : …
• Entrées : …
• États requis / interdits : …
• Règles (table) : …
• Paramètres : …
• Priorités / conflits : …
• Collisions concernées : …
• Cas limites : …
• Feedback : visuel / sonore / haptique
• Critères de test : scénarios reproductibles

Livrable 2 : exemples remplis (2 mécaniques courantes)

Exemple A — Mécanique : Saut (avec coyote time + jump buffer)

But gameplay : permettre au joueur de franchir des obstacles avec une tolérance d’exécution (plus fluide, moins punitif).

États : autorisé depuis Idle, Run, Fall (via coyote). Interdit depuis Dead, Hurt (si non annulable).

Paramètres :

• jumpVelocity = 520 px/s
• gravity = 1500 px/s²
• coyoteTime = 0.10 s
• jumpBuffer = 0.10 s
• maxJumps = 1
• jumpCutMultiplier = 0.55 (si saut variable au relâchement)

Critères de test :

• Appuyer sur saut 0,05 s après avoir quitté une plateforme : le saut doit partir (coyote).
• Appuyer sur saut 0,05 s avant d’atterrir : le saut doit partir à l’atterrissage (buffer).
• Relâcher rapidement : saut plus bas (si saut variable).
• Toucher un plafond : arrêt vertical immédiat, pas de traversée.

Exemple B — Mécanique : Tir (semi-auto avec cooldown et munitions)

But gameplay : permettre une attaque rythmée, lisible, avec gestion simple de ressource.

États : autorisé depuis Idle, Run, Jump, Fall. Interdit depuis Dead. Option : interdit pendant Interact.

Paramètres :

• fireRate = 4 shots/s (donc cooldown = 0.25 s)
• ammoMax = 12, ammo = 12
• reloadTime = 1.2 s (si rechargement)
• damage = 1
• projectileSpeed = 900 px/s
• range = 10 tiles (ou projectileLifetime = 0.7 s)
• shotSpread = 0° (si précis) ou ex. ±3°

Critères de test :

• Spam du bouton tir : ne doit jamais dépasser 4 tirs/seconde.
• Tir avec 0 munition : aucun projectile, feedback d’échec.
• Rechargement : tir impossible pendant la durée définie (si règle choisie).
• Projectile : disparaît à la portée/fin de vie, collision correcte avec murs/ennemis.

Priorités globales (exemple de règle de résolution)

Si votre jeu autorise plusieurs actions simultanées, écrivez une règle simple et stable. Exemple :

Cas limites : mini-checklist à intégrer à chaque fiche

• Entrées simultanées : que se passe-t-il si Fire et Interact sont pressés au même frame ?
• Spam : que se passe-t-il si le joueur martèle une touche ? (buffer, ignore, file d’attente)
• Changement d’état : si le joueur est touché pendant une action, l’action est-elle annulée ?
• Collision extrême : vitesse élevée, coins, plateformes traversables.
• Ressource à zéro : ammo/énergie, cooldown, surcharge.
• Feedback d’échec : toujours présent pour éviter l’impression de bug.