มันเป็นความคิดที่ดีที่จะมี Game1 แบบคงที่ใน XNA หรือไม่?

เป็นความคิดที่ดีจริงๆหรือที่จะให้Game1ชั้นเรียนของฉันคงที่? ในขณะที่ในGame1ชั้นเรียนของฉันฉันมีชั้นเรียนที่เรียกว่าTileHandlerซึ่งจัดการทุกอย่างที่จะทำกับชุดกระเบื้องปัจจุบันของฉันและAnimalHandlerที่จัดการสัตว์ทั้งหมดของฉัน (น่าแปลกใจ)

ตอนนี้ถ้าฉันอยู่ในAnimalHandlerและต้องการตรวจสอบว่ากระเบื้องนั้นสามารถเดินได้จากTileHandlerนั้นเป็นปัญหาหรือฉันต้องส่งรายการของกระเบื้องที่เดินได้AnimalHandlerซึ่งฉันไม่อยากทำ

อะไรจะง่ายขึ้นจะทำให้Game1คงที่และแล้วก็ไปAnimalHandlerGame1._tileHandler.WalkableTile(position)

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

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

เมื่อคุณมีค้อนใหม่ที่เงางามทุกปัญหาดูเหมือนกับเล็บ

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

นี่คือปมปัญหาของคุณ:

... ถ้าฉันอยู่ในAnimalHandlerและต้องการตรวจสอบว่าแผ่นกระเบื้องนั้นสามารถเดินได้จาก TileHandlerนั้นเป็นปัญหาหรือฉันต้องส่งรายการแผ่นกระเบื้องที่สามารถเดินได้AnimalHandlerซึ่งฉันไม่อยากทำ

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

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

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

หากคุณเลือกที่จะมี TileHandler มากกว่าหนึ่งคนในอนาคตคุณจะต้องทำงานมากมายเพื่อรองรับการเปลี่ยนแปลงนี้

หากคุณเลือกที่จะลบ TileHandler คุณจะต้องทำงานมากมายเพื่อรองรับการเปลี่ยนแปลงนี้

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

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

โดยส่วนตัวแล้วฉันเข้าถึงหลาย ๆ อย่างในเกม XNA ของฉันจากบริบทแบบสแตติกและคิดว่าฉันจะไม่มีมากกว่าหนึ่งในนั้น

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

ในระยะสั้น:

เพื่อไม่ให้ใช้บริบทแบบคงที่:

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

ในความโปรดปรานของบริบทคงที่:

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

ฉันไม่คิดว่ามันเป็นความคิดที่แย่มากสำหรับเกมง่ายๆ แต่คุณสามารถดูได้ที่ http://www.nuclex.org/articles/4-architecture/6-game-components-and-game-services สำหรับ ความคิดที่ดีขึ้นเกี่ยวกับวิธีการสร้างส่วนประกอบของเกม

สิ่งต่าง ๆ เช่น TileHandler และ AnimalHandler ฉันต้องการเพิ่มระดับให้สูงขึ้นในหน้าจอเกม หน้าจอชื่อเรื่องของคุณต้องเข้าถึง TileHandler และมันเริ่มต้นได้เมื่อโหลดเกมครั้งแรกหรือไม่ อาจจะไม่.

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

ในเกมพื้นฐานฉันใช้สแตติกสองสามตัว แต่พวกมันอยู่ในระดับต่ำมากเช่น InputHelper, Log หรือ Config reader พวกมันค่อนข้างมาตรฐานในทุกเกมดังนั้นเครื่องยนต์พื้นฐานสามารถทำการพอร์ตได้อย่างรวดเร็วและง่ายดาย หน้าจอเป็นที่ที่ตรรกะของเกมเกิดขึ้นจริง นานคำตอบสั้น ๆ - ไม่ฉันไม่คิดว่ามันเป็นความคิดที่ไม่ดีในทางทฤษฎีเพียงระวังสิ่งที่คุณทำคงที่ เมื่อคุณก้าวไปข้างหน้าและทำอะไรบางอย่างให้นิ่งมันเป็นจำนวนมหาศาลของงานถ้าคุณเปลี่ยนใจ

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

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

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

ใช่มันเป็นความคิดที่ไม่ดีเสมอ

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

1. มันส่งเสริมการพึ่งพาอาศัยแบบส่งเดชที่ทำลาย modularity และได้รับในทางของการใช้รหัส สมมติว่าคุณต้องการเขียนโปรแกรมแก้ไขสำหรับเกมของคุณ - คุณจะมีชั้นเรียนจำนวนมากกำลังร้องไห้อยู่ในขณะGame1ที่คุณไม่สามารถย้ายเข้าไปในไลบรารีที่แชร์ได้อย่างง่ายดาย

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

3. มันซ่อนการพึ่งพา เช่นเดียวกับรูปแบบการต่อต้านของผู้ให้บริการ (เช่น XNA, Game.Services), ชั้นเรียนของคุณสามารถเลือกการพึ่งพาที่คุณไม่เห็นจากภายนอก

วิธีการนี้จะกลายเป็นโดยเฉพาะอย่างยิ่งที่เป็นพิษหากรวมการเรียนแบบคงที่กับสายรถไฟบรรทุกสินค้า (thingsl Ike Game.Instance.ActorManager.Enemies.FindInRange(10)- เรียกเช่นนี้เพราะของรถไฟรถเหมือนสัญลักษณ์ที่ถูกล่ามโซ่) ซึ่งส่วนประกอบจู่ ๆ ไม่เพียง แต่ต้องมีGameระดับ แต่อย่างหนึ่งที่มีความคงที่Instanceทรัพย์สินที่ผลตอบแทนอะไรกับActorManagerทรัพย์สินที่มีEnemiesคุณสมบัติที่ส่งกลับวัตถุที่มีFindInRange()วิธีการ

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