ฉันควรใช้รหัสฮาร์โค้ดเมื่อใดกับโหลดข้อมูลภายนอก


36

ฉันเขียนโค้ดหนึ่งพันหรือมากกว่านั้นเพื่อสร้างเกมตามพื้นที่ 2D ของฉันซึ่งสร้างเครือข่ายของระบบดาวที่สร้างขึ้นแบบสุ่มและเติมพวกมันด้วยการสุ่มเลือกดาวเคราะห์สถานีเรือและอาวุธ

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

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

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


10
คำที่คุณกำลังค้นหาคือ "Data Driven" และใช่มันเร็วกว่ามากในระยะยาวเพื่อสร้างสถานีและเรือใหม่ด้วยไฟล์ XML (หรือรูปแบบใด ๆ เช่น JSON จริง ๆ ) มากกว่าสิ่งที่คุณทำในโครงการขนาดเล็ก . นอกจากนี้ในภายหลังคุณสามารถลบและแก้ไขโดยไม่ต้องสัมผัสรหัสและคอมไพล์อีกครั้งเพื่อการประหยัดครั้งที่สอง
Patrick Hughes

@PatrickHughes ในขณะที่พิมพ์คำตอบของฉันคุณได้ใส่ไว้ในความคิดเห็นแล้ว!
MartinTeeVarga

1
หากเรากำลังพยายามทำให้ถูกต้องตามกฎหมาย "การเข้ารหัสแบบอ่อน" เป็นคำศัพท์จริงฉันขอเสนอการเข้ารหัสแบบ บริษัท ว่า "โดยใช้การป้อนรหัสแบบฮาร์โค้ดลงในเมทริกซ์ข้อมูลแบบอ่อนแบบรหัส"
Sean Middleditch

1
@ Singular1ty เว็บไซต์นี้ให้อภัยการสนทนามากกว่า SEs อื่น ๆ ฉันคิดว่าคำถามของคุณมีคุณสมบัติเหมาะสมสำหรับสถานะ "การสนทนาที่ดี"
เซทแบททิน

2
@ Singular1ty อ่านี่ไง ไม่พบเมื่อฉันโพสต์ความคิดเห็นแรกของฉัน blog.stackoverflow.com/2010/09/good-subjective-bad-subjective
Seth Battin

คำตอบ:


62

ใช่. คุณควรใช้ระบบเพื่อโหลดเนื้อหานอกเอ็นจิ้นหลักของคุณ

ส่วนหัวสำหรับคำตอบสั้น ๆ

ไม่มันไม่กินเวลามากเกินไป

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

คุณจะใช้เวลาหลายร้อย (หลายพัน) ชั่วโมงในโครงการเกมที่คุณทำจนเสร็จ บางทีอาจจะไม่ใช่เกมโคลนนิ่ง แต่แน่นอนว่าเป็นเกมอวกาศที่ซับซ้อนของคุณ เปรียบเทียบกับตัวอ่านไฟล์ปรับแต่ง การใช้ระบบเพื่อไพพ์ XML ลงในตัวสร้างหลักของคุณและจากนั้นเริ่มระบบของเกมใหม่อาจใช้เวลา10 หรือ 20 ชั่วโมง แม้ว่าจะใช้เวลาคุณ 50 หรือ 100 มันจะเป็นเพียงส่วนเล็ก ๆ ของเวลาโครงการทั้งหมด

มันจะประหยัดเวลา

มันไม่เสียเวลา มันเป็นการลงทุนครั้ง และมันจะจ่ายออก

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

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

ทีมหนึ่งสมาชิกได้รับประโยชน์มากที่สุด

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

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

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


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

เซทยินดีต้อนรับสู่ระดับสิทธิ์ใหม่ของคุณ ใช้คะแนนปิดของคุณและเปิดใหม่ได้ดี!
MichaelHouse

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

10

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

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

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

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

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

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

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

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

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


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

@ Singular1ty ในกรณีนี้ให้หยุดสิ่งที่คุณทำอยู่ตอนนี้ ถึงเวลาที่จะสร้างใหม่อย่างบ้าคลั่ง ลืมเนื้อหาใหม่ใด ๆ และมุ่งเน้นที่การปรับปรุงโครงสร้างโดยรวมที่มีอยู่ ฉันทำงานใน บริษัท เกมและฉันมักจะผลักดันให้มีช่วงเวลาของการมีชีวิตที่มีชีวิตชีวาและ refactoring แต่แน่นอนว่ามันอยู่ในหูของคนหูหนวกและเรามักจะจบลงอย่างกระทันหันอย่างบ้าคลั่งลุยผ่านบั๊ก / แฮ็คที่รบกวน Ho hum
DaleyPaley

8

สิ่งที่คุณกำลังพูดถึงคือการเขียนโปรแกรมที่ขับเคลื่อนด้วยข้อมูล

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

อย่างไรก็ตามการเขียนโปรแกรมขับเคลื่อนข้อมูลสามารถใช้งานได้ง่ายมาก หากคุณจริงจังกับเรื่องนี้คุณควรใช้ XML, JSON หรือ YAML แต่คุณสามารถใช้ไฟล์ข้อความธรรมดาได้

การเขียนโปรแกรมที่ขับเคลื่อนด้วยข้อมูล

ข้อดี

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

จุดด้อย

  1. ต้องใช้เวลาและความพยายามในการดำเนินการ
  2. มันอาจเพิ่มความซับซ้อนของโปรแกรม

นี่เป็นเพียงข้อดีและข้อเสียบางประการที่ฉันสามารถนึกได้ในตอนนี้ แจ้งให้เราทราบหากคุณคิดถึงมากขึ้น!
Nick Caplinger

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