Du code commenté et documenté pour Noël

Il m’arrive assez souvent de pondre un article aux environs de Noël, voire le jour même, car c’est le moment où je suis en vacances. Comme plein de monde, en fait.

Comme promis le mois dernier, j’ai rangé et commenté le code de ma petite animation pour la vidéo-boulette de l’UTBM. C’est dans mon repository git, par ici : https://github.com/darkrecher/anim-tunnel-utbm

J’ai fini un autre mini-projet sur lequel j’avançais par intermittence depuis quelques mois : compléter un challenge de niveau « très difficile » sur le site CodinGame.

Il s’agit du challenge « Vox Codei – épisode 2 ». Des vilains carrés rouges se déplacent sur un quadrillage, il faut déterminer les coordonnées où placer des bombes pour les détruire.

Cliquez sur l’image pour accéder au challenge (il vous faut un compte CodinGame).

Boum !

J’en ai profité pour utiliser « aboard », ma librairie de code gérant des plateaux de jeux en 2D. Je vous en avais déjà parlé, fouillez dans mes anciens articles ou dans mes repo git si ça vous intéresse.

Petit conseil pour les jeux dans CodinGame

Que ce soit des challenges ou des combats de bots : respectez le rythme des échanges stdin/stdout entre votre code et le jeu. À chaque tour de jeu, récupérez bien les infos qui vous sont envoyées en appelant des fonctions « input() », même si vous n’en faites rien.

Dans Vox Codei, la situation du plateau de jeu, avec les positions des carrés rouges, vous est transmise à chaque tour. Et à chaque tour, vous devez renvoyer soit le texte « WAIT », soit les coordonnées d’une bombe à poser.

Les mouvements des carrés rouges sont assez simples. Au bout de quelques tours, il est possible de les extrapoler. Vous n’aurez donc plus besoin des infos transmises par le jeu. J’avais pris la décision de ne plus les lire, et de simplement renvoyer mon WAIT ou mes coordonnées.

Eh bien ça met le jeu dans les choux.

Comme vous ne récupérez rien, le jeu croit que vous en êtes resté au début. Il attend, et au bout d’un moment, considère que c’est votre code qui est dans les choux. Il y a en effet un temps limite d’exécution pour chaque tour. Le jeu arrête votre programme si celui-ci est dépassé, pour les cas où vous auriez envoyé du code pourri comportant une boucle infinie.

Vous êtes alors averti d’un message d’erreur indiquant, en substance : « Désolé gros con, on a killé ton process car on le suspectait de glander. Corrige ton code de merde. Respect et robustesse. » Sauf que votre code n’est pas spécialement lent, c’est juste qu’il n’exécute pas les input() permettant de vider régulièrement le buffer d’entrée-sortie entre vous et le jeu.

De la doc publiée mais pas publique

Ce mini-projet m’ayant pris un peu de temps, je me suis dit que ça méritait une petite documentation, que j’ai directement écrite dans le code. Ensuite, j’ai publié le tout sur CodinGame.

Le problème, c’est que seuls les gens ayant déjà résolu le challenge ont accès aux solutions publiées par les autres. Je me suis donc cassé le fondement à décrire et commenter un algo dont seules 258 personnes pourront profiter. Ce qu’elles ne feront pas forcément car rien ne dit que ça les intéressera.

Tant pis pour la gloire. Je me console en me disant que j’ai réussi une chose que seules 258 autres personnes dans le monde ont réussie.

Joyeux Noël quand même

Voici pour l’occasion Meagan Kerr et ses dents du bonheur.