Kısaca: Prosedürel dağıtım yalnızca tekrarlanabilir olursa güvenilirdir: aynı girdiler her makinede ve her build'de her zaman aynı ormanı üretmelidir. Bu, seed'leri anlamak (rastgeleliği nasıl tekrarlanabilir kılacağını), yaşayan bir prosedürel sistemin kaynak kontrolü altında neden tehlikeli olduğunu ve bir dağıtımı native motor instance'larına pişirmenin neden birleştirilemez bir kara kutuyu diffable, incelenebilir, sürüm kontrol edilebilir bir varlığa dönüştürdüğünü anlamak demektir. Bu makale determinizmi, seed'leri ve bir ekibin bitki örtüsünün herkesin ayakları altında sessizce değişmesini nasıl önleyeceğini kapsar.
Bu rastgele görünüyor ama bir ekip için tekrarlanabilir rastgele olmalı: senin makinende, takım arkadaşınınkinde ve build sunucusunda aynı. Determinizm, güzel bir dağıtımı gerçekten shipleyip sürdürebileceğin bir şeye dönüştüren şeydir.
Determinizm neden önemli
Bir dağıtım her açıldığında veya inşa edildiğinde farklı yeniden oluşuyorsa, seviyen sessizce değişir: çarpışmalar hareket eder, gizli nesneler belirir, playtestler tekrarlanabilir olmaktan çıkar. Deterministik dağıtım, aynı girdilerden her zaman tam olarak aynı sonucu üretir.
Tekrarlanabilir olmayan rastgelelik bir seviyede bir hata fabrikasıdır. Sahneyi başka bir makinede açmak veya haftaya yeniden inşa etmek her taşın ve çalının nereye düştüğünü yeniden karıştırırsa, o zaman açık olan bir yer şimdi tıkanmıştır, ayarladığın bir görüş hattı kırılmıştır ve bir playtest sonucuna güvenilemez çünkü test edilen seviye shipley'lediğin seviye değildir. Determinizm, yani aynı girdiler, aynı çıktı, her zaman, prosedürel dağıtımı güvenli kılan şeydir. "Bilgisayar bazı bitkiler yerleştirdi" ile "seviyenin güvenebileceğim tanımlı, sabit bir durumu var" arasındaki fark budur.
Seed'ler: rastgeleliği tekrarlanabilir kılmak
Bir seed rastgele bir sıra için başlangıç sayısıdır. Aynı seed → her zaman aynı "rastgele" yerleşim. Seed'i açığa çıkar ve kaydet, dağıtımın tekrarlanabilir olur; onu gerçek rastgeleliğe bırak ve her çalıştırmada farklı bir seviye olur.
Bilgisayarlar gerçek rastgelelik yapmaz, rastgele görünen deterministik sıralar çalıştırırlar, her sıra seed denen bir başlangıç sayısıyla tanımlanır. Aynı seed'i besle ve aynı sırayı, dolayısıyla aynı yerleşimi, her seferinde alırsın. Bu tekrarlanabilir dağıtımın anahtarıdır: araç bir seed açığa çıkarır, onu sahneyle kaydedersin ve orman artık (seed + parametreler + yüzey) fonksiyonudur. Beğendiğin farklı bir düzenlemeyi keşfetmek için seed'i değiştir, sonra kilitle. Bunun yerine gerçekten seed'siz bir rastgele kaynaktan çeken herhangi bir şey (saatten, her açılışta taze bir atıştan) her yüklendiğinde farklı bir seviye üretir ve bu üretim için kullanılamaz.
Sürüm kontrolü problemi
"sistem + parametreler" olarak depolanan yaşayan prosedürel bir dağıtım kaynak kontrolü için bir kara kutudur: diff'leyemez, inceleyemez, ve iki kişi onu düzenlerse birleştirilemez bir çakışma üretir. Ekipler dağıtımı Git veya Perforce'un gerçekten izleyebileceği bir formda ister.
Dağıtımın bir ekibin gerçekliğiyle karşılaştığı yer burasıdır. Ormanın yalnızca "bu ayarlarla bir dağıtım sistemi" olarak varsa, kaynak kontrolü ne ürettiğini göremez, yalnızca bazı parametrelerin değiştiğini görür. Bir yerleşim değişikliğini pull request'te inceleyemez, neyin hareket ettiğini söyleyemez ve iki sanatçı aynı dağıtıma dokunursa, hiçbir aracın anlamlı çözemeyeceği bir merge çakışması alırsın. Yalnızca yaşayan bir üretici içinde yaşayan dağıtılmış bir seviye, ekiplerin güvenli işbirliği için güvendiği tam sistemlere görünmezdir, bu yüzden "hepsi prosedürel" sessizce "kimse ormanı güvenle düzenleyemez" olabilir.
Bunların her biri konum, dönüş ve ölçekli bir instance'dır. Dağıtım native instance'lara pişirildiğinde, bunlar gerçek, incelenebilir veri olur; orman bir formül olmaktan çıkar ve satır satır inceleyebileceğin bir şey olur.
Pişirmek onu diff'lenebilir kılar
Dağıtımı native motor instance'larına pişir: somut dönüşümlerle gerçek yerleştirilmiş nesneler elde edersin. Şimdi bunlar sıradan sahne verisidir: diffable, incelenebilir, mergeable ve her makinede aynı çünkü depolanmıştır, yeniden üretilmemiştir.
Hem determinizmin hem de sürüm kontrolünün çözümü aynı harekettir: pişirmek. Yaşayan bir üreticiyi shipley'lemek yerine, dağıtımı basit native motor instance'larına pişirirsin: sahnede depolanmış somut konumlar, dönüşler ve ölçeklerle gerçek yerleştirilmiş meshler. Bu her problemi bir kerede çökertir. Tanım gereği deterministiktir (depolanmış veridir, yeniden atış değil). Diff'lenebilir (kaynak kontrolü değişen somut dönüşümleri görür). İncelenebilir (bir lead bir pull request'te tam olarak neyin hareket ettiğini görebilir). Ve çalışma zamanında motora olağandışı bir şey mal olmaz, çünkü sadece instance'lanmış meshlerdir. Kurallarla yoğunluğu boyayıp sonra native instance'lara pişiren bir workflow, tam da Numivo'nun çalıştığı gibi, sana prosedürel dağıtımın yazma hızını ve elle yerleştirilmiş içeriğin sabitliğini kara kutunun kırılganlığı olmadan verir.
Bir ekibin bitki örtüsünü sabit tutmak
Seed'leri kilitle, commit'ten önce pişir ve pişirilmiş sonucu doğrunun kaynağı olarak muamele et. Kasıtlı olarak yeniden dağıt (seed'i artır, diff'i incele), kazayla değil; böylece orman yalnızca birisi istediğinde değişir.
Bir ekip için pratik disiplin kısadır. Dağıtımın tekrarlanabilir olması için seed'i kilitle. Kaynak kontrolündeki şey herkesin paylaştığı somut sonuç olsun ve makine başına yeniden atan bir tarif olmasın diye commit'ten önce pişir. Pişirilmiş instance'ları doğrunun kaynağı olarak muamele et: incelediğin ve shipley'lediğin şey budur. Ve ormanı değiştirmek istediğinde, kasıtlı yap: parametreleri veya seed'i ayarla, yeniden pişir ve diff'i başka herhangi bir değişiklik gibi incele. Amaç yalnızca bir insanın olmalı diye karar verdiğinde değişen ve her değişikliği görünür ve incelenebilir olan bir orman; seviyenin başka herhangi bir bölümüne tutacağın aynı standart bu. Hız için prosedürel, sabitlik için pişirilmiş: tüm püf noktası bu.
Çalınmaya değer saha rakamları
- Determinizm kuralı: aynı girdiler → aynı çıktı, her zaman; yoksa seviyen sürüklenir
- Bir seed rastgeleliği tekrarlanabilir kılar: açığa çıkar, kaydet, kilitle
- Yaşayan bir prosedürel dağıtım Git/Perforce için bir kara kutudur: diffable değil, mergeable değil
- Native instance'lara piş → diffable, incelenebilir, mergeable, her yerde aynı
- Ekip alışkanlığı: seed'i kilitle → piş → commit; kasıtlı yeniden dağıt, asla kazayla değil
Mini-SSS
Dağıtımı sadece prosedürel tutup asla pişirmeyebilir miyim? Hızlı bir tek kişilik proje için, belki. Bir ekip veya sürdüreceğin bir şey için hayır: diffing, inceleme ve güvenli merge'i kaybedersin ve sessiz sürüklenmeyi riske atarsın. Pişirmek prosedürel dağıtımı üretim için güvenli kılan şeydir.
Kaynak kontrolüne tam olarak ne koymalıyım, ayarları mı sonucu mu? Pişirilmiş sonuç doğrunun kaynağıdır; ayarları/seed'i de kasıtlı olarak yeniden üretebilmek için tut. Yalnızca ayarları commit etmek, kaynak kontrolünün seviyede gerçekten neyin değiştiğini göremeyeceği anlamına gelir.
İki sanatçı aynı ormanı düzenledi, nasıl merge ederiz? Pişirilmiş instance'larla, bunlar sıradan sahne verisidir ve normal merge araçların uygulanır. Yaşayan bir üreticiyle, sıklıkla çözülemez; bu, commit'ten önce pişirme ve belirli bir dağıtımın sahibinin kim olduğunu koordine etme için merkezi argümandır.
Pişirmek bana sonra ince ayar yapma yeteneğini kaybettirir mi? Hayır, seed ve parametreleri tut, ve yeniden pişirmek düzenlemeyi değiştirmek istediğinde kasıtlı bir adımdır. Yeniden dağıtma kendi başına olan bir şey olmaktan çok, kasıtlı, incelenmiş bir eylem olduğu sürece iterasyon ve sabitlik alırsın.
Prosedürel dağıtım yerini yalnızca tekrarlanabilir olduğunda kazanır. Seed'lerini kilitle, native instance'lara piş ve o pişirilmiş sonucu seviyenin gerçeği olarak muamele et; o zaman orman, bütün bir ekibin üzerine inşa edebileceği bir şey olur: yazması hızlı, shipley'lemesi sabit ve yalnızca birisi istediğinde değiştirmesi güvenli.
