สถาปัตยกรรมเอ็นจิ้นเกม MVC (Model-View-Controller) - ใช่หรือไม่? [ปิด]


18

ฉันกำลังอ่านหนังสือเล่มหนึ่งที่ยอดเยี่ยมGame Coding Completeและหนังสือเล่มนี้ขอแนะนำอย่างยิ่งให้ใช้วิธีMVC (Model-View-Controller)ด้วยเลเยอร์สำคัญสามประการ:

  1. แอปพลิเคชันเลเยอร์
  2. เกมลอจิก
  3. มุมมองเกม

สำหรับฉันแล้ววิธีการนี้ดูเหมือนว่าเป็นเกมเกินราคาสำหรับเกมคอมพิวเตอร์พกพา

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


5
-1 และโหวตให้ปิด ทุกสิ่งที่ควรพูดเกี่ยวกับ MVC ในเกมนั้นได้รับการพูดถึงที่gamedev.stackexchange.com/questions/3426/และสิ่งที่เราได้มาที่นี่ก็คือขยะ

@Joe Wreschnig มันค่อนข้างโหดร้าย แต่ฉันเดาว่าเป็นเรื่องจริง ...
358 Spooks

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

2
@Joe: โอ้ขอบคุณมาก :) การโต้แย้งว่า OOP นั้นฟรีไม่มีค่าใช้จ่าย ฉันคิดว่าตามมาตรฐานบางอย่างเราไม่ควรต้องการคะแนนเหมือนที่ฉันได้ย้ำ แต่ noobs เกิดขึ้นและทำคำถามที่ซ้ำกัน debatably นอกจากนี้ยังให้บริการฟังก์ชั่นในการปล่อยให้ผู้มาที่หน้าเว็บเช่นฉันขูดร่วมกันเล็กน้อยแม้จะมีกิจกรรมที่มีผู้เสียชีวิตจำนวนมาก :) ฉันหมายถึงเอ่อฉันมี 40K ตัวแทนบน SO แต่ที่นี่ฉันไม่สามารถแม้แต่แก้ไขแท็กวิกิ
ความโกลาหล

คำตอบ:


30

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

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

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


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

1
คำตอบที่ดี +1 ที่ .. ทฤษฎีทั้งหมดและดี แต่มันสามารถทำให้เกมไม่ถูกจัดส่งถ้าคุณไม่ได้ทำมัน
James

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

4

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

เกมสมัยใหม่หลายเกมใช้โมเดลและมุมมองของเธรดแยกกันและรับประโยชน์ด้านประสิทธิภาพที่ยอดเยี่ยมบนแพลตฟอร์มส่วนใหญ่

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

แก้ไข: การออกแบบเวลารวบรวมไม่ใช้พลังงาน CPU การออกแบบรันไทม์เช่นการสืบทอดทำได้ชัดเจน


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

ขอบคุณ DeadMG สำหรับคำตอบของคุณ โดยพื้นฐานแล้วฉันหมายถึงว่าในทุกระดับของนามธรรมรหัสจะได้รับ slover เนื่องจากมีการเพิ่มขั้นตอนกลางมากขึ้นเรื่อย ๆ MVC เป็นการออกแบบที่เป็นนามธรรมมากกว่าซึ่งน่าจะส่งผลให้มีขั้นตอนมากขึ้นในการทำงานเดียวกัน สิ่งนี้จะมีอิทธิพลต่อความเร็ว imo
Bunkai.Satori

4

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

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

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

สำหรับข้อมูลเพิ่มเติมโปรดอ่านคำถาม"ทำไม MVC & TDD ถึงไม่ได้ใช้งานในโครงสร้างของเกมมากกว่านี้" และคำตอบที่ยาวมากของฉัน


1
ภาษา OO นั้นไม่ช้าไปกว่าภาษาเชิงดำเนินการเลย หากคุณเขียนโค้ดบางตัวใน C ++ ที่ทำการเปลี่ยนบิตมันจะไม่ช้ากว่าใน C ภาษาหรือโปรแกรมจะไม่ช้าลงเมื่อเทียบกับขั้นตอนเลยเพียงเพราะมันเป็นวัตถุที่วางแนว โปรแกรมแสดงผลการปฏิบัติงานที่อันตรายเนื่องจากเขียนได้ไม่ดีเท่านั้น เป็นผลให้ฉันรู้สึกจำเป็นต้อง downvote คำตอบของคุณ
DeadMG

สวัสดี Ricket ขอขอบคุณสำหรับคำอธิบายของคุณ มันฟังดูมีเหตุผลมาก DeadMG ในอีกด้านหนึ่งคุณถูกต้องในอีกด้านหนึ่งฉันคิดว่าวิธีการ OO เพิ่มข้อมูลจำนวนมากในโค้ดที่คอมไพล์มากกว่าภาษาเชิงปฏิบัติ บิตเพิ่มเติมของรหัสที่เกี่ยวข้อง OO นี้ทำให้รหัสผลลัพธ์ช้าลง คุณเห็นด้วยไหม?
Bunkai.Satori

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

2
หากฟังก์ชั่นเป็นเสมือนนั่นหมายความว่าโปรแกรมจำเป็นต้องเลือกระหว่างฟังก์ชั่นรุ่นเดียวกัน 2 รุ่นในเวลาทำงาน (ไม่เช่นนั้นคุณจะไม่ทำให้มันเป็นเสมือน) ในกรณีนี้คุณมีเงื่อนไขพิเศษหรือระดับของความไม่สอดคล้องกันอยู่แล้วซึ่งคุณจะต้องใช้ตัวเองเป็นภาษาขั้นตอน (เช่นผ่านตัวชี้ฟังก์ชันหรือคำสั่งเปลี่ยน) . นั่นไม่ใช่ค่าใช้จ่าย - นั่นเป็นปัญหาที่แท้จริง
Kylotan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.