รูปแบบการออกแบบการเขียนโปรแกรมอะไรบ้างที่มีประโยชน์ในการพัฒนาเกม [ปิด]

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

ตัวอย่างเช่นฉันมีหนังสือชื่อว่า ActionScript 3 ที่มีรูปแบบการออกแบบที่มีรายละเอียดรูปแบบการออกแบบหลายอย่างเช่นตัวควบคุมมุมมองโมเดล, ซิงเกิล, โรงงาน, คำสั่ง ฯลฯ

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

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

ขอบคุณ!

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

• ตัวสร้าง: ตั้งค่าเอนทิตีที่ยึดตามส่วนประกอบทีละองค์ประกอบตามข้อมูล
• วิธีการจากโรงงาน: สร้าง NPC หรือวิดเจ็ต GUI ตามสตริงที่อ่านจากไฟล์
• ต้นแบบ: เก็บอักขระ 'เอลฟ์' หนึ่งตัวพร้อมคุณสมบัติเริ่มต้นและสร้างอินสแตนซ์เอลฟ์โดยการโคลน
• ซิงเกิล: พื้นที่นี้เว้นว่างโดยเจตนา
• อะแดปเตอร์: รวมไลบรารีของบุคคลที่สามที่เป็นตัวเลือกโดยห่อไว้ในเลเยอร์ที่ดูเหมือนรหัสที่มีอยู่ของคุณ มีประโยชน์มากกับ DLLs
• Composite: สร้างกราฟฉากของวัตถุที่แสดงผลได้หรือสร้าง GUI จากต้นไม้ของวิดเจ็ต
• Facade: ลดความซับซ้อนของไลบรารี่ของบุคคลที่สามด้วยการจัดหาอินเทอร์เฟซที่เรียบง่ายเพื่อทำให้ชีวิตของคุณง่ายขึ้นในภายหลัง
• Flyweight: จัดเก็บแง่มุมที่ใช้ร่วมกันของ NPC (เช่นแบบจำลองพื้นผิวภาพเคลื่อนไหว) แยกต่างหากจากแต่ละด้าน (เช่นตำแหน่งสุขภาพ) ในแบบโปร่งใสส่วนใหญ่
• พร็อกซี: สร้างคลาสขนาดเล็กบนไคลเอนต์ที่แสดงคลาสที่ใหญ่ขึ้นซับซ้อนกว่าบนเซิร์ฟเวอร์และส่งต่อคำขอผ่านเครือข่าย
• ห่วงโซ่ความรับผิดชอบ: จัดการอินพุตเป็นสายโซ่ของตัวจัดการเช่น ปุ่มสากล (เช่นสำหรับภาพหน้าจอ) จากนั้น GUI (เช่นในกรณีที่กล่องข้อความเน้นหรือเมนูขึ้น) จากนั้นเกม (เช่นสำหรับการย้ายตัวละคร)
• Command: ห่อหุ้มฟังก์ชันการทำงานของเกมเป็นคำสั่งที่สามารถพิมพ์ลงในคอนโซลจัดเก็บและเล่นซ้ำหรือแม้แต่เขียนสคริปต์เพื่อช่วยทดสอบเกม
• ผู้ไกล่เกลี่ย: ใช้เอนทิตีเกมเป็นคลาสคนกลางขนาดเล็กที่ทำงานกับส่วนประกอบต่าง ๆ (เช่นการอ่านจากองค์ประกอบด้านสุขภาพเพื่อส่งผ่านข้อมูลไปยังองค์ประกอบ AI)
• ผู้สังเกตการณ์: มีการแสดงตัวของตัวละครที่ฟังเหตุการณ์จากการเป็นตัวแทนทางตรรกะเพื่อเปลี่ยนการนำเสนอภาพเมื่อมีความจำเป็นโดยไม่ต้องใช้ตรรกะของเกมจำเป็นต้องรู้อะไรเกี่ยวกับการสร้างรหัส
• สถานะ: เก็บ NPC AI เป็นหนึ่งในหลาย ๆ รัฐเช่น โจมตีหลงทางหนี แต่ละคนสามารถมีวิธีการอัพเดต () ของตัวเองและข้อมูลอื่น ๆ ที่ต้องการ (เช่นการจัดเก็บอักขระที่มันถูกโจมตีหรือหนีออกจากพื้นที่ที่มันกำลังหลงทาง ฯลฯ )
• กลยุทธ์: สลับไปมาระหว่างฮิวริสติกที่แตกต่างกันสำหรับการค้นหา A * ของคุณขึ้นอยู่กับภูมิประเทศที่คุณอยู่หรืออาจใช้เฟรมเวิร์ก A * เดียวกันเพื่อทำทั้งการค้นหาเส้นทางและการวางแผนทั่วไป
• แม่แบบวิธีการ: ตั้งค่ารูทีนทั่วไป 'combat' พร้อมฟังก์ชั่น hook ที่หลากหลายเพื่อจัดการแต่ละขั้นตอนเช่น กระสุนที่ลดลง, คำนวณโอกาสในการโจมตี, แก้ไขการชนหรือพลาด, คำนวณความเสียหายและทักษะการโจมตีแต่ละประเภทจะใช้วิธีการในแบบของตนเอง

บางรูปแบบถูกทิ้งไว้เนื่องจากขาดแรงบันดาลใจ

ผมเขียนหนังสือเกี่ยวกับว่าที่หัวข้อ: รูปแบบการเขียนโปรแกรมเกม บทที่มีอาจเป็นประโยชน์สำหรับคุณ

สิ่งหนึ่งที่แบรนดอนไอชมีความรู้สึกที่ดีที่จะนำขึ้นมาใช้ในโคเดอร์สออฟเวิร์คคือรูปแบบการแฮ็กและการแก้ปัญหา: [รูปแบบ] แสดงข้อบกพร่องบางอย่างในภาษา รูปแบบเหล่านี้ไม่ฟรี ไม่มีอาหารกลางวันฟรี ดังนั้นเราควรมองหาวิวัฒนาการในภาษาที่เพิ่มบิตที่ถูกต้อง

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

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

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

การเขียนโปรแกรม:

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

การใช้งาน:

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

แน่นอนว่าหนังสือเล่มนี้มีรายละเอียดเพิ่มเติมเกี่ยวกับสิ่งเหล่านี้

ระบบเอนทิตีเป็นรูปแบบที่ดี มันไม่ใช่รูปแบบการออกแบบที่แน่นอนเพราะไม่ใช่ OOP อย่างน่ากลัว อย่างไรก็ตามคุณสามารถผสมกับ OOP

ลิงก์ที่ดีบางรายการ (เริ่มจากบนสุดสำหรับอินโทรภายใน):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

ทั้งหมดนั้น. ยกเว้นซิงเกิล [/ เล้]

ไม่เกี่ยวกับรูปแบบจริงๆ แต่เกี่ยวกับหลักการพื้นฐานที่อยู่เบื้องหลังพวกเขา ใน"รูปแบบการออกแบบ: องค์ประกอบของซอฟต์แวร์เชิงวัตถุที่ใช้ซ้ำได้" (1995)กลุ่มของสี่ (Gamma, Erich; Richard Helm, Ralph Johnson และ John Vlissides) แนะนำเพียงสองหลักการสำหรับการออกแบบเชิงวัตถุ: (1)โปรแกรมเพื่อ อินเทอร์เฟซและไม่นำไปใช้และ(2)สนับสนุนการจัดวางวัตถุมากกว่าการสืบทอดคลาส

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

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

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

ตัวอย่างเช่นคุณสามารถใช้สิ่งนี้เมื่อรวบรวมคลาสสำหรับหลายแพลตฟอร์มหรือเอ็นจิ้น (dx vs. opengl) ซึ่งทราบความแปรปรวนของชนิดในเวลารวบรวม

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

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