Planifiez un jeu de plateforme coopératif avec des règles claires

Précisez une condition commune, vérifiez l’arrivée des deux joueurs et n’étendez le niveau qu’après validation de la récupération.

Seele Editorial TeamMis à jour 14 novembre 2026

Un jeu de plateforme coopératif a besoin d’une condition commune claire : ce que fait chaque joueur, le moment où leurs actions se combinent et ce qui arrive en cas d’échec. Définissez cette petite boucle avant de demander un long niveau. Twinspan Relay est un exemple de conception original sur papier, pas un prototype existant ni un test de jeu. Sa fenêtre d’association de 1,5 seconde et son pont de 4 secondes facilitent l’examen des règles ; ces durées ne sont pas des valeurs d’équilibrage mesurées.

Deux messagers se préparent à sauter vers des plateformes appariées au-dessus d’un ravin côtier.
Les deux joueurs partent d’un point de contrôle commun et se dirigent chacun vers sa plateforme de l’autre côté du même gouffre.

Définissez le contrat coopératif

Décrivez la boucle d’action comme une séquence d’états, pas par une consigne vague telle que « faites-les coopérer ». Dans Twinspan Relay, les deux messagers ont les mêmes mouvements de course et de saut. À chaque relais, A doit toucher la plateforme bleue et B la plateforme ambre. Le premier atterrissage correct lance un délai commun. Si le second joueur atteint sa plateforme correspondante à temps, un pont temporaire apparaît ; les deux doivent le traverser avant sa disparition. Le point de contrôle n’avance que lorsque tous deux l’atteignent.

Le contrat définit aussi l’échec. Une mauvaise plateforme, une chute ou l’expiration du délai renvoie les deux joueurs à leur dernier point de contrôle commun et supprime le pont. Dans cet exemple pédagogique, personne n’attend seul ni ne perd de vie. Si l’un atteint le point de contrôle pendant que l’autre traverse encore, il y reste inactif jusqu’à l’arrivée des deux. La progression dépend ainsi de l’état de l’équipe.

Action du joueurChangement de l’état partagéConséquence
Le premier joueur atterrit sur la plateforme qui lui est attribuéeLance une fenêtre d’association de 1,5 seconde et enregistre la plateforme occupéeL’autre joueur peut encore compléter la paire
Le second joueur atteint sa plateforme correspondante avant la fin du délaiValide la paire et ouvre un pont praticable pendant 4 secondesLes deux joueurs avancent vers le même point de contrôle
Les deux joueurs atteignent le point de contrôle avant la fermeture du pontFait avancer le point de contrôle commun et efface le délai du relaisPrésente la paire de plateformes suivante
Mauvaise plateforme, chute, atterrissage tardif ou expiration du pontEfface la paire active et renvoie les deux joueurs au point de contrôle précédentPermet à l’équipe de réessayer le même relais

Le tableau rend visibles le timing et la récupération pour les deux joueurs. Avant d’ajouter des décors ou des mécaniques, vérifiez que chaque ligne indique un déclencheur, un changement d’état et l’état suivant. Si le prompt dit seulement que « le pont s’ouvre », il doit également préciser quand il se ferme et comment l’équipe récupère.

Prompt 1 : écrivez les règles communes

Utilisez un bref prompt de contrat pour fixer le nombre de joueurs, le format d’écran, l’objectif commun et la règle de récupération. Demandez d’énumérer les hypothèses ouvertes plutôt que de laisser le créateur combler silencieusement les lacunes.

Planifie un jeu de plateforme coopératif local à deux joueurs sur écran partagé. Les deux peuvent courir et sauter avec les mêmes mouvements ; aucun n’a de capacité spéciale. L’objectif commun est de franchir trois relais de plateformes appariées et d’atteindre la sortie ensemble.

À chaque relais, A doit atterrir sur la plateforme bleue et B sur la plateforme ambre. Le premier atterrissage correct déclenche une fenêtre d’association de 1,5 seconde. Si le second joueur atterrit sur la plateforme qui lui est attribuée avant l’expiration, un pont continu et praticable apparaît pendant 4 secondes. Les deux doivent atteindre le point de contrôle commun suivant avant la fermeture du pont. Une mauvaise plateforme, une chute, le dépassement de la fenêtre ou l’expiration du pont renvoie les deux joueurs au dernier point de contrôle partagé et efface le pont et le délai actifs. Le point de contrôle n’avance que lorsque les deux l’atteignent. La sortie s’ouvre lorsque chacun atteint sa plateforme finale attribuée. La réinitialisation ramène les deux au départ et efface tous les délais.

Renvoie un tableau d’états comprenant les positions des deux joueurs, les plateformes attribuées, le délai d’association, le délai du pont, le point de contrôle commun et l’état de la sortie. Énumère les hypothèses restantes. Garde le plan local et sur un écran partagé ; n’ajoute ni réseau, ni pouvoirs asymétriques, ni vies, ni événements aléatoires.

Ce prompt est un modèle de conception, pas le compte rendu d’une partie. Demandez au créateur d’afficher les états nécessaires à l’examen. Si le schéma des commandes attribue des boutons différents aux deux manettes, vérifiez que chacun garde les mêmes actions et que les instructions identifient les entrées de chaque joueur avant le premier gouffre.

Rédigez le prompt d’un seul gouffre

Transformez le contrat en une courte rencontre avec un départ, une interaction et un point de contrôle reconnaissable. Utilisez une seule paire de plateformes et un seul gouffre pour limiter les causes possibles d’un résultat confus. Précisez ce que les joueurs voient avant le saut, comment le premier atterrissage déclenche le chronomètre et comment le pont indique le temps restant.

Dans Twinspan, les deux plateformes brillent de couleurs différentes sur des rebords opposés. Le premier atterrissage valide lance la fenêtre de 1,5 seconde ; le second fait apparaître le pont. Le passage temporaire doit être assez large pour être perçu comme un chemin, et le point de contrôle de l’autre côté reste inactif jusqu’à l’arrivée des deux messagers.

Deux messagers atterrissent sur les plateformes correspondantes tandis qu’un pont de pierre commun se forme.
Le pont confirme la réussite de la paire ; sa durée de quatre secondes donne aux deux joueurs un nouvel objectif commun.

Prompt 2 : demandez un relais

Limitez la demande du premier prototype. Incluez la réinitialisation et un indicateur d’état visible en plus des déplacements : tous deux font partie de la boucle coopérative.

Crée un petit prototype local de plateforme coopératif à deux joueurs selon ce contrat. Utilise un écran partagé et deux manettes ; donne à chacun les mêmes mouvements de course et de saut. Construis un seul gouffre franchissable avec un rebord de départ sûr, une plateforme bleue pour A, une plateforme ambre pour B et un point de contrôle commun de l’autre côté.

Montre les deux joueurs, la couleur de leur plateforme attribuée, la fenêtre d’association de 1,5 seconde après le premier atterrissage correct et un indicateur clair des 4 secondes du pont lorsque les deux plateformes correspondantes sont occupées. Le pont doit former une surface continue praticable. Fais avancer le point de contrôle seulement lorsque les deux le touchent avant la fermeture du pont. Si un joueur tombe, atterrit sur la mauvaise plateforme, dépasse la fenêtre ou manque le délai du pont, renvoie les deux au point de contrôle précédent et efface l’état actif. Ajoute une réinitialisation qui les ramène au départ.

Utilise une caméra assez large pour montrer les deux joueurs et tout le gouffre. Ajoute un panneau de commandes compact. N’ajoute ni autre gouffre, ni objet à collecter, ni ennemi, ni pouvoir spécial, ni événement aléatoire, ni jeu en ligne. Indique quelles règles ont été implémentées et lesquelles restent à vérifier ; ne présume pas que cette demande a produit un prototype satisfaisant.

Une bonne spécification ne garantit pas sa mise en œuvre. Si vous l’utilisez avec un outil de création, vérifiez que l’indicateur d’état change à chaque déclencheur et que le second joueur peut agir pendant que le premier attend. Conservez le prompt exact et la version du prototype avant de comparer les changements ultérieurs.

N’allongez le parcours qu’après le premier relais

Lorsqu’une vraie version d’un seul gouffre réussit les vérifications avec chaque joueur dans les deux rôles, prolongez le parcours sans modifier les règles de base. Réutilisez les couleurs, les délais, la durée du pont, la réinitialisation et le comportement du point de contrôle. Ne modifiez qu’un élément géométrique à la fois — par exemple la largeur du gouffre ou la hauteur d’atterrissage — afin de mieux localiser les problèmes ultérieurs.

ÉtapeGarder inchangéNe modifier que lorsque
Rencontre avec un seul gouffreDeux joueurs, une paire de plateformes attribuées, réinitialisation et point de contrôle communsLes deux ordres d’arrivée et un cas d’échec respectent le contrat
Parcours de trois relaisMêmes mouvements, attribution des plateformes, délais et récupérationLe relais suivant ne commence qu’après l’avancement du point de contrôle commun
Sortie finaleObjectif visible de chaque joueur et condition d’arrivée communeLa porte s’ouvre seulement lorsque chacun atteint sa plateforme finale
Itération du décorCollisions, indicateurs, cadrage de la caméra et logique du relaisUn seul changement visuel ou spatial peut être comparé avec la même séquence

Le prompt d’extension doit conserver ces invariants et demander un résumé du parcours montrant le relais actif et le point de contrôle. N’ajoutez pas une capacité simplement parce que le gouffre suivant est plus difficile ; décidez d’abord si le défi porte sur le timing, la communication ou la distance de saut.

Prompt 3 : ajoutez deux autres relais

Après avoir examiné la version à un gouffre selon ses critères d’acceptation, prolonge le même parcours coopératif local avec deux autres relais de plateformes appariées et une sortie finale. Conserve les mêmes mouvements, l’attribution bleu/ambre, la fenêtre d’association de 1,5 seconde, le pont de 4 secondes, le point de contrôle commun, la récupération après échec ou chute et le comportement de réinitialisation. Ne change que l’espacement des gouffres, la hauteur d’atterrissage et le décor entre les relais.

Garde les deux joueurs visibles lorsqu’un signal d’association apparaît. Affiche le point de contrôle commun actuel, le relais actif et indique si chaque joueur est avant le gouffre, sur sa plateforme, en train de traverser le pont ou au point de contrôle. La porte finale ne s’ouvre que lorsque les deux atteignent leur plateforme de sortie respective. Renvoie un plan compact du parcours et la liste des transitions d’état. N’ajoute ni réseau, ni nouveaux pouvoirs, ni ennemis, ni règles aléatoires. Si la version à un gouffre n’a pas été examinée, présente cette extension comme un projet et ne la marque pas comme vérifiée.

Vérifiez l’état des deux joueurs

Écrivez des séquences d’actions reproductibles avant de décider si un moment coopératif est clair. Notez les positions de départ, quel joueur atterrit en premier, le délai entre les atterrissages, l’apparition du pont et l’avancement du point de contrôle commun. Les valeurs ci-dessous sont un calcul sur papier pour Twinspan Relay, pas des observations d’un prototype jouable.

Au premier relais, A atterrit sur la plateforme bleue à t=0 ; B atterrit sur la plateforme ambre à t=1.0 . Une seconde est dans la fenêtre d’association de 1,5 seconde : le pont s’ouvre donc à t=1.0 et expire à t=5.0 . Les deux joueurs atteignent le point de contrôle à t=3.2 , avant la fermeture ; l’état de l’exemple avance donc. Au deuxième relais, B arrive à t=1.9 , après l’expiration de la fenêtre d’association à t=1.5 . Aucun pont n’apparaît et les deux retournent au point de contrôle commun précédent.

Séquence d’actionsÉtat commun attenduVérification
A atterrit à 0,0 s ; B à 1,0 s ; les deux atteignent le point de contrôle à 3,2 sLa paire réussit ; le pont reste ouvert de 1,0 à 5,0 s ; le point de contrôle commun avancePlateformes correspondantes, déclenchement du délai, durée du pont et arrivée commune
A atterrit à 0,0 s ; B à 1,9 sLe délai expire à 1,5 s ; le pont n’apparaît pas ; les deux sont réinitialisésL’arrivée tardive n’ouvre pas le pont et ne permet pas à un joueur d’avancer seul
Un joueur atterrit sur la mauvaise couleurLe relais échoue et les deux reviennent au dernier point de contrôle communL’attribution des plateformes est lisible et appliquée de façon cohérente
Les deux réussissent leur plateforme, mais un joueur tombe avant le point de contrôleLe pont disparaît ; aucun ne conserve de progression individuelleLa récupération de l’échec reste commune
Un seul joueur atteint le point de contrôle avant la fermeture du pontLe point de contrôle reste inactif ; à l’expiration, les deux sont renvoyés en arrièreUn joueur ne peut pas faire avancer l’équipe seul
Les deux atteignent leurs plateformes finales appariéesLa sortie s’ouvre et le parcours commun est terminéLa condition de fin exige les deux joueurs
Réinitialisation pendant n’importe quel relais actifLes deux retournent au départ ; les délais et les ponts sont effacésLa réinitialisation supprime tout état partagé antérieur

Ces états attendus sont des critères d’acceptation à appliquer plus tard à un vrai prototype. Ce ne sont pas des preuves de test. Un journal utile indique la version des règles, les deux manettes, les actions, les temps, les positions, l’état du relais, le point de contrôle et le résultat. Si le résultat diffère, gardez la séquence identique pendant l’enquête.

Les deux messagers atteignent ensemble la sortie ouverte après avoir traversé un pont temporaire.
L’objectif commun n’est atteint que lorsque les deux messagers franchissent le dernier relais et occupent les plateformes de sortie qui leur sont attribuées.

Corrigez l’échec sans modifier toute la boucle

Lorsqu’une paire échoue, repérez le premier état qui diffère de la séquence attendue. Si un joueur n’a pas vu l’attribution de plateforme, améliorez l’indicateur ou le cadrage avant de modifier le délai. Si le bon atterrissage est enregistré mais que le pont ne s’ouvre pas, vérifiez la correspondance des plateformes et le déclenchement du délai. Si un joueur avance seul, corrigez la condition du point de contrôle avant d’ajouter du niveau.

Dans une vraie révision, ne changez qu’une cause à la fois et rejouez la même séquence. Un réglage de caméra ne devrait pas modifier aussi la fenêtre d’association ; éclairer davantage une plateforme ne devrait pas changer la règle de réinitialisation. Notez séparément l’observation, la cause supposée et la modification effectuée. Sans prototype ni observation de joueurs, présentez une correction proposée comme une idée de conception, pas comme une amélioration démontrée.

Prompt 4 : demandez une révision ciblée

À partir de la séquence d’actions réelle et du journal d’états que je fournirai, repère le premier point où le relais coopératif diverge du contrat écrit. Distingue une erreur d’implémentation d’un problème de visibilité, de caméra ou de commandes. Propose une petite modification, indique ce qui doit rester inchangé et réécris la même séquence pour la rejouer.

N’invente ni commentaires de joueurs, ni résultats de test, ni révision réussie. En l’absence d’un journal d’observation, donne une liste de causes possibles sans affirmer que l’une d’elles s’est produite. Conserve le point de contrôle commun, l’attribution des plateformes, les délais et les règles de réinitialisation, sauf si les éléments disponibles indiquent précisément lequel changer.

Utilisez un petit scénario multijoueur comme point de départ

La page Multiplayer Game Maker de SEELE décrit la planification du nombre de joueurs, des rôles, des objectifs communs, des règles d’interaction et d’un scénario bref. Elle précise aussi que le jeu en ligne exige une implémentation spécifique, le réseau, la synchronisation, l’hébergement et des tests. Ces conseils aident à cadrer le concept coopératif, mais ils ne vérifient ni les commandes locales de Twinspan Relay ni ses durées exactes. Avant d’étendre le mode, examinez les changements d’état des deux joueurs dans le résultat réel.

Commencez par écrire l’objectif partagé et une séquence d’acceptation. Pour présenter ce bref concept multijoueur, utilisez Multiplayer game maker. Servez-vous de la page comme référence de planification et vérifiez le comportement nécessaire dans le projet que vous créez.

Foire aux questions

Combien de joueurs prévoir pour un premier jeu de plateforme coopératif ?

Commencez par deux joueurs sur un écran partagé. Cela suffit pour vérifier que chacun a une action utile et que le mouvement de l’un change un résultat commun. N’ajoutez d’autres joueurs que lorsque l’attribution des plateformes, le délai, le point de contrôle et les règles de fin restent compréhensibles avec le premier duo.

Les joueurs coopératifs ont-ils besoin de capacités différentes ?

Non. Deux joueurs peuvent se coordonner par le timing, la position ou des objectifs communs avec les mêmes mouvements. Des pouvoirs différents ajoutent un système à expliquer ; ne les introduisez que lorsque la boucle de base fonctionne et que la nouvelle capacité crée une décision que personne ne peut résoudre seul.

Que se passe-t-il si un seul joueur atteint le point de contrôle ?

Dans la conception de Twinspan, le point de contrôle n’avance que lorsque les deux joueurs l’ont atteint. Si le pont expire avant, les deux retournent au dernier point de contrôle commun. L’arrivée individuelle ne laisse donc pas l’autre joueur derrière et ne crée pas d’état sans solution pour l’équipe.

Un créateur de jeux IA peut-il garantir le jeu coopératif en ligne ?

Aucun prompt ne prouve à lui seul que le réseau, la synchronisation, l’hébergement ou le jeu entre plusieurs appareils fonctionnent. Une page de planification aide à définir le nombre de joueurs et les règles d’interaction, mais un projet réel doit encore être implémenté et testé sur les appareils et dans les conditions réseau visés. Distinguez le jeu local sur écran partagé des affirmations de jeu en ligne.

Les délais d’association et du pont ont-ils été testés ?

Non. La fenêtre d’association de 1,5 seconde et la durée de 4 secondes du pont sont des valeurs illustratives de l’exemple sur papier. Elles montrent comment préciser les durées dans un prompt. Fondez leur ajustement sur des actions observées dans un vrai prototype et consignez séparément chaque révision.

SEELE AI

Transformez ce guide en projet jouable.

Commencez par un brief précis, puis développez votre idée dans Seele AI Workspace.

Commencer à créer