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

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

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

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

ฉันขอความช่วยเหลือจากคำถามต่อไปนี้:

• อะไรคือข้อดีและข้อเสียของทั้งสองวิธีคืออะไร?
• อันไหนดีกว่าอีกอัน?
• การออกแบบเกมเป็นไปตามหลักสากลและดีกว่าในทุก ๆ ด้านหรือไม่? ดังนั้นจึงแนะนำให้ใช้งานแม้ในแพลตฟอร์ม mombile?
• อันไหนมีประสิทธิภาพมากขึ้นและยากต่อการพัฒนา

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

ตัวอย่าง: คำถามนี้ทำให้เกิดความขัดแย้งเล็กน้อยที่นี่ดังนั้นฉันขอเสนอตัวอย่าง: ตาม MVC เครื่องมือเกมแบ่งออกเป็นสามส่วนหลัก:

1. Application Layer (การสื่อสารของฮาร์ดแวร์และระบบปฏิบัติการ)
2. เกมลอจิก
3. มุมมองเกม

ในเกมแข่งรถ Game View รับผิดชอบในการแสดงผลหน้าจอโดยเร็วที่สุดอย่างน้อย 30 เฟรมต่อวินาที Game View รับฟังอินพุตของผู้เล่นด้วย ตอนนี้สิ่งนี้เกิดขึ้น:

• ผู้เล่นกดแป้นคันเร่งเป็น 80%
• GameView สร้างข้อความ "เหยียบเชื้อเพลิงรถยนต์ 2 กดถึง 80%" และส่งไปที่ Game Logic
• เกมลอจิกได้รับข้อความประเมินคำนวณตำแหน่งและพฤติกรรมของรถยนต์ใหม่และสร้างข้อความต่อไปนี้สำหรับ GameView: "Draw Car 2 Fuel Pedal Pressed 80%", "Car 2 Sound Acceleration", "Car 2 Coordinates X, Y" .. .
• GameView ได้รับข้อความและดำเนินการตามนั้น

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

อะไรคือข้อดีและข้อเสียของทั้งสองวิธี?

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

อันไหนดีกว่าอีกอัน?

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

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

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

อันไหนมีประสิทธิภาพมากขึ้นและยากต่อการพัฒนา

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

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

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

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

บรรทัดล่าง: ไม่มีวิธีที่ดีกว่าหรือไม่ได้เป็นพิเศษ

สิ่งนี้เริ่มต้นเป็นความเห็นต่อคำตอบของ bummzack แต่ใช้เวลานาน

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

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

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

พวกเขาเป็นเครื่องมือที่ยอดเยี่ยม แต่อย่าง bummzack กล่าวอย่าคิดว่า polymorphism และเหตุการณ์ต่าง ๆ แก้ปัญหาเดียวกันได้

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

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

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

แก้ไขให้ชัดเจนขึ้นในประโยคแรกของฉัน