การจัดการสินทรัพย์ฐานข้อมูลหรือระบบการกำหนดเวอร์ชัน?

ในขณะที่กำลังพัฒนาสินทรัพย์สำหรับเกม (meshes, พื้นผิว, เสียง, วิดีโอ) คุณจัดการกับมันได้หรือไม่?

1. ทำให้พวกเขาพร้อมกับซอร์สโค้ดภายในระบบเวอร์ชันหรือไม่ (จำเป็นต้องใช้คอมไพล์ ฯลฯ …)
2. หรือมี back-upped กลางฐานข้อมูลที่ทุ่มเทให้กับสินทรัพย์และมีบรรณาธิการชอบทำงานเสมอหรือไม่ (PostgreSQL, MySQL, ฯลฯ …)
3. อื่น ๆ ?

ข้อดีและข้อเสียของแต่ละคนคืออะไรและทำไมจึงควรเลือกสิ่งอื่น ๆ

สำหรับเราหลายคน - โดยเฉพาะอย่างยิ่งการทำงานในการเล่นเกมที่มีขนาดเล็ก - คุณแน่นอนควรมีสินทรัพย์ในที่เก็บเช่นเดียวกับแหล่งที่มาของ

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

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

ตัวอย่างเช่น: รหัสของคุณอาจคาดว่าจะสามารถตั้งค่าพารามิเตอร์บน shader และ shader นั้นอาจขึ้นอยู่กับพื้นผิวที่มี หรือบางทีรูปแบบข้อมูลของระดับของคุณอาจขึ้นอยู่กับรหัสเกมของคุณ

มันเกือบจะยุ่งแน่นอน และคุณมีสิ่งที่ดีกว่าที่จะทำมากกว่าที่จะพยายามทำให้เป็นระเบียบ

ตอนนี้ตามที่ Mike Wagner แสดงความคิดเห็น ( คำตอบนี้ ) - คุณไม่ต้องการหรือจำเป็นต้องใช้เนื้อหาทั้งหมดของคุณภายใต้การควบคุมเวอร์ชัน! เพียงแค่รุ่นสุดท้าย / การทำงานที่ใช้โดยรหัสของคุณจะทำ - บ่อยครั้งที่สิ่งนี้คือสิ่งที่คุณส่งออกจากเครื่องมือของคุณ

(แม้ว่าถ้าคุณต้องการควบคุมเวอร์ชันของสินทรัพย์ที่อยู่ระหว่างดำเนินการ - ก็ดีและเหมาะกับที่เก็บแยกต่างหากโดยส่วนตัวฉันพบว่าการจัดระเบียบโฟลเดอร์ที่ดีและระบบสำรองข้อมูลที่เหมาะสมนั้นพอเพียง)

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

ระบบการกำหนดเวอร์ชัน

ด้วยแนวทางแบบม้วนของคุณเองคุณจะต้องจบการวางระบบเวอร์ชันอย่างมีประสิทธิภาพดังนั้นควรใช้ชั้นวางที่มีการออกแบบ / รหัส / ทดสอบมานานหลายปี

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

ไฟล์ Mark XML เป็นเครื่องมือไบนารีรวมที่มีแนวโน้มจะแย่มากในการผสานมาร์กอัปที่ซ้อนกันและศิลปินไม่น่าจะเห็นมาร์กอัปที่เสียหายถ้าเครื่องมือคิดว่าไม่มีความขัดแย้งกัน

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

ทุกอย่างในที่เก็บเดียวถ้าคุณสามารถซื้อได้ในแง่ของขนาด ฉันเคยได้ยินคลังเก็บของการโค่นล้มในบริเวณใกล้เคียง 1 TB ขณะนี้เรามีขนาดต่ำกว่า 400 GB

นอกจากนี้ศิลปินยังเช็คอินทุกอย่างรวมถึงแนวคิดคร่าวๆ 30 ข้อ; เราใช้โครงสร้างโฟลเดอร์แยกกันสำหรับ "แหล่งเนื้อหา" และ "ส่งออก" - รายการที่เข้าสู่สคริปต์การสร้างเนื้อหา หากวันพรุ่งนี้ศิลปินของคุณโดนรถบัสคุณจะต้องมีใครบางคนทำงานต่อในทรัพย์สินของเขาในวันถัดไปเพียงมองผ่านพื้นที่เก็บข้อมูล (ไม่มีโบราณคดีบนเครื่องส่วนตัวของเขา) กาลครั้งหนึ่งเมื่อเกมเป็น 2D และสไปรต์ได้รับการแสดงผลล่วงหน้าจากฉาก Max ที่ซับซ้อนเราต้องส่งหน่วยจำนวนมากในเกม RTS ที่มีเส็งเคร็งและดูไม่สอดคล้องกัน (เทียบกับหน่วยอื่น ๆ ) แม้ว่ามันจะเป็นเรื่องของการเรนเดอร์ใหม่ด้วยการตั้งค่าแสงและการลดรอยหยักที่แตกต่างกันเล็กน้อย - เพราะศิลปินดั้งเดิมเลิกแล้วและเราไม่มีฉากแม็กซ์ดั้งเดิมของเขา ดอน'