La dispersion procédurale n'est fiable que si elle est reproductible : les mêmes entrées doivent toujours produire la même forêt, sur chaque machine et à chaque build. Cela signifie comprendre les seeds (comment rendre l'aléatoire répétable), pourquoi un système procédural vivant est dangereux sous contrôle de source, et pourquoi cuire une dispersion vers des instances natives du moteur transforme une boîte noire non-mergeable en un asset diffable, revuable et versionnable. Cet article couvre le déterminisme, les seeds, et comment empêcher le feuillage d'une équipe de changer silencieusement sous les pieds de tout le monde.
Cela paraît aléatoire, mais pour une équipe il doit s'agir d'un aléatoire répétable : le même sur ta machine, celle de ton coéquipier et le serveur de build. Le déterminisme est ce qui transforme une jolie dispersion en quelque chose que tu peux vraiment livrer et maintenir.
Pourquoi le déterminisme compte
Si une dispersion se régénère différemment chaque fois qu'elle est ouverte ou construite, ton niveau change silencieusement : les collisions bougent, des objets cachés apparaissent, les playtests cessent d'être reproductibles. Une dispersion déterministe produit toujours exactement le même résultat à partir des mêmes entrées.
L'aléatoire qui n'est pas répétable est une usine à bugs dans un niveau. Si ouvrir la scène sur une autre machine, ou la reconstruire la semaine prochaine, redistribue où chaque pierre et buisson atterrit, alors un endroit qui était dégagé est maintenant bloqué, une ligne de vue que tu as tunée est cassée, et un résultat de playtest ne peut pas être fiable parce que le niveau testé n'est pas le niveau que tu as livré. Le déterminisme (mêmes entrées, même sortie, toujours) c'est ce qui rend une dispersion procédurale sûre. C'est la différence entre "l'ordinateur a placé quelques plantes" et "le niveau a un état défini et stable sur lequel je peux compter."
Seeds : rendre l'aléatoire répétable
Un seed est le nombre de départ d'une séquence aléatoire. Même seed → même placement "aléatoire" à chaque fois. Expose et sauvegarde le seed, et ta dispersion est reproductible ; laisse-la à un vrai aléatoire et c'est un niveau différent à chaque exécution.
Les ordinateurs ne font pas de vrai aléatoire : ils exécutent des séquences déterministes qui paraissent aléatoires, chaque séquence définie par un nombre de départ appelé le seed. Nourris le même seed et tu obtiens la même séquence, donc le même placement, à chaque fois. C'est la clé de la dispersion reproductible : l'outil expose un seed, tu le sauvegardes avec la scène, et la forêt est maintenant une fonction pure de (seed + paramètres + surface). Change le seed pour explorer un arrangement différent qui te plaît, puis verrouille-le. Tout ce qui à la place tire d'une source aléatoire vraiment non-seedée (l'horloge, un nouveau lancer à chaque ouverture) produit un niveau différent à chaque chargement, ce qui est inutilisable en production.
Le problème du contrôle de source
Une dispersion procédurale vivante stockée sous forme de "un système + paramètres" est une boîte noire pour le contrôle de source : tu ne peux pas la differ, la reviewer, et deux personnes l'éditant produisent un conflit non-mergeable. Les équipes ont besoin de la dispersion sous une forme que Git ou Perforce peuvent vraiment tracker.
Voici où la dispersion rencontre la réalité d'une équipe. Si ta forêt existe seulement comme "un système de dispersion avec ces réglages", le contrôle de source ne peut pas voir ce qu'elle a produit : seulement que certains paramètres ont changé. Tu ne peux pas reviewer un changement de placement dans une pull request, tu ne peux pas dire ce qui a bougé, et si deux artistes touchent la même dispersion, tu obtiens un conflit de merge qu'aucun outil ne peut résoudre de manière significative. Un niveau dispersé qui ne vit que dans un générateur vivant est invisible aux systèmes précis sur lesquels les équipes comptent pour collaborer en sécurité, c'est pourquoi "tout est procédural" peut silencieusement devenir "personne ne peut éditer la forêt en sécurité".
Chacun est une instance avec une position, une rotation et une échelle. Quand la dispersion est cuite vers des instances natives, celles-ci deviennent des données réelles, inspectables : la forêt cesse d'être une formule et devient quelque chose que tu peux reviewer ligne par ligne.
Cuire la rend diffable
Cuis la dispersion vers des instances natives du moteur : de vrais objets placés avec des transformations concrètes. Maintenant ce sont des données de scène ordinaires : diffables, revuables, mergeables, et identiques sur chaque machine parce qu'elles sont stockées, pas régénérées.
La résolution à la fois du déterminisme et du contrôle de source est le même geste : cuire. Au lieu de livrer un générateur vivant, tu cuis la dispersion vers de simples instances natives du moteur : de vrais meshes placés avec des positions, rotations et échelles concrètes stockées dans la scène. Cela fait s'effondrer chaque problème d'un coup. C'est déterministe par définition (ce sont des données stockées, pas un re-tirage). C'est diffable (le contrôle de source voit les transformations concrètes qui ont changé). C'est revuable (un lead peut voir exactement ce qui a bougé dans une pull request). Et cela ne coûte rien d'inhabituel au moteur à l'exécution, parce que ce sont juste des meshes instanciés. Un flux qui peint la densité avec des règles puis cuit vers des instances natives (c'est exactement comme cela que Numivo fonctionne) te donne la vitesse d'auteur de la dispersion procédurale et la stabilité du contenu placé à la main, sans la fragilité de boîte noire.
Garder le feuillage d'une équipe stable
Verrouille les seeds, cuis avant de committer, et traite le résultat cuit comme la source de vérité. Re-disperse délibérément (change le seed, review le diff), jamais accidentellement, pour que la forêt ne change que quand quelqu'un le veut.
La discipline pratique pour une équipe est courte. Verrouille le seed pour que la dispersion soit reproductible. Cuis avant de committer, pour que ce qui est dans le contrôle de source soit le résultat concret que tout le monde partage, pas une recette qui re-lance par machine. Traite les instances cuites comme la source de vérité : la chose que tu review et livre. Et quand tu veux changer la forêt, fais-le délibérément : ajuste les paramètres ou le seed, re-cuis, et review le diff comme n'importe quel autre changement. L'objectif est une forêt qui ne change que quand un humain le décide, et dont chaque changement est visible et revuable : le même standard que tu tiendrais à n'importe quelle autre partie du niveau. Procédural pour la vitesse, cuit pour la stabilité : c'est tout le truc.
Chiffres de terrain à voler
- Règle de déterminisme : mêmes entrées → même sortie, toujours, ou ton niveau dérive
- Un seed rend l'aléatoire répétable : expose-le, sauvegarde-le, verrouille-le
- Une dispersion procédurale vivante est une boîte noire pour Git/Perforce : indiffable, non-mergeable
- Cuire vers des instances natives → diffable, revuable, mergeable, identique partout
- Habitude d'équipe : verrouille le seed → cuis → committe ; re-disperse délibérément, jamais par accident
Mini-FAQ
Ne puis-je pas juste garder la dispersion procédurale et ne jamais cuire ? Pour un projet solo rapide, peut-être. Pour une équipe ou quelque chose que tu maintiendras, non : tu perds le diffing, la review et le merge sûr, et tu risques une dérive silencieuse. La cuisson est ce qui rend la dispersion procédurale sûre pour la production.
Que dois-je exactement mettre sous contrôle de source : les réglages ou le résultat ? Le résultat cuit est la source de vérité ; garde les réglages/seed aussi pour pouvoir régénérer délibérément. Ne committer que les réglages signifie que le contrôle de source ne peut pas voir ce qui a réellement changé dans le niveau.
Deux artistes ont édité la même forêt : comment mergeons-nous ? Avec des instances cuites, ce sont des données de scène ordinaires et tes outils de merge normaux s'appliquent. Avec un générateur vivant, c'est souvent insoluble : ce qui est l'argument central pour cuire avant de committer et coordonner qui possède une dispersion donnée.
La cuisson me coûte-t-elle la capacité de peaufiner plus tard ? Non, garde le seed et les paramètres, et re-cuire est une étape délibérée à chaque fois que tu veux changer l'arrangement. Tu obtiens itération et stabilité, tant que le re-scatter est une action intentionnelle et revuée plutôt que quelque chose qui arrive tout seul.
La dispersion procédurale gagne sa place seulement quand elle est reproductible. Verrouille tes seeds, cuis vers des instances natives, et traite ce résultat cuit comme la vérité du niveau, et ta forêt devient quelque chose sur quoi une équipe entière peut construire : rapide à auteur, stable à livrer, et sûre à changer seulement quand quelqu'un le veut.
