ด้วยเวลาที่แทบจะไม่พอที่จะทำให้เกมที่เราสร้างเสร็จสมบูรณ์คุณจะสร้างสมดุลที่ดีระหว่างสถาปัตยกรรมซอฟต์แวร์ที่แข็งแกร่งกับความก้าวหน้าที่ดีในการทำให้เสร็จสมบูรณ์ได้อย่างไร
ความท้าทายส่วนบุคคลของฉัน: แล้วการมีประสิทธิภาพในวันนี้และการคิดระยะยาวในเวลาเดียวกันล่ะ? นอกจากนี้ในขณะที่คุณกำลังทำคุณอาจต้องการเรียนรู้สิ่งใหม่ ๆ ระหว่างทางแทนที่จะหันไปใช้รูปแบบซ้ำ ๆ เดิม ๆ ที่คุณใช้ในช่วง 5 ปีที่ผ่านมาใช่ไหม
คำตอบ:
ยิ่งคุณมีประสบการณ์น้อยลงเท่าไหร่คุณก็ยิ่งเสียเวลามากขึ้นด้วยการออกแบบล่วงหน้า การออกแบบที่ดีนั้นเป็นสิ่งที่คุณจะได้เรียนรู้ด้วยการทำแล้วเห็น / ประเมินว่ามันเป็นอย่างไร การตัดสินใจบางอย่างมีความหมายไกล แต่ไม่ชัดเจน หลังจากเกมบางเกมคุณอาจจะสามารถทำให้การออกแบบเริ่มต้นค่อนข้างมั่นคงและมันจะจ่ายเงินเพื่อลงทุนเวลานี้
คำขวัญของฉัน: ทำสิ่งต่าง ๆ ให้สำเร็จตั้งแต่แรก แต่ใช้สามัญสำนึกในการตรวจสอบว่าองค์ประกอบใดมีความสำคัญยิ่งกว่าสิ่งอื่นและออกแบบสิ่งเหล่านั้นให้ดีภายในเวลาที่กำหนด ตัวอย่างเช่นหาก AI สำคัญต่อเกมของคุณตรวจสอบให้แน่ใจว่าคุณสามารถขยาย / เปลี่ยนแปลงได้อย่างง่ายดายในภายหลัง หรือถ้าคุณกำลังจะเขียนส่วนประกอบที่คุณจะใช้ในทุกเกมให้ออกแบบเพื่อนำมาใช้ใหม่ ติดตามเวลาของคุณและอย่าไปยุ่งกับการออกแบบ กำหนดเส้นตายการออกแบบและหลังจากนั้นเริ่มต้นแฮ็คทุกอย่างเพื่อรับกำหนดส่งของคุณ แต่ให้แน่ใจว่าคุณจดบันทึกจุดที่ต้องปรับเปลี่ยน / ออกแบบใหม่ในภายหลังและคำนวณในบางช่วงเวลาก่อนที่คุณจะเริ่มเกมถัดไปเพื่อปรับปรุงสิ่งเหล่านั้นเพื่อที่ว่าพวกเขาจะไม่กัดคุณกลับมา!
คำแนะนำที่ดี: ถ้าคุณต้องเลือกระหว่างสองตัวเลือกอย่าอวดอ้างรายละเอียดนานเกินไป บ่อยครั้งที่ไม่มี "ดี" หรือ "ไม่ดี" ในบางสถานการณ์ A จะดีกว่าในบาง B จะและโดยรวมความแตกต่างระหว่างทั้งสองอาจไม่คุ้มค่ากับเวลาเสมอไป
มีประสบการณ์มากมายในการออกแบบซอฟต์แวร์หรือเกมดังนั้นให้แน่ใจว่าคุณใช้เวลาในการค้นคว้า (เช่นการอ่านหนังสือเกี่ยวกับการออกแบบการอ่านเกี่ยวกับประสบการณ์ของผู้อื่นการพูดคุยกับเพื่อนโปรแกรมเมอร์เกี่ยวกับการออกแบบ ฯลฯ ) )
ผู้คนกำลังทำนายอนาคตไม่ดี นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งสำหรับเกมที่ความต้องการสามารถเปลี่ยนแปลงได้ในแต่ละวัน
มีหลักการที่เรียกว่าYAGNIหรือที่เรียกว่า"คุณไม่ต้องการมัน" ซึ่งโดยทั่วไปบอกว่าคุณไม่ควรใช้อะไรจนกว่าคุณจะรู้ว่าคุณต้องการมัน
ฉันได้เห็นระบบจำนวนมากจมอยู่กับความแข็งแกร่งทางสถาปัตยกรรมที่ไม่ได้ใช้งานจริง ๆ ตั้งแต่คุณสมบัติที่ผู้คนคิดว่าพวกเขาจะต้องไม่เคยถูกใช้งาน
ปรัชญาส่วนตัวของฉันคือทำสิ่งที่ง่ายที่สุดที่อาจเป็นไปได้ ที่ถูกกล่าวว่ามีความแตกต่างระหว่างการทำมันและแฮ็คอึด้วยกัน การเขียนโค้ดโดยมีวัตถุประสงค์ไม่ควรบ่งบอกถึงการทำสิ่งต่าง ๆ ที่ทำให้เกิด "รหัสกลิ่น" เช่นการทำให้ทุกอย่างเป็นสาธารณะการมีคลาสหยดที่ทำทุกอย่างหรือสิ่งอื่น ๆ
สิ่งนี้ประเมินว่าเป็นจริงในความคิดของฉันในวันนี้:
ฉันเป็นเพื่อนกับการสร้างต้นแบบอย่างรวดเร็วของซอฟต์แวร์ โดยเฉพาะในช่วงพัฒนาเกม เหมาะสำหรับการเรียนรู้ทดสอบและใช้งานอย่างรวดเร็ว สำหรับการเขียนโปรแกรมฮาร์ดแวร์หรืออัลกอริทึมที่ซับซ้อนเป็นวิธีที่ดีที่สุดสำหรับฉัน
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();Rapid Prototype รุ่นของฉันต้องมีเปลือกต้นแบบที่เหมาะสม:
ข้อดี:
ถ้าคุณทำได้ดีคุณสามารถแก้ไขข้อบกพร่อง / เรียนรู้เวอร์ชันของผลิตภัณฑ์ของคุณได้ในตอนท้าย
เราใช้มันในโครงการของเราและเรามีความสุขกับมัน
มีลักษณะที่พัฒนาซอฟต์แวร์เปรียว แม้ว่ามันจะไม่ใช่ bullet Silver แต่มันก็มีจุดมุ่งหมายที่จะทำทั้งสองอย่าง (ทำให้เสร็จและมีการออกแบบซอฟต์แวร์ที่แข็งแกร่ง)