ออกแบบเพื่อประสิทธิภาพ

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

อุปกรณ์ระดับต่ำ

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

• หากคุณต้องการสนับสนุนอุปกรณ์ระดับต่ำ ให้เลือกอุปกรณ์ "พื้นฐาน" อย่างน้อยหนึ่งเครื่อง ทดสอบประสบการณ์ของคุณบนอุปกรณ์นั้นตลอดกระบวนการพัฒนา และใส่ใจในอัตราเฟรมและการใช้หน่วยความจำให้มาก เมื่อคุณค้นพบพื้นที่ปัญหาในประสบการณ์ของคุณ ให้ใช้พื้นที่เหล่านั้นเพื่อระบุขอบเขตของอุปกรณ์ของคุณ

  ตัวอย่างเช่น คุณอาจทดสอบประสบการณ์พร้อมสถิติการดีบัก Render (ShiftF2) และ Summary (ShiftF2) ที่เปิดใช้งาน หากอัตราเฟรมเริ่มลดลงในพื้นที่ที่ยุ่งเหยิง คุณอาจตรวจสอบหมายเลข Draw (scene) และกำหนดว่าคุณจะต้องอยู่ต่ำกว่า 1,000 คำสั่งวาดและ 1,000,000 รูปสามเหลี่ยมเพื่อให้ประสบการณ์ทำงานได้ดีบนอุปกรณ์พื้นฐานของคุณ

  หรือคุณอาจตรวจสอบ Developer Console (F9) และสังเกตว่าการใช้หน่วยความจำค่อนข้างสูง เว้นแต่คุณจะเปิดใช้งาน streaming การเข้าใจข้อจำกัดของอุปกรณ์อย่างชัดเจนสามารถช่วยคุณอยู่ภายใต้ข้อจำกัดเหล่านั้นเมื่อคุณยังคงสร้างประสบการณ์ของคุณต่อไป

  

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

โดยทั่วไปแล้ว การทดสอบบนอุปกรณ์ที่หลากหลายสามารถช่วยให้คุณตรวจสอบว่า ประสบการณ์ตรงตามความคาดหวังด้านภาพและประสิทธิภาพในระดับคุณภาพกราฟิกที่แตกต่างกันอย่างไร สำหรับตัวอย่างที่ละเอียดมากขึ้นเกี่ยวกับวิธีการที่คุณอาจคิดเกี่ยวกับการเพิ่มประสิทธิภาพประสบการณ์ของคุณสำหรับอุปกรณ์มือถือระดับต่ำ โปรดดูที่ Real World Building and Scripting Optimization.

การสตรีมและการเคลื่อนย้าย

• Instance streaming ช่วยให้ Roblox โหลดและปลดโหลดเนื้อหาสามมิติได้อย่างไดนามิกและเป็นตัวเลือกที่ยอดเยี่ยมสำหรับสถานที่ส่วนใหญ่ โดยเฉพาะที่ใหญ่กว่า สตรีมมิ่งช่วยปรับปรุงเวลาเข้าร่วม ลดขนาดการใช้หน่วยความจำ และเพิ่มอัตราเฟรม สำหรับข้อมูลเพิ่มเติม โปรดดูที่ Improve performance.

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

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

วัสดุและการทำซ้ำ

• วัสดุที่สร้างขึ้นภายในใช้หน่วยความจำน้อยกว่าภาพพื้นผิวที่กำหนดเองอย่างมาก แต่ قد لن تتطابق مع رؤيتك الفنية حاول استخدام المواد في كلما كان ذلك ممكنًا من أجل الحفاظ على ميزانية الذاكرة للنسيج المركزية في تجربتك

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

• เมื่อคุณเพิ่ม Meshes และ textures ใช้และนำกลับมาใช้ใหม่แทนที่จะนำเข้าภาพซ้ำ โดยการปรับขนาด การหมุน และการทับซ้อน คุณสามารถสร้างสภาพแวดล้อมที่หลากหลายและอุดมสมบูรณ์ซึ่งต้องการ คำสั่งวาด ที่น้อยมาก สำหรับข้อมูลเพิ่มเติม โปรดดูที่ Remove duplicate textures.

ความโปร่งใส

• หลีกเลี่ยงค่าโปร่งใสอื่นนอกจาก 0 (มองเห็นได้) และ 1 (มองไม่เห็น) เมื่อคุณใช้ความโปร่งใสบางส่วน ให้ระมัดระวังเป็นพิเศษเพื่อหลีกเลี่ยง การทับซ้อนความโปร่งใสสูง.

สคริปต์

• เมื่อใดก็ตามที่เป็นไปได้ ให้เขียนโค้ดที่ขับเคลื่อนด้วยเหตุการณ์แทนการคำนวณต่อเฟรม ที่ 60 FPS งบประมาณทั้งหมดสำหรับแต่ละเฟรมคือ 16.67 มิลลิวินาที (ms) แม้แต่การคำนวณที่ดูเหมือนจะเล็กน้อยต่อเฟรมอาจใช้สัดส่วนที่สำคัญของงบประมาณนั้น

• ค้นหาวิธีในการแบ่งโค้ดยาวๆ เป็นชิ้นส่วนที่จัดการได้ หากโค้ดบางส่วนใช้เวลา 100 ms ในการดำเนินการและคุณรันมันทุกเฟรม ประสบการณ์ของคุณจะสามารถทำงานได้เพียง 10 FPS หากคุณตัดสินใจที่จะรันโค้ดเพียงครั้งเดียวต่อวินาทีในประสบการณ์ที่ทำงานอยู่ที่ 60 FPS 59 เฟรมของคุณจะมาถึงหลังจาก 16.67 ms... และจากนั้นหนึ่งเฟรมหลังจาก 100 ms ซึ่งทำให้เกิดการสะดุดที่เจ็บปวด

  แทนที่จะทำเช่นนั้น ให้ตรวจสอบวิธีที่คุณสามารถแบ่งแยกโค้ด อาจจะมีงาน 5 ms ต่อเฟรม ใช้ task.wait() และมีการคำนวณที่เสร็จสมบูรณ์ทุก ๆ 20 เฟรมในขณะที่ยังคงรักษา 60 FPS Multithreading บางครั้งเรียกว่า Parallel Luau ก็สามารถช่วยได้เช่นกัน

• ใช้เมธอด RBXScriptConnection:Disconnect() เพื่อหยุดฟังก์ชันจากการถูกเรียกใช้อย่างไม่จำเป็นเมื่อมีการเรียกใช้งานต่อไปอีกครั้ง

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

• อย่าเก็บทุกอย่างใน ReplicatedStorage. ไคลเอนต์จะโหลดทุกอย่างที่อยู่ในที่เก็บนี้ แทนที่จะใช้ ServerStorage สำหรับสิ่งที่ไคลเอนต์ไม่จำเป็นต้องเข้าถึง