จะหลีกเลี่ยงวัตถุ GameManager god ได้อย่างไร?

ฉันเพียงแค่อ่านคำตอบสำหรับคำถามเกี่ยวกับโครงสร้างรหัสเกม มันทำให้ฉันสงสัยเกี่ยวกับGameManagerคลาสที่แพร่หลายและบ่อยครั้งที่มันจะกลายเป็นปัญหาในสภาพแวดล้อมการผลิต ให้ฉันอธิบายสิ่งนี้

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

แล้วมี Greenlight GameManagerและในความพยายามที่จะทำความสะอาดสิ่งขึ้นบางคนเขียน อาจเป็นไปได้ที่จะถือมัดGameStatesอาจจะเก็บไม่กี่GameObjectsไม่มีอะไรใหญ่จริงๆ ผู้จัดการเล็ก ๆ น้อย ๆ ที่น่ารัก

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

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

ณ จุดนั้นโดยปกติแล้วสิ่งGameManagerนี้จะเป็นระเบียบขนาดใหญ่ที่แท้จริง (เพื่อให้สุภาพ)

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

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

คุณอยากแนะนำอะไรให้ป้องกันไม่ให้สิ่งนี้เกิดขึ้น

แก้ไข

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

จากนั้นก็มีไฟเขียวและในความพยายามที่จะทำความสะอาดบางสิ่งบางคนเขียน GameManager อาจเป็นไปได้ที่จะจับ GameStates ไว้มากมายอาจจะเก็บ GameObjects ไว้สองสามอันไม่มีอะไรใหญ่โตจริงๆ ผู้จัดการเล็ก ๆ น้อย ๆ ที่น่ารัก

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

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

กฎง่ายๆเกี่ยวกับขนาดของคลาส: หากคุณใช้โค้ดหลายร้อยบรรทัดต่อคลาสสิ่งหนึ่งเริ่มที่จะผิดไป ไม่มีอะไรจะพูดมากกว่า 300 LOC เป็นรหัสกลิ่นสำหรับฉันและถ้าคุณไปมากกว่า 1,000 ระฆังเตือนควรจะดับ ด้วยการเชื่อว่ารหัส 1000 บรรทัดนั้นง่ายต่อการเข้าใจมากกว่า 4 คลาสที่มีโครงสร้างอย่างละ 250 คลาสคุณจะหลอกตัวเอง

เมื่อเวลากลายเป็นปัญหาไม่มีวิธีการเขียนชั้นแยกต่างหากหรือแยกผู้จัดการยักษ์รายนี้เป็นผู้จัดการย่อย

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

คุณอยากแนะนำอะไรให้ป้องกันไม่ให้สิ่งนี้เกิดขึ้น

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

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

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

แก้ไข - ข้อมูลเพิ่มเติมอีกเล็กน้อย:

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

โดยเฉพาะสำหรับการพัฒนาเกม แต่คำตอบที่ได้รับการยอมรับสำหรับคำถามนี้เกี่ยวกับ StackOverflow เกี่ยวกับเคล็ดลับ "โดยเฉพาะอย่างยิ่งสถาปัตยกรรมเกม" กล่าวว่า:

ปฏิบัติตามหลักการของการออกแบบเชิงวัตถุ ....

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

• แก้ไขสิ่งต่าง ๆ ในวันเดียวกันกับที่คุณใช้รหัส
• คุณจะดีใจที่คุณทำภายในไม่กี่ชั่วโมง

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

ในการตอบตัวอย่างเฉพาะของคุณ:

Clean Codeของลุงบ็อบทำหน้าที่ได้อย่างยอดเยี่ยมในการสรุปว่ารหัสคุณภาพดีเป็นอย่างไร ฉันบังเอิญเห็นด้วยกับเนื้อหาเกือบทั้งหมด ดังนั้นเมื่อฉันคิดถึงตัวอย่างของคลาสผู้จัดการ 30,000 LOC ของคุณฉันไม่เห็นด้วยกับส่วน "เหตุผลที่ดี" จริงๆ ฉันไม่ต้องการที่จะฟังดูน่ารังเกียจ แต่การคิดแบบนั้นจะนำไปสู่ปัญหา ไม่มีเหตุผลที่ดีสำหรับการมีรหัสมากในไฟล์เดียว - มันเป็นข้อความเกือบ 1,000 หน้า! ผลประโยชน์ใด ๆ ของท้องถิ่น (ความเร็วในการเรียกใช้งานหรือการออกแบบ "ความเรียบง่าย") จะถูกยกเลิกทันทีโดยนักพัฒนาที่ถูกจมลงอย่างสมบูรณ์พยายามที่จะควบคุมความผิดพลาดนั้นและนั่นคือก่อนที่เราจะพูดถึงการผสาน

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

นี่ไม่ใช่ปัญหาของการเขียนโปรแกรมเกม แต่โดยทั่วไปแล้วการเขียนโปรแกรม

รหัสแหล่งที่มาทั้งหมดเป็นจริงที่นี่เพื่อจัดการเกม

นี่คือเหตุผลที่คุณควรขมวดคิ้วที่ Object Oriented coder ที่จะแนะนำคลาสที่มี "Manager" ในชื่อ เพื่อความยุติธรรมฉันคิดว่าเป็นไปไม่ได้ที่จะหลีกเลี่ยงวัตถุ "semigod" ในเกม แต่เราเรียกพวกเขาว่า "ระบบ"

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

แม้ว่าจะชัดเจนหากคุณถูกล่อลวงให้นำสิ่งต่าง ๆ เข้ามาใน GameManager นั่นหมายความว่าคุณไม่มีฐานรหัสที่ดีมาก อาจมีสองปัญหา:

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

• รหัสของคุณมีโครงสร้างไม่ดี คุณ (ab) ใช้ตัวแปร globals คลาสไม่ได้เชื่อมกันอย่างหลวม ๆ ไม่มีอินเทอร์เฟซใด ๆ ไม่มีระบบเหตุการณ์และอื่น ๆ

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

ในที่สุดก็อาจเป็นปัญหาการจัดการทีม: มีเวลาเพียงพอหรือไม่ ทุกคนรู้เกี่ยวกับสถาปัตยกรรมที่คุณต้องการหรือไม่ ใครอนุญาตให้มีการเรียนกับคำว่า "ผู้จัดการ" ในชั้นเรียน

ดังนั้นการนำเสนอวิธีแก้ปัญหาที่เป็นไปได้จากโลกขององค์กร -y: คุณเคยลองดูการกลับกันของการควบคุม / การพึ่งพาหรือไม่?

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

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

โอ้ฉันเห็นชั้น PlayerSprite ของคุณใช้ IUpdateable ดีมากเพราะเฟรมเวิร์กสมัครสมาชิกวัตถุ IUpdateable ทุกรายการโดยอัตโนมัติซึ่งเป็นที่ที่เกมหลักวนซ้ำ ทุกตัวจับเวลา :: ติ๊ก () จะเรียกใช้เมธอด IUpdatedable :: update () ทั้งหมดโดยอัตโนมัติ ง่ายใช่มั้ย

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

ในอดีตฉันมักจะจบด้วยคลาสเทพเจ้าถ้าฉันทำต่อไปนี้:

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

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

ฉันรู้ว่าคำถามนี้เก่าแล้ว แต่ฉันคิดว่าฉันจะเพิ่ม 2 เซ็นต์ของฉัน

เมื่อออกแบบเกมฉันมักจะมีวัตถุเป็นเกม อย่างไรก็ตามมันอยู่ในระดับสูงมากและไม่ได้ "ทำอะไร" เอง

ตัวอย่างเช่นมันบอกคลาส Graphics ให้แก่ Render แต่ไม่มีส่วนเกี่ยวข้องกับกระบวนการเรนเดอร์ อาจขอให้ LevelManager โหลดระดับใหม่ แต่ไม่มีส่วนเกี่ยวข้องกับกระบวนการโหลด

ในระยะสั้นฉันใช้วัตถุกึ่งเทพเจ้าเพื่อจัดการการใช้คลาสอื่น