การวางแผนเกมและการออกแบบซอฟต์แวร์? ฉันรู้สึกว่า UML ไม่สะดวก

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

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

คำถามอื่นคือ "การสร้างต้นแบบ" ตามปกติเป็นอย่างไร

ฉันแค่ต้องการคำแนะนำจากผู้เชี่ยวชาญเกี่ยวกับวิธีที่ฉันจะเริ่มออกแบบเกมของฉันได้อย่างไร

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

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

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

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

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

ดูเหมือนว่าคุณกำลังมีปัญหา 2 ข้อที่นี่การออกแบบเกมและการออกแบบรหัส

ฉันขอแนะนำให้เขียนการออกแบบเกมขั้นพื้นฐานก่อนระบุคุณสมบัติที่คุณต้องการกราฟิกและเสียงที่คุณต้องการวิธีที่เกมชนะและแพ้ ฯลฯ ค้นหา 'เอกสารการออกแบบ' หากคุณต้องการความช่วยเหลือ

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

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

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

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

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

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

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

ฉันยังทำงานเกี่ยวกับโปรเจคเกมอิสระบางอย่างกับเพื่อน (ทีม 2 คน) ในฐานะที่เป็นคนที่คล้ายกับคุณฉันสามารถเสนอเกร็ดเล็กเกร็ดน้อยที่ฉันคิดว่ามีประโยชน์

1. หากความคิดของคุณหยาบลองนำไปใช้ในโครงการต้นแบบเล็ก ๆ ตัวอย่างเช่นตอนนี้ฉันกำลังสร้างเกมแพลตฟอร์ม 2D และการกระโดดของผู้เล่นเป็นสิ่งสำคัญสำหรับฉัน ดังนั้นฉันจึงสร้างโครงการใหม่ที่มีเพียง 2 สิ่งเท่านั้นที่เกิดขึ้นคือ a) การวาดผู้เล่นบนหน้าจอและ b) การตรวจจับอินพุตและวาดการกระโดดใหม่ [ตัวละครไม่สามารถขยับไปทางซ้ายหรือขวาได้]
2. บางคนอาจขมวดคิ้วกับคำแนะนำนี้ แต่ให้คิดถึงการเขียนคู่มือเกมก่อน (เพื่ออธิบายแนวคิดการควบคุมวัตถุประสงค์) สิ่งนี้สามารถทำ 2 สิ่งให้คุณ - สร้างเอกสารที่จำเป็นมาก แต่ยังร่างระบบย่อยของเกมและรายละเอียดที่จำเป็นสำหรับผู้เล่น หากคุณรู้ล่วงหน้าสิ่งที่ผู้เล่นจำเป็นต้องรู้คุณต้องรู้ล่วงหน้าว่าคุณต้องทำอะไร
3. เขียนโค้ดในพอขนาดเล็ก (aka modularized ) ชิ้นว่าชิ้นเอาเรื่องสามารถเคลื่อนย้ายได้อย่างใดอย่างหนึ่งรอบหรือการจัดระเบียบโดยไม่รู้สึกเหมือนคุณกำลังพยายามที่จะลบทั้งหมดของชิ้นขนาดกลางของปาเก็ตตี้จากจานพาสต้าที่ดีกว่า

หวังว่าคุณจะพบข้อมูลที่เป็นประโยชน์อย่างน้อยหนึ่งชิ้นในนั้นและขอให้โชคดี!

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

UML คือ"วิธีมาตรฐานในการมองเห็นสถาปัตยกรรมของระบบ"

UML อธิบาย

• กิจกรรม
• นักแสดง
• กระบวนการทางธุรกิจ
• สกีมาฐานข้อมูล
• ส่วนประกอบ (ตรรกะ)
• ข้อความภาษาโปรแกรม
• ส่วนประกอบซอฟต์แวร์ที่นำมาใช้ซ้ำได้

แต่ถ้าคุณทำเกมง่ายๆคุณจำเป็นต้องสร้างแบบจำลองทั้งหมดนี้หรือไม่?

• นักแสดง: ผู้เล่น

มันช่วยได้เท่าไหร่?

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

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

UML ไม่ใช่สิ่งหนึ่งมันเป็นชุดของสิ่งที่บางคนมีค่าอื่น ๆ ไม่มาก สไตล์ที่เก่ากว่าใช้เคส (อย่างน้อยสิ่งที่เราเรียกใช้เคส) สถานะนั้น

• ชื่อ
• ความต้องการ
• ปัจจัยพื้นฐาน
• ทริกเกอร์
• การปฏิบัติ
• การกระทำอื่น
• ข้อยกเว้น

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

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

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

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

พวกเขาจะสอนคุณเกี่ยวกับ UML ที่มหาวิทยาลัยของคุณเพื่อช่วยให้คุณสื่อสารความคิดของคุณกับทีมอื่น ๆ และแสดงอาจารย์ที่คุณมีความรู้เกี่ยวกับหลักการวิศวกรรมซอฟต์แวร์พื้นฐานที่ดี

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

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

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