การสื่อสารที่ขับเคลื่อนด้วยเหตุการณ์ใน Game Engine: ใช่หรือไม่ใช่

ฉันกำลังอ่านGame Coding Completeและผู้เขียนแนะนำให้ใช้การสื่อสาร Event Drivenระหว่างวัตถุและโมดูลเกม

โดยพื้นฐานแล้วนักแสดงเกมที่มีชีวิตทุกคนควรสื่อสารกับโมดูลหลัก (Physics, AI, Game Logic, Game View, ฯลฯ ) ผ่านระบบการส่งข้อความเหตุการณ์ภายใน ซึ่งหมายความว่าต้องออกแบบผู้จัดการเหตุการณ์ที่มีประสิทธิภาพ ระบบที่ออกแบบมาไม่ดีจะกินซีพียูเป็นวงรอบ

นี่เป็นแนวทางที่ได้รับการพิสูจน์แล้วหรือไม่? ฉันจะตัดสินใจได้อย่างไรว่าจะใช้หรือไม่

นี่คือการขยายความคิดเห็นของฉันไปยังคำตอบแบบเต็มตามที่แนะนำ

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

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

แก้ไข : เพื่อตอบคำถามความคิดเห็นเกี่ยวกับวิธีการที่คุณรู้ว่าวัตถุใดควรได้รับข้อความ : ตัววัตถุควรRequestได้รับการแจ้งเตือนเกี่ยวกับเหตุการณ์ EventMessagingSystem(EMS) ของคุณจะต้องมีRegister(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)การจับคู่Unregister(ทำรายการที่ไม่ซ้ำกันสำหรับiEventIdตัวชี้วัตถุและโทรกลับ) วิธีนี้เมื่อวัตถุต้องการทราบเกี่ยวกับข้อความที่มันสามารถทำได้Register()กับระบบ เมื่อไม่ต้องการรู้เกี่ยวกับเหตุการณ์อีกต่อไปก็สามารถทำได้Unregister(). เห็นได้ชัดว่าคุณต้องการกลุ่มของวัตถุการลงทะเบียนติดต่อกลับและวิธีที่มีประสิทธิภาพในการเพิ่ม / ลบออกจากรายการ (ฉันมักจะใช้อาร์เรย์สั่งซื้อด้วยตนเอง; วิธีที่ดีในการบอกว่าพวกเขาติดตามการจัดสรรของตัวเองระหว่างกลุ่มสแตกของวัตถุที่ไม่ได้ใช้และอาร์เรย์ที่เปลี่ยนขนาดในสถานที่เมื่อจำเป็น)

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

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

และก็ไม่เป็นไรเพราะเมื่อคุณทำเสร็จแล้วคุณจะมีเกมจริง ๆ และเกมนั้นเจ๋งกว่าระบบส่งข้อความ

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

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

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

(การสื่อสารระหว่างกระบวนการคือการสื่อสารระหว่างกระบวนการ (เช่นการใช้งานอินสแตนซ์ของโปรแกรม) ภายในสภาพแวดล้อมระบบปฏิบัติการ)

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

ฉันยังถามคำถามใน Stack Overflow ว่า"โครงสร้างข้อมูลสำหรับการส่งข้อความภายในโปรแกรม" ซึ่งคุณอาจต้องการอ่านมากกว่า

ข้อความโดยทั่วไปทำงานได้ดีเมื่อ:

1. สิ่งที่ส่งข้อความไม่สนใจหากได้รับ
2. ผู้ส่งไม่จำเป็นต้องได้รับการตอบกลับทันทีจากผู้รับ
3. อาจมีผู้รับหลายคนที่ฟังผู้ส่งรายเดียว
4. ข้อความจะถูกส่งไม่บ่อยหรือไม่แน่นอน (กล่าวอีกนัยหนึ่งถ้าทุกวัตถุจำเป็นต้องได้รับข้อความ "อัปเดต" ทุก ๆ เฟรมข้อความจะไม่ซื้อคุณมากนัก)

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

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

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

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

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

ฉันรู้ว่าโพสต์นี้ค่อนข้างเก่า แต่ฉันไม่สามารถต้านทานได้

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

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

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

แม้จะมีระบบข้อความพื้นฐานฉันก็บอกได้ว่าระบบนี้ส่วนใหญ่จะเป็น "update loop based"

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

แต่ฉันก็คิดด้วยว่าระบบ "การอัพเดทแบบวนซ้ำ" เช่นเดียวกับฉันก็มีปัญหาเช่นกัน

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

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

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

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

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

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

รายละเอียดเพิ่มเติมและการใช้งานที่นี่

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

• เอ็นจิ้นเกมจัดการกับข้อมูลจำนวนมาก
• เกมจะต้องเร็ว (20-30 FPS ควรน้อยที่สุด)
• บ่อยครั้งที่มีความจำเป็นต้องทราบว่ามีบางสิ่งที่ทำไปแล้วหรือจะทำเมื่อใด

ด้วยวิธีการที่นักพัฒนาเกมทั่วไปของ "มันต้องมีประสิทธิภาพมากที่สุด" ระบบการส่งข้อความดังกล่าวจึงไม่ธรรมดา

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