เกมจะจัดการกับตัวละครทั้งหมดในครั้งเดียวได้อย่างไร?

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

ตัวอย่าง

ฉันกำลังสร้างเกมป้องกันหอคอยที่มีช่องหอคอย 15 ช่องที่หอคอยถูกสร้างขึ้นและแต่ละหอจะยิงกระสุนออกมาในอัตราที่แน่นอน สมมติว่าทุก ๆ วินาทีมี 2 projectilesถูกสร้างขึ้นโดยแต่ละหอคอยและมีศัตรูเดินทัพในสนามรบให้บอกว่า 70 (แต่ละชนิดมีคุณลักษณะ 10 ประเภทเช่น HP, มานา ฯลฯ ซึ่งจะเปลี่ยนไปตามการเคลื่อนที่รอบ ๆ สนามรบ).

สรุป

จำนวนหอคอย = 15
Projectiles ที่สร้างโดยแต่ละหอคอยต่อวินาที = 2
จำนวนทั้งหมดของ Projectile ที่สร้างต่อวินาที = 30
หน่วยใน Battlefield Count = 70

ตอนนี้เกมจัดการ30 projectiles และ 70 ยูนิตโดยจัดการกับเธรด 100 หัวข้อ (ซึ่งมากเกินไปสำหรับพีซี) หรือ1 เธรดที่ย้ายทั้งหมดของพวกเขาลดค่าของพวกเขา ฯลฯ (ซึ่งจะช้า , ฉันคิด)?

ฉันไม่มีเงื่อนงำเกี่ยวกับเรื่องนี้เพื่อให้ทุกคนสามารถแนะนำฉันเกี่ยวกับวิธีนี้จะทำงานออกมา?

ตอนนี้เกมจัดการ 30 Projectile และ 70 ยูนิตอย่างไรโดยจัดการกับ 100 หัวข้อที่แตกต่างกัน

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

1 เธรดที่ย้ายทั้งหมดของพวกเขาลดค่า ฯลฯ ?

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

(ซึ่งจะช้าฉันคิดว่า)

ทีนี้คุณนิยามว่าอะไรช้า สำหรับหน่วยงาน 100 หน่วยไม่ควรใช้เวลามากกว่าครึ่งมิลลิวินาทีอาจน้อยกว่านี้ขึ้นอยู่กับคุณภาพของรหัสและภาษาที่คุณใช้งาน และแม้ว่าจะใช้เวลาสองมิลลิวินาทีเต็ม แต่ก็ยังดีพอที่จะกด 60 tps (ติ๊กต่อวินาทีไม่พูดถึงเฟรมในกรณีนี้)

กฎข้อที่หนึ่งของมัลติเธรดคือ: อย่าใช้มันเว้นแต่คุณจะต้องขนานกับแกน CPU หลายตัวเพื่อประสิทธิภาพหรือการตอบสนอง ความต้องการ "x และ y ควรเกิดขึ้นพร้อมกันจากมุมมองของผู้ใช้" ยังไม่เพียงพอที่จะใช้มัลติเธรด

ทำไม?

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

โดยปกติแล้วเกมที่จัดการกับวัตถุจำนวนน้อยเช่นนี้เพียงไม่กี่ร้อย (ใช่นี่ไม่ได้มีอะไรมากในการพัฒนาเกม) โดยทั่วไปแล้วจะประมวลผลพวกมันในลักษณะที่เป็นอนุกรมแต่ละตรรกะ - เห็บโดยใช้forวงวนทั่วไป

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

นอกจากนี้ภูมิปัญญาทั่วไปในการพัฒนาเกมก็คือ logics ของเกมแทบจะไม่ได้เป็นคอขวดของเกม ส่วนที่สำคัญต่อประสิทธิภาพคือกราฟิกเกือบทุกครั้ง ใช่แม้กระทั่งสำหรับเกม 2d

คำตอบอื่น ๆ ได้จัดการเกลียวและพลังของคอมพิวเตอร์ที่ทันสมัย เพื่อตอบคำถามที่ใหญ่กว่าสิ่งที่คุณพยายามทำที่นี่คือหลีกเลี่ยงสถานการณ์ "n กำลังสอง"

ตัวอย่างเช่นถ้าคุณมีขีปนาวุธ 1,000 ตัวและศัตรู 1,000 ตัวโซลูชั่นไร้เดียงสาก็คือตรวจสอบพวกมันทั้งหมดต่อกัน

ซึ่งหมายความว่าคุณจะจบลงด้วย p * e = 1,000 * 1,000 = 1,000,000 เช็คที่แตกต่างกัน! นี่คือ O (n ^ 2)

ในทางตรงกันข้ามถ้าคุณจัดระเบียบข้อมูลของคุณดีขึ้นคุณสามารถหลีกเลี่ยงได้มาก

ตัวอย่างเช่นหากคุณแสดงรายการสี่เหลี่ยมจัตุรัสแต่ละตารางของสิ่งที่ศัตรูอยู่ในตารางนั้นคุณสามารถวนลูปผ่าน 1,000 ขีปนาวุธของคุณและเพียงตรวจสอบสแควร์บนกริด ตอนนี้คุณเพียงแค่ต้องตรวจสอบกระสุนปืนแต่ละตัวกับสแควร์นี่คือ O (n) แทนที่จะเป็นล้านตรวจสอบแต่ละเฟรมคุณเพียงต้องการพัน

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

อย่าสร้างหัวข้อต่อทรัพยากร / วัตถุ แต่ต่อส่วนของตรรกะโปรแกรมของคุณ ตัวอย่างเช่น:

1. เธรดเพื่ออัพเดตหน่วยและ projectiles - เธรดตรรกะ
2. หัวข้อสำหรับการแสดงผลหน้าจอ - ด้าย GUI
3. เธรดสำหรับเครือข่าย (เช่นหลายผู้เล่น) - เธรด IO

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

แม้แต่ Space Invaders ก็จัดการวัตถุที่มีปฏิสัมพันธ์หลายสิบอย่าง ในขณะที่การถอดรหัสหนึ่งเฟรมของวิดีโอ HD H264 เกี่ยวข้องกับการดำเนินการทางคณิตศาสตร์หลายร้อยล้าน คุณมีพลังในการประมวลผลจำนวนมาก

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

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

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

คุณอาจไม่ต้องการเธรดหนึ่งเธรดสำหรับการชนกันที่อาจเกิดขึ้นเพียงเพราะนั่นเป็นโอกาสที่จะทำให้กำหนดการทำงานล้มเหลว นอกจากนี้ยังมีค่าใช้จ่ายที่เกี่ยวข้องกับการสร้างและทำลายเธรด ดีกว่าที่จะสร้างจำนวนเธรดรอบ ๆ คอร์ของระบบ (หรือใช้เมทริกเหมือนเก่า#cores * 2 + 4) จากนั้นใช้ซ้ำเมื่อกระบวนการเสร็จสิ้น

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

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

ที่กล่าวว่าเครื่องมือฟิสิกส์มักจะใช้หลายเธรดและฉันสามารถตั้งชื่อเกมหลายเกมที่ฉันคิดว่าจะได้รับประโยชน์จากหลายเธรดตรรกะ (เกม Paradox RTS เช่น HOI3 และเช่น)

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

ฉันคิดว่าคำตอบอื่น ๆ พลาดส่วนสำคัญของคำถามโดยเน้นไปที่ส่วนที่เป็นเกลียวของคำถาม

คอมพิวเตอร์ไม่ได้จัดการวัตถุทั้งหมดในเกมพร้อมกัน มันจัดการพวกเขาในลำดับ

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

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

CPU โดยเฉลี่ยควรเป็น 2 GHz หรือเร็วกว่านั่นหมายถึง 10 ⁹รอบนาฬิกาต่อวินาที ถ้าเราคำนวณ 60 timesteps ต่อวินาทีที่ใบ 10 ⁹รอบ / 60 รอบนาฬิกา = 16666666 นาฬิกาต่อขั้นตอนเวลา ด้วย 70 หน่วยเรายังคงมีรอบนาฬิกาเหลือประมาณ 2,400,000 รอบต่อหน่วย หากเราต้องปรับให้เหมาะสมเราอาจสามารถอัปเดตแต่ละยูนิตในเวลาเพียง 240 รอบขึ้นอยู่กับความซับซ้อนของตรรกะเกม อย่างที่คุณเห็นคอมพิวเตอร์ของเราเร็วกว่าประมาณ 10,000 เท่าที่จำเป็นสำหรับงานนี้

ข้อจำกัดความรับผิดชอบ: เกมประเภทที่ฉันชอบตลอดเวลานั้นเป็นแบบข้อความและฉันเขียนสิ่งนี้เป็นโปรแกรมเมอร์ตัวเก่าของ MUD เก่า

ฉันคิดว่าคำถามสำคัญที่คุณต้องถามตัวเองคือ: คุณต้องการเธรดหรือไม่ ฉันเข้าใจว่าเกมกราฟิกอาจมีการใช้งาน MT มากกว่า แต่ฉันคิดว่ามันขึ้นอยู่กับกลไกของเกมด้วย (มันอาจจะคุ้มค่าเมื่อพิจารณาด้วย GPUs, CPU และทรัพยากรอื่น ๆ ที่เรามีในปัจจุบันมีพลังมากกว่าซึ่งทำให้คุณกังวลเกี่ยวกับทรัพยากรที่เป็นปัญหาอย่างที่คุณเห็น นอกจากนี้ยังขึ้นอยู่กับวิธีที่คุณกำหนด 'ตัวละครทั้งหมดในครั้งเดียว' คุณหมายถึงในเวลาเดียวกันแน่นอน? คุณจะไม่มีสิ่งนั้นในขณะที่ปีเตอร์ชี้ให้เห็นอย่างถูกต้องดังนั้นในครั้งเดียวนั้นไม่เกี่ยวข้องในความหมายที่แท้จริง มันจะปรากฏแบบนี้เท่านั้น

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

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

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

(จำนวนอินสแตนซ์จะแตกต่างกันไปตามหลักสูตร - สูงและต่ำ)

โทรศัพท์มือถือ (NPC เช่นตัวละครที่ไม่ใช่ผู้เล่น): 2614; ต้นแบบ: 1360 วัตถุ: 4457; ต้นแบบ: 2281 ห้อง: 7983; แบบตัวอย่าง: 7983 แต่ละห้องมีตัวอย่างของตัวเองโดยปกติ แต่เรายังมีห้องแบบไดนามิกที่จะพูดห้องภายในห้อง; หรือห้องที่อยู่ในมือถือเช่นท้องของมังกร หรือห้องในวัตถุเช่นคุณป้อนวัตถุวิเศษ) โปรดทราบว่าห้องไดนามิกเหล่านี้มีอยู่ตามวัตถุ / ห้อง / มือถือที่กำหนดไว้จริง ใช่นี่เป็นเหมือน World of Warcraft (ฉันไม่เล่น แต่เพื่อนให้ฉันเล่นเมื่อฉันมีเครื่อง Windows สักครู่) ความคิดของอินสแตนซ์ยกเว้นเรามีมันมานานก่อนที่ World of Warcraft จะมีอยู่

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

เราจะจัดการทั้งหมดนี้ได้อย่างไรโดยไม่ชักช้า?

• ซ็อกเก็ต: select (), คิว (อินพุต, เอาท์พุท, เหตุการณ์, สิ่งอื่น ๆ ), บัฟเฟอร์ (อินพุต, เอาต์พุต, สิ่งอื่น ๆ ) ฯลฯ สิ่งเหล่านี้มีการสำรวจ 10 ครั้งต่อวินาที

• ตัวละคร, วัตถุ, ห้องพัก, การต่อสู้, ทุกอย่าง: ทั้งหมดอยู่ในวงวนกลางในพัลส์ที่แตกต่างกัน

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