The Programming of Patrick's Parabox - Patrick Traynor (ThinkyCon 2025)

Patrick Traynor présente une présentation éclair à ThinkyCon 2025 sur les aspects intéressants de la programmation derrière le développement de Patrick's Parabox.

• Parabox est un jeu Sokoban où les boîtes peuvent contenir d'autres boîtes. • Les boîtes peuvent être poussées à l'intérieur et à l'extérieur les unes des autres, les imbriquant dans n'importe quelle configuration. • Certaines boîtes peuvent se contenir directement, ce qui permet d'entrer et de sortir à plusieurs reprises tout en conservant la même logique Sokoban.

• Au lieu d'un seul tableau bidimensionnel, il y a un tableau 2D pour chaque boîte du jeu. • Cela forme un tableau 2D de pointeurs vers des tableaux 2D. • Les emplacements aux bords se connectent les uns aux autres, et les niveaux récursifs utilisent la même structure, une boîte se référant à elle-même.

La présentation pose la question de savoir comment rendre effectivement une scène construite sur cette structure de données imbriquée.

Tout est rendu en coordonnées d'écran, ancré à un seul rectangle de référence représentant la vue actuelle.

• Une fonction appelée draw block dessine un bloc spécifique et tous ses enfants dans un rectangle donné. • Quand un enfant contient d'autres blocs, draw block est appelée à nouveau récursivement sur un rectangle plus petit. • La récursion s'arrête une fois que les blocs atteignent une taille d'un ou deux pixels.

• Pour rendre les objets plus grands en dehors de la vue actuelle, le carré est conceptuellement déplacé vers le niveau parent, puis au parent du parent, sortant trois niveaux au total. • Cela produit un rectangle beaucoup plus grand que l'écran ; la plupart n'apparaît pas à l'écran, mais il revient correctement au carré de départ.

Tant que chaque bloc est positionné par rapport à son parent, avec une seule coordonnée absolue (le carré d'ancrage), le rendu fonctionne correctement.

Pousser un bloc auto-contenant dans une autre boîte produit une animation de rétrécissement, et les bords de l'écran affichent un effet d'écrasement correspondant sur le monde extérieur.

• Le même algorithme draw block est utilisé, gardant tout par rapport au point d'ancrage. • Au lieu de dessiner le bloc bleu à sa vraie position, il est décalé vers le bas et mis à l'échelle (rétréci ou agrandi) avant d'appeler draw block à nouveau. • Les mêmes décalages de décalage et de croissance s'appliquent en sortant aux trois niveaux parents.

Le tri de profondeur est nécessaire pour s'assurer que le bloc qui se rétrécit est toujours dessiné au-dessus des autres blocs comme les blocs rouges.

Une citation du collègue développeur de Sokoban Marcos Donatini : « les coordonnées relatives égalent le bonheur absolu. »

Les grands objets nets en dehors de l'écran ne sont pas des graphiques vectoriels mais de grands PNG dimensionnés juste assez pour éviter le flou visible.

Une question du chat de Don demandait pourquoi l'algorithme sort trois niveaux parents au lieu d'un.

• Sortir d'un seul parent manquerait certains éléments, comme un jeton de joueur deux couches plus loin. • Sortir de deux couches couvrirait ce cas. • Trois n'est pas un nombre magique — c'est simplement assez de niveaux pour couvrir la plupart des situations courantes du jeu.

Un pseudo-code de l'algorithme de rendu expliqué a été montré aux spectateurs pour examen.

Certains niveaux ont une boîte contenant plusieurs copies d'elle-même ; l'algorithme draw block existant gère cela sans problème.

Initialement, un objet joueur apparaissait instantanément à toutes les copies avant de rétrécir, ce qui avait mauvaise apparence.

• Un mode ciseau (commun dans les API graphiques) a été utilisé pour limiter les enfants au carré. • Un cas spécial a été ajouté pour éviter de réduire le grand rectangle au centre ; au lieu de cela, une approche positionnelle uniquement a été utilisée qui est toujours limitée.

La correction a produit un effet d'apparence naturelle tout en préservant la réponse visuelle récursive à l'entrée du joueur, après de nombreux bogues pendant le développement.

Certains blocs se contiennent horizontalement retournés : sortir de la gauche fait apparaître à droite, et vice versa.

C'est simple à implémenter en échangeant les positions de sortie logiques.

• La fonction draw block gagne un paramètre vrai/faux pour savoir s'il faut dessiner un bloc et ses enfants retournés. • Implémenter cela correctement a nécessité des fragments de code dans tout le code base multipliant par -1 et retournant les drapeaux.

C'était inopinément difficile à programmer ; une fonction de rotation de 90° prévue a été abandonnée car le retournement horizontal seul était déjà assez difficile.

Une autre mécanique permet au joueur lui-même de contenir d'autres blocs.

Le joueur a été refactorisé pour être le même objet qu'un bloc, distingué uniquement par un drapeau booléen pour savoir s'il s'agit du joueur.

La logique Sokoban et la logique de rendu ont travaillé avec cette approche avec une relative facilité, en contraste avec la difficulté de la fonction de retournement horizontal.

Cette mécanique a été implémentée très tôt dans le développement.

Patrick démontre les outils d'éditeur de niveaux qu'il a construits, notant qu'ils ne sont pas strictement de la programmation mais s'y rapportent.

• Créer de nouveaux blocs et éditer leurs enfants. • Placer des blocs à l'intérieur d'autres blocs et les en retirer. • Un bloc référentiel est représenté simplement par la lettre R, agissant comme un pointeur.

• Un raccourci recharge le jeu et joue le niveau pour une itération rapide. • Les touches de retournement horizontal et vertical retournent un objet et tous ses enfants. • Un raccourci accède à la vue du niveau dans le hub, et les niveaux peuvent être réorganisés rapidement.

Un raccourci augmente ou diminue la taille des blocs, aidant à l'itération rapide de la difficulté et de la conception des puzzles.

Patrick remercie le public d'avoir suivi la présentation et partage ses coordonnées.

Une question du chat de Scrupulous demandait si quelqu'un d'autre a aidé avec le code.

• Le studio de portage Plastic Fern a géré les ports console du jeu, y compris la version Switch. • Il y avait quelques optimisations de performance pour le port, mais pas de changements énormes ; Patrick note qu'il n'est pas un expert en optimisation.

Patrick confirme que le code du jeu de base était entièrement son propre travail.