La promesse de No Man’s Sky est difficile à ignorer : un univers trop vaste pour être fabriqué à la main. La génération procédurale ne stocke pas chaque planète. Elle stocke des règles et une graine, puis reconstruit le contenu de façon déterministe lorsque le joueur arrive.

Un générateur pseudo-aléatoire produit la même séquence pour la même graine. Les coordonnées d’un système peuvent devenir cette graine. Des fonctions de bruit créent relief, climat et distribution; des règles combinent plantes, couleurs et créatures selon des paramètres. Le résultat occupe moins de stockage que tous les mondes finis.

Générer une planète reproductible

Une séquence pourrait être :

1. calculer seed = hash(x, y, z);
2. tirer température, gravité et atmosphère;
3. générer un champ de hauteur multi-échelle;
4. choisir biomes compatibles;
5. placer ressources selon bruit et contraintes;
6. composer faune à partir de modules;
7. sauvegarder seulement les changements du joueur.

Deux joueurs visitant les mêmes coordonnées retrouvent la même base. Le serveur n’a besoin de persister que découverte, construction ou ressource retirée. La version de l’algorithme doit toutefois rester stable : changer la fonction peut transformer une planète sous une sauvegarde existante.

L’infini combinatoire ne garantit pas la variété perçue. Si les mêmes cinq règles dominent, le joueur reconnaît la grammaire après dix planètes. Des contraintes fortes évitent des assemblages absurdes, mais réduisent l’espace. Le travail de design consiste à distribuer les surprises, pas seulement compter les combinaisons.

Tester ce qu’on ne peut pas parcourir

Une équipe ne visite pas des milliards de sorties. Elle échantillonne des graines, calcule des distributions et vérifie des invariants : point de départ jouable, ressources accessibles, pas de géométrie impossible. Les graines qui échouent sont conservées comme tests de régression.

La performance exige une génération par morceaux autour du joueur. Les tâches sont asynchrones et les niveaux de détail évitent de construire les objets lointains. Si le disque ou CPU retarde, le moteur doit limiter la vitesse ou afficher une transition plutôt que laisser le joueur tomber dans un trou.

Les règles et graines peuvent être inversées ou modifiées par des joueurs; ce n’est pas nécessairement une menace, mais le serveur doit valider les changements compétitifs. Une sauvegarde corrompue ne devrait pas exiger de régénérer l’univers entier.

Prévoir la panne d’une règle générative

Une graine peut produire une planète sans ressource nécessaire ou une géométrie où le joueur reste coincé. Le générateur valide donc des invariants après création et applique un correctif déterministe, ou rejette la graine. Le serveur garde le numéro de version et un hash du résultat. Si un bug est découvert, une migration cible les graines touchées sans réécrire toutes les sauvegardes. Un mode de récupération replace le joueur à un point sûr et journalise la cause. Ces cas montrent une limite concrète : la génération procédurale réduit le stockage, mais demande un contrôle et une reprise pour les sorties que personne n’a conçues à la main.

Dans un système d’entreprise, je retiens l’idée de stocker règles, version et exceptions plutôt qu’une copie de chaque résultat. Mais je testerais la distribution réelle et la migration de version. Une immense échelle n’a de valeur que si les sorties restent cohérentes, intéressantes et reproductibles.