การควบคุมแหล่งที่มาสำหรับจัดเก็บทุกสิ่งในโครงการเกมหรือไม่


10

เป็นเรื่องปกติที่จะจัดการไม่เพียง แต่ซอร์สโค้ด แต่เนื้อหาพื้นผิวศิลปะไฟล์เอกสาร ฯลฯ ภายใต้ที่เก็บ git สำหรับการควบคุมเวอร์ชันหรือไม่? ตัวอย่างเช่นฉันต้องการกลับไปใช้พื้นผิวแบบเก่า หากเป็นการปฏิบัติที่ไม่ดีมากคุณใช้เครื่องมือใดในการควบคุมเวอร์ชันของเนื้อหาและเนื้อหาอื่น ๆ


ที่เกี่ยวข้อง: gamedev.stackexchange.com/questions/35949/…
MichaelHouse

1
ซอร์สโค้ดคือทุกสิ่งที่คุณไม่สามารถสร้างได้จากซอร์สโค้ด เนื้อหาพื้นผิวงานศิลปะและเอกสารประกอบยังเป็นซอร์สโค้ดภายใต้คำจำกัดความนั้น
Christoffer Hammarström

คำตอบ:


12

ฉันจะบอกว่ามันเป็นวิธีปฏิบัติที่ดีมาก ควรใช้การควบคุมแหล่งที่มาสำหรับแหล่งที่มาและสินทรัพย์ คุณสามารถนึกถึงมันเหมือนการแบ็คอัพคุณต้องการที่จะกู้คืนจากการควบคุมทุกอย่างที่จำเป็นในการสร้างเกม

ฉันเชื่อมโยงคำถามที่เกี่ยวกับการจัดเก็บเนื้อหาในที่เก็บ มีที่เก็บบางแห่งที่ทำงานได้ดีกว่าที่อื่นเพื่อเก็บงานศิลปะ พวกเขาจะอนุญาตให้คุณ "กระจาย" ศิลปะและดูว่ามีอะไรเปลี่ยนแปลง คนอื่น ๆ จะปฏิบัติต่อสินทรัพย์เป็นข้อมูลไบนารีดังนั้นคุณจะต้องตรวจสอบเพื่อดูว่ามีอะไรที่แตกต่างกัน นอกจากนี้ยังหมายความว่าคุณจะต้องอัปโหลดเนื้อหาทั้งหมดเมื่อมีการเปลี่ยนแปลงเนื่องจากที่เก็บจะไม่สามารถ "รู้" (แยกวิเคราะห์) สิ่งที่เปลี่ยนแปลงระหว่างเวอร์ชัน

ฉันเก็บทุกอย่างไว้ในที่เก็บ เมื่อฉันได้แล็ปท็อปเครื่องใหม่ฉันสามารถตรวจสอบที่เก็บข้อมูลของฉันและสร้างเกมของฉันได้โดยไม่จำเป็นต้องคัดลอกเนื้อหาจากที่อื่น นั่นหมายความว่าฉันยังเก็บไลบรารีทรัพย์สินและการควบคุมแหล่งข้อมูลของบุคคลที่สามไว้ในที่เก็บของฉันด้วย


7

Git นั้นยอดเยี่ยมสำหรับไฟล์ที่ไม่ใช่ข้อความ การโคลน repo git ต้องการดาวน์โหลดไฟล์ประวัติรุ่นทั้งหมดยกเว้นว่าใช้นามสกุลไฟล์ขนาดใหญ่ (ไม่ใช่แบบมาตรฐานมักไม่รองรับโดย GUIs) หรือคำสั่งพิเศษ (ต้องเป็นกูรู git ที่ต้องทำ) เช่นเดียวกันกับระบบ DVCS ส่วนใหญ่ สำหรับพื้นผิวแบบจำลองหรือคลิปเสียงหมายถึงการดึงสำเนาหลายไฟล์ที่มีขนาดใหญ่มาก เนื้อหา 1GB สามารถเป็น 200GB ของข้อมูลการแก้ไขที่ผ่านมาได้อย่างง่ายดายและ git ทำให้คุณดาวน์โหลดได้ทุกเมื่อเมื่อคุณคัดลอก repo ใหม่และดาวน์โหลดการแก้ไขระดับกลางทั้งหมดเมื่อคว้าข้อมูลล่าสุด สิ่งนี้จะกลายเป็นคอขวดขนาดใหญ่เมื่อคุณสามารถทนต่อความล่าช้าในการผลิตได้น้อยที่สุด

การโค่นล้ม Perforce และอื่น ๆ เป็นตัวเลือกที่ดีกว่าสำหรับสินทรัพย์เนื่องจากต้องการเพียงการดาวน์โหลดการแก้ไขที่ต้องการ (โดยปกติแล้วล่าสุด) คุณสามารถใช้พวกเขาสำหรับสินทรัพย์และใช้ git สำหรับรหัสหรือใช้พวกเขาสำหรับแหล่งที่มาด้วย Perforce มีคุณสมบัติบางอย่างที่ให้มันทำหน้าที่เหมือน DVCS ที่ดูน่าเบื่อและดีกว่าฟังก์ชั่น SVN (แม้ว่าจะมีความซับซ้อนมากกว่า) ในประสบการณ์ของฉัน แต่ค่าใช้จ่ายหมายความว่าคุณน่าจะใช้ Subversion

ผู้เชี่ยวชาญด้านเนื้อหาส่วนใหญ่มีความต้องการ DVCS เพียงเล็กน้อยและบางคนมีปัญหากับแม้แต่พื้นฐานของ VCS คลาสสิกอยู่ดี อย่าอานด้วยคอมไพล์ หรือ Mercurial, DARCS เป็นต้น


จุดดี แต่คุณสามารถโคลนได้โดยไม่ต้องดึงข้อมูลประวัติstackoverflow.com/questions/11497457/ ทั้งหมด
อาลี

1
@Ali: โคลนตื้นไม่ได้แก้ปัญหาอย่างเพียงพอ (พวกเขาปิดการใช้งานคำสั่งจำนวนมากไม่ใช่ค่าเริ่มต้นสำหรับ GUIs ส่วนใหญ่ ฯลฯ ) และไร้ประโยชน์เป็นหลักสำหรับสิ่งต่างๆนอกเหนือจากเซิร์ฟเวอร์ CI และสิ่งที่คล้ายกัน วิธีแก้ปัญหา git ที่ใหม่กว่าเช่น git-lfs ได้เกิดขึ้นเพื่อแก้ไขปัญหาที่ฉันอธิบายไว้ในความพยายามที่จะนำทีมงานที่มีเนื้อหามากไปสู่ ​​git
Sean Middleditch

git lfsแก้ปัญหา "ไฟล์ไบนารีขนาดใหญ่" ได้เป็นอย่างดี
Nepoxx

3

เป็นแนวปฏิบัติที่ดีแม้ในฐานะศิลปินเมื่อคุณทำงานในโครงการที่มีแนวโน้มว่าจะมีรูปแบบการควบคุมเวอร์ชันความเสียหายของไฟล์หรือข้อผิดพลาดเกิดขึ้นโดยที่ศิลปินไม่มีการควบคุมแหล่งที่มามักจะทำการแก้ไขบันทึกใด ๆ ก็ตาม

ตัวอย่างในโลกแห่งความเป็นจริงที่คุณเห็นนี่คือโครงการภาพยนตร์เปิดที่สร้างขึ้นด้วย Blender (Big Buck Bunny, Durian, ฯลฯ )

ไปป์ไลน์สำหรับเกมนั้นมีความเหมือนกันไม่มากก็น้อยเว้นแต่อาจมีขั้นตอนการสร้างสำหรับสินทรัพย์เพื่อทำการแปลงจากข้อมูลไขมันขนาดใหญ่ไปเป็นรูปแบบเฉพาะของเครื่องยนต์เช่นการบีบอัดพื้นผิวและการแปลงรูปแบบโมเดล

เครื่องมือบางอย่างเช่น GitHub ยังเสนอเครื่องมือเปรียบเทียบภาพที่ดีและเหมือนกันซึ่งดีกว่าการเปรียบเทียบไบนารีหยด

เนื่องจากที่เก็บสินทรัพย์มีขนาดใหญ่มากการตั้งค่าของฉัน / เราคือการเก็บที่เก็บสินทรัพย์แยกต่างหากซึ่งเป็น submodule ในที่เก็บโครงการ คุณไม่ต้องการที่จะดึงลงกิกะไบต์ของสินทรัพย์เมื่อทั้งหมดที่คุณต้องการคือการแยกแหล่งที่มาเช่น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.