โครงการรีเวิร์สวิศวกรรม ROM ของ Duke Nukem: Zero Hour บน N64 บรรลุ 100%

 (github.com/Gillou68310)
1 คะแนน โดย GN⁺ 2025-10-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Duke Nukem: Zero Hour เป็นโครงการโอเพนซอร์สที่ดีคอมไพล์ ROM สำหรับ Nintendo 64 ได้อย่างสมบูรณ์
  • โปรเจกต์นี้ได้ ฟื้นฟูซอร์สโค้ดทั้งหมดของซอฟต์แวร์เกมต้นฉบับ ให้ครบ 100%
  • ผู้ใช้ต้องเป็นเจ้าของ ROM ของเกมเอง และสามารถคอมไพล์และทดสอบได้เต็มรูปแบบผ่าน ROM ต้นฉบับเวอร์ชันสหรัฐฯ หรือฝรั่งเศส
  • เมื่อเทียบกับโครงการดีคอมไพล์ที่มีมาก่อนหน้าแล้ว โครงการนี้มีจุดเด่นทางเทคนิคด้วย ความเข้ากันได้การทำงานที่สมบูรณ์และการรองรับเครื่องมือดีบัก
  • โครงการนี้เป็นแหล่งข้อมูลที่มีคุณค่าอย่างมากสำหรับ การวิจัย การดัดแปลง การพอร์ต และการวิเคราะห์เอนจินเกม

ความสำคัญและความสามารถในการแข่งขัน

  • Duke Nukem: Zero Hour เป็นเกมแอ็กชันชื่อดังที่วางจำหน่ายแบบเฉพาะบนแพลตฟอร์ม Nintendo 64
  • โครงการโอเพนซอร์สนี้ได้ดีคอมไพล์ ROM ทั้งหมดของเกมดังกล่าว ด้วย C, Python และภาษาอื่น ๆ อย่างครบถ้วน แล้วนำไปสร้างโครงสร้างใหม่ระดับซอร์สโค้ด
  • แตกต่างจากโครงการดีคอมไพล์ของ N64 อื่น ๆ โครงการนี้ได้รับการรับรองความเข้ากันได้อย่างสมบูรณ์ โดยรองรับการสร้างและรัน ROM ปกติ การดีบักระดับซอร์สโค้ด รวมถึงรองรับหลายเวอร์ชัน
  • มีคุณค่าเชิงต้นแบบสูงในการศึกษาโครงสร้างเอนจินเกมและความรู้การพัฒนาเกมคอนโซลในยุค 1990
  • เครื่องมือวิเคราะห์/ดีคอมไพล์อัตโนมัติหลายตัว (เช่น asm-differ, mips2c, splat, decomp-permuter ฯลฯ) ถูกนำมาบูรณาการในโปรเจกต์เพื่อเพิ่มประสิทธิภาพนักพัฒนาให้สูงสุด

คุณสมบัติหลักและโครงสร้าง

โครงสร้างโดยรวม

  • โครงการนี้พัฒนาด้วยหลายภาษา โดยประกอบด้วยส่วนต่าง ๆ ที่เขียนด้วย C (มากกว่า 95%), Python, Roff, C++, Makefile และ Shell
  • ไดเรกทอรีหลัก:
    • .github/workflows: การตั้งค่า CI และการทำงานอัตโนมัติ
    • include, libs, src: การจัดการซอร์สโค้ดเกม ไลบรารี และไฟล์ Header
    • tools: เครื่องมือสำหรับวิเคราะห์ สกัด และแปลง
    • versions: โครงสร้างที่รองรับหลายเวอร์ชันของเกม เช่น US/FR
  • มีการ commit เกือบ 370 ครั้ง แสดงถึงการดูแลรักษาอย่างแข็งขัน

สรุปการ build และการใช้งาน

  • รองรับสภาพแวดล้อม Ubuntu 20.04 และ Docker
  • รองรับการสกัด ROM, การเปรียบเทียบระดับบิต และโหมด NON_MATCHING
  • รองรับ ROM เวอร์ชันฝรั่งเศสและเวอร์ชันสหรัฐฯ และอนุญาตให้กำหนดตัวเลือกตามความต้องการของผู้ใช้
  • ใช้สภาพแวดล้อม Docker และ Mutagen Extension เพื่อรองรับความเข้ากันได้ระหว่างระบบปฏิบัติการต่าง ๆ (WIN/Mac/Linux)

เครื่องมือดีบักและการพัฒนา

  • รองรับการดีบักระดับซอร์สโค้ดด้วย gdb และ mupen64plus (ปัจจุบันให้ความสำคัญกับ Windows เป็นหลัก)
  • รองรับการเชื่อมต่อกับ Visual Studio Code และ Native Debug Extension
  • เครื่องมืออัตโนมัติและวิเคราะห์หลัก:
    • asm-differ: เปรียบเทียบซอร์สและโค้ดเป้าหมายในระดับแอสเซมบลี
    • decomp-permuter: ปรับลำดับโค้ดและให้คะแนนอัตโนมัติ
    • mips2c: แปลงโค้ดจาก MIPS assembly เป็น C
    • splat: เครื่องมือวิเคราะห์โครงสร้าง ROM

การนำไปใช้

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

สรุป

  • โครงการโอเพนซอร์สนี้เป็นตัวอย่างที่หายากซึ่งทำให้การเปิดเผยซอร์สโค้ดเต็มรูปแบบของซอฟต์แวร์เกมคอนโซลคลาสสิกยุค 1990s เป็นจริง
  • เป็นทรัพยากรที่มีค่ามากสำหรับนักวิจัยด้านรีเวิร์สวิศวกรรมเกมและคอนโซล นักพัฒนารุ่นใหม่ ผู้พอร์ตเกม และผู้สร้างเกมแฟนๆ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-20
ความเห็นบน Hacker News
  • น่าสนใจตรงที่แม้จะถอดกลับเป็น C ได้ 100% แล้ว แต่หลายส่วนของชื่อฟังก์ชันและตัวแปรยังถูกสร้างขึ้นอัตโนมัติ ทำให้การติดป้ายชื่อยังไม่สมบูรณ์ ถ้ามีใครลองพอร์ตตอนนี้ก็น่าจะสนุกดี
    • สงสัยว่า LLM จะช่วยเรื่องการติดป้ายชื่อได้มีประสิทธิภาพแค่ไหน กลัวว่าจะเสียเวลาไปกับการตั้งชื่อผิดมากกว่า
    • ทุกวันนี้มีเครื่องมืออย่าง Ghidra ให้ใช้ฟรีอยู่แล้ว เลยรู้สึกว่า "ถอดกลับเป็น C ได้ 100%" อาจไม่ใช่เรื่องยิ่งใหญ่มากนัก
    • ซอร์สโค้ดของ Build engine เปิดเผยเพื่อการใช้งานที่ไม่ใช่เชิงพาณิชย์อยู่แล้ว เลยสงสัยว่าจะช่วยจับคู่ชื่อฟังก์ชันและตัวแปรได้หรือไม่
  • ดูเหมือนว่า Gillou68310 จะทำไปคนเดียวถึง 99% ถือว่าเป็นความทุ่มเทที่น่าทึ่งมาก The Legend of Zelda: Twilight Princess ก็เดินหน้าได้ดีเหมือนกัน https://decomp.dev/zeldaret/tp
    • ขอถือโอกาสนี้ส่งกำลังใจให้โปรเจ็กต์ถอดกลับ Castlevania: Symphony of the Night ด้วย กำลังไปได้สวยทีเดียว (แม้จะยังมีงานอีกมาก) https://github.com/Xeeynamo/sotn-decomp
  • Zero Hour เป็นหนึ่งในเกมที่ต้องเล่นของยุค N64 และเป็นหนึ่งในเกมดีไม่กี่เกมของช่วงท้ายซีรีส์ Duke Nukem แม้จะมีส่วนแพลตฟอร์มที่ท้าทายและบางด่านที่ชวนหัวเสียพอสมควร แต่ความพยายามในการสร้างฉากที่แข็งแรงสม่ำเสมอและถ่ายทอดเสน่ห์ของ Duke 3D ออกมานั้นน่าประทับใจ การพอร์ต Perfect Dark ช่วงหลังทำออกมาได้ยอดเยี่ยมมาก เลยหวังว่าโปรเจ็กต์ถอดกลับนี้จะได้รับการดูแลในคุณภาพใกล้เคียงกัน
  • สงสัยว่าทำไมถึงเลือก Duke Nukem: Zero Hour เป็นเป้าหมาย
    • Zero Hour เป็นเกมเพชรเม็ดงามที่คนลืมไปนิดหน่อย เกม Duke Nukem บน Playstation เป็นงานเลียนแบบ Tomb Raider ที่เสียงตอบรับไม่ค่อยดี แต่ Zero Hour ใช้พื้นฐานจาก Build engine แบบเดียวกับ Duke Nukem 3D ต้นฉบับ แม้จะยังไม่ถึงระดับนั้น แต่ก็อาจนับว่าเป็นเกม Duke Nukem ที่ดีที่สุดนอกเหนือจากงานของ 3D Realms ข้อเสียคือเปลี่ยนมุมมองเป็นบุคคลที่สาม (มีโหมดบุคคลที่หนึ่งที่ยังทำไม่เสร็จซ่อนอยู่ผ่านโค้ดโกง) และการควบคุมไม่ค่อยดี แต่ตอนนี้มีซอร์สโค้ดแล้ว ปัญหาเหล่านี้ก็น่าจะแก้ได้
    • เป็นคำถามที่ดี แต่อยากให้มีภาพหน้าจอ จะได้เอาไปแชร์ให้เพื่อนดู ตอนเล่นกับเพื่อนสมัยก่อนมันคือสวรรค์แห่งความโกลาหลจริง ๆ
  • สงสัยว่าทำไมคนคนหนึ่ง (หรือกลุ่มหนึ่ง) ถึงยอมทุ่มเวลาและแรงกายให้โปรเจ็กต์ถอดกลับแบบนี้ อยากรู้ว่าเป็นชมรมเกมเมอร์งานอดิเรกที่รักเกมนั้นมาก ๆ หรือมีเป้าหมายด้านการอนุรักษ์ดิจิทัล
    • ผมคือคนที่เคย reimplement Cosmo's Cosmic Adventure (DOS, 1992) เหตุผลก็ง่าย ๆ คืออยากรู้ว่าเกมนี้ใช้ลูกเล่นกราฟิกเจ๋ง ๆ บนฮาร์ดแวร์สเปกต่ำ (IBM AT) ได้อย่างไร ไม่ได้แปลว่าเกมนี้ยอดเยี่ยมเป็นพิเศษ แค่เป็นความทรงจำสำคัญในวัยเด็กของผม เลยผูกพันกับมัน ประสบการณ์นี้ทำให้ผมเข้าใจแพลตฟอร์ม PC, ระบบนิเวศ C ในยุค 80 และรสนิยมของตัวเองมากขึ้น https://github.com/smitelli/cosmore https://cosmodoc.org/
    • ผมใช้เวลาไปมากกับการรีเวิร์สเอนจิเนียร์เฟิร์มแวร์ของซินธิไซเซอร์วินเทจ (ซึ่งง่ายกว่าเกมสมัยใหม่) เช่น ผมเคยใส่คอมเมนต์ให้รอมของ Yamaha DX7 และ DX9 และกระบวนการนี้ช่วยขยายทักษะวิศวกรรมของผมอย่างมาก มันทั้งสนุกและทำให้ได้รู้จักคนฉลาดมาก ๆ ด้วย มันเหมือนการต่อจิ๊กซอว์ทางเทคนิค และยังมีเฟิร์มแวร์ม็อดสนุก ๆ ที่เกิดจากกระบวนการนี้ด้วย คำอธิบาย DX7 คำอธิบาย DX9 DX97 และผมยังเขียนบทแนะนำเกี่ยวกับกระบวนการรีเวิร์สเอนจิเนียร์ไว้ด้วย บทแนะนำ มันคล้ายงานโบราณคดีตรงที่ได้เห็นวิธีคิดของวิศวกรรุ่นก่อน และจำได้ว่า N64 เองก็เป็นแพลตฟอร์มที่พัฒนาได้ยากในยุคนั้น
    • อาจเป็นเพราะรักเกมนั้นจริง ๆ ก็ได้ ผมเองก็รัก Mega Man Battle Network 2 มากในวัยเด็ก เกมนี้ทำให้ผมเรียนภาษาอังกฤษและกลายมาเป็นโปรแกรมเมอร์ ผมยังเก็บตลับจริงไว้ถึงสองตลับ บางครั้งก็ลองวิเคราะห์ด้วย IDA เพื่อค่อย ๆ ทำความเข้าใจเกม แม้จะไม่มีทักษะหรือเวลามากเท่าชุมชน ROM hacking จริงจัง แต่ก็ยังพยายามอยู่
    • ในมุมผม คนพวกนี้คือคนที่อยากลองทำเอง หรือมีใจชอบความท้าทายเป็นพิเศษ
    • ปีนี้ผมพูดที่ Game On Expo เกี่ยวกับโปรเจ็กต์ถอดกลับ Castlevania: Symphony of the Night https://github.com/xeeynamo/sotn-decomp คนส่วนใหญ่ที่มาร่วมงานแบบนี้มีแรงจูงใจจากความรักเกมนั้นมาก ๆ จากนั้นค่อยแตกไปเป็นเรื่องการพอร์ต การม็อด การเรียนรู้ หรือความต้องการอนุรักษ์ ส่วนตัวผมก็ชอบความท้าทายของมันด้วย (คล้ายแก้ปริศนาคณิตศาสตร์) ถ้าจะทำงานนี้ระยะยาว ต้องเข้าใจทั้งประวัติและทฤษฎีของคอมไพเลอร์ รวมถึงแรงกดดันทางธุรกิจและวิศวกรรมในช่วงที่เกมถูกสร้างขึ้น กระบวนการนี้ยังทำให้เข้าใจด้วยว่าทำไมบางส่วนของเกมถึงถูกสร้างแบบนั้น ผมก็สตรีมงาน SotN อยู่ด้วย ถ้ามีคำถามอะไรก็มาคุยในแชตได้เลย https://m.twitch.tv/madeupofwires/home
  • เป็นโปรเจ็กต์ที่เจ๋งมาก! แต่...พออยู่บน GitHub ก็แอบกังวลว่าจะโดนแจ้งให้ลบในไม่ช้าไหม
    • ผมลองดูในรีโปเร็ว ๆ แล้ว ดูเหมือนไม่มีเนื้อหาที่มีลิขสิทธิ์อยู่เลย มีแค่โค้ดที่ใช้สำหรับทำ decompile จริง ๆ เท่านั้น
    • โปรเจ็กต์ถอดกลับเกม Nintendo ก็ยังเผยแพร่อยู่บน GitHub กันตามปกติ เลยไม่เข้าใจว่าทำไมอันนี้จะต้องโดนลบด้วย
  • อยากเน้นว่ามีข้อความกำกับว่า “นี่คือการถอดกลับ Duke Nukem Zero Hour N64 หมายเหตุ: คุณต้องมีตลับเกมจึงจะใช้รีโปนี้ได้”
  • สงสัยว่า LLM เหมาะกับงานรีเวิร์สเอนจิเนียร์แบบนี้หรือไม่
    • ใช้ LLM ทำงานติดป้ายชื่ออัตโนมัติได้เยอะทีเดียว และก็ดูเหมือนจะทำแบบ "แก้ซ้ำไปเรื่อย ๆ จนไบนารีตรงกัน" ได้ด้วย แม้ผมจะยังไม่เคยเห็นกรณีที่จัดระบบอย่างจริงจังไว้เป็นตัวอย่าง อ้างอิงได้จากโปรเจ็กต์ decompai ที่ใช้แนวทางคล้ายกันอยู่บ้าง (แม้จะไม่เหมือนโปรเจ็กต์นี้เสียทีเดียว) ผมเคยลองใช้เอง แล้วพบว่าถ้ามีข้อมูลตั้งต้นอยู่บ้าง มันช่วยเดาชื่อตัวแปรได้ดีมาก โดยเฉพาะงานน่าเบื่อซ้ำ ๆ อย่างการตั้งชื่อตัวนับหรือชื่อตัวแปรชั่วคราว ส่วนชื่อฟังก์ชันก็มักอนุมานได้จากรูปแบบของอัลกอริทึม
    • ไม่แน่ใจว่า EFF เคยออกจุดยืนอย่างเป็นทางการเรื่องการใช้ LLM แบบนี้หรือไม่ แต่ผมคิดว่ามีความเสี่ยงทางกฎหมายด้านลิขสิทธิ์อยู่ การถอดกลับทำได้เพราะก่อให้เกิดงานสร้างสรรค์ใหม่ แต่ LLM อาจถูกโจมตีได้ง่ายว่าผลลัพธ์ที่ได้เป็นงานดัดแปลงหรือไม่สร้างสรรค์ อีกทั้งบริษัทยังต้องจ่ายเงินก้อนโตให้กับไลเซนส์ข้อมูลฝึกสอนด้วย ยิ่งทำให้เรื่องซับซ้อน ผมคงหลีกเลี่ยงการใช้เพราะความเสี่ยงเรื่องลิขสิทธิ์นี้ แต่ถ้าการถอดกลับด้วย LLM กลายเป็นเรื่องง่ายจริง ๆ ก็น่าจะได้เห็นบรรทัดฐานคดีใหม่ในไม่ช้า
    • ผมว่ามันใช้ได้ดีพอสมควร ไม่สมบูรณ์แบบแต่ช่วยลดเวลาได้มาก โดยเฉพาะการระบุฟังก์ชันไลบรารีหรืออัลกอริทึมที่เป็นที่รู้จัก แม่นยำถึงระดับที่มนุษย์สู้แทบไม่ได้ มันยังจำแนกได้แม้โค้ดจะเสียรูปไปจากกระบวนการคอมไพล์และถอดกลับ
    • ผมกำลังใช้เอเจนต์ช่วยพอร์ตเกมอยู่ แม้จะมีซอร์สโค้ดแล้วก็ยังติดขัดบ่อย ปัญหาคือ LLM มักไม่ค่อยอยากพอร์ตไลบรารีจำนวนมาก ทำให้แทนที่จะลดงานซ้ำ ๆ กลับกลายเป็นมีแต่สตับและสมมติฐานเต็มไปหมด จนงานทั้งหมดพังเป็นโดมิโนมาหลายครั้ง
    • ผมยังไม่เคยใช้เอง แต่คิดว่าน่าจะช่วยได้ในงานปรับปรุงเฉพาะจุด เช่น การเปลี่ยนชื่อตัวแปรหรือชื่อฟังก์ชัน
  • มีการพูดถึงข้อควรระวังเรื่อง “ต้องเป็นเจ้าของตลับเกมจึงจะใช้รีโปได้” โดยตั้งใจ
    • คนที่ใช้เครื่องเกมพกพาเรโทรจากจีนต้องดึง ROM ออกมาเองถึงจะถูกกฎหมาย แต่ถ้าซื้อรุ่นราคาถูกที่แถมเกมมา 10,000 เกม กลับกลายเป็นว่าทุกอย่างดูเหมือนถูกกฎหมายขึ้นมาอย่างน่าประหลาด แน่นอนว่าแทบไม่มีใครโดนลงโทษจริง จึงทำให้คำเตือนแบบนี้ดูน่าเอ็นดู
    • ในทางปฏิบัติ ต่อให้ไม่มีตลับเกมก็ใช้งานได้สบาย ผมเลยคิดว่าคำเตือนนั้นไม่ถูกต้อง
    • นี่เป็นเพียงคำเตือนทางกฎหมายจริง ๆ ไม่ใช่เงื่อนไขที่มีผลบังคับใช้จริง
  • ผมยังคงเฝ้ารอ Duke Nukem Forever อย่างใจจดใจจ่ออยู่เลย จำแทบไม่ได้แล้วว่ารอนานแค่ไหน