Blog du grouik

Les joueurs sont arrivés nombreux, principalement grâce à la communauté *Bobiverse* sur Reddit. Et forcément, faire arriver beaucoup de monde d'un coup est une méthode particulièrement efficace pour découvrir tous les petits bugs qui avaient tranquillement survécu à mes tests. Les une à deux premières semaines ont donc été assez intenses, avec pas mal de corrections à faire rapidement. Parmi elles, quelques jolis bugs de duplication, que nous avons — Codex et moi — souvent résolus à coups de locks. Ça fonctionnait. Mais certains de ces locks allaient revenir me mordre beaucoup plus tard. J'y reviendrai.

Une fois cette période passée, un autre constat s'est imposé : le forum intégré au jeu n'était franchement pas très pratique pour discuter. La communauté a donc migré vers Discord, qui est aujourd'hui plutôt bien animé. Et ça, ça fait vraiment plaisir.

Maintenant que la majorité des joueurs a compris — notamment grâce aux différents indices disséminés dans le jeu — à peu près les distances qui séparent les sondes, je peux aussi révéler quelques éléments sur la façon dont j'avais initialement dimensionné l'univers.

Au départ, les durées des actions et la probabilité d'apparition d'une planète abritant une civilisation étaient calculées pour qu'il soit raisonnablement probable qu'un joueur mette plus d'un mois à découvrir une forme de vie, même en automatisant ses déplacements via l'API. Sauf que plusieurs choses sont venues perturber ce beau calcul.

Lors des bêta-tests avec le hackerspace, j'ai d'abord divisé toutes les durées par deux pour rendre l'expérience plus agréable.

Ensuite, les planètes ne sont actuellement pas directement exploitables. Je pars du principe qu'une sonde ne dispose pas de la poussée nécessaire pour redécoller d'un puits gravitationnel planétaire. Les astéroïdes restent donc la principale source de matières premières.

J'avais envisagé de permettre aux joueurs de fabriquer des fusées, de les déposer sur une planète, d'y installer des moyens de production, etc. Mais en suivant cette idée, je me serais assez rapidement retrouvé à développer une sorte de *Factorio* spatial à l'intérieur de Neumann Probe. Ce qui pourrait être amusant, mais représente à lui seul un autre jeu.

Autre surprise : développer des missions est relativement coûteux.

Paradoxalement, à l'heure du développement assisté par IA, ajouter une grosse fonctionnalité reposant sur de nouvelles mécaniques peut être plus rapide que d'écrire et d'intégrer correctement une mission. Une mission, ce sont des dialogues, plusieurs états, des conditions de réussite et d'échec, des cas particuliers… et surtout beaucoup de tests à effectuer manuellement, étape par étape, pour vérifier chaque embranchement. À l'inverse, lorsqu'une mécanique repose sur des API clairement définies, l'IA est plutôt bonne pour écrire les tests qui vont avec. D'ailleurs, la mise en place assez tôt d'une vraie batterie de tests sur l'API a probablement sauvé le jeu à plusieurs reprises. J'y reviendrai plus loin.

Et puis il y avait une erreur de dimensionnement beaucoup plus fondamentale :

j'ai vu beaucoup trop grand pour la zone de spawn.

Les sondes sont très, très éloignées les unes des autres. Dans ma tête, ce n'était pas vraiment un problème. J'avais imaginé devoir assez rapidement ajouter des fonctions permettant aux joueurs d'interagir à proximité, et je pensais aussi que les premières rencontres entre sondes finiraient par se produire accidentellement après quelques semaines d'exploration.

Sauf que la zone de spawn représente environ un milliard de secteurs.

Forcément, ça calme un peu les rencontres fortuites. Enfin, j'avais imaginé que l'exploration constituerait naturellement l'activité principale du jeu. Or une bonne partie des joueurs — en tout cas parmi ceux qui sont actifs sur Discord — semble avoir, dans un premier temps, adopté Neumann Probe davantage comme un idle game : développer sa sonde, automatiser la récolte, fabriquer toujours davantage de matériel et optimiser tout ça.

Ce n'est pas vraiment ce que j'avais anticipé. Même si Neumann Probe se présente volontairement comme un jeu sans objectif imposé, j'avais supposé qu'une grande partie des joueurs se donnerait spontanément pour but de trouver la vie. Les premières planètes habitées ont bien été découvertes. Elles sont intéressantes, permettent de raconter de petites histoires et ouvrent de nouvelles possibilités, mais la manière dont je les ai implémentées fait qu'elles ne constituent finalement pas un *goal* ultime.

En revanche, un autre objectif a progressivement émergé dans les discussions entre joueurs :

se retrouver.

Ce qui, dans ma tête, aurait dû finir par arriver plus ou moins accidentellement au bout de quelques semaines de jeu. Ai-je déjà précisé que le spawn couvre environ un milliard de secteurs ? Finalement, cet objectif choisi par les joueurs est devenu beaucoup plus intéressant que celui que j'avais imaginé au départ.

Alors, un peu comme un maître de jeu de rôle qui avait soigneusement préparé son scénario avant de regarder ses joueurs partir avec enthousiasme dans une direction complètement différente, j'ai revu la roadmap — qui, soyons honnêtes, existe principalement dans ma tête — pour accompagner ce qu'ils avaient décidé de faire.

Et j'avoue qu'une bonne partie des développements qui ont suivi a eu pour objectif de compenser la difficulté complètement déraisonnable de cette rencontre.

Parmi toutes les petites fonctionnalités ajoutées depuis — que je ne vais pas détailler ici, le changelog est là pour ça, et l'API en est déjà à sa 115e version au moment où j'écris ces lignes — trois grosses évolutions méritent particulièrement qu'on s'y attarde :

• le réseau SCUT ;
• les sondes drones ;
• et, beaucoup plus récemment, la possibilité de transformer des astéroïdes en projectiles cinétiques.

Le réseau SCUT

Le SCUT est un réseau de communication construit par les joueurs : chaque relais déployé couvre une zone autour de lui et peut se connecter aux autres relais compatibles pour former progressivement un réseau interstellaire.

Dans l'univers du *Bobiverse*, de mémoire, les relais SCUT ont une portée de l'ordre de 2,5 années-lumière. Dans Neumann Probe, mon problème était légèrement différent : il fallait augmenter les chances que deux sondes puissent finir par se rencontrer. J'ai donc fixé la portée d'un relais à 10 secteurs de rayon. Enfin… « rayon ». Il y a eu un petit détail.

Codex m'a fait de la merde sur la méthode de calcul de la zone de couverture et m'a implémenté un cube au lieu d'une sphère.

Je ne m'en suis pas rendu compte immédiatement. Et quand je m'en suis rendu compte, des joueurs avaient déjà construit leurs réseaux. Corriger proprement le calcul aurait réduit leur couverture et potentiellement cassé des liaisons existantes. Il était donc trop tard pour corriger sans modifier rétroactivement les règles du jeu. Le bug est devenu une feature.

Un relais SCUT couvre ainsi un peu plus de 4 000 secteurs. Ce qui, en faisant un énorme raccourci statistique, revient à multiplier par plusieurs milliers la probabilité qu'une sonde finisse par entrer dans une zone couverte par le réseau d'un autre joueur.

Ça tombe bien : c'était précisément le problème que j'essayais de résoudre.

Lorsque j'ai déployé les relais SCUT, leurs coûts de fabrication me donnaient au moins deux jours avant de voir apparaître les premiers réseaux fonctionnels. Et c'est là que Discord a une nouvelle fois joué son rôle de laboratoire grandeur nature. Les joueurs étaient très enthousiastes à l'idée de pouvoir utiliser le réseau pour piloter leurs Mannys à distance.

Les Mannys sont les petits robots polyvalents embarqués par les sondes : ce sont eux qui minent les astéroïdes, manipulent les containers, fabriquent des objets et réalisent une bonne partie des tâches matérielles du jeu.

Avec le SCUT, les joueurs imaginaient donc naturellement pouvoir laisser des Mannys travailler dans un secteur, repartir avec leur sonde et continuer à leur donner des ordres à travers le réseau.

Excellente idée.

Je n'avais absolument pas implémenté ça. Je n'y avais même pas pensé.

Je vous avais dit que j'étais passé à côté du côté *idle game* qu'allaient adopter certains joueurs.

En voyant les discussions sur Discord, je pouvais assez facilement deviner ce qui allait se passer : deux jours plus tard, les premiers relais allaient être opérationnels, les joueurs allaient essayer de piloter leurs Mannys à distance… et découvrir que ce n'était pas possible. Je sentais venir la déception.

J'avais deux jours. J'ai donc ajouté rapidement le contrôle distant des Mannys via le réseau SCUT avant que les premiers réseaux ne deviennent opérationnels. Personne ne s'est rendu compte que cette fonctionnalité n'existait pas encore lorsqu'ils ont commencé à fabriquer leurs relais.

Parfois, une roadmap consiste surtout à coder suffisamment vite pour que les joueurs ne découvrent jamais qu'elle n'existait pas.

Les sondes « drones »

Une sonde de Von Neumann est, par définition, capable de se répliquer.

Et c'est d'ailleurs l'un des aspects que je trouve les plus intéressants dans le *Bobiverse* : ce ne sont pas seulement les sondes qui sont copiées, mais aussi l'intelligence qui les pilote, avec ses souvenirs et sa personnalité. Il fallait absolument que la réplication finisse par arriver dans Neumann Probe. C'est quand même un peu la clé de voûte de l'univers. Restait une question assez importante : comment représenter ça dans un jeu multijoueur ?

J'avais imaginé plusieurs possibilités.

• La première était que la fabrication d'une nouvelle sonde génère un lien de parrainage. Le joueur aurait ainsi pu inviter quelqu'un à rejoindre le jeu en apparaissant directement dans son secteur.L'idée me plaisait bien : elle reproduisait d'une certaine manière la création d'un nouveau Bob. L'inconvénient, c'est que cette mécanique aurait aussi pu constituer une belle invitation au multicompte.
• L'autre possibilité était beaucoup plus simple : permettre au joueur de piloter lui-même plusieurs sondes indépendantes.

En parallèle, une autre discussion avait commencé autour de l'imprimante atomique. Dans Neumann Probe, elle est volontairement très liée à la sonde. Elle n'est pas craftable et constitue le principal goulot d'étranglement de toute la chaîne de fabrication : une sonde n'en possède qu'une. Plusieurs joueurs ont donc assez logiquement suggéré la possibilité de construire une usine fixe.

Sauf que je n'avais surtout pas envie de les encourager à se sédentariser. Depuis le début, j'essaie plutôt de pousser les sondes à voyager et à explorer. Les deux problèmes ont fini par se rejoindre.

Puisqu'on avait maintenant le réseau SCUT, pourquoi ne pas permettre de fabriquer de nouvelles sondes et de les piloter à distance à travers le réseau ?

C'est ainsi que sont apparues les sondes « drones ». L'intelligence — c'est-à-dire le joueur — reste normalement dans sa sonde principale. Les autres sondes peuvent être envoyées ailleurs, transporter leurs propres Mannys et containers, exploiter d'autres secteurs ou servir de relais logistiques. Et l'intelligence peut également se transférer d'une sonde à une autre.

Ce qui introduit au passage une conséquence assez intéressante : perdre une sonde ne signifie plus nécessairement mourir. Si la sonde contenant l'intelligence est détruite mais qu'une autre existe encore, une sauvegarde de l'intelligence peut être restaurée sur une sonde survivante.

On commence donc enfin à avoir quelque chose qui ressemble vraiment à une sonde de Von Neumann : une machine capable de fabriquer d'autres machines capables de poursuivre son travail. Et, accessoirement, encore un moyen pour les joueurs de couvrir davantage de terrain et d'augmenter leurs chances de finir par se rencontrer.

Déplacer les astéroïdes

Ceux qui connaissent le *Bobiverse* se doutent probablement de la finalité de cette fonctionnalité. Elle vient tout juste d'être implémentée et, dans les discussions, je vois que certains joueurs ont déjà parfaitement compris son intérêt logistique. Mais le déplacement des astéroïdes est surtout un prérequis pour ce qui viendra ensuite. Les sondes vont finir par se rejoindre. Elles pourront collaborer ou s'affronter — ce n'est pas particulièrement le but du jeu, mais techniquement rien ne les en empêchera. Et peut-être devront-ils un jour collaborer contre autre chose.

Pour ça, il fallait d'abord leur donner quelques outils supplémentaires. Il est donc maintenant possible de débloquer la technologie nécessaire, d'installer un moteur au deutérium sur un astéroïde et de modifier sa trajectoire. Le moteur peut être ravitaillé et l'astéroïde envoyé vers un secteur voisin ou lancé contre un corps du système. Cela signifie qu'un gros caillou peut désormais devenir un projectile cinétique relativiste.

Cette fonctionnalité a aussi été l'occasion d'une expérience de développement assez intéressante.

Je me suis surpris à passer plusieurs jours avec Codex à rédiger un véritable cahier des charges "Trajectoires d’astéroïdes motorisés — instructions de développement", découpé en lots, en réfléchissant aux modèles physiques, aux règles, aux cas limites et à l'architecture… sans écrire une seule ligne de code. Je l'ai donné à implémenter à l'IA. Trois ou quatre retouches mineures plus tard, en moins d'une heure, l'ensemble fonctionnait.

Et ça illustre assez bien la manière dont ma façon de développer a changé depuis le début de Neumann Probe.

Vibe coder un projet de cette taille

Neumann Probe est probablement le plus gros projet que j'ai développé en utilisant massivement une IA. Après quelques mois et plus d'une centaine de versions d'API, j'ai donc maintenant un peu de recul sur ce que ça change réellement.

L'IA possède des avantages assez évidents par rapport à « moi + un IDE »

Le premier, c'est évidemment la vitesse.

Pour un développeur seul sur un projet personnel, j'estime le gain quelque part entre ×20 et ×100 selon les tâches. Dans un environnement professionnel, ce serait évidemment beaucoup moins spectaculaire : les temps de formation, de communication, de validation, les contraintes organisationnelles et tout ce qui entoure le développement ne disparaissent pas parce que le code est produit plus rapidement. Mais même un facteur cinq changerait déjà énormément de choses.

Deuxième avantage : elle ne fatigue pas.

Quand on chasse un bug et qu'il faut suivre une variable qui traverse cinq méthodes appartenant à quatre classes différentes après avoir parcouru quelques milliers de lignes de code, un humain finit par perdre en concentration. L'IA, elle, continue.

Et, à condition de lui demander explicitement de le faire, elle peut également être beaucoup plus rigoureuse que moi pour certaines tâches ingrates : maintenir une batterie de tests, mettre à jour un changelog, vérifier systématiquement les régressions, etc.

Mais elle possède aussi quelques défauts que je n'avais pas

Avant l'ère du développement assisté par IA, lorsque j'écrivais mes classes de type Factory ou Repository — celles qui font le lien entre la base de données et les objets métier — j'avais naturellement tendance à prévoir des méthodes du genre :

`get`, `create`, `update`, `delete`…

Mais aussi un `get_list` permettant de récupérer toute une collection d'objets en un nombre fixe de requêtes, plutôt que d'aller interroger la base récursivement pour chaque objet.

Codex — à l'époque avec GPT-5.5 — a eu une tendance presque systématique à faire l'inverse. Une requête par objet. Et parfois une requête pour chaque sous-objet de chaque objet. On découvre alors assez rapidement le merveilleux monde des complexités quadratiques appliquées à MariaDB.

Tant qu'il y a dix objets, tout va bien. Quand il commence à y en avoir quelques milliers, le serveur exprime son désaccord.

J'ai vu pire.

À un moment, Codex avait besoin de conserver la liste des secteurs couverts par un réseau de relais SCUT. Un relais seul couvre, rappelons-le, plus de 4 000 secteurs.

Solution proposée ?

Mettre toute la liste en JSON dans un champ de la base de données. Voilà. Mettre *n* fois 4 000 coordonnées dans un `TEXT` et souhaiter bonne chance au CPU et à la machine virtuelle MariaDB.

L'IA possède également certains défauts qu'elle partage parfaitement avec les développeurs humains

C'est plus facile de patcher que de refactoriser.

Même lorsqu'un projet a été correctement pensé au départ pour faciliter sa maintenance et son évolution, on ajoute une fonctionnalité. Puis une autre. Puis une petite exception. Puis « juste ce cas particulier ».

Et un jour, on ouvre un fichier et on découvre qu'on a créé un god file. À côté se trouve généralement un plat de spaghetti.

Neumann Probe n'y a pas échappé.

À mesure que le projet grossissait, Codex consommait également de plus en plus de tokens pour réaliser des modifications pourtant parfois minuscules. Il devait parcourir davantage de code, comprendre davantage de dépendances et retrouver des comportements répartis dans de plus en plus de fichiers.

À certains moments, deux prompts particulièrement gourmands pouvaient suffire à pulvériser ma limite hebdomadaire.

Il a donc fallu faire ce qu'on finit toujours par devoir faire sur un projet qui grossit :

arrêter d'ajouter des fonctionnalités et faire du ménage.

Audits de code, découpage des gros fichiers, suppression des duplications, refactorisation de services entiers, remise à plat de certaines responsabilités… Ça coûte énormément de tokens et ça ne produit absolument aucune nouvelle fonctionnalité visible pour les joueurs. Mais c'est aussi à ce moment-là qu'on est particulièrement content d'avoir laissé l'IA maintenir depuis le début une batterie complète de tests API. On peut lui demander de démonter puis reconstruire une partie importante du moteur, lancer les tests et vérifier immédiatement combien de morceaux sont tombés par terre.

Les moments où le serveur a commencé à souffrir

Neumann Probe tourne sur un serveur dédié, avec une architecture trois tiers répartie entre plusieurs machines virtuelles : reverse proxy, PHP-FPM de production, PHP-FPM de développement et base de données sont séparés. Il y a quand même eu deux ou trois périodes où l'infrastructure n'était plus franchement stable.

Assez rapidement après le lancement, j'ai basculé de SQLite à MariaDB. Ce n'était pas encore vraiment un problème de performances : c'était surtout lié à mon ressenti lorsque j'utilisais mes scripts de maintenance et de debug. Les locks SQLite devenaient pénibles. Le code avait été prévu dès le départ pour pouvoir changer de moteur de base de données, donc jusque-là, pas de souci particulier.

Quelques jours plus tard, en revanche, les joueurs commencent à se plaindre de gros ralentissements. Les logs nginx montrent que ça cogne pas mal sur le serveur, mais rien qui ressemble réellement à un abus de la part des joueurs. Je trouve rapidement le coupable : MariaDB, dont les vCPU plafonnent à 100 %.

Dans un premier temps, je lui ajoute un vCPU pour débloquer temporairement la situation. Ça soigne le symptôme pas la maladie.

Je commence donc à ajouter des métriques sur les serveurs, à réorganiser les logs et à m'appuyer sur un audit de code que j'avais fait réaliser quelques jours auparavant par Claude. Dans le désordre et de manière absolument non exhaustive :

• les *slow query logs* me révèlent que `initdb`, chargé de vérifier et éventuellement de mettre à jour la structure de la base de données, est exécuté à chaque appel API. Très bonne idée sur mon environnement de développement. Nettement moins en production. C'est retiré ;
• optimisation des réglages des pools PHP-FPM ;
• chasse aux gros locks englobant toute la sonde — sonde, inventaires, Mannys, tâches des Mannys — qui faisaient qu'une opération pouvait ralentir toutes les autres actions parallèles. Ils sont progressivement remplacés par des modifications atomiques beaucoup plus ciblées ;
• chasse aux données sérialisées en JSON et stockées directement dans la base ;
• chasse aux traitements effectuant une requête par objet, voire, dans certains cas, un nombre quadratique de requêtes ;
• et mise en place d'un rate limit sur l'API.

Ce dernier point, un peu à contrecœur.

Je préfère largement optimiser le code plutôt que limiter artificiellement ce que les joueurs peuvent faire. Les limitations doivent arriver en dernier recours. Mais il fallait quand même protéger le serveur contre un script un peu trop enthousiaste. Après tout ça, la situation rentre dans l'ordre.

Quelques jours plus tard…

Les deux joueurs possédant des sondes dignes d'une megafactory Samsung se retrouvent bloqués. S'ils se reconnaissent : je vous aime, ne changez rien. Leurs appels API tombent en erreur 500. Cette fois, le problème vient des tâches des Mannys.

Le fonctionnement historique était assez simple : lorsqu'un appel API concernait un Manny, le code vérifiait si sa tâche était terminée et, si le délai prévu était écoulé, finalisait cette tâche à ce moment-là. Avec quelques Mannys, ça fonctionne. Avec une megafactory Samsung, beaucoup moins.

Le plus agaçant, c'est qu'au tout début du projet j'avais justement fait mettre en place un scheduler, appelé périodiquement par une tâche cron, pour gérer ce genre de choses. Codex l'avait correctement utilisé pour les déplacements des sondes. Puis, au fur et à mesure du développement, il avait recommencé à traiter certaines tâches opportunément lors des appels API.

Je l'avais vu et j'avais préféré ignorer le problème.

J'ai donc retiré des appels API tous les traitements de finalisation des tâches. Ils sont désormais entièrement pris en charge par le scheduler, que j'ai transformé au passage en véritable worker systemd.

Les lectures API redeviennent ainsi ce qu'elles auraient toujours dû être : des lectures. Elles ne font plus avancer le monde simplement parce qu'un joueur ou un script vient demander son état. Et pour cette partie-là : merci Codex.

Avec du recul, je pense que l'IA a spontanément dimensionné la qualité, la stabilité et l'optimisation du code pour ce qu'elle percevait probablement comme un projet amateur.

Sauf qu'aujourd'hui, je ne considère plus vraiment Neumann Probe comme tel. C'est certes un jeu développé sur mon temps libre, sans studio, sans équipe et sans ambition commerciale particulière. Mais techniquement, avec son univers persistant, ses joueurs simultanés, ses centaines de sondes et de Mannys, ses clients automatisés utilisant l'API, ses tâches asynchrones et son infrastructure serveur, Neumann Probe est devenu un MMORPG de niche.

Et ça change un peu le niveau d'exigence.

La morale de cette histoire

Je n'aurais pas été capable de développer tout ça sur mon temps libre en quelques mois sans les IA. Ou alors il m'aurait fallu plusieurs années. Je n'aurais probablement pas non plus été capable d'être aussi réactif lorsque les problèmes sont apparus : analyser un comportement, auditer plusieurs milliers de lignes, proposer une refactorisation, modifier le code, compléter les tests et vérifier les régressions peut maintenant se faire à une vitesse assez impressionnante.

Mais l'inverse est également vrai : même avec les IA, je n'aurais pas été capable de faire Neumann Probe sans mon background de développeur et d'administrateur systèmes.

L'IA peut produire très rapidement énormément de code. Elle peut chercher un bug pendant des heures sans fatiguer, écrire des tests et refactoriser des pans entiers d'une application. Encore faut-il être capable de comprendre que le problème vient de MariaDB plutôt que de nginx, de regarder les bonnes métriques, de reconnaître un problème de locking ou un N+1, de savoir pourquoi exécuter un `initdb` à chaque requête est une mauvaise idée, ou simplement de décider qu'ajouter encore deux vCPU ne constitue pas une solution d'architecture.

Et un mot sur la communauté

Ils sont super cools et enthousiastes.

Même pendant les périodes où le serveur merdouillait franchement, les retours sont restés constructifs.

Le meilleur exemple est probablement l'annonce du rate limit de l'API. Je m'attendais à quelques protestations — après tout, certains joueurs avaient développé leurs propres scripts et outils autour de l'API et j'étais littéralement en train de leur annoncer que j'allais limiter le nombre de requêtes qu'ils pouvaient envoyer. À la place, la discussion sur Discord est presque immédiatement devenue un nouveau challenge : comment adapter les clients API pour gérer la rate-limit ?

Conclusion

Après presque trois mois, Neumann Probe est donc allé assez loin par rapport au petit jeu que j'avais en tête au lancement. Une bonne partie de cette évolution vient directement des joueurs : de ce qu'ils ont essayé de faire, des usages que je n'avais pas anticipés, des limites qu'ils ont rencontrées et des idées qui sont apparues dans les discussions.

Quelques remerciements s'imposent donc.

• MagiCrazy, qui a donné plusieurs coups de main et développé neumann-cockpit, une interface alternative qui complète la WebUI. Il a aussi ouvert la voie aux développements utilisant directement l'API — une composante du jeu qui, manifestement, plaît beaucoup aux joueurs.
• Les potos du hackerspace, qui ont béta-testé pendant une ou deux.
• Lena, très présente sur Discord, dont l'enthousiasme et les échanges contribuent, je pense, beaucoup à faire vivre le jeu.
• Les donateurs Ko-fi. Je ne suis pas encore tout à fait devenu une sonde se nourrissant uniquement de deutérium frais : il me reste quelques traces d'humanité et, oui, les thunes, ça motive aussi. Merci donc à Funk, ZeroSum, aLurkerAppears, Bonopaws, Ziegenbagel, Chris, mycket, abovetheFray, SnoozyBob, Bonsi et Kratos.
• Et évidemment, tous les joueurs. Ceux qui explorent, ceux qui optimisent, ceux qui codent leurs propres outils, ceux qui construisent des megafactories Samsung, ceux qui trouvent les bugs les plus improbables et ceux qui prennent mes erreurs de dimensionnement comme de nouveaux challenges à résoudre.

Bon allez, c'est pas tout ça, mais il faut maintenant que je réfléchisse à la prochaine feature. Enfin, je la coinnais, c'est que j'hésite entre deux manières très différentes de l'implémenter…

Je vais donc clore ici ce long, très long billet de blog.