เหตุใด MVC & TDD จึงไม่ได้ใช้งานสถาปัตยกรรมเกมมากขึ้น? [ปิด]


155

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

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

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

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

ความผิดพลาด # 4: การสร้างระบบไม่ใช่เกม

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

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

... รับของบนหน้าจอให้เร็วที่สุดเท่าที่จะทำได้

และไม่เคยใช้อาร์กิวเมนต์ "ถ้าเราใช้เวลาเพิ่มเติมและทำสิ่งนี้ในวิธีที่ถูกต้องเราสามารถนำมันกลับมาใช้ใหม่ได้ในเกม" EVER

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

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

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

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

คำตอบ:


137

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

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

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

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

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

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

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

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

และเฮ้ทำในสิ่งที่คุณคิดว่าจะได้ผล คุณสามารถเปลี่ยนมันได้หรือทำให้เป็นเศษซากและเริ่มต้นใหม่ นั่นคือสิ่งที่ยอดเยี่ยมเกี่ยวกับวิศวกรรมทุกรูปแบบ ถ้าในตอนแรกคุณไม่ประสบความสำเร็จลองทำสิ่งที่แตกต่าง (หรืออะไรทำนองนั้น :-P) คุณไม่ได้เทคอนกรีต ซอฟต์แวร์มีความอ่อนไหว


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


32

นี่คือคำตอบดั้งเดิมของฉันสำหรับคำถามที่คล้ายกันเกี่ยวกับ SO จากหลังในขณะที่อย่างน้อยเกี่ยวกับส่วน MVC ของคำถามของคุณ:

มันไม่ค่อยได้ใช้ในเกม ฉันใช้เวลาซักพักแล้วหาสาเหตุ แต่นี่คือความคิดของฉัน:

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

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

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

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

เกมมีแนวโน้มที่จะแยกแยะสิ่งต่าง ๆ ตามขอบเขตของโดเมน: AI, ฟิสิกส์, เสียง, การเรนเดอร์และอื่น ๆ จะถูกแยกออกจากกันมากที่สุด


20

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

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

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

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

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


13

เหตุใด MVC & TDD จึงไม่ได้ใช้งานสถาปัตยกรรมเกมมากขึ้น?

คำเตือน: ความเห็นล่วงหน้า

MVC ไม่ได้ใช้ (มาก) เพราะ:

  1. MVC เป็นวิธีการที่ค่อนข้างใหม่และเกมมักจะสร้างด้วยรหัสเดิม คนส่วนใหญ่ที่สร้างแอป MVC กำลังสร้างสิ่งเหล่านี้จากทุกครั้ง (ฉันรู้ว่า MVC เป็นของจริงมานานหลายทศวรรษแล้ว) สิ่งใหม่ ๆ คือความสนใจอย่างกว้างขวางซึ่งมาจากเว็บแอปเช่น RoR) ในซอฟต์แวร์ธุรกิจที่ฉันทำงานนั้นขึ้นอยู่กับรหัสดั้งเดิมไม่มีประโยชน์สำหรับ MVC เช่นกัน มันเป็นวัฒนธรรม แต่ไม่ใช่เกมเฉพาะ
  2. MVC นั้นเป็นรูปแบบ GUI สำหรับโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์ เกมไม่ได้เป็นแบบ GUI หรือควบคุมเหตุการณ์ดังนั้นการบังคับใช้จึงไม่ดีเท่าสำหรับเว็บแอปหรือแอพพลิเคชั่นอื่น ๆ โดยทั่วไปแล้ว MVC เป็นรูปแบบของนักสังเกตการณ์ที่มีบทบาทที่รู้จักกันดีและเกมมักไม่มีความหรูหราในการรอคอยที่จะสังเกตเห็นสิ่งที่น่าสนใจ - พวกเขาต้องอัพเดททุกอย่างทุกเฟรม (หรือการเปลี่ยนแปลงบางอย่างในนั้น) .

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

TDD ไม่ได้ใช้ (มาก) เพราะ:

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

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

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


9

ดังที่ Kylotan ตั้งข้อสังเกตว่า "ในเกมคุณไม่สามารถนำเสนอมุมมองการนำเสนอในรูปแบบแนวคิดที่ถอดออกได้และถอดเปลี่ยนได้เช่น HTML และ CSS สำหรับเว็บแอป" การสร้างเกมสองสามเกมโดยใช้รูปแบบ MVC แบบง่าย ๆ (ไม่ใช่กรอบขนาดใหญ่) ฉันพบว่าปัญหาสำคัญคือโมเดลของคุณจำเป็นต้องรู้เกี่ยวกับมุมมองของคุณ มีความเป็นไปได้สูงมากที่คุณจะต้องใช้ข้อมูล sprite bitmap, hitbox data หรือข้อมูลเรขาคณิต 3 มิติจากเนื้อหาศิลปะของคุณเพื่อช่วยในการตรวจจับการชนกันของข้อมูล (หรืองานอื่นที่คล้ายกัน) ซึ่งหมายความว่าแต่ละรุ่นต้องการการอ้างอิงถึงมุมมองของมันซึ่งแบ่งรูปแบบ MVC แบบคลาสสิก - ตัวอย่างเช่นคุณไม่สามารถสร้างมุมมองใหม่ไปยังโมเดลที่มีอยู่แล้วได้อีกต่อไป

โมเดลส่วนประกอบที่คุณเห็นเช่น Unity3D เป็นวิธีที่ดีที่สุดในการจัดระเบียบรหัสเกม


4

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

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


3

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

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

ตามปกติเมื่อคุณเล่นเกมเสร็จคุณมีแนวคิดอย่างน้อย 1,000 ข้อเกี่ยวกับวิธีการปรับปรุงกลไกพื้นฐานระบบหลัก ฯลฯ ในลักษณะที่รหัส "ใช้งานได้" น้อยมากจะ ใช้งานได้จริง ในแต่ละวันฉันทำงานเป็นประจำทาง SE และในขณะที่ระบบที่เราใช้อาจมีขนาดใหญ่ แต่จริงๆแล้วฉันคิดว่าพวกเขาหน้าซีดเมื่อเปรียบเทียบกับความซับซ้อนในเกม


2

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

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.