มันควรค่าแก่การวางแผนก่อนที่จะกระโดดลงไปในโค้ด?

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

แก้ไข: ฉันทำงานคนเดียวในโครงการนี้

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

คุณพูดถึงสองสิ่งที่ฉลาดในคำถามของคุณ:

1. "รหัสแทนที่จะคิด" - มีปรัชญาทั้งหมดที่อธิบายสิ่งนี้: http://gettingreal.37signals.com/toc.php
2. "หลักฐานของแนวคิดเพื่อตรวจสอบว่าสามารถทำได้" - ฉันเคยเห็นและมีแนวคิดมากมายที่กลายเป็นไปไม่ได้หรือยากมากที่จะทำเมื่อพวกเขาใกล้จะเสร็จ บางครั้งคุณก็ไม่สามารถทำนายได้เพราะมันเป็นสภาพแวดล้อมการเขียนโปรแกรมของคุณ (ภาษา, ไลบรารี, ประสิทธิภาพของฮาร์ดแวร์) ที่ จำกัด คุณ

นั่นเป็นเหตุผลที่ฉันพูดว่า:

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

ใช่ แต่เพียงเล็กน้อย

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

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

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

บางคนบอกว่าคุณควรเขียนโค้ดแทนที่จะคิด? ในการเขียนโค้ดคุณต้องรู้ว่าคุณต้องการสร้างอะไรรู้ว่าคุณต้องการสร้างอะไรก่อนอื่นคุณต้องคิดว่าคุณต้องการอะไรก่อนอื่นคุณต้องคิดก่อนที่จะเขียนโค้ด;)

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

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

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

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

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

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

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

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

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