เหตุใดจึงต้องใช้ไฟล์รายการเนื้อหา

บางครั้งคุณจะเห็นคนแนะนำว่าแทนที่จะใช้กราฟิก / ไฟล์เสียง / ฯลฯ แบบนี้...

// Game code
Image myImage = new Image("path/to/image.png");

... คุณควรใช้ไฟล์Manifestเป็นระดับทางอ้อมแทน:

// Manifest file
MY_IMAGE: path/to/image.png

// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");

ฉันจะมีเหตุผลอะไรในการทำแนวทางนี้ หากฉันไม่ได้ใช้ภาษาที่คอมไพล์แล้วจะมีเหตุผลที่จะทำเช่นนี้หรือไม่?

ไฟล์รายการเวลาส่วนใหญ่จะเชื่อมโยงกับรูปแบบไฟล์เก็บถาวรบางประเภท ตัวอย่างเช่นไฟล์ JAR ใน java เป็นเพียงไฟล์ zip ที่มีไฟล์รายการที่แสดงรายการเนื้อหาภายในไฟล์ zip และตำแหน่งที่จะค้นหา ในกรณีนั้น "path / to / image.png" ไม่ใช่เส้นทางระบบไฟล์จริง แต่เป็นข้อมูลเกี่ยวกับวิธีการค้นหาวัตถุภายในไฟล์บีบอัดที่ถูกบีบอัดแทน นอกเหนือจากข้อได้เปรียบของพื้นที่ดิสก์ในการบีบอัดการใช้ไฟล์เก็บถาวรสามารถปรับปรุงประสิทธิภาพได้เนื่องจาก windows มีเวลาที่ยากมากในการจัดการกับไฟล์แต่ละไฟล์เป็นหมื่นในไดเรกทอรีจำนวนน้อย

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

ตอนนี้หากคุณใช้ภาษาที่ไม่ได้รวบรวมไฟล์รายการนี้อาจเป็นไฟล์ต้นฉบับ C # ได้อย่างแน่นอน แต่ก็ดีถ้าคุณสามารถแก้ไขไฟล์ Manifest ที่คุณกำลังใช้งานได้อย่างง่ายดาย ณ เวลาที่ทำการเรียกใช้ไคลเอนต์ตามการตั้งค่ารีจิสตรี ตัวอย่างเช่นคุณสามารถตรวจสอบในระหว่างการดำเนินการเพื่อดูว่าแคชบนฮาร์ดไดรฟ์มีอยู่หรือไม่หรือเฉพาะดีวีดีที่มีอยู่ จากนั้นคุณสามารถสลับรายการที่จะใช้ขึ้นอยู่กับการตั้งค่าที่มี

เหตุผลหนึ่ง: การเขียนโปรแกรมขับเคลื่อนข้อมูล

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

<material name="wood">
  <diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
  <normals>environment.zip/wood_normals.jpg</normals>
  <shader>environment.zip/wood.fx</shader>
  <specular color="1,1,1,1" power="0.5" flat="yes" />
</material>

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

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

ไฟล์เก็บถาวรจำเป็นต้องใช้รายการเพราะเพียงสารบัญของไฟล์เก็บถาวรนั้นเป็นรายการเองดังนั้นคุณจะได้รับพฤติกรรมฟรี และหากคุณจำเป็นต้องใช้รายการสำหรับสินทรัพย์ในที่เดียวมันอาจสะอาดกว่าที่จะยืนยันว่าสินทรัพย์ทั้งหมดถูกอ้างอิงผ่านรายการ ช่วยให้คุณสามารถสรุปที่ตั้ง / กลไกการจัดเก็บที่แท้จริงของสินทรัพย์จากการอ้างอิงไปยังสินทรัพย์เหล่านั้นในรหัส ด้วยวิธีนี้คุณสามารถมีประเภทอ้างอิงเนื้อหาเดียวในรหัสของคุณและไม่จำเป็นต้องแยกความแตกต่างระหว่างเส้นทางของไฟล์เส้นทางไฟล์เก็บถาวร + ออฟเซ็ตหรือสินทรัพย์ย่อย

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

ไฟล์มานิเฟสต์ให้เลเยอร์ของการอ้อมระหว่างชื่อทรัพยากรและที่ตั้ง หลังจากเลเยอร์ทางอ้อมที่เพิ่มขึ้นเป็นเพียงสัญลักษณ์ของการออกแบบ อย่างไรก็ตามบางครั้งเลเยอร์เพิ่มเติมนั้นเป็นสิ่งที่จำเป็นในการสร้างโซลูชันที่หรูหราและมีประสิทธิภาพ

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

ฉันไม่ต้องการกระจายเกมด้วยสินทรัพย์ที่กระจัดกระจาย ดังนั้นเมื่อฉันพร้อมที่จะเผยแพร่มันฉันสามารถบีบอัดสินทรัพย์ของฉันลงในไฟล์ทรัพยากรและสร้างรายการใหม่ได้อย่างง่ายดาย

แผนที่เนื้อยังเป็นวิธีที่ดีในการบีบประสิทธิภาพออกเล็กน้อยจากระบบกราฟิก แผนที่โลกเป็นไปอย่างรวดเร็ว แต่พวกเขาก็เจ็บปวดที่จะทำงานด้วยในขณะที่งานศิลปะยังอยู่ระหว่างการพัฒนา ทางออกของฉันคือสร้างแผนที่ตอนท้ายเมื่อฉันปรับเกมให้เหมาะสมที่สุด เนื่องจากฉันใช้รายการทั้งหมดที่ฉันต้องทำคืออัปเดตรายการให้ชี้ไปที่ตำแหน่งแอตลาสและvoilàเกมใช้ atlases แทนไฟล์แบบตรง