10 ข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนา Unity สร้างขึ้น

Unity เป็นเครื่องมือที่ยอดเยี่ยมและตรงไปตรงมาสำหรับใช้ในการพัฒนาหลายแพลตฟอร์ม หลักการนั้นเข้าใจง่าย และคุณสามารถเริ่มสร้างผลิตภัณฑ์ของคุณได้โดยสัญชาตญาณ อย่างไรก็ตาม หากไม่ได้คำนึงถึงบางสิ่ง สิ่งเหล่านี้จะทำให้ความคืบหน้าของคุณช้าลงเมื่อคุณทำงานในระดับต่อไป เนื่องจากคุณกำลังย้ายจากขั้นตอนต้นแบบเริ่มต้นหรือใกล้จะถึงการเปิดตัวขั้นสุดท้าย บทความนี้จะให้คำแนะนำเกี่ยวกับวิธีการเอาชนะปัญหาที่พบบ่อยที่สุด และวิธีหลีกเลี่ยงข้อผิดพลาดพื้นฐานในโครงการใหม่หรือโครงการที่มีอยู่ของคุณ โปรดทราบว่ามุมมองของบทความนี้เน้นไปที่การพัฒนาแอปพลิเคชัน 3D มากกว่า แต่ทุกอย่างที่กล่าวถึงก็ใช้ได้กับการพัฒนา 2D เช่นกัน

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #1: การประเมินระยะการวางแผนโครงการต่ำไป

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

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

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

ข้อผิดพลาดเกี่ยวกับความสามัคคีทั่วไป #2: การทำงานกับโมเดลที่ไม่ได้รับการปรับให้เหมาะสม

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

สิ่งสำคัญคือต้องตั้งค่ามาตราส่วนอย่างถูกต้อง ในบางครั้ง คุณไม่สามารถตั้งค่าอย่างถูกต้องจากซอฟต์แวร์สร้างแบบจำลอง 3 มิติของคุณ เนื่องจากแอปพลิเคชันเหล่านี้ใช้หน่วยต่างๆ กัน เพื่อให้ทุกอย่างถูกต้อง ให้ตั้งค่าตัวประกอบมาตราส่วนในการตั้งค่าการนำเข้าแบบจำลอง (ปล่อย 0.01 สำหรับ 3dsMax และ Modo ตั้งค่า 1.0 สำหรับ Maya) และโปรดทราบว่าบางครั้งคุณจะต้องนำเข้าวัตถุอีกครั้งหลังจากเปลี่ยนการตั้งค่ามาตราส่วน การตั้งค่าเหล่านี้ควรรับรองว่าคุณสามารถใช้เพียงมาตราส่วนพื้นฐาน 1,1,1 ในฉากของคุณเพื่อให้ได้พฤติกรรมที่สอดคล้องกันและไม่มีปัญหาทางฟิสิกส์ การแบ่งกลุ่มแบบไดนามิกจะทำงานอย่างถูกต้องเช่นกัน กฎนี้ควรใช้กับทุกอ็อบเจ็กต์ย่อยในโมเดล ไม่ใช่เฉพาะวัตถุหลัก เมื่อคุณต้องการปรับขนาดของวัตถุ ให้ดำเนินการกับวัตถุอื่นๆ ในแอปพลิเคชันการสร้างแบบจำลอง 3 มิติ มากกว่าใน Unity อย่างไรก็ตาม คุณสามารถทดลองด้วยมาตราส่วนใน Unity เพื่อค้นหาค่าที่เหมาะสม แต่สำหรับแอปพลิเคชันขั้นสุดท้ายและเวิร์กโฟลว์ที่สอดคล้องกัน คุณควรเตรียมทุกอย่างให้พร้อมก่อนที่จะนำเข้าไปยัง Unity

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

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #3: การสร้างสถาปัตยกรรมรหัสแบบพึ่งพาอาศัยกัน

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

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

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #4: เสียประสิทธิภาพของคุณ

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

มีหลายพื้นที่สำหรับการเพิ่มประสิทธิภาพ บทความทั้งหมดจะมีความจำเป็นเพียงเพื่อเกาพื้นผิวเกี่ยวกับหัวข้อนี้ อย่างน้อย ฉันจะพยายามแบ่งโดเมนนี้ออกเป็นประเด็นหลัก

อัปเดตลูป

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

อินสแตนซ์

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

กำลังแสดงผล

ใช้เทคนิค occlusion culling หรือ LOD เพื่อจำกัดการเรนเดอร์บางส่วนของฉาก พยายามใช้โมเดลที่ได้รับการปรับให้เหมาะสมเพื่อให้สามารถนับจุดยอดในฉากได้ภายใต้การควบคุม โปรดทราบว่าการนับจุดยอดไม่ได้เป็นเพียงจำนวนจุดยอดบนตัวแบบเท่านั้น แต่ยังได้รับอิทธิพลจากสิ่งอื่น เช่น เส้นปกติ (ขอบแข็ง) พิกัด UV (ตะเข็บ UV) และสีของจุดยอด นอกจากนี้ จำนวนแสงไดนามิกในฉากจะส่งผลต่อประสิทธิภาพโดยรวมอย่างมาก ดังนั้น พยายามอบทุกอย่างล่วงหน้าทุกครั้งที่ทำได้

วาดการโทร

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

หมดปัญหา

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

Shaders

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

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #5: ละเว้นปัญหาการเก็บขยะ

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

• หลีกเลี่ยงการจัดสรรที่ไม่จำเป็นในลูปการอัพเดท
• ใช้โครงสร้างสำหรับคอนเทนเนอร์คุณสมบัติอย่างง่าย เนื่องจากไม่ได้จัดสรรบนฮีป
• พยายามจัดสรรอาร์เรย์หรือรายการล่วงหน้าหรือคอลเล็กชันของอ็อบเจ็กต์อื่นๆ ล่วงหน้า แทนที่จะสร้างภายในลูปการอัพเดท
• หลีกเลี่ยงการใช้สิ่งที่เป็นปัญหาแบบโมโน (เช่น นิพจน์ LINQ หรือ foreach loop เป็นต้น) เนื่องจาก Unity ใช้ Mono เวอร์ชันเก่าที่ไม่ได้รับการปรับให้เหมาะสมที่สุด (ในขณะที่เขียนจะมีการแก้ไขเวอร์ชัน 2.6 โดยมีการอัปเกรดในแผนงาน)
• แคชสตริงในเมธอด Awake() หรือในเหตุการณ์
• หากจำเป็นต้องอัพเดตคุณสมบัติสตริงในลูปอัพเดต ให้ใช้อ็อบเจ็กต์ StringBuilder แทนสตริง
• ใช้ตัวสร้างโปรไฟล์เพื่อระบุปัญหาที่อาจเกิดขึ้น

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #6: การเพิ่มประสิทธิภาพหน่วยความจำและการใช้พื้นที่ล่าสุด

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

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

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

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #7: ข้อผิดพลาดทั่วไปเกี่ยวกับฟิสิกส์

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

ในการแก้ไขตำแหน่งของวัตถุที่มี Rigidbody อยู่ ให้ตั้งค่า Rigidbody.position เสมอเมื่อตำแหน่งใหม่ไม่เป็นไปตามตำแหน่งก่อนหน้า หรือ Rigidbody.MovePosition เมื่อเป็นการเคลื่อนไหวต่อเนื่อง ซึ่งคำนึงถึงการแก้ไขด้วย เมื่อทำการแก้ไข ให้ใช้การดำเนินการเสมอใน FixedUpdate ไม่ใช่ในฟังก์ชัน Update มันจะรับรองพฤติกรรมทางฟิสิกส์ที่สอดคล้องกัน

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #8: การทดสอบฟังก์ชันการทำงานทั้งหมดด้วยตนเอง

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

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

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

ข้อผิดพลาดทั่วไปของ Unity #9: ปลั๊กอินการคิด Unity Asset Store จะแก้ปัญหาทั้งหมดของคุณ

เชื่อฉัน; พวกเขาจะไม่ เมื่อทำงานกับลูกค้าบางราย บางครั้งฉันต้องเผชิญกับแนวโน้มหรือความซ้ำซากจำเจจากการใช้ปลั๊กอินของที่เก็บสินทรัพย์สำหรับทุกสิ่งเล็กน้อย ฉันไม่ได้หมายความว่าไม่มีส่วนขยาย Unity ที่เป็นประโยชน์ใน Unity Asset Store มีมากมายและบางครั้งก็ยากที่จะตัดสินใจว่าจะเลือกอันไหน แต่สำหรับทุกโครงการ การรักษาความสม่ำเสมอเป็นสิ่งสำคัญ ซึ่งสามารถถูกทำลายได้โดยการใช้ชิ้นส่วนต่างๆ ที่ไม่เข้ากันอย่างไม่ฉลาด

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

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

ข้อผิดพลาดทั่วไปเกี่ยวกับความสามัคคี #10: ไม่จำเป็นต้องขยายฟังก์ชันพื้นฐานของความสามัคคี

บางครั้งอาจดูเหมือนว่าสภาพแวดล้อม Unity Editor นั้นเพียงพอสำหรับการทดสอบเกมพื้นฐานและการออกแบบด่าน และการขยายเวลาก็ทำให้เสียเวลา แต่เชื่อฉันเถอะ มันไม่ใช่ ศักยภาพในการขยายที่ยอดเยี่ยมของ Unity มาจากความสามารถในการปรับให้เข้ากับปัญหาเฉพาะซึ่งจำเป็นต้องแก้ไขในโครงการต่างๆ สิ่งนี้สามารถปรับปรุงประสบการณ์ผู้ใช้เมื่อทำงานใน Unity หรือเร่งความเร็วขั้นตอนการพัฒนาทั้งหมดและการออกแบบระดับได้อย่างมาก น่าเสียดายที่จะไม่ใช้คุณสมบัติในตัว เช่น ลิ้นชักคุณสมบัติในตัวหรือแบบกำหนดเอง ลิ้นชักมัณฑนากร การตั้งค่าตัวตรวจสอบส่วนประกอบที่กำหนดเอง หรือแม้แต่การไม่สร้างปลั๊กอินทั้งหมดด้วย Editor Windows ของตัวเอง

บทสรุป

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

อ่านเพิ่มเติมในบล็อก Toptal Engineering:

• การพัฒนา Unity AI: บทช่วยสอนเกี่ยวกับเครื่องจักรที่มีสถานะจำกัด