WOLF : un FPS en raycasting sur game boy color! (Interview du développeur)

Bonjour les amis,

C'est un plaisir de vous retrouver sur le blog!

Comme je vous l'avais annoncé le 11 août dernier, j'ai reçu avant sa sortie le dernier jeu de Shane Mc Cafferty, alias EGVROOM, intitulé Wolf et toujours édité par Thalamus Digital.

C'est d'ailleurs Andy de Thalamus qui me l'a envoyé et je le remercie.

Le jeu est disponible depuis le jeudi 13 août au tarif d'1.99$ sur itch.io

C'est un jeu qui n'aura pas d'édition physique car c'est un jeu court mais qui bénéficie tout de même d'une excellente rejouabilité par son fonctionnement procédural et son côté défouloir.

L'ami gbrew nous a proposé une review très intéressante donc n'hésitez pas à la lire ici.

Mon ressenti est que j'ai beaucoup aimé cette expérience un peu stressante surtout quand vous vous retrouvez avec un seul point de vie et que la moindre erreur peut signer l'arrêt définitif de votre progression.

Bien sûr il y a parfois quelques ralentissements mais l'optimisation a été faite au maximum pour les diminuer.

Nous sommes sur du raycasting sur game boy color tout de même, il me paraît important d'insister sur ce point car cela reste une prouesse rarissime. En dehors de projets légendaires comme le prototype de Tyrannosaurus Tex (réédité par Piko Interactive), rares sont les développeurs à s'être attaqués à un tel défi sur le hardware 8-bits de Nintendo. C'est ce qui rend la démarche derrière WOLF d'autant plus fascinante.

Il fallait donc bien creuser tout cela avec son talentueux créateur que je remercie pour avoir répondu avec autant de précision à mes nombreuses questions.

Sur ce, avant de nous retrouver à la fin de l'été pour un petit live dédié pour en plus en gagner un exemplaire numérique (plus de précisions seront apportées prochainement), je vous souhaite une agréable lecture 😊

***

Alex : Salut Shane et merci de répondre à mes questions. Pour commencer pourrais-tu me dire comment t'est venue l'idée de développer un FPS en raycasting spécifiquement sur Game Boy Color ? Y a-t-il un jeu en particulier qui t'a inspiré ou convaincu que c'était possible ?

Shane : Depuis que j'ai commencé à créer des jeux Game Boy il y a 2 ans, j'ai toujours voulu faire un moteur de raycasting. J'ai essayé plusieurs fois au cours des deux dernières années et j'ai abandonné à chaque fois. Il y a au moins 5 dossiers de projets abandonnés sur mon Mac ! :) Je suis vraiment très heureux d'avoir enfin réussi à en faire un. Si tu remontes dans mon fil sur les réseaux sociaux, tu pourras voir quelques-unes de ces différentes tentatives.

Alex : Pour le développement, tu es passé par GBDK ?

Shane : Comme d'habitude. J'utilise GBDK 2020 et une version modifiée du moteur de GBStudio. Toutes mes scènes sont configurées dans GBStudio tandis que la boucle de jeu principale tourne en code C natif. C'est un joyeux bazar ! Lol.

Alex : La GBC n'a jamais été conçue pour la 3D ni pour gérer un framebuffer. À quel moment du développement t'es-tu dit : "Le matériel est contre ça, mais je vais trouver une parade" ? Quel a été ton plus gros obstacle ?

Shane : Je savais que c'était possible. Le fait que cela semble être une chose difficile et absurde à faire m'a donné encore plus envie de le tenter ! Je suis quelqu'un de très têtu. Le plus gros obstacle a été le nombre d'images par seconde (FPS). Je ne connais pas l'Assembleur (ASM), j'ai donc dû optimiser mon code C du mieux que je pouvais.

Alex : Beaucoup de gens confondent encore le raytracing moderne et le raycasting classique. Comment expliquerais-tu simplement ce qu'est le raycasting 8-bits à quelqu'un qui découvre le projet ?

Shane : C'est difficile à expliquer ici en un seul paragraphe. J'ai récemment essayé de le faire dans un post sur les réseaux sociaux. Je mets le lien ci-dessous (NDA : vidéo en anglais).

En bref — Raycasting vs Raytracing :

Le raycasting est la technique pionnière popularisée par Wolfenstein 3D : le moteur projette un rayon virtuel par colonne d'écran pour calculer la distance des murs et bâtir une illusion de relief à partir d'une carte en 2D. Une astuce mathématique géniale pour afficher de la 3D sur un processeur 8-bits, à ne pas confondre avec le raytracing moderne qui simule le comportement réel de la lumière et des reflets !

(NDA : pour aller plus loin, n'hésitez pas à consulter ce site très intéressant.

How a Raycasting engine works in 2 minutes 8 seconds. !:) #indieDev #gameDev #retroGaming #gameBoy

[image or embed]

— EGVroom (@egvroom.bsky.social) 12 août 2026 à 00:38

Alex : La gestion des éclairages, la fluidité des déplacements et la réactivité sont impressionnantes. Même si de légers ralentissements apparaissent très ponctuellement quand l'écran est chargé, comment as-tu structuré ton moteur pour limiter au maximum ces baisses de framerate ?

Shane : Le moteur fait beaucoup de choses pour minimiser les baisses de framerate. En voici quelques-unes :

• Nous ne dessinons que la moitié supérieure de l'écran (le bas est un miroir du haut).
• Nous ne dessinons que ce qui a changé depuis la dernière image (frame).
• Nous précalculons (cache) chaque opération mathématique possible dans des tables de correspondance (LUT) pour éviter de faire les calculs à la volée.
• Nous ne rafraîchissons l'écran que si c'est absolument nécessaire (pour garder la lecture des commandes aussi fréquente que possible).

Et plein d'autres choses encore.

Alex : Pour afficher la 3D, le raycasting dessine l'écran colonne par colonne. Comme la GBC est trop limitée pour calculer la hauteur des murs en temps réel, tu as donc fortement compté sur les tables précalculées (LUT - Look Up Tables) ?

Shane : Oui, énormément de tables de correspondance.

Une table de correspondance (ou lookup table, LUT) en raycasting est un tableau de valeurs précalculées qui remplace des calculs mathématiques lourds par un simple accès en mémoire.

Alex : La GBC fonctionne par tuiles (tiles 8x8). Comment as-tu contourné cette contrainte pour afficher une image 3D fluide ? Modifies-tu la VRAM à la volée pendant le H-Blank ou réutilises-tu un jeu de tuiles dynamique ?

Shane : Oui, nous mettons à jour la VRAM avec les tuiles nécessaires pour dessiner l'image suivante. Nous faisons beaucoup de choses pour réduire au minimum le nombre de tuiles à créer (voir les réponses précédentes). Nous utilisons aussi un tampon (buffer) pour construire l'écran, afin d’empêcher le joueur de voir le rafraîchissement.

Alex : La GBC impose une limite de 8 palettes de 4 couleurs pour le décor. Comment as-tu géré cette contrainte pour offrir des environnements variés et colorés sans dépasser les limites d'affichage ?

Shane : En réalité, l'écran de jeu n'utilise que 4 palettes : 2 couleurs et une variante plus sombre de chacune pour la profondeur. Ça donne l'impression d'en avoir plus grâce aux dégradés utilisés pour le ciel et le sol. Ces dégradés sont créés par une interruption de ligne de balayage qui change la couleur 0 des palettes tous les 8 pixels.

Alex : Le moteur affiche un effet d'assombrissement selon la distance. Comment as-tu géré le mappage des textures et les dégradés de lumière sans surcharger le processeur ?

Shane : La couleur utilisée dépend simplement de la hauteur de la colonne (les petites colonnes sont plus éloignées). C'est aussi simple que ça. Vous verrez quelques erreurs graphiques lorsque deux colonnes se disputent la palette « lointain/proche », mais ce n’est pas trop visible et je pense que le résultat global en vaut la peine.

Alex : Quel type d’algorithme as-tu utilisé pour générer les plans des labyrinthes ? Comment l’as-tu adapté pour que la génération des niveaux soit quasi instantanée ?

Shane : C’est juste du code vraiment moche ! :) Rien d’extraordinaire. Il ne se passe rien d’autre au démarrage du jeu, on peut donc se permettre d’avoir du code un peu brouillon pour générer les niveaux. Je l’ai simplement peaufiné encore et encore jusqu’à ce qu’il crée des niveaux acceptables. Je suis sûr qu’il en existe un bien plus ingénieux que j’aurais pu utiliser.

Alex : Comment fonctionne le système de générateur aléatoire (RNG) pour générer la disposition des salles et le placement des ennemis ? Te bases-tu sur les actions/le timing du joueur, des minuteries internes ou des valeurs fixes ?

Shane : Il s'agit simplement du générateur de nombres aléatoires (RNG) du GBDK 2020, dont la valeur de départ est définie lorsque le joueur lance la partie.

Alex : Concernant l'IA des ennemis, certains patrouillent tandis que d'autres nous traquent activement. Comment as-tu structuré ces différents comportements d'IA et le calcul d’itinéraires sans surcharger le processeur ?

Shane : C’est en fait très simple. Ils errent simplement jusqu’à ce qu’ils aient le joueur dans leur champ de vision. Ensuite, ils se dirigent directement vers lui. Ils décident de tirer de manière aléatoire en fonction de la difficulté et ne tirent jamais dans le dos d’un joueur.

Alex : Sachant que la sortie E (Exit) ne se débloque qu'une fois le dernier ennemi éliminé, comment gères-tu le suivi des ennemis et le déclenchement de la fin de niveau dans la mémoire RAM très limitée de la console ?

Shane : Le 'E' est simplement placé à la dernière position XY de la carte où le dernier ennemi est mort. Comme nous connaissons la position XY du joueur, c'est facile à suivre. Les ennemis apparaissent à des emplacements vides aléatoires sur la carte, pas trop près du joueur.

Alex : La bande-son composée par sloopygoop est incroyable et les bruitages apportent une vraie dynamique. Sur GBC, le traitement du son partage les ressources système : la lecture de la musique et des effets sonores a-t-elle ajouté une charge CPU critique qui risquait de ralentir le moteur ?

Shane : Je craignais que la musique ne fasse baisser le nombre d’images par seconde, mais cela n’a pas été le cas. Sloopy est brillant et il a livré un excellent travail audio, comme toujours.

Alex : Quand on pousse une console 8-bits dans ses retranchements, il faut faire des choix. À quelles fonctionnalités, idées de gameplay ou détails visuels as-tu dû renoncer à regret pour préserver les performances ?

Shane : C'était en fait la partie la plus intéressante de tout le projet. C'était amusant de gérer la partie technique, mais au fond, je suis un game designer. J'ai adoré le défi de rendre amusant un FPS extrêmement limité. Je savais que ce ne serait pas un jeu rapide et frénétique, donc tout le game design pousse le joueur vers une expérience plus calculée et tendue. J'espère que c'est une expérience courte, peaufinée, sous tension, avec un vrai sentiment de "juste une dernière partie". Ce n'est pas QUAKE ni DOOM. C'est quelque chose de différent.

Alex : Est-ce que cette expérience sur WOLF te donne envie d'explorer d'autres genres réputés "impossibles" sur 8-bits ?

Shane : Peut-être. Je pense qu'un rendu de type Mode 7... est possible.

A suivre...😉

Rendez-vous en Live ce samedi 29 août à 21h20 !

Pour prolonger la découverte et voir ce que le jeu a dans le ventre en direct, je vous donne rendez-vous ce samedi 29 août à 21h20 sur YouTube ! Je serai accompagné par le grand Éric Quaranta (Studio 40A) pour analyser cette prouesse technique. Une clé numérique de WOLF GBC sera également mise en jeu (tirage au sort en direct ou en différé durant le week-end) !