Le moteur de gameplay d’un jeu est un morceau de code qui s’occupe de reproduire les mécaniques du jeu telles que définies par le game design. La mise à jour 1.1 de TURN Episode 1 introduit un nouveau moteur de gameplay, réécrit depuis zéro.
Dans ce deuxième billet (lire le premier), je vais raconter comment nous avons déterminé le nouveau fonctionnement du jeu.
Se mettre d’accord sur le comportement du jeu
Après avoir passé trop de temps à tenter de faire fonctionner correctement l’ancien moteur, ayant réalisé tous les problèmes qui restaient à résoudre, cinq d’entre nous nous sommes enfermés dans une salle pour déterminer une bonne fois pour toute chaque cas problématique et y apporter une réponse.

Quelques cas pas évidents
Nous avons commencé par énumérer sur un tableau blanc quelques cas que nous avions rencontrés en jouant et dont le comportement semblait étrange voire faux. Et devinez quoi : c’est à ce moment qu’on a réalisé qu’on n’était pas d’accord sur quel comportement était le bon. TURN est un jeu de type casse-tête, pas une simulation physique, un niveau est une grille dans laquelle se trouve des objets et on ne peut pas se retrouver avec un objet arrêté entre deux cases. Parfois, comme je le disais dans le précédent billet, il faut simplement prendre une décision sur le comportement du jeu, il n’y a pas toujours une solution supérieure.
Au fur et à mesure que nous avancions, nous éditions une page de wiki projetée sur le mur avec les décisions prises.
Les nouvelles règles
Nous sommes arrivés à la conclusion que le jeu devait être découpé en tours successifs au cours desquels chaque objet pouvait se déplacer au maximum d’une case (dans le jeu final, chacun de ces tours dure 1/6ème de seconde). Voici un extrait du déroulement d’un tour de jeu :
- Gravité : En partant du bas de la salle (en fonction de la gravité), chaque objet qui n’est pas supporté par un élément solide à l’arrêt descend d’une case
- Artefact : Si Kurt (ou Camila) se trouve sur l’artefact de fin de niveau, le niveau est gagné immédiatement
- Écrasement : Si un objet non solide vivant (Kurt / Camila, ennemi) se trouve à présent sur une même case qu’un élément solide, il meurt et est retiré de la salle
- Atterrissage : géré du bas vers le haut
- Caisse : Si une caisse vient de chuter d’une case et se trouve à présent sur un objet solide à l’arrêt, elle lui inflige un choc et passe en état arrêt si l’objet sur lequel elle repose existe encore.
- Caisse cassable : Si une caisse cassable vient de chuter d’une case et se trouve à présent sur un objet solide à l’arrêt, elle s’inflige un choc et en inflige un à l’autre. Elle passe en état arrêt si l’objet sur lequel elle repose existe encore.
- Rocher : Si un rocher vient de chuter d’une case et se trouve à présent sur un objet solide à l’arrêt, il lui inflige un choc, et si l’objet survit, le rocher commence à rouler
Il y a quelques autres étapes mais ce serait trop long de tout détailler ici.

L'équipe travaillant d'arrache-pied sur un cas problématique
Une fois que nous avions couvert un échantillon suffisamment large de situations et que nous avions mis en place des règles simples (mais précises), nous nous sommes mis autour d’une table, avons coupé plusieurs petites cartes pour chaque type d’objet du jeu, et nous avons commencé à tester nos règles.
Quand nous avons commencé la réunion, je me demandais vraiment si nous arriverions à détailler un comportement cohérent pour les rochers qui roulent. Et nous avons réussi. La prochaine fois, on fera attention à faire ce genre de réunions avant de commencer à programmer le jeu. On aurait pu économiser pas mal de temps et de sueur !
Share on Facebook