Le jeu en bref
Vous creusez, vendez ou gardez ce que vous trouvez, et remplissez l'index. Les pièces achètent une meilleure pelle, et une meilleure pelle creuse plus vite et atteint des gemmes plus rares. Les pièces et les jalons de l'index débloquent aussi de nouvelles zones, chacune avec son propre catalogue de gemmes. Au-delà du creusage, il y a des familiers issus d'œufs de zone, des quêtes quotidiennes et hebdomadaires, un coffre-fort où se promener pour montrer ses meilleures trouvailles, et des événements chronométrés. Une renaissance réinitialise vos pièces, outils et zones en échange de plus de chance, tout en gardant votre index, vos familiers et vos cosmétiques. Les zones les plus lointaines forment un ensemble d'îles de l'Enfer, atteintes via un portail après avoir vaincu un boss, pour les joueurs ayant fait assez de renaissances pour vouloir un nouvel endroit où creuser.
De vraies probabilités, et la preuve
Tout l'argument tient en une phrase : « chaque gemme affiche sa vraie probabilité, aucun secret ». Ça n'a de sens que si les probabilités affichées à l'écran sont celles que le serveur applique réellement. RollService, le module qui gère chaque tirage, est testé avec une série de 1 000 000 de fouilles à graine fixe qui vérifie le résultat par rapport à la table des probabilités : le plus grand écart sur tout le catalogue s'est établi à 1,75 sigma, largement dans la marge attendue d'un tirage équitable, à 168 000 tirages par seconde dans le harnais en ligne de commande. Ce harnais tourne entièrement hors de Roblox, contre les mêmes modules Luau que ceux utilisés par le jeu en direct, donc le test des probabilités ne teste pas une copie de la logique, il teste la logique elle-même.
Tout est une table de configuration
Les gemmes, les prix, les probabilités de drop, les agencements de zone et les articles de boutique vivent tous dans des modules de configuration Luau plutôt que dispersés dans la logique du jeu. La première zone, Meadow, compte à elle seule un catalogue de 49 lignes, et le jeu complet compte maintenant des centaines de gemmes réparties sur neuf îles de surface plus le monde de l'Enfer. Garder chaque nombre en configuration veut dire qu'une échelle de rareté de cette taille peut être équilibrée par une passe façon tableur, sans avoir à modifier une ligne de code par gemme.
Un wiki qui ne peut montrer que ce qui est en ligne
Le wiki joueur
est généré directement depuis la configuration du jeu lui-même, si bien que les gemmes, zones, familiers,
pelles et codes du wiki correspondent exactement au jeu, sans rien à synchroniser à la main. La
construction lit le plus récent tag git live-v<version>, donc tout ce qui n'est pas
encore publié sur Roblox ne peut simplement pas apparaître sur le wiki, même si ça existe déjà dans le
code. Le piège de cette conception : l'outil qui publie une nouvelle version du lieu ne crée pas ce tag
tout seul, si bien qu'une série de mises à jour est partie sans tag et le wiki est resté silencieusement
plusieurs versions en retard jusqu'à ce que le tag soit ajouté à la main et le site redéployé.
Maintenant, chaque publication est suivie d'un tag, puis d'un redéploiement.
Livraison par vagues, sous forme de versions du lieu
Les mises à jour sortent sous forme de versions numérotées du lieu Roblox, chacune un petit lot de changements nommé plutôt qu'une seule grosse version. Une passe de confort, un système de boss et de reliques, une série d'îles de l'Enfer : chacune arrive dans sa propre version, taguée et vérifiée avant que la suivante commence. Ça garde chaque changement traçable à ce qui a exactement été livré et quand, et ça permet d'attribuer un bug à la version qui l'a introduit.
Des bugs qui n'apparaissent qu'en direct
Compiler proprement et réussir tous les tests hors ligne ne dit rien de ce à quoi le jeu ressemble réellement une fois lancé. Quelques bugs ne sont apparus qu'en ouvrant Studio et en jouant pour de vrai :
- Éclairage hérité. Une version est sortie sans définir
Lighting.Technology, elle se chargeait donc sur l'ancien moteur de rendu Legacy, qui ne rend jamais l'Atmosphere du tout. Le réglage de brume de chaque zone était silencieusement ignoré, et ça n'est devenu visible qu'une fois que quelqu'un a vraiment regardé le monde dans Studio. - Une course de spawn repérée après publication. Un script séparé construisait le décor du monde en parallèle du script plaçant les spawns de gemmes, et les générateurs tournaient parfois en premier. Une vérification en direct après publication a trouvé 18 objets sur 50 coincés dans des collines et des rochers. La correction a été de construire le décor juste après le monde lui-même, dans un ordre fixe, et la version suivante l'a confirmé.
- Un appui d'amélioration qui ressemblait à du lag. Des joueurs ont signalé que le bouton de la boutique traînait lors d'améliorations rapides. Le limiteur de requêtes de la boutique supprimait silencieusement les requêtes dès qu'un joueur tapait plus vite que son budget ne le permettait, le bouton restait donc figé quelques secondes. Augmenter le budget de requêtes a corrigé ce qui ressemblait à du lag mais était en fait un limiteur sans retour visuel.
Comment c'est construit
Je construis ce jeu en solo, dans Claude Code avec des sous-agents qui effectuent le travail d'implémentation en parallèle pendant que je relis et je dirige. Ça permet de faire avancer un gros catalogue et un large ensemble de fonctionnalités sans que chaque changement passe par une seule file linéaire.