สรุป: การกระจายเชิงกระบวนการเชื่อถือได้เฉพาะเมื่อ ทำซ้ำได้ อินพุตเดียวกันต้องผลิต ป่าเดียวกันเสมอ ในทุกเครื่องและทุกบิลด์ นั่นหมายถึงเข้าใจ seed (วิธีทำให้การสุ่มทำซ้ำได้) ทำไมระบบเชิงกระบวนการที่มีชีวิตจึงอันตรายภายใต้การควบคุมซอร์ส และทำไมการอบการกระจายเป็น อินสแตนซ์เอนจินเนทีฟถึงเปลี่ยนกล่องดำที่ merge ไม่ได้ให้เป็นสินทรัพย์ที่ diff, review และ ควบคุมเวอร์ชันได้ บทความนี้ครอบคลุมดีเทอร์มินิสม์ seed และวิธีป้องกันไม่ให้ใบไม้ของทีม เปลี่ยนแปลงเงียบๆ ใต้เท้าทุกคน
มันดูเหมือนสุ่ม แต่สำหรับทีมมันต้องเป็นการสุ่ม ที่ทำซ้ำได้ เหมือนกันในเครื่องคุณ เครื่อง เพื่อนร่วมทีม และบิลด์เซิร์ฟเวอร์ ดีเทอร์มินิสม์คือสิ่งที่เปลี่ยนการกระจายที่สวยเป็นสิ่งที่คุณ สามารถ ship และบำรุงรักษาได้จริงๆ
ทำไมดีเทอร์มินิสม์ถึงสำคัญ
ถ้าการกระจายสร้างใหม่แตกต่างกันทุกครั้งที่เปิดหรือบิลด์ เลเวลของคุณเปลี่ยนแปลง เงียบๆ การชนกันเคลื่อนที่ วัตถุที่ซ่อนอยู่ปรากฏ playtest หยุดเป็นสิ่งที่ทำซ้ำได้ การกระจาย ดีเทอร์มินิสติกผลิตผลลัพธ์เดียวกันแน่นอนจากอินพุตเดียวกันเสมอ
การสุ่มที่ทำซ้ำไม่ได้คือโรงงานผลิตบั๊กในเลเวล ถ้าการเปิดฉากในเครื่องอื่น หรือการสร้างมันใหม่ สัปดาห์หน้า สับใหม่ว่าหินและพุ่มไม้แต่ละอันตกที่ไหน จุดที่เคยว่างตอนนี้ถูกปิดกั้น เส้นสายตาที่ คุณปรับแต่งถูกทำลาย และผลลัพธ์ playtest ไม่สามารถเชื่อถือได้เพราะเลเวลที่ทดสอบไม่ใช่เลเวลที่ คุณ ship ดีเทอร์มินิสม์ (อินพุตเดียวกัน เอาต์พุตเดียวกัน เสมอ) คือสิ่งที่ทำให้การกระจาย เชิงกระบวนการ ปลอดภัย มันคือความแตกต่างระหว่าง "คอมพิวเตอร์วางพืชบางต้น" และ "เลเวลมีสถานะ ที่กำหนดและมั่นคงที่ฉันสามารถพึ่งพาได้"
Seed: ทำให้การสุ่มทำซ้ำได้
seed คือตัวเลขเริ่มต้นสำหรับลำดับสุ่ม seed เดียวกัน → การวาง "สุ่ม" เดียวกันทุกครั้ง เปิดเผยและบันทึก seed และการกระจายของคุณทำซ้ำได้; ปล่อยให้เป็นการสุ่มจริงและมันเป็นเลเวล ที่แตกต่างกันในทุกการรัน
คอมพิวเตอร์ไม่ทำการสุ่มจริง (มันรันลำดับดีเทอร์มินิสติกที่ ดูเหมือน สุ่ม แต่ละลำดับกำหนด โดยตัวเลขเริ่มต้นเรียกว่า seed ป้อน seed เดียวกันและคุณได้ลำดับเดียวกัน ดังนั้นการวาง เดียวกัน ทุกครั้ง นี่คือกุญแจสู่การกระจายที่ทำซ้ำได้: เครื่องมือเปิดเผย seed คุณบันทึกมันกับ ฉาก และป่าตอนนี้เป็นฟังก์ชันบริสุทธิ์ของ (seed + พารามิเตอร์ + พื้นผิว) เปลี่ยน seed เพื่อ สำรวจการจัดเรียงที่แตกต่างกันที่คุณชอบ จากนั้นล็อค อะไรก็ตามที่กลับดึงจากแหล่งสุ่มที่ไม่มี seed จริงๆ) นาฬิกา การทอยใหม่ทุกครั้งที่เปิด ผลิตเลเวลที่แตกต่างกันทุกครั้งที่โหลด ซึ่ง ใช้ในการผลิตไม่ได้
ปัญหาการควบคุมเวอร์ชัน
การกระจายเชิงกระบวนการที่มีชีวิตที่เก็บเป็น "ระบบ + พารามิเตอร์" เป็นกล่องดำ สำหรับการควบคุมซอร์ส: คุณไม่สามารถ diff, review และสองคนที่แก้ไขผลิตความขัดแย้งที่ merge ไม่ได้ ทีมต้องการการกระจายในรูปแบบที่ Git หรือ Perforce สามารถติดตามได้จริงๆ
นี่คือที่การกระจายพบกับความจริงของทีม ถ้าป่าของคุณมีอยู่เพียงในฐานะ "ระบบการกระจายที่มี การตั้งค่านี้" การควบคุมซอร์สไม่สามารถเห็น อะไร ที่มันผลิต เพียงว่าพารามิเตอร์บางตัว เปลี่ยน คุณไม่สามารถ review การเปลี่ยนแปลงการวางในพูลริเควสต์ คุณไม่สามารถบอกว่าอะไร เคลื่อนที่ และถ้าศิลปินสองคนสัมผัสการกระจายเดียวกัน คุณได้ความขัดแย้ง merge ที่ไม่มีเครื่องมือ ใดสามารถแก้ไขได้อย่างมีความหมาย เลเวลที่กระจายซึ่งอยู่เพียงภายในตัวสร้างที่มีชีวิตนั้นมองไม่ เห็นสำหรับระบบที่ทีมพึ่งพาเพื่อร่วมมือกันอย่างปลอดภัย ซึ่งเป็นเหตุผลที่ "ทั้งหมดเป็นเชิงกระบวน การ" อาจกลายเป็น "ไม่มีใครสามารถแก้ไขป่าได้อย่างปลอดภัย" ได้อย่างเงียบ
แต่ละอันเหล่านี้เป็นอินสแตนซ์ที่มีตำแหน่ง การหมุน และมาตราส่วน เมื่อการกระจายถูกอบเป็น อินสแตนซ์เนทีฟ พวกมันกลายเป็นข้อมูลจริงที่ตรวจสอบได้ ป่าหยุดเป็นสูตรและกลายเป็นบางสิ่งที่ คุณสามารถ review บรรทัดต่อบรรทัด
การอบทำให้มัน diff ได้
อบการกระจายเป็นอินสแตนซ์เอนจินเนทีฟ วัตถุที่วางจริงพร้อมการแปลงที่เป็นรูปธรรม ตอนนี้มันเป็นข้อมูลฉากธรรมดา: diff, review, merge ได้ และเหมือนกันในทุกเครื่องเพราะมันถูก เก็บ ไม่ใช่สร้างใหม่
การแก้ไขทั้งดีเทอร์มินิสม์และการควบคุมเวอร์ชันเป็นการเคลื่อนไหวเดียวกัน: อบ แทนที่จะ ship ตัวสร้างที่มีชีวิต คุณอบการกระจายเป็นอินสแตนซ์เอนจินเนทีฟง่ายๆ (mesh จริงที่วางพร้อมตำแหน่ง การหมุน และมาตราส่วนที่เป็นรูปธรรมเก็บในฉาก สิ่งนี้ยุบทุกปัญหาพร้อมกัน มันเป็นดีเทอร์มินิสติก ตามคำจำกัดความ (มันเป็นข้อมูลที่เก็บ ไม่ใช่การทอยใหม่) มัน diff ได้ (การควบคุมซอร์สเห็น การแปลงที่เป็นรูปธรรมที่เปลี่ยน) มัน review ได้ (lead สามารถเห็นได้อย่างชัดเจนว่าอะไร เคลื่อนที่ในพูลริเควสต์) และมันไม่เสียค่าใช้จ่ายกับเอนจินอะไรที่ผิดปกติที่ runtime เพราะมัน เป็นเพียง mesh ที่ instance กระบวนการทำงานที่ทาความหนาแน่นด้วยกฎแล้ว อบเป็นอินสแตนซ์ เนทีฟ) วิธีที่ Numivo ทำงานพอดี ให้คุณความเร็วในการเขียนของการกระจาย เชิงกระบวนการ และ ความมั่นคงของเนื้อหาที่วางด้วยมือ โดยไม่มีความเปราะบางของกล่องดำ
รักษาใบไม้ของทีมให้มั่นคง
ล็อค seed อบก่อน commit และปฏิบัติต่อผลลัพธ์ที่อบเป็นแหล่งความจริง กระจายใหม่ โดยเจตนา (เพิ่ม seed, review diff) ไม่ใช่โดยบังเอิญ เพื่อให้ป่าเปลี่ยนเฉพาะเมื่อมีใครต้องการ
วินัยเชิงปฏิบัติสำหรับทีมสั้น ล็อค seed เพื่อให้การกระจายทำซ้ำได้ อบก่อน commit เพื่อ ให้สิ่งที่อยู่ในการควบคุมซอร์สเป็นผลลัพธ์ที่เป็นรูปธรรมที่ทุกคนแบ่งปัน ไม่ใช่สูตรที่ทอยใหม่ต่อ เครื่อง ปฏิบัติต่อ อินสแตนซ์ที่อบเป็นแหล่งความจริง (สิ่งที่คุณ review และ ship และเมื่อ คุณ ต้องการ เปลี่ยนป่า ทำโดยเจตนา: ปรับพารามิเตอร์หรือ seed อบใหม่ และ review diff เช่น เดียวกับการเปลี่ยนแปลงอื่นๆ เป้าหมายคือป่าที่เปลี่ยนเฉพาะเมื่อมนุษย์ตัดสินใจว่าควร และการ เปลี่ยนแปลงทุกอย่างมองเห็นได้และ review ได้) มาตรฐานเดียวกันที่คุณจะถือให้กับส่วนอื่นๆ ของ เลเวล เชิงกระบวนการสำหรับความเร็ว อบสำหรับความมั่นคง: นั่นคือเคล็ดลับทั้งหมด
ตัวเลขภาคสนามที่ควรขโมย
- กฎดีเทอร์มินิสม์: อินพุตเดียวกัน → เอาต์พุตเดียวกัน เสมอ หรือเลเวลของคุณลอย
- seed ทำให้การสุ่มทำซ้ำได้ เปิดเผย บันทึก ล็อค
- การกระจายเชิงกระบวนการที่มีชีวิตเป็น กล่องดำ สำหรับ Git/Perforce diff ไม่ได้ merge ไม่ได้
- อบเป็นอินสแตนซ์เนทีฟ → diff, review, merge ได้ เหมือนกันทุกที่
- นิสัยทีม: ล็อค seed → อบ → commit; กระจายใหม่โดยเจตนา ไม่โดยบังเอิญ
Mini-FAQ
ฉันไม่สามารถเก็บการกระจายเชิงกระบวนการและไม่อบเลยได้เหรอ? สำหรับโครงการเดี่ยวเร็ว อาจ จะ สำหรับทีมหรือสิ่งที่คุณจะบำรุงรักษา ไม่: คุณสูญเสีย diffing, review และ merge ที่ปลอดภัย และคุณเสี่ยงกับการลอยเงียบ การอบคือสิ่งที่ทำให้การกระจายเชิงกระบวนการปลอดภัยสำหรับการผลิต
ฉันควรใส่อะไรภายใต้การควบคุมซอร์สจริงๆ การตั้งค่าหรือผลลัพธ์? ผลลัพธ์ที่อบเป็นแหล่ง ความจริง เก็บการตั้งค่า/seed ด้วยเพื่อให้คุณสามารถสร้างใหม่โดยเจตนา การ commit เพียงการ ตั้งค่าหมายความว่าการควบคุมซอร์สไม่สามารถเห็นว่าอะไรเปลี่ยนจริงๆ ในเลเวล
ศิลปินสองคนแก้ไขป่าเดียวกัน (เรา merge อย่างไร? ด้วยอินสแตนซ์ที่อบ มันเป็นข้อมูลฉาก ธรรมดาและเครื่องมือ merge ปกติของคุณใช้ได้ ด้วยตัวสร้างที่มีชีวิต บ่อยครั้งแก้ไขไม่ได้) ซึ่ง เป็นข้อโต้แย้งหลักสำหรับการอบก่อน commit และการประสานงานว่าใครเป็นเจ้าของการกระจายที่กำหนด
การอบทำให้ฉันสูญเสียความสามารถในการปรับแต่งภายหลังไหม? ไม่ เก็บ seed และพารามิเตอร์ และการอบใหม่เป็นขั้นตอนที่เจตนาเมื่อไรก็ตามที่คุณต้องการเปลี่ยนการจัดเรียง คุณได้การวนซ้ำ และ ความมั่นคง ตราบใดที่การกระจายใหม่เป็นการกระทำที่ตั้งใจและ review แล้วมากกว่าสิ่งที่ เกิดขึ้นเอง
การกระจายเชิงกระบวนการได้ที่ของมันเฉพาะเมื่อมันทำซ้ำได้ ล็อค seed ของคุณ อบเป็นอินสแตนซ์ เนทีฟ และปฏิบัติต่อผลลัพธ์ที่อบนั้นเป็นความจริงของเลเวล และป่าของคุณจะกลายเป็นบางสิ่งที่ ทั้งทีมสามารถสร้างบนได้: เขียนรวดเร็ว ship มั่นคง และเปลี่ยนแปลงอย่างปลอดภัยเฉพาะเมื่อมีใคร ต้องการ
