Noel Llopis เกมส์จากภายในบล็อกสัมผัสเกี่ยวกับเรื่องนี้เมื่อเร็ว ๆ นี้ใน"เกมระยะไกลการแก้ไข" โพสต์ ย่อหน้าเปิด:
ฉันเป็นแฟนตัวยงของเกมเพียงเล็กน้อยเท่านั้น ทุกสิ่งที่สามารถทำได้แบบออฟไลน์หรือในเครื่องมือแยกต่างหากควรอยู่นอกรันไทม์ ที่ใบเกมสถาปัตยกรรมและรหัสมากลีนและเรียบง่าย
(บทความนี้เป็นบทความที่แนะนำให้อ่านเช่นเดียวกับเนื้อหาส่วนใหญ่ของโนเอลไม่ว่าคุณจะเห็นด้วย 100% หรือไม่ก็ตาม)
ฉันเชื่อว่ากุญแจสำคัญในที่นี้คือการรักษาความซับซ้อนภายนอกเครื่องยนต์ คุณยังสามารถมีความยืดหยุ่น แต่ก็มีความยืดหยุ่นในการส่งเนื้อหา และคุณจะได้ประสิทธิภาพที่ดีขึ้นโดยไม่ต้องเสียเวลาในการแปลงและย้ายข้อมูล
ประสิทธิภาพที่ดีขึ้นอาจทำให้เวลาในการทำซ้ำลดลงอย่างน่าประหลาดใจแม้ว่าจะมีความสามารถในการแก้ไขบางอย่างในเครื่องยนต์ลดลง: ลองทำอะไรสักอย่างง่ายขึ้นถ้าคุณสามารถโหลดเกมได้ในเวลาไม่นาน
การใช้หลักคำสอนบางส่วนของ " ปรัชญา unix " จะช่วยให้คุณรักษาความยืดหยุ่นของ toolchain: ไปป์ไลน์โมดูลาร์ขนาดเล็ก
ปรัชญาส่วนตัวของฉัน: อบข้อมูลให้มากที่สุดเท่าที่จะเป็นไปได้แบบออฟไลน์ แต่ให้การสนับสนุนเครื่องยนต์เพื่อรับข้อมูลอบใหม่ได้ตลอดเวลา (โปรดทราบว่าข้อมูลใหม่นี้ไม่จำเป็นต้องเล่นจนกว่าจะถึงจุดที่สะดวกสบาย: กดปุ่ม "รีเฟรช" ระดับถัดไปจะเริ่มขึ้นคุณจะเปลี่ยนไปสู่พื้นที่ใหม่ไม่ว่าอะไรก็ตามกุญแจคือการค้นหาจุดหวานที่ลดลง เวลาทำซ้ำโดยมีความซับซ้อนของรหัสขั้นต่ำและความพยายามในการเขียนโค้ด)
ที่ บริษัท ของเราเครื่องมือสำหรับศิลปิน / นักออกแบบของเราส่วนใหญ่มุ่งเน้นไปที่ปัญหา UI: ความสะดวกในการจัดการกับสินทรัพย์เดี่ยวหรือแบทช์ของมันเป็นต้นบางครั้งพวกเขาเป็นเพียงเครื่องมือของบุคคลที่สามเช่น Photoshop หรือ 3DS Max เครื่องมือเหล่านี้ส่งออกไปยังรูปแบบกลาง (มัก xml ที่อ้างอิงข้อมูลไบนารีแหล่งที่มา แต่ไม่เสมอไป) รูปแบบกลางจะถูกหยิบขึ้นมาโดยเครื่องมือ "data make" แบ็กเอนด์ซึ่งจะทำให้มันกลายเป็นสิ่งที่มีประโยชน์และโหลดเร็วสำหรับแพลตฟอร์มเป้าหมาย
ความสามารถในการพกพาทำได้โดยการเพิ่มเครื่องมือสร้างแบ็กเอนด์เพิ่มเติมหรือขยายเครื่องมือสร้างแบ็กเอนด์ที่มีอยู่ซึ่งมีข้อได้เปรียบเพิ่มเติมในการมองไม่เห็นต่อผู้สร้างเนื้อหา
ตอนนี้ด้วยการเพิ่มข้อมูลที่เหมาะสมคุณสามารถมีการเปลี่ยนแปลงในรูปแบบการอบภายในไม่กี่วินาที เครื่องยนต์ของคุณสามารถสไปเดอร์หรือเครื่องมือสามารถสไปเดอร์แล้วสิ่งเหล่านี้จะปรากฏในระบบทรัพยากรของคุณพร้อมสำหรับการโหลดใหม่เมื่อสะดวก
เครื่องมือ - โดยเฉพาะอย่างยิ่งข้อมูลแบ็กเอนด์สร้างเครื่องมือ - มักจะมีความลื่นและตัวเลือกมากกว่ารหัสเครื่องยนต์ ไม่เป็นไรเพราะง่ายต่อการสร้าง / ขยายใหม่เขียนใหม่และทดสอบ คุณมีรายละเอียดสำหรับพฤติกรรมของพวกเขาและมันค่อนข้างง่ายต่อการทดสอบหน่วยเปรียบเทียบกับรหัสเครื่องยนต์
ความคิดเห็นของฉันในคำถามของคุณ:
เครื่องยนต์ควรโหลดรูปแบบภาพต่างๆได้หรือไม่? ตัวโหลด TGA เท่านั้นนั้นค่อนข้างง่ายต่อการเขียนด้วยมือ
(นอกเหนือจาก: แม้ว่าคุณจะใช้ตัวถอดรหัส TGA ในเครื่องยนต์อย่าเขียนโค้ดด้วยมือคุณแค่ขอปัญหา - มีรายละเอียดปลีกย่อยมากมายที่มีรูปแบบภาพส่วนใหญ่และเครื่องมือมากมายที่ไม่ยึดติด ตรงกับรูปแบบที่ไม่แน่นอนคุณควรหารหัสห้องสมุดที่ผ่านการทดสอบอย่างดีสำหรับการประมวลผลภาพ)
ฉันต้องการเครื่องมือที่แปลงจาก TGA เป็นรูปแบบพื้นผิวภายในของคุณรวมถึงข้อมูลเมตา
รูปแบบเสียงเป็นอย่างไร เป็นไปได้หรือไม่ที่จะรองรับการโหลดไฟล์ wav เท่านั้น? ไฟล์เพลงโดยรอบมักมีขนาดใหญ่มาก
เราใช้สามรูปแบบที่นี่: เพลงที่ติดตาม (.xm), ADPCM (.wav) และ Speex (.spx) นี่เป็นเพราะเราอยู่ในอุปกรณ์พกพาและรูปแบบเหล่านี้มีน้ำหนักเบามากในการถอดรหัส
เครื่องยนต์ควรมีความสามารถในการแยกวิเคราะห์ TTF และการสร้างแผนที่แบบไดนามิกหรือไม่? บรรจุพื้นผิว
การแปลเป็นปัญหาอย่างหนัก: ดูคำตอบของคำถามล่าสุดของคุณ มันเกือบจะคุ้มค่าที่จะทำแบบออฟไลน์
นอกจากนี้คุณยังสามารถสร้างข้อมูลเมตาต่ออักขระให้เป็นโครงสร้างการอบที่เกือบเป็นศูนย์โหลด
ในการปิดคุณสามารถล้างข้อมูลและทำแพ็คเกจนี้กับเกมของคุณสำหรับชุมชน mod คุณสามารถเพิ่มรูปแบบแหล่งที่มาเพิ่มเติมได้ตลอดเวลา และไม่มีอะไรขัดขวางคุณไม่ให้เชื่อมช่องว่างระหว่างเครื่องมือสร้างเนื้อหาและเอ็นจิ้นในบางกรณี หวังว่าโค้ดอบข้อมูลและรหัสสไปเดอร์ / การถ่ายโอนของคุณสามารถนำไปปรับใช้ใหม่ในไลบรารีซึ่งในที่สุดอาจใช้เครื่องมือสร้างเนื้อหาโดยตรงในบางกรณี แต่ฉันจะไม่ทำให้เป้าหมายแรกของฉันจำเป็นต้อง ... แค่ระวังให้ดีว่ามันจะเป็นเป้าหมายในที่สุดและปล่อยให้สิ่งนั้นมีอิทธิพลต่อการออกแบบของคุณเล็กน้อยและไปหาผลไม้แขวนลอยต่ำก่อน
เป็นการอัพเดตคุณอาจต้องการพิจารณาใช้รูปแบบไฟล์ KTXสำหรับพื้นผิว มันมีข้อดีของการเป็นส่วนใหญ่ "อ่านstructแล้วไป" สำหรับการใช้งาน GL ส่วนใหญ่ (และจากความคิดเห็นของคุณดูเหมือนว่าคุณกำลังกำหนดเป้าหมาย GL) ในขณะที่ยังยืดหยุ่นและกำหนดชัดเจน
ค่าใช้จ่ายส่วนหัวของ KTX อาจสูงเล็กน้อยสำหรับข้อมูลที่อบเสร็จแล้วขึ้นอยู่กับเป้าหมายของคุณและคุณอาจต้องละทิ้งการสนับสนุน endian swap ขึ้นอยู่กับ usecase ของคุณ ... แต่อย่างน้อยก็คุ้มค่าสำหรับการพิจารณาการออกแบบ