ข้อผิดพลาดทั่วไปเมื่อเขียนเกมด้วยภาษาที่มีการจัดการเช่น C # คืออะไร [ปิด]

คุณพบข้อผิดพลาดอะไรบ้างเมื่อเขียนเกมสำหรับพีซีด้วยภาษาที่มีการจัดการเช่น C # และคุณแก้ปัญหาได้อย่างไร

ฉันไม่รู้เกี่ยวกับจาวามากนักดังนั้นนี่มาจากมุมมองของ. dev สุทธิ

ที่ใหญ่ที่สุดคือขยะ ตัวรวบรวมขยะ. net บน windows ทำหน้าที่ได้อย่างยอดเยี่ยมและคุณสามารถออกไปได้โดยไม่ต้องให้ลูกนั่งเป็นส่วนใหญ่ บน xbox / winPhone7 นั่นเป็นเรื่องที่แตกต่าง หากคุณได้รับแผงลอยทุก ๆ สองสามครั้งการรวบรวมขยะอาจทำให้คุณมีปัญหา ในขณะนี้มันจะเริ่มทำงานหลังจากการจัดสรร 1mb ทุกครั้ง

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

• วาดเนื้อหาของGC.GetTotalMemory()ไปยังหน้าจอ สิ่งนี้จะช่วยให้คุณประมาณจำนวนไบต์ที่จัดสรรเกมของคุณใช้ ถ้ามันแทบจะไม่เคลื่อนไหวคุณก็โอเค หากเกิดขึ้นเร็วคุณมีปัญหา
• พยายามจัดสรรวัตถุฮีปทั้งหมดของคุณล่วงหน้า หากคุณไม่จัดสรรทุกอย่างก่อนที่เกมจะเริ่มขึ้นทุกครั้งที่คุณมีการจัดสรรจำนวนมาก ไม่มีการจัดสรรไม่มีการรวบรวม ง่ายเหมือนที่
• หลังจากโหลดแล้วให้เรียก GC.Collect () หากคุณรู้ว่าการจัดสรรขนาดใหญ่ส่วนใหญ่ของคุณเป็นไปอย่างไม่น่าเชื่อก็เป็นเรื่องดีที่จะให้ระบบทราบ
• อย่าโทรGC.Collect()ทุกเฟรม มันอาจเป็นความคิดที่ดีโดยเฉพาะอย่างยิ่งการเก็บขยะและสิ่งอื่น ๆ แต่อย่าลืมว่าสิ่งที่แย่กว่าการเก็บขยะก็คือการเก็บขยะ
• มองหาที่ขยะของคุณมาจากไหน มีสาเหตุบางอย่างที่พบบ่อยเช่นการต่อสตริงแทนที่จะใช้StringBuilder(ระวังStringBuilderไม่ใช่ bullet เวทมนตร์และยังสามารถทำให้เกิดการจัดสรร!ซึ่งหมายถึงการดำเนินการอย่างง่ายเช่นการเพิ่มตัวเลขไปยังจุดสิ้นสุดของสตริงสามารถสร้างขยะที่น่าประหลาดใจ) หรือ การใช้foreachลูปมากกว่าคอลเลกชันที่ใช้IEnumerableอินเทอร์เฟซยังสามารถสร้างขยะโดยที่คุณไม่รู้ตัว (เช่นforeach (EffectPass pass in effect.CurrentTechnique.Passes)เป็นเรื่องธรรมดา)
• ใช้เครื่องมือเช่นตัวสร้างโปรไฟล์หน่วยความจำ CLRเพื่อหาตำแหน่งที่จะจัดสรรหน่วยความจำ มีบทเรียนมากมายเกี่ยวกับวิธีใช้เครื่องมือนี้
• เมื่อคุณทราบว่าการจัดสรรของคุณในระหว่างการเล่นเกมดูว่าคุณสามารถใช้เทคนิคเช่นการรวมวัตถุเพื่อลดจำนวนการจัดสรรนั้น
• หากสิ่งอื่นล้มเหลวทำให้คอลเล็กชันของคุณทำงานได้เร็วขึ้น! GC ในเฟรมเวิร์กขนาดกะทัดรัดติดตามทุกการอ้างอิงในรหัสของคุณเพื่อหาว่าวัตถุใดไม่ได้ใช้งานอีกต่อไป Refactor รหัสของคุณใช้การอ้างอิงน้อยลง!
• จำไว้ว่าให้ใช้IDisposableกับคลาสที่มีทรัพยากรที่ไม่มีการจัดการ คุณสามารถใช้สิ่งเหล่านี้เพื่อล้างหน่วยความจำที่ GC ไม่สามารถทำให้ตัวเองว่างเปล่าได้

อีกอย่างที่ต้องคิดคือประสิทธิภาพของจุดลอย ในขณะที่. Net JITer ทำจำนวนการปรับแต่งเฉพาะโปรเซสเซอร์ให้เหมาะสม แต่ก็ไม่สามารถใช้ SSE หรือชุดคำสั่ง SIMD อื่น ๆ เพื่อเพิ่มความเร็วในการคำนวณเลขทศนิยมของคุณ นี่อาจทำให้ความเร็วแตกต่างกันค่อนข้างมากระหว่าง C ++ และ C # สำหรับเกม หากคุณใช้โมโนพวกเขามีไลบรารี่คณิตศาสตร์ SIMD พิเศษที่คุณสามารถใช้ประโยชน์ได้

ข้อผิดพลาดของประสิทธิภาพในการทำงานนั้นไม่ได้พิจารณาถึงตัวรวบรวมขยะในการออกแบบ / พัฒนาเกม การผลิตขยะมากเกินไปสามารถนำไปสู่ ​​"hiccups" ในเกมซึ่งเกิดขึ้นเมื่อ GC ทำงานเป็นเวลานาน

สำหรับ C # การใช้วัตถุที่มีค่าและคำสั่ง "การใช้" สามารถบรรเทาความกดดันจาก GC

ฉันจะบอกว่าปัญหาที่ใหญ่ที่สุดที่ฉันพบการเขียนเกมใน C # คือการขาดห้องสมุดที่เหมาะสม ส่วนใหญ่ฉันพบว่าเป็นพอร์ตโดยตรง แต่ไม่สมบูรณ์หรือล้อมรอบห้องสมุด C ++ ที่ต้องเสียค่าปรับหนักสำหรับ marshaling (ฉันกำลังพูดเฉพาะเกี่ยวกับ MOgre และ Axiom สำหรับห้องสมุด OGRE และ BulletSharp สำหรับห้องสมุดฟิสิกส์ Bullet)

ภาษาที่มีการจัดการ (แตกต่างจากการตีความ - Java และ C # จะไม่ถูกตีความอีกต่อไป) สามารถเร็วเท่ากับภาษาท้องถิ่นหากคุณมีความเข้าใจอย่างถ่องแท้เกี่ยวกับสิ่งที่ทำให้พวกเขาช้า (การจัดเก็บขยะ) ฉันคิดว่าปัญหาที่แท้จริงคือผู้พัฒนาห้องสมุดยังไม่เข้าใจ

เช่นเดียวกับคนอื่น ๆ ที่กล่าวว่าการหยุดการรวบรวม GC เป็นปัญหาที่ใหญ่ที่สุด การใช้พูลอ็อบเจ็กต์เป็นโซลูชันทั่วไปหนึ่งรายการ

C # และ Java ไม่ถูกตีความ พวกเขาจะถูกรวบรวมเป็นไบต์กลางซึ่งหลังจากJITกลายเป็นเร็วเป็นรหัสพื้นเมือง (หรือใกล้พอที่จะไม่มีนัยสำคัญ)

ข้อผิดพลาดที่ใหญ่ที่สุดที่ฉันพบคือการปลดปล่อยทรัพยากรที่ส่งผลกระทบโดยตรงต่อประสบการณ์ของผู้ใช้ ภาษาเหล่านี้ไม่รองรับการกำหนดขั้นสุดท้ายแบบอัตโนมัติเช่น C ++ แต่ถ้าคุณไม่คาดหวังว่ามันจะนำไปสู่สิ่งต่าง ๆ เช่นตาข่ายที่ลอยอยู่รอบ ๆ ฉากหลังจากที่คุณคิดว่ามันถูกทำลาย (C # บรรลุการกำหนดค่าขั้นสุดท้ายผ่านIDisposableฉันไม่แน่ใจว่า Java ทำอะไร)

นอกเหนือจากนั้นภาษาที่ได้รับการจัดการนั้นมีความสามารถในการจัดการประสิทธิภาพที่เกมต้องการมากกว่าที่ได้รับเครดิต โค้ดที่มีการจัดการที่เขียนดีนั้นเร็วกว่าโค้ดเนทีฟที่เขียนไม่ดีมาก

ไม่มีการตีความ Java หรือ C # ทั้งคู่ได้รับการคอมไพล์เป็นรหัสเครื่องดั้งเดิม

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

ข้อผิดพลาดที่ใหญ่อย่างหนึ่งที่ฉันเห็นจากการทำเกมด้วยภาษาเช่นนี้ (หรือใช้เครื่องมือเช่น XNA, TorqueX engine ฯลฯ ) คือคุณจะต้องเจอกับทีมคนดีที่มีความเชี่ยวชาญที่จำเป็นในการสร้างเกมที่เทียบเท่า จะค่อนข้างง่ายต่อการค้นหาผู้คนใน C ++ และ OpenGL / DirectX

อุตสาหกรรมเกม dev ยังคงเป็นที่แพร่หลายอย่างมากใน C ++ เนื่องจากเครื่องมือและท่อส่วนใหญ่ที่ใช้ในการผลักดันเกมเล็ก ๆ ที่มีขนาดใหญ่หรือขัดเงาถูกเขียนขึ้นใน C ++ และเท่าที่ฉันรู้ชุด dev ทางการทั้งหมดที่คุณสามารถ รับสำหรับ XBox, PS3 และ Wii เปิดตัวเฉพาะกับความเข้ากันได้กับ C ++ (ชุดเครื่องมือ XBox อาจมีการจัดการมากขึ้นในปัจจุบันทุกคนรู้เพิ่มเติมหรือไม่)

หากคุณต้องการพัฒนาเกมสำหรับคอนโซลตอนนี้คุณจะได้ XNA และ C # บน XBox และจากนั้นจะอยู่ในส่วนของไลบรารีเกมที่เรียกว่า XBox Live Indie Games ผู้ที่ชนะการแข่งขันและอื่น ๆ ได้รับเลือกให้เข้าเกมเพื่อ XBox Live Arcade ที่แท้จริง นอกเหนือจากแผนการสร้างเกมสำหรับพีซี