Comme l'an dernier, c'était absolument génial. Comme l'an dernier, le sujet était absolument délirant (diriger un hamster pour s'emparer de pommes plus vite que l'adversaire, en planifiant ses déplacements trois par trois). Contrairement à l'an dernier, toutefois, j'ai fini premier (j'étais 44e en 2007). Ça m'a beaucoup et agréablement surpris. Certes, je savais mieux comment gérer mon temps, et le sujet m'a paru beaucoup plus abordable (l'an dernier, il fallait gérer des messages entre collègues, et collaborer avec l'ennemi tout en le trahissant, ce qui n'était pas simple). Mais quand même.

Comme l'an dernier, je mets mon code source à disposition ici (sous licence GNU GPL, si quelqu'un souhaite l'utiliser). Le code est raisonnablement bien documenté (même s'il manque le fichier README.TXT principal), j'ai passé ma dernière heure à faire ça (et quelques minutes de plus auraient été bien utiles). Le code ne montre pas non plus une petite bidouille que j'avais utilisée, et qui a été bien pratique (sans doute un facteur non négligeable pour expliquer ma première place) : une interface à Stechec (utilisant wget, avec des paramètres POST et les cookies de Firefox) pour lancer de manière automatique plusieurs centaines de matches. Grâce à la fonction de score proposée par Stechec pour chaque IA uploadée, cela me permettait de comparer très facilement les versions entre elles pour mesurer les améliorations et identifier les régressions. (Il n'y avait pas encore de feedback, toutefois ; le script ne parsait pas le HTML de Stechec pour aller lire les scores. Il serait rigolo d'essayer d'optimiser chacune des constantes numériques du code de façon automatisée avec un système un peu plus évolué... peut-être le ferai-je l'an prochain, si les concours me laissent le temps de participer...)

  • amarillia.tgz (13 Kio), archive TGZ du champion soumise à Stechec, modifiée seulement en ajoutant un fichier COPYING et en rangeant les fichiers dans un dossier "finale" (licences GNU GPL version 2 ou ultérieure, et Creative Commons BY-SA version 2.0 ou ultérieure).

Mes conseils aux futurs participants à Prologin, pour éviter de tomber dans les pièges classiques (s'il y en a que ça intéresse) :

  • Qualifiez-vous pour la demi-finale. C'est super important. Pour ce faire, remplissez le QCM de sélection. Il est d'une difficulté très raisonnable, la plupart des réponses aux questions pouvant être obtenues à l'aide d'un moteur de recherche. Les programmes à écrire sont aussi d'une difficulté raisonnable : rédigez-les proprement, commentez-les soigneusement (ils sont lus par des humains), et surtout, assurez-vous qu'ils fonctionnent correctement sur des données de test avant de les soumettre (c'est la moindre des choses). Le plus difficile est sans doute de trouver le temps de rédiger les programmes parce qu'on n'est pas sûr que ça en vaille la peine (si j'ai participé en 2007, c'est en très grande partie parce que je suis tombé sur le concours un soir où je n'avais pas grand-chose d'autre à faire), mais croyez-moi, le jeu en vaut la chandelle.
  • Qualifiez-vous pour la finale. C'est super important aussi. (Si l'épreuve machine de la demi-finale peut sembler fun, la finale l'est encore beaucoup plus.) L'épreuve papier est sans doute la partie la plus "scolaire" de Prologin (même si le sujet est rédigé avec humour) : des connaissances en algorithmique et en informatique théorique sont sans doute utiles, mais si, comme moi, vous en avez peu, savoir programmer devrait suffire. L'entretien n'est pas très difficile : on vous demandera grosso modo ce que vous avez fait ces derniers temps qui ait trait à l'informatique, pour s'assurer que vous pratiquez. L'épreuve machine est très sympathique ; les programmes à rédiger sont de difficulté croissante (normalement), il faut en écrire le plus possible. Il est facile de perdre plusieurs dizaines de minutes pour traquer une ânerie qui empêche votre code de fonctionner ; si vous en avez marre, n'hésitez pas à demander l'aide d'un organisateur.
  • Assurez-vous d'avoir bien compris le sujet de la finale. Cela va de soi : inutile de commencer à coder si vous avez encore des doutes. Étant donné que les sujets de finale sont en règle générale bien tordus, dissiper les confusions peut prendre un certain temps.
  • Faites quelque chose de simple qui marche à peu près, puis améliorez-le progressivement. Il est très difficile de gérer son temps (trente-six heures, c'est à la fois très long et très court), et il vaut mieux être sûr de rendre quelque chose de primitif, plutôt que de s'embarquer dans un projet pharaonique qui ne sera pas fini à la fin du temps et qui ne fonctionnera pas.
  • En première approximation, oubliez que l'ennemi est présent (si c'est possible). Tant qu'il n'est pas possible d'affronter d'autres IA sur Stechec, inutile de partir dans de complexes pronostics sur les stratégies adverses possibles. Faites une IA qui répond à peu près à la question posée, seule, sans se soucier des éventuelles perturbations que l'ennemi pourrait provoquer. (Bien entendu, si tout cela a un sens par rapport au sujet posé, mais en général c'est le cas).
  • Par contre, dès que possible, battez-vous sur Stechec. Vu que c'est Stechec qui va être utilisé pour noter votre IA, c'est la référence pour que vous puissiez juger de sa performance. Si vous perdez systématiquement contre une autre IA, il peut être utile de visionner le match pour identifier d'où proviennent vos échecs (c'est comme ça que, vers le début, j'ai compris que si je passais mon temps à transporter des pommes de la zone neutre à ma base ; comme l'ennemi passait le sien à transporter des pommes de ma zone à la sienne, j'étais mal parti). Par contre, essayez aussi de ne pas perdre trop de temps à faire ça : au bout d'un moment, il faut essayer d'améliorer son IA par rapport à sa capacité à battre les autres en moyenne, même si elle perd de temps en temps.
  • Gardez les tâches faciles pour la fin. Par exemple, la documentation (même si écrire du code propre dès le départ est préférable, car il n'est pas exclu qu'en commentant, vous supprimiez accidentellement un point critique de votre code...). À quelques heures de la fin, essayez d'avoir une version stable à laquelle vous ne touchez plus. Si vous essayez encore de l'améliorer, vérifiez sur Stechec que tout fonctionne encore correctement.
  • Utilisez un gestionnaire de versions. Ou, au moins, faites des copies de sauvegarde. Et n'hésitez pas à revenir en arrière, vous aurez parfois des surprises. (Vers la fin, certaines corrections de bug (du genre, ne pas tirer sur un hamster s'il y a un rocher dans le chemin) ou améliorations (par exemple, utilisation du turbo) rendaient en fait l'IA moins efficace, pour des raisons mystérieuses.)
  • Ne passez pas tout votre temps à coder. Bon, j'y ai quand même passé le plus clair de mon temps, mais prendre du recul par rapport à ce que vous faites peut vous aider à comprendre quelques points essentiels. Par exemple, ce n'est que vers le deuxième soir que j'ai compris que l'histoire de la planification à trois tours m'obligeait à récrire dans mon code une partie du code du serveur pour anticiper correctement ce qui arriverait à mes hamsters (sans compter l'ennemi).

Pour terminer ce billet, je voudrais remercier l'équipe de Prologin. Ils font vraiment un travail remarquable. En particulier, merci pour la stabilité du serveur cette année. Ce n'est pas une blague ; alors que, l'an dernier, les règles du jeu changeaient en cours de route et que le serveur n'acceptait qu'un match sur trois (quand il ne plantait pas), tout a fonctionné (presque) parfaitement cette année, et le serveur a accepté sans broncher les milliers de matches que mon script a lancés. Du beau boulot !