เอ็นจิ้นเกมและการออกแบบที่ขับเคลื่อนด้วยข้อมูล

ฉันได้ยินเกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยข้อมูลและได้ทำการค้นคว้าเกี่ยวกับมันมาระยะหนึ่งแล้ว ดังนั้นฉันได้อ่านหลายบทความเพื่อให้ได้แนวคิด

หนึ่งในบทความคือData Driven Design ที่เขียนโดย Kyle Wilson. ตามที่เขาอธิบายดูเหมือนว่ารหัสแอปพลิเคชัน (เช่นรหัสสำหรับการควบคุมทรัพยากรเช่นหน่วยความจำเครือข่าย ... ) และรหัสเกมควรแยกจากกันและรหัสเกมตรรกะควรถูกขับเคลื่อนโดยแหล่งข้อมูลภายนอก ณ จุดนี้ฉันสามารถจินตนาการได้ว่าผู้พัฒนาจะเขียนตัวแก้ไขเกมซึ่งยอมรับข้อมูลภายนอกเกี่ยวกับวัตถุในเกม (เช่นข้อมูลตัวละครข้อมูลอาวุธข้อมูลแผนที่ ... ) การออกแบบสถานการณ์จะถูกเขียนสคริปต์โดยภาษาที่กำหนดเอง / เครื่องมือที่เขียนโดยโปรแกรมเมอร์เพื่อให้ผู้ออกแบบเกมสร้างปฏิสัมพันธ์ระหว่างในวัตถุในเกม ผู้ออกแบบเกมจะใช้ภาษาสคริปต์ที่มีอยู่ / กำหนดเองเพื่อเขียนสคริปต์สำหรับเกมหรือเครื่องมือลากแล้ววางเพื่อสร้างโลกของเกม ตัวอย่างของวิธีการใช้เครื่องมือที่ฉันคิดได้คือ World Editor ซึ่งโดยปกติจะบรรจุพร้อมกับเกมของ Bliizard

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

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

ดังนั้นหลังจากทั้งหมดนี้ฉันแค่ต้องการตรวจสอบว่ามีข้อบกพร่องในความเข้าใจของฉันเกี่ยวกับความคิดเหล่านี้ (ข้อมูลที่ขับเคลื่อนด้วยไดรฟ์โปรแกรมเมอร์โปรแกรมเมอร์สคริปต์ ฯลฯ ... )?

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

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

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

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

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

สำหรับคำถามเฉพาะของคุณ:

นี่เป็นความจริงที่ว่าเอ็นจิ้นเกมควรเป็นอย่างไร

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

ดังนั้นหลังจากทั้งหมดนี้ฉันแค่ต้องการตรวจสอบว่ามีข้อบกพร่องในความเข้าใจของฉันเกี่ยวกับความคิดเหล่านี้ (ข้อมูลที่ขับเคลื่อนด้วยไดรฟ์โปรแกรมเมอร์โปรแกรมเมอร์สคริปต์ ฯลฯ ... )?

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

ในฐานะผู้เขียนโพสต์ที่สองฉันต้องการชี้แจงบางประเด็น

1. ดังที่ Josh Petrie แนะนำให้จัดโครงสร้างโค้ดของคุณเพื่อใช้ข้อมูลแทนที่จะเขียนโค้ดอย่างหนักทุกอย่างเป็นชัยชนะเสมอ ฉันไม่ได้แนะนำอย่างอื่น ฉันชี้ให้เห็นว่าการผลักทุกอย่างให้กับนักออกแบบไม่ใช่ความคิดที่ดี คำว่า "การออกแบบที่ขับเคลื่อนด้วยข้อมูล" หมายถึงสิ่งที่แตกต่างสำหรับคนอื่นดังนั้นฉันอาจจะต้องเจาะจงมากขึ้นเมื่อฉันเขียนบทความต้นฉบับ
2. ทุกที่ที่ฉันทำงานเราสร้างโครงสร้างข้อมูลที่ปรับแต่งได้ในเอ็นจิ้น เพื่อทำการเปลี่ยนแปลงเราไม่จำเป็นต้องคอมไพล์เกมอีกครั้ง เราสามารถเปลี่ยนจำนวนแบบไดนามิกที่รันไทม์ โครงสร้างข้อมูลมักจะถูกเก็บไว้ในรหัส แต่ขึ้นอยู่กับว่าใครมีการเปลี่ยนแปลงพวกเขาสามารถโหลดได้ง่ายจาก "ไฟล์ข้อมูล"
3. สภาพแวดล้อมการพัฒนาส่วนใหญ่รองรับรูปแบบการแก้ไขและดำเนินการต่อหรือโหลดโมดูลใหม่สำหรับ C / C ++
4. สตูดิโอพัฒนาเกมส่วนใหญ่มีโปรแกรมเมอร์เกม งานของพวกเขามักจะทำงานร่วมกับนักออกแบบในการสร้างประสบการณ์ที่สนุกสนาน ความกังวลหลักของพวกเขาไม่ใช่ความท้าทายด้านเทคนิค แต่ค่อนข้างสนุกจากรหัส ฉันทำงานเป็นโปรแกรมเมอร์เกมเป็นเวลาหลายปีและฉันพบว่าสิ่งนี้น่าสนใจมากกว่าแค่พยายามแก้ปัญหาด้านเทคนิค ความรับผิดชอบของฉันแตกต่างกันไป แต่ฉันพบว่างานของฉันสำเร็จลุล่วงไปได้มากที่สุดเมื่อฉันรับผิดชอบในการนำไปปฏิบัติ ปัญหาเกี่ยวกับการเขียนโค้ดหรือการเขียนสคริปต์ของนักออกแบบคือโปรแกรมเมอร์มักจะต้องจัดการกับข้อบกพร่องซึ่งเป็นหนึ่งในสิ่งที่สนุกที่สุดที่คุณสามารถทำได้ในฐานะโปรแกรมเมอร์
5. สิ่งที่ดีที่สุดสำหรับสตูดิโอขึ้นอยู่กับเกม หากคุณมีเวลานานในการสร้างเกมและคุณต้องการมอบเกมให้กับชุมชน mod และสร้างสิ่งที่ยิ่งใหญ่ในขอบเขตจากนั้นสร้างเกมที่ขับเคลื่อนด้วยข้อมูลอย่างสมบูรณ์ เกมจำนวนมากไม่มีเป้าหมายนั้น พวกเขาต้องปั่นเกมใหม่ในอีกสองปีและถ้าพวกเขาไม่ได้รับสิทธิพิเศษมันอาจเป็นเกมประเภทที่แตกต่างจากงานก่อนหน้านี้
6. สิ่งที่ "ผู้ออกแบบ" อาจแตกต่างกันไปในแต่ละสตูดิโอ ฉันเคยได้ยินสตูดิโอพัฒนาที่จ้างโปรแกรมเมอร์เกมจากสตูดิโออื่นเรียกพวกเขาว่านักออกแบบและให้พวกเขาเขียนพฤติกรรมของเกม นี่เป็นปัญหาของการมีคนที่ไม่ได้รับการฝึกฝนในการเขียนโปรแกรมการเขียนโปรแกรม / การเขียนสคริปต์
7. ควรมีการอธิบายระหว่างรหัสเกมตรรกะและรหัสเครื่องยนต์เสมอ และโดยปกติคุณต้องการให้มีโปรแกรมแก้ไขภาพบางประเภทสำหรับการจัดวางวัตถุ ฉันไม่เคยทำงานในสตูดิโอที่มีสถานที่ตั้งของศัตรูอย่างหนัก พวกเขาอยู่ในตัวแก้ไข ฉันขอเสนอตัวอย่างของสิ่งที่ฉันกำลังพูดถึง สมมติว่าผู้ออกแบบคิดถึงศัตรู นักออกแบบมากกว่าสคริปต์ที่ทำงานกับศัตรูประเภทใหม่นี้หรือไม่? นั่นคือสิ่งที่ฉันพิจารณาการออกแบบที่ขับเคลื่อนด้วยข้อมูล (ในแง่ของสิ่งที่ Tim Moss เขียนเกี่ยวกับมัน) ในแบบที่ฉันกำลังเสนอโปรแกรมเมอร์ทำงานร่วมกับนักออกแบบพวกเขาสร้างศัตรูที่สนุกด้วยกันอาจมีพารามิเตอร์ที่ปรับเปลี่ยนได้และจากนั้นพวกเขาจะอยู่ในระดับ
8. โค้ดเนทีฟที่เขียนโดยโปรแกรมเมอร์จะทำงานได้เร็วกว่ารันไทม์กว่าสคริปต์ที่เขียนโดยโปรแกรมเมอร์ซึ่งจะทำงานได้เร็วกว่าสคริปต์ที่เขียนโดยบุคคลที่มีความเชี่ยวชาญด้านเทคนิคน้อยกว่า การแสดงนี้อาจมีหรือไม่มีความสำคัญขึ้นอยู่กับประเภทของเกมที่คุณกำลังทำและสิ่งที่คุณกำลังทำอยู่ แต่มันเป็นสิ่งที่ต้องพิจารณา
9. คุณสามารถแบ่งปันรหัสเกมระหว่างเกมโดยไม่คำนึงถึงวิธีการที่คุณเลือก ฉันไม่แน่ใจจริงๆว่าคุณกำลังทำอะไรกับประเด็นนี้ แม้ว่าคุณจะไม่ได้ใช้ภาษาสคริปต์หรือเครื่องมือแสดงภาพเพื่อกำหนดพฤติกรรมบางอย่างคุณควรจะสร้างรหัสการเล่นเกมของคุณให้เป็นองค์ประกอบที่สามารถใช้ซ้ำได้มากเท่าที่คุณจะทำได้ จะมีสิ่งที่ไม่สามารถใช้ได้กับเกมถัดไปของคุณเสมอ แต่ทุกที่ที่ฉันเคยทำงานเมื่อเราเริ่มเกมถัดไปเราเริ่มต้นด้วย codebase จากก่อนหน้านี้แม้ว่ามันจะไม่ใช่ภาคต่อก็ตาม จากนั้นเราจะเก็บเนื้อหาที่เหมาะสมและลบเนื้อหาเฉพาะของเกม

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

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

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

คุณควรจะดูBitSquid เทคเครื่องยนต์ มันคือการสร้างโดยใช้แนวคิด DOD บล็อกของNiklas Frykholmนั้นน่าสนใจมาก มีบทความมากมายเกี่ยวกับวิธีการออกแบบเครื่องยนต์นี้

ที่ GDC 2011 Niklas ได้ทำการนำเสนอเกี่ยวกับข้อมูลขับเคลื่อน Renderer