มาตรฐานทองคำของการปรับแต่งประสิทธิภาพ: เจาะลึกภายใน RollerCoaster Tycoon

 (larstofus.com)
27 คะแนน โดย GN⁺ 2026-03-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • RollerCoaster Tycoon เกมจากปี 1999 เป็น เกมจำลองสถานการณ์ที่เขียนด้วยภาษาแอสเซมบลีแทบทั้งหมด และยังคงรักษาประสิทธิภาพที่เสถียรได้แม้ต้องประมวลผลแขกนับพันคนแบบเรียลไทม์
  • ผู้พัฒนา Chris Sawyer เลือกการควบคุมระดับล่างแทนภาษาระดับสูง จนสร้างผลงานที่อาจเรียกได้ว่าเป็น เกมแอสเซมบลีรุ่นท้าย ๆ ที่รีดประสิทธิภาพของ CPU ได้สูงสุด
  • ผ่านโปรเจกต์แฟนเมด OpenRCT2 ทำให้มีการวิเคราะห์ย้อนกลับของ รูปแบบการปรับแต่งอย่างละเอียดและเทคนิคการประหยัดหน่วยความจำ ของต้นฉบับ
  • เกมนี้ใช้ การคำนวณแบบ bit shift และการแยกชนิดข้อมูลอย่างละเอียด เพื่อเพิ่มความเร็วในการคำนวณและประสิทธิภาพของแคช พร้อมทั้งทำให้การจำลองขนาดใหญ่เป็นไปได้ด้วย การจำกัดความลึกของ pathfinding และ การตัดการคำนวณการชนกันออกไป
  • โครงสร้างเหล่านี้เป็น ตัวอย่างคลาสสิกของการใช้ข้อจำกัดทางเทคนิคอย่างสร้างสรรค์เพื่อการปรับแต่งประสิทธิภาพ และยังสะท้อนให้เห็นถึงความสำคัญของการกำจัดการคำนวณที่ไม่จำเป็นตั้งแต่ขั้นตอนการออกแบบแม้ในปัจจุบัน

วิเคราะห์โครงสร้างการปรับแต่งประสิทธิภาพของ RollerCoaster Tycoon

  • RollerCoaster Tycoon(RCT) ที่วางจำหน่ายในปี 1999 ถูกเขียนด้วย แอสเซมบลี (Assembly) เกือบทั้งหมด และได้รับการยกย่องว่าเป็นเกมที่สามารถจำลองเอเจนต์นับพันแบบเรียลไทม์พร้อมรักษาเฟรมเรตที่เสถียรบนฮาร์ดแวร์ในยุคนั้นได้
  • โดยอ้างอิงจากเนื้อหาที่กล่าวถึงในพอดแคสต์เกมเยอรมัน Stay Forever บทความนี้วิเคราะห์อย่างเป็นรูปธรรมว่า Chris Sawyer บรรลุการปรับแต่งระดับสุดขั้วได้อย่างไร
  • แม้ซอร์สโค้ดต้นฉบับจะไม่ได้เปิดเผย แต่ผ่านโปรเจกต์ OpenRCT2 ที่แฟน ๆ สร้างขึ้น ก็ทำให้สามารถตรวจสอบโครงสร้างโค้ดและเทคนิคการปรับแต่งผ่านการทำ reverse engineering ได้

  • การรีดประสิทธิภาพสูงสุดด้วยแอสเซมบลี

    • RCT ถูกเขียนด้วย แอสเซมบลีแทน C หรือ C++ ทำให้ควบคุมประสิทธิภาพได้ละเอียดกว่าเกมอื่น ๆ ในยุคนั้นมาก
      • ตัวอย่างเช่น Doom (1993) เขียนด้วย C เป็นส่วนใหญ่ แต่ RCT นั้นถูกสร้างขึ้นด้วยแอสเซมบลีเกือบทั้งหมด
      • แนวทางนี้ถือว่าพบได้ยากแล้วแม้แต่ในช่วงปลายทศวรรษ 1990 และ RCT ก็ถูกมองว่าเป็นหนึ่งใน เกมแอสเซมบลีขนาดใหญ่รุ่นสุดท้าย
    • ในเวลานั้นการปรับแต่งอัตโนมัติของคอมไพเลอร์ยังมีข้อจำกัดมาก การปรับแต่งด้วยมือจึงสร้างความแตกต่างด้านประสิทธิภาพได้อย่างชัดเจน

  • วิเคราะห์โค้ดผ่าน OpenRCT2

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

  • การแยกชนิดข้อมูลอย่างละเอียด — ประหยัดหน่วยความจำ

    • RCT เก็บข้อมูลจำนวนเงินด้วยขนาดที่ต่างกันตามบริบทการใช้งาน
      • ตัวอย่าง: มูลค่ารวมของสวนสนุกใช้ตัวแปร 4 ไบต์ ส่วนราคาสินค้าในร้านใช้ตัวแปร 1 ไบต์
    • การแยกเช่นนี้มีเป้าหมายเพื่อประหยัดหน่วยความจำและเพิ่มประสิทธิภาพของแคช แต่ บน CPU สมัยใหม่แทบไม่เห็นความต่างด้านประสิทธิภาพ ทำให้ใน OpenRCT2 ถูกรวมเป็นตัวแปร 8 ไบต์แบบเดียวกัน

  • การปรับคณิตศาสตร์ให้เร็วขึ้นด้วย bit shift

    • ในโค้ดมีการใช้การคำนวณอย่าง NewValue = OldValue >> เพื่อแทนการหารด้วยเลขยกกำลังของ 2
    • การปรับแต่งลักษณะนี้ ทำได้เฉพาะเมื่อการคูณหรือหารเป็นเลขยกกำลังของ 2 เท่านั้น จึงดูเหมือนว่าสูตรคำนวณในเกมเองก็ถูกออกแบบให้สอดคล้องกับเงื่อนไขนี้
    • กล่าวอีกอย่างคือ โครงสร้างทางคณิตศาสตร์ของเกมถูกออกแบบโดยคำนึงถึงประสิทธิภาพการคำนวณของ CPU ตั้งแต่ขั้นตอนการออกแบบเกม

  • การออกแบบเกมโดยคำนึงถึงประสิทธิภาพ

    • RCT มี Chris Sawyer เป็นทั้งโปรแกรมเมอร์และผู้ออกแบบเกมเพียงคนเดียว จึงสามารถสร้างโครงสร้างที่คำนึงถึงประสิทธิภาพได้ตั้งแต่ระยะออกแบบ
    • กรณีตัวอย่างที่เด่นชัดคือ ระบบแขก (Pathfinding)
      • เกมจำลองส่วนใหญ่มักให้แขกกำหนดจุดหมายแล้วค้นหาเส้นทาง แต่ใน RCT แขกจะ เดินแบบสุ่ม แล้วค่อยพบเครื่องเล่นโดยบังเอิญ
      • วิธีนี้เป็น โครงสร้างที่หลีกเลี่ยงการคำนวณ pathfinding ขนาดใหญ่ ทำให้รองรับแขกนับพันคนพร้อมกันได้
    • ในกรณีที่จำเป็นต้องใช้ pathfinding (เช่น ช่างซ่อมเดินไปยังเครื่องเล่นที่เสีย) ก็มีการกำหนด ขีดจำกัดความลึกของการค้นหา เพื่อป้องกันเฟรมดรอป
      • แขกทั่วไปค้นหาได้ถึง 5 ทางแยก, ช่างซ่อมได้ถึง 8 ทางแยก
      • แขกที่ซื้อแผนที่จะมีขีดจำกัดการค้นหาเพิ่มเป็น 7
    • ข้อจำกัดเหล่านี้ไม่ใช่เพียงการประนีประนอมทางเทคนิค แต่เป็น โครงสร้างการปรับแต่งที่ถูกรวมเข้ากับองค์ประกอบการเล่นอย่างเป็นธรรมชาติ

  • การจัดการฝูงชนและการละเว้นการหลบหลีกการชน

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

  • ข้อคิดที่มีต่อการพัฒนาสมัยใหม่

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

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

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

 
cadenzah 2026-03-24

ช่วยรัก RollerCoaster Tycoon กันเยอะ ๆ นะ
 
GN⁺ 2026-03-23
ความคิดเห็นจาก Hacker News

  • Warcraft 1, 2 และ StarCraft ต่างก็ใช้ ขนาดแผนที่เป็นหน่วยกำลังสอง
    ทำให้บน CPU 386/486 ที่ช้า สามารถใช้การเลื่อนบิตแทนการหาร·คูณเพื่อเพิ่มความเร็วได้
    การเรนเดอร์แผนที่, สไปรต์, ฟอนต์, เอฟเฟกต์หมอก ฯลฯ ถูกจัดการด้วยแอสเซมบลีหลายพันบรรทัด และส่วนที่เหลือเป็น โค้ดที่พกพาได้สูงซึ่งเขียนด้วย C
    ในกรณีของ Blackthorne เวอร์ชัน SNES, Genesis และ DOS ถูกพอร์ตแบบทำมือด้วยแอสเซมบลีที่ต่างกันในแต่ละแพลตฟอร์ม และเวอร์ชัน PC ก็สร้างโค้ดเรนเดอร์ด้วยแมโครถึง 100,000 บรรทัดเพื่อรองรับ VGA Mode X
    จากประสบการณ์แบบนี้ Blizzard จึงได้บทเรียนว่า “แอสเซมบลีกินเวลาพัฒนามากเกินไป”
    Comanche: Maximum Overkill เป็น เฮลิคอปเตอร์ซิมูเลเตอร์แบบ voxel-based ที่เขียนด้วยแอสเซมบลีทั้งหมด แต่การพอร์ตไป protected mode ยากเกินไป จึงเปลี่ยนไปใช้การเรนเดอร์แบบ polygon ตั้งแต่เวอร์ชันถัดไป

    • มีผู้ใช้ Reddit พบซอร์สโค้ด gold master ของ StarCraft แต่ก็น่าเสียดายที่คืนไปโดยแลกกับ ของสะสม Blizzard
      EA เคยเปิดซอร์สโค้ดของ ซีรีส์ Command & Conquer แต่ Tiberian Sun กับ Red Alert 2 ไม่ได้รวมอยู่ด้วย
      StarCraft ก็น่าจะดีถ้าได้เปิดเผยออกมาเพื่อการอนุรักษ์ประวัติศาสตร์
    • ตอนเด็ก ๆ ตอนเห็น Comanche กับ Settlers 1 ครั้งแรก รู้สึกเหมือนเวทมนตร์ที่กราฟิกออกมาบน DOS text mode ได้
      ตั้งแต่นั้นมาก็หลงใหลเกมอย่างเต็มที่
    • ถ้าเคยมีส่วนร่วมกับ Lost Vikings ด้วย ก็อยากบอกว่าขอบคุณที่มอบความสนุกในวัยเด็ก
      แล้วก็สงสัยว่าเคยทำกิจกรรมใน demoscene ด้วยไหม
    • ตอนอยู่ที่ Blizzard เคยมี เหตุการณ์ที่เซิร์ฟเวอร์ซอร์สโค้ดหายและไม่มีแบ็กอัป อยากรู้ว่าอยู่ในช่วงนั้นไหม
      ฉันเคยเป็นที่ปรึกษาอยู่สั้น ๆ แถวช่วงที่ WC3 ออก
    • Maximum Overkill เป็นเกมที่น่าทึ่งจริง ๆ ถึงขั้นเล่นไป หลายร้อยชั่วโมง

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

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

    • เมื่อก่อนฉันก็คิดว่าการจูนแบบจุกจิกพวกนี้สำคัญ แต่พอศึกษา โครงสร้าง pipeline ของ CPU สมัยใหม่ แล้วก็เปลี่ยนความคิด
      ตอนนี้การบวกอยู่ราว 1 cycle, การคูณ 3 cycles, การหาร 12 cycles และยังประมวลผลหลายคำสั่งแบบขนานได้
      สมัย Pentium เก่านั้นใช้ถึง 46 cycles และความถี่ก็แค่ 100MHz
      ตอนนี้ memory layout สำคัญกว่ามาก — แค่ cache miss ครั้งเดียวก็เสียไป 100~1000 cycles
      การคำนวณกับ int[] เร็วกว่า Monster[] มาก
    • ฉันกำลังพัฒนา csgrs CAD kernel และรู้สึกว่า การคำนวณเชิงตัวเลขยังเป็นปัญหาที่แก้ไม่ตก
      มันมี trade-off ระหว่างความเร็ว, ความแม่นยำ, ขนาดจัดเก็บ และความซับซ้อน
      งานอย่าง Toward an API for the Real Numbers เสนอแนวทางแก้ปัญหาเหล่านี้แบบค่อยเป็นค่อยไป
      มีทั้ง floating-point error, interval arithmetic, symbolic computation และวิธีอื่น ๆ อีกมาก แต่สุดท้ายถ้าไม่เข้าใจ trade-off ก็จะโดนปัญหาเล่นงาน
    • เกมเชิงพาณิชย์เป็นสินค้าที่ผลิตจำนวนมาก ดังนั้นการที่ดีไซเนอร์เข้าใจข้อจำกัดทางเทคนิคจึงเป็นข้อได้เปรียบอย่างมากในฐานะ สัญชาตญาณด้านการออกแบบอุตสาหกรรม
      ตัวอย่างเช่น Fumito Ueda ใส่ใจเรื่องความเป็นไปได้ทางเทคนิคอย่างมากใน 『Shadow of the Colossus』 และ Doom ก็เป็นการผสานกันของความคิดสร้างสรรค์กับเทคโนโลยี
      ดู บทสัมภาษณ์ที่เกี่ยวข้อง ได้
    • คุณภาพของเกมไม่ได้เป็นแค่เรื่องประสิทธิภาพ runtime ที่มีประสิทธิผล แต่เป็นเรื่องของ ความสนุกและความสมบูรณ์ของงาน
      บั๊ก, ความสอดคล้องของเนื้อเรื่อง และความดื่มด่ำสำคัญกว่า
      แน่นอนว่าถ้าเฟรมเรตตกหนักก็ทำให้คุณภาพลดลง แต่ถ้ารันได้ลื่นบนฮาร์ดแวร์เป้าหมายแล้ว การปรับปรุงก็ควรไปโฟกัสส่วนอื่น
    • ตอนพัฒนาผลิตภัณฑ์ที่ใช้ ARM Cortex-M4 ฉันเคยทำ ตัวสร้างเลขสุ่มแบบกำหนดเอง
      ปรับให้สามารถโหลดค่าคงที่แบบ immediate ด้วยคำสั่ง Thumb-2 เพื่อหลีกเลี่ยง memory stall
      ผลคือใช้งานเลขสุ่มได้เร็วและมีประสิทธิภาพ แถมผ่านการทดสอบทั้งหมด
      แต่ภายหลังเปลี่ยนไปใช้ Cortex-M0 โค้ดนี้ก็ถูกทิ้งไป

  • ประเด็นที่เปลี่ยน ข้อจำกัดทางเทคนิคให้กลายเป็นองค์ประกอบของเกมเพลย์ น่าสนใจมาก
    ทำให้นึกถึงระบบ Blood Moon ใน 『The Legend of Zelda』

  • คำอธิบายว่า “ใช้ >>3 แทน /8 จะช่วยประหยัดการหารได้” นั้น ไม่จริงสำหรับคอมไพเลอร์สมัยใหม่
    ถ้าชนิดข้อมูลถูกต้อง คอมไพเลอร์จะ optimize เป็นการเลื่อนบิตให้อัตโนมัติ

    • แต่สำหรับ signed integer จะมีการเพิ่มคำสั่งบางอย่างเพื่อให้สอดคล้องกับกฎการปัดเศษของมาตรฐาน C

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

    • ทำให้นึกถึง xkcd 2501

  • คำพูดที่ว่า “คอมไพเลอร์ไม่เปลี่ยนการคูณด้วยกำลังสองให้เป็นการเลื่อนบิต” เป็นมุกเก่ามากแล้ว
    ต่อให้ในยุค 2000s เอง คอมไพเลอร์ก็ optimize เรื่องนี้เป็นเรื่องพื้นฐานจนแทบหาวใส่ได้เลย

  • อ่านสนุกมาก สำหรับ RCT ก็ขอแนะนำข้อมูลด้านล่างด้วย

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

  • พอเห็นส่วน pathfinding ของ RCT ก็ทำให้นึกถึง วิดีโอ YouTube ของ Marcel Vos
    เขามีวิดีโอจำนวนมากที่เจาะลึกการทำงานภายในของ RCT