การจัดเก็บวัตถุของเกมทั้งหมดในรายการเดียวเป็นการออกแบบที่ยอมรับได้หรือไม่?

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

ฉันสงสัยว่านี่เป็นวิธีที่เหมาะสมในการดำเนินการต่างๆหรือเป็นวิธีที่มีประสิทธิภาพมากขึ้นเร็วขึ้นหรือไม่

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

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

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

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

อย่างที่คนอื่นพูดถ้ามันเร็วพอมันก็เร็วพอ หากคุณสงสัยว่ามีวิธีที่ดีกว่าคำถามที่ถามตัวเองคือ

ฉันพบตัวเองวนซ้ำตามวัตถุทั้งหมด แต่ทำงานเฉพาะในส่วนย่อยของวัตถุเหล่านั้นหรือไม่

หากคุณทำเช่นนั้นนั่นเป็นข้อบ่งชี้ว่าคุณอาจต้องการมีหลายรายการที่มีการอ้างอิงที่เกี่ยวข้องเท่านั้น ตัวอย่างเช่นหากคุณวนลูปผ่านทุก ๆ ออบเจ็กต์เกมเพื่อเรนเดอร์ แต่จำเป็นต้องเรนเดอร์เซ็ตย่อยของออบเจ็กต์เท่านั้นมันอาจคุ้มค่าที่จะเก็บ Renderable list แยกต่างหากสำหรับออบเจ็กต์เหล่านั้นเท่านั้น

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

คุณจะต้องทำการโพรไฟล์มันเพื่อดูว่าคุณได้รับผลงานมากขึ้นหรือไม่

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

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

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

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

การอัพเดท Game Objects

นี่เป็นข้อความที่ตัดตอนมาจาก Game Engine Architectureซึ่งฉันอยากจะแนะนำให้อ่าน:

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

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

การแสดงผลวัตถุในเกม

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

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

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

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

โดยทั่วไปสิ่งที่คุณต้องการทำคือทำรายการตามที่คุณต้องการ หากคุณวาดวัตถุภูมิประเทศทั้งหมดในครั้งเดียวรายการของวัตถุเหล่านั้นอาจมีประโยชน์ แต่การทำเช่นนี้จะมีค่าในขณะที่คุณต้องการหมื่นของพวกเขาและอีก 10,000 ของสิ่งที่ไม่ใช่ภูมิประเทศ มิฉะนั้นการอ่านรายการสิ่งของของคุณและใช้ "if" เพื่อดึงวัตถุภูมิประเทศออกมานั้นเร็วพอ

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

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

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

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

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

ฉันใช้วิธีการที่ค่อนข้างคล้ายกันสำหรับเกมง่ายๆ การเก็บทุกอย่างในอาเรย์หนึ่งมีประโยชน์มากเมื่อเงื่อนไขต่อไปนี้เป็นจริง:

1. คุณมีวัตถุเกมจำนวนน้อยหรือมากที่สุดที่ทราบ
2. คุณชอบความเรียบง่ายมากกว่าการแสดง (เช่น: โครงสร้างข้อมูลที่ปรับให้เหมาะสมเช่น tree ไม่คุ้มค่ากับปัญหา)

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

วัตถุประสงค์ของบูลีนคือเพิ่มความเร็วในการสร้างและการลบ แทนที่จะทำลายวัตถุเกมเมื่อพวกเขาถูกลบออกจากการจำลองฉันก็จะตั้งค่า "ชีวิต" falseธง

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

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

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

นี่คือโพสต์แรกของฉัน! ฉันหวังว่ามันจะตอบคำถามของคุณ!

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

คุณพูดว่าอาเรย์เดียวและวัตถุ

ดังนั้น (โดยไม่ต้องดูรหัสของคุณ) ฉันเดาว่าพวกเขาทั้งหมดเกี่ยวข้องกับ 'uberGameObject'

ดังนั้นอาจมีปัญหาสองข้อ

1) คุณอาจมีวัตถุ 'เทพเจ้า' - ทำสิ่งต่าง ๆ เป็นตันไม่แบ่งตามสิ่งที่มันทำหรือเป็น

2) คุณย้ำผ่านรายการนี้แล้วเลือกพิมพ์? หรือแกะกล่องออกจากกัน นี่คือโทษประสิทธิภาพที่ยิ่งใหญ่

พิจารณาแบ่งประเภทต่าง ๆ (สัญลักษณ์แสดงหัวข้อย่อยคนเลว ฯลฯ ) ลงในรายการที่พิมพ์ของตนเองอย่างยิ่ง

List<BadGuyObj> BadGuys = new List<BadGuyObj>();
List<BulletsObj> Bullets = new List<BulletObj>();

 //Game 
OnUpdate(gameticks gt)
{  foreach (BulletObj thisbullet in Bullets) {thisbullet.Update();}  // much quicker.

ฉันสามารถเสนอการประนีประนอมระหว่างรายการเดียวทั่วไปและรายการแยกสำหรับแต่ละประเภทวัตถุ

อ้างอิงถึงหนึ่งวัตถุในหลายรายการ รายการเหล่านี้ถูกกำหนดโดยพฤติกรรมพื้นฐาน ยกตัวอย่างเช่นMarineSoldierวัตถุที่จะได้รับการอ้างอิงในPhysicalObjList, GraphicalObjList, ,UserControlObjList HumanObjListดังนั้นเมื่อคุณประมวลผลฟิสิกส์คุณย้ำผ่านPhysicalObjListเมื่อกระบวนการสร้างความเสียหายจากพิษ - HumanObjListถ้าตายทหาร - เอามันออกไปจากแต่เก็บไว้ในHumanObjList PhysicalObjListเพื่อให้กลไกนี้ทำงานคุณต้องจัดระเบียบการแทรก / ลบวัตถุโดยอัตโนมัติเมื่อสร้าง / ลบ

ข้อดีของวิธีการ:

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

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