ใน Source engine (และเป็นผู้บุกเบิก, goldsrc, quake's) วัตถุของเกมจะถูกแบ่งออกเป็นสองประเภทโลกและเอนทิตี โลกคือรูปทรงเรขาคณิตของแผนที่และเอนทิตีคือผู้เล่น, อนุภาค, เสียง, คะแนน, ฯลฯ (สำหรับ Source Engine)

ทุกหน่วยงานมีฟังก์ชั่นการคิดซึ่งทำทุกตรรกะสำหรับเอนทิตีนั้น

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

ในตอนแรกความคิดนี้มีเหตุผล แต่อาจใช้ทรัพยากรมากเกินไปถ้าเกมมีเอนทิตีจำนวนมาก ..

ดังนั้นเอ็นจินเช่น Source ดูแล (กระบวนการอัปเดตวาด ฯลฯ ) ของวัตถุในเกมอย่างไร

ไม่มีวิธีอื่นที่จะทำ - คุณจะต้องวนซ้ำและเรียกร้องthink()ให้ทุกเอนทิตี้อย่างน้อยหนึ่งครั้งในทุก ๆ สองสามเฟรม

คุณสามารถใส่เอนทิตีในเธรดของตัวเอง แต่จากนั้นคุณมีฝันร้ายที่ซิงโครไนซ์สถานะทั้งหมดซึ่งไม่คุ้มค่าอย่างแน่นอน

ในตอนแรกความคิดนี้มีเหตุผล แต่อาจใช้ทรัพยากรมากเกินไปถ้าเกมมีเอนทิตีจำนวนมาก ..

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

นี่คือเหตุผลว่าทำไมเมื่อสร้างแผนที่พวกเขาแนะนำให้คุณอย่าใช้มากกว่า 800 รายการ

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

for each object
    do physics
    do game logic
    draw

กลายเป็น

call physics subsystem
call game logic subsystem
call drawing subsystem

เครื่องยนต์ฟิสิกส์ดูแลตำแหน่งและขนาด

เครื่องยนต์เกมลอจิกดูแลการตีความสิ่งที่ฟิสิกส์เครื่องยนต์เปลี่ยน (เขาอาจขัดขวางจุดบาง ... ), สิ่งที่ตัวละครเป้าหมายมีและสิ่งที่พฤติกรรมของพวกเขาควรจะทำสคริปต์เขาทำงานที่กำหนด (ซึ่งคิดว่าฟังก์ชั่น)

เครื่องมือวาดภาพวาดสิ่งที่วัตถุที่มองเห็นได้และเขารู้ว่าวัตถุที่มองเห็นได้เพราะเครื่องยนต์ Quake ชนิดของการโกงที่นี่ (ดูส่วนการวาด)

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

ฟิสิกส์

ความคิดทั้งหมดของการทำซ้ำทุกหน่วยงานและทำ {คิดว่าวาด} อาจนำไปสู่ปัญหา จะมีความขัดแย้งเป็นต้น ฉันเชื่อว่า Valve มี Havok และฉันคิดว่า Havok จะดูแลฟิสิกส์ที่ถูกต้องเพียงพอ

คิด

คิดว่าฟังก์ชั่นจะทำงานเมื่อเวลาในเกมเท่ากับเวลาในการคิดต่อไป มันใช้วิธีนี้ใน Quake engine และ Quake engine เป็นพื้นฐานสำหรับเครื่องยนต์ Half Life มันไม่ได้ทำงานทุกครั้ง

ภายในควรเป็นการวนซ้ำอย่างง่าย ๆ ผ่านรายการของเอนทิตีและตรวจสอบว่าเวลาผ่านไปเพื่อเรียกฟังก์ชันคิด ความซับซ้อนของเวลาจะเป็น O (N) โดยที่ N คือจำนวนเอนทิตี

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

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

นอกจากนี้คุณยังควรมีลักษณะที่O (1) การจัดตารางเวลาในลินุกซ์

วาด

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

พวกเขาเก็บสิ่งที่พื้นที่เป็นพื้นที่ที่มองเห็นได้ มันถูกเรียกว่า"ชุดศักยภาพที่มองเห็นได้", PVSสั้น ๆ มีการสร้างภาพของ PVSเป็นแคปซูลสีเขียวเป็นผู้เล่นและรอบตัวเขาจะแสดงสิ่งที่ PVS ของเขามี

ดังนั้นหากทุกอย่างที่ต้องประมวลผลมาจากคลาสพื้นฐานพร้อมฟังก์ชันคิดเครื่องมือสร้างเกมสามารถเก็บทุกอย่างไว้ในรายการและในทุกเฟรมวนรอบมันและเรียกฟังก์ชันนั้น

ในตอนแรกความคิดนี้มีเหตุผล แต่อาจต้องใช้ทรัพยากรมากเกินไปถ้าเกมมีเอนทิตี้มากมาย ..

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

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

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

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

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

และมีการเพิ่มประสิทธิภาพระดับอื่น ๆ ที่เฉพาะเจาะจงขึ้นอยู่กับตรรกะของเกมและสถานการณ์ของคุณ