เหตุผลที่สร้างเกมด้วย C (ใช่, ด้วย C นั่นแหละ)

 (jonathanwhiting.com)
3 คะแนน โดย GN⁺ 2026-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทุกเกมในโปรเจกต์ส่วนตัวถูกพัฒนาด้วย ‘C ล้วน’ ซึ่งถือเป็นทางเลือกที่พบได้ไม่บ่อยในปัจจุบัน
  • เกณฑ์หลักในการเลือกภาษาคือ ความน่าเชื่อถือ ความสามารถในการพกพา และความยั่งยืนในระยะยาว โดยไม่ผูกติดกับ OS หรือแพลตฟอร์มใดแพลตฟอร์มหนึ่ง
  • ให้ความสำคัญกับ ความเรียบง่ายและความเร็วในการคอมไพล์ รวมถึง การตรวจสอบชนิดข้อมูลอย่างเข้มงวดและระบบคำเตือนที่ทรงพลัง
  • ได้พิจารณาภาษาทางเลือกอย่าง C++·C#·Java·Go·Haxe เป็นต้น แต่ตัดสินว่าไม่เหมาะสมเพราะความซับซ้อน, GC, การบังคับใช้ OOP เป็นต้น
  • C เป็นภาษา ที่อันตรายแต่เรียบง่ายและรวดเร็ว และยังคงเป็นตัวเลือกที่ดีที่สุดด้วยการรองรับแพลตฟอร์มอย่างกว้างขวางและระบบนิเวศของไลบรารีที่แข็งแกร่ง

เกณฑ์ในการเลือกภาษา

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

การประเมินภาษาทางเลือกหลัก

  • C++
    • แม้ยังเป็นมาตรฐานในวงการพัฒนาเกม แต่ไม่พอใจกับ ความซับซ้อนและความเร็วในการคอมไพล์ที่ช้า
    • แม้จะให้ประสิทธิภาพสูงและมีฟีเจอร์หลากหลาย แต่ก็มีฟีเจอร์จำนวนมากที่ไม่ต้องการ และต้นทุนด้านความซับซ้อนก็สูง
  • C# และ Java
    • ยืดยาวและซับซ้อน และด้วยโครงสร้างที่เน้น OOP อย่างหนักทำให้มีอิสระน้อย
    • แม้คุณลักษณะของภาษาระดับสูงจะซ่อนความซับซ้อนไว้ แต่ก็ไม่ได้ป้องกันปัญหาพื้นฐาน
  • Go
    • มองในแง่บวกว่าเป็นการตีความ C ใหม่ในแบบสมัยใหม่ แต่ stop-the-world garbage collection ไม่เหมาะกับการพัฒนาเกม
    • มีข้อกังวลทั้งเรื่องการขาดแคลนไลบรารีสำหรับเกมและความยั่งยืนในระยะยาว
  • JavaScript
    • การเปลี่ยนแปลงอย่างรวดเร็วของสภาพแวดล้อมการพัฒนาเว็บและการสิ้นสุดของ Flash ทำให้รู้สึกว่าไม่เสถียร
    • ตัดสินว่า ไวยากรณ์ที่หลวม ไม่เหมาะกับการเขียนซอฟต์แวร์ขนาดใหญ่
  • Haxe
    • มองว่าน่าสนใจเมื่อใช้พัฒนาเว็บ แต่มีความกังวลเรื่องความยั่งยืนเพราะเป็น ภาษาที่ค่อนข้างใหม่
  • การพัฒนาภาษาของตัวเอง
    • เป็นแนวคิดที่น่าสนใจ แต่ตัดสินว่าไม่สมจริงเพราะ ต้องทิ้งไลบรารีเดิมและมีภาระในการรักษาความเข้ากันได้

เหตุผลที่เลือก C

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

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

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

 
GN⁺ 2026-02-09
ความคิดเห็นจาก Hacker News

  • ปกติฉันเขียนโค้ดแบบ สไตล์ C เป็นหลัก แต่จะใช้ฟีเจอร์ของ C++ เฉพาะเวลาจำเป็นเท่านั้น
    เพราะงั้นถ้ามองผ่าน ๆ บางทีก็ดูเหมือนโค้ด Rust
    คนที่บอกว่าเขียนเกมด้วย C มักจะไม่ชอบฟีเจอร์ของ C++ แต่สุดท้ายก็ลงมือทำ virtual interface เอง หรือสร้าง switch ก้อนมหึมาเพื่อทำเรื่องคล้าย ๆ กัน
    ถ้าไม่อยากใช้ฟีเจอร์ที่ภาษาให้มาก็แค่ไม่ต้องใช้ แต่การบ่นว่ามันมีอยู่ตั้งแต่แรกผมว่าก็ไม่ค่อยมีความหมาย
    C++ ไม่ได้คอมไพล์ช้าถ้าไม่ใช้ template แบบเกินเหตุ

    • ตอนทำคนเดียวอาจเป็นแบบนั้นได้ แต่ในโปรเจกต์ที่ทำกันเป็นทีมและต้องดูแลระยะยาว สถานการณ์จะต่างออกไป
      เมื่อเวลาผ่านไป สมาชิกทีมเปลี่ยน หัวหน้าทีมเปลี่ยน ชุดของฟีเจอร์ ที่ถูกใช้งานก็จะค่อย ๆ ขยายใหญ่ขึ้น
      และพอฟีเจอร์เพิ่มไปแล้ว การลดมันกลับลงมานั้นยากมาก
      อีกอย่าง คุณอาจจำเป็นต้องใช้ ไลบรารี ที่ใช้ฟีเจอร์ซึ่งคุณไม่ต้องการ
      ยกตัวอย่าง ผมไม่ชอบการเรียกแบบแฝง (destructor, operator overloading ฯลฯ) แต่ถ้าไลบรารีใช้มัน สุดท้ายก็ต้องตามน้ำ
    • อย่างน้อย switch ก็ยังอ่านรู้เรื่อง
      หนึ่งในสิ่งที่แย่ที่สุดของ C++ คือมันมี โค้ดที่ซ่อนอยู่ ซึ่งถูกสร้างขึ้นอัตโนมัติเยอะเกินไป
    • dynamic dispatch ของ C++ ใช้วิธีแนบ vtable ให้กับทุก type
      ต่อให้โค้ดส่วนใหญ่จัดการกับ concrete type (Goose, Duck ฯลฯ) ทุกอ็อบเจ็กต์ก็ยังต้องพกตัวชี้ vtable ไปด้วย
      ขณะที่ Rust จะใช้ vtable เฉพาะจุดที่จำเป็น จึงประหยัดหน่วยความจำกว่า
      โปรแกรมเมอร์ C จะลงมือทำเฉพาะฟังก์ชันที่ต้องใช้เอง จึงไม่ถูกผูกไว้กับโครงสร้างที่ภาษาบังคับมากนัก
    • C++ ช้าแม้จะไม่ได้ใช้ template แบบเกินเลย
      แค่ include <vector> ก็ลากโค้ดเข้ามาเป็นหมื่นบรรทัดแล้ว
      เพราะงั้นถ้าไม่ใช้ standard library ก็จะมีการเถียงกันว่า “ทำไมต้องประดิษฐ์วงล้อใหม่”
      พอถกแบบนี้ซ้ำ ๆ ก็รู้สึกว่า กลับไปใช้ C ง่ายกว่าเยอะ
      ผมเองก็ย้ายไปใช้ C ราวปี 2017 และจนถึงตอนนี้ทุกครั้งที่ต้องใช้ไลบรารี C++ ก็ยังรู้สึกล้า
      มีข้อยกเว้นคือ Dear ImGui ที่โอเค แต่ถึงอย่างนั้นผมก็ยังชอบ C binding มากกว่า
    • เคยมีครั้งหนึ่งที่ผมเขียนไฟล์ C++ แต่ไม่ได้ใช้ฟีเจอร์ C++ เลยแม้แต่นิดเดียว
      พอเปลี่ยนนามสกุลเป็น .c เวลาคอมไพล์ก็ลดลงครึ่งหนึ่ง

  • ฉันชอบ ความหยาบและความเรียบง่าย ของ C แต่ไม่ชอบ preprocessor
    เพราะงั้น Zig เลยเหมือนของขวัญจากพระเจ้า — มันเรียบง่ายกว่า C และมี การออกแบบภาษา ที่แม่นยำกว่า
    ตัวอย่างเช่น Zig แยก single pointer ออกจาก array pointer
    มันสามารถ import ไลบรารี C และทำให้ใช้งานง่ายขึ้นได้ ซึ่งมีประโยชน์มากในงานพัฒนาเกม
    ไลบรารี C++ ส่วนใหญ่ก็มี C header ให้มาด้วย
    ใน zig-gamedev มี ไลบรารี C ที่ถูกทำให้เป็นสไตล์ Zig แบบนี้อยู่เยอะ
    แทนที่จะใช้ preprocessor ฟีเจอร์ comptime ของ Zig ดีกว่ามาก และมันก็เป็นแค่ “โค้ด Zig ที่รันตอนคอมไพล์” เท่านั้น

    • แต่ในความเป็นจริง ไลบรารี C++ ที่ export C header ออกมานั้นมี น้อยเกินไปมาก

  • ฉันก็เห็นด้วยกับผู้เขียน
    เหตุผลใหญ่ที่สุดที่ทำให้ชอบภาษาสักภาษาคือ ความเรียบง่าย
    เพราะงั้นฉันเลยชอบภาษาอย่าง C, Go, Odin, Zig
    แต่ภาษาที่จัดการกับ ความซับซ้อนที่จำเป็น ได้อย่างสง่างามก็สำคัญเหมือนกัน
    ในโค้ดเครือข่ายที่ต้องการ memory safety, concurrency และ functional pattern นั้น Rust ดูเป็นธรรมชาติ
    ในทางกลับกัน สำหรับโค้ดที่เรียบง่ายและเร็วอย่างเกมอินดี้ C หรือ Odin จะเหมาะกว่า
    Odin ให้ความรู้สึกเหมือนรวมความเรียบง่ายของ Go เข้ากับประสิทธิภาพของ C เลยแนะนำได้
    และยังทำเกมด้วย Raylib ได้ง่ายด้วย

    • น่าสนใจที่ฉันมักอธิบาย Zig ว่าเป็น จุดกึ่งกลางระหว่าง Go กับ C
      เลยสงสัยว่าคุณคิดว่า Odin เหมาะกับตำแหน่งนั้นมากกว่า Zig หรือเปล่า
    • อ้างอิงไว้นิดหนึ่ง ชื่อภาษาคือ Go ส่วน golang เป็นแค่ชื่อโดเมน

  • ในต้นฉบับบอกว่าการรองรับไลบรารีเกมของ Go ยังไม่ดี แต่ดูเหมือนนั่นจะเป็น บทความราวปี 2015
    ตอนนี้สถานการณ์อาจเปลี่ยนไปแล้วก็ได้

    • มี snapshot ของเดือนมกราคม 2016 อยู่ใน Wayback Machine
      และยังดูภาพหน้าจอของเกมที่ทำไว้ตอนนั้นได้ด้วย
      ตัวอย่างเช่น Knossu มีสไตล์ 3D ที่โดดเด่นดี

  • การทำเกมด้วย C ในปี 2026 อาจจะดู บ้าหน่อย ๆ แต่ฉันก็ทำอยู่เหมือนกัน
    เช่น Chrysalis ก็พัฒนาด้วย C (ใช้ GLFW3, FMOD)

    • ฉันทำงานกับ โค้ดเบส Jedi Academy มา 2 ปีแล้ว (C & C++)
      มันอยู่บนพื้นฐาน idTech3 และระบบต่อสู้ละเอียดมากจนการเปลี่ยนเล็กน้อยก็ทำให้สมดุลทั้งเกมพังได้
      ต่อให้เพิ่ม i++ แค่ตัวเดียว จังหวะเวลาก็เปลี่ยนแล้ว
      เพราะงั้นเลยยังใช้คอมไพเลอร์อายุ 22 ปีตัวเดิมอยู่
      ถึงจะมีฟอร์กที่ทำให้ทันสมัยขึ้น แต่ความรู้สึกดั้งเดิมมันหายไป
      idTech3 เป็นเอนจินที่แสดง แก่นแท้ของ C ได้ดีจริง ๆ

  • มีเกมนับพันเกมที่เขียนด้วย C และ graphics API อย่าง OpenGL, Vulkan, DX ก็ล้วนมีพื้นฐานเป็น C
    เพราะงั้นมันไม่ได้แปลกอะไรเลย
    เอนจินเกมส่วนใหญ่ก็เขียนด้วย C/C++

    • API ของ Khronos เป็น C, DirectX เป็น COM/WinRT บน C++, ส่วน Metal เป็นการผสม Objective-C กับ C++
      ฝั่งคอนโซลก็แตกต่างกันไปในแต่ละยุค
    • SDL3 ก็เขียนด้วย C และ Box2D เวอร์ชันล่าสุดก็ ถูกเขียนกลับมาเป็น C อีกครั้ง
    • DirectX เป็น C++ และเอนจินเกมส่วนใหญ่ก็เป็น C++
      ต่างจากการเขียนโปรแกรมบนลินุกซ์ งานพัฒนาเกมนั้นมี C++ เป็นศูนย์กลางมานานกว่า 30 ปีแล้ว

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

    • สงสัยว่าทำไมโค้ดเบส C ถึงเจ็บปวดกว่าเวลาทำงานเป็นทีม
      จากประสบการณ์ของฉัน C เจ็บปวดน้อยกว่า C++ เสียอีก
    • “พูดให้น้อยลงแต่สื่อความหมายได้มากกว่า” — หรือก็คือ ความกระชับ นั่นสำคัญที่สุด
    • ในปี 2025 เพียงปีเดียว มีนักพัฒนา 2,134 คนเข้ามามีส่วนร่วมกับ Linux kernel
      ข้อเท็จจริงนี้ทำให้ข้อจำกัดด้านการทำงานร่วมกันของ C ดูอ่อนลง

  • คำพูดว่า “ไม่มีใครทำเกมด้วย C แล้ว” นั้นเกินจริง
    ตอนนี้อาจไม่ใช่กระแสหลัก แต่ก็ยังมีคนจำนวนมากทำเกมด้วย C อยู่

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

  • ฉันชอบ C
    ฉันควบคุม การจัดการหน่วยความจำ ได้ทั้งหมด และได้พฤติกรรมที่คาดเดาได้
    มันมีประโยชน์มากโดยเฉพาะในสภาพแวดล้อมที่ต้องการการจัดสรรล่วงหน้าแบบกฎ MISRA
    มันยังเหมาะกับการจัดการ exception หรือ error ในระดับฮาร์ดแวร์โดยตรง
    และก็เขียน unit test ได้ง่ายด้วย

  • C เข้าถึงได้ง่าย แต่ ความรู้เรื่องการจัดการหน่วยความจำ เป็นสิ่งจำเป็น
    ตอนที่ฉันเป็นนักพัฒนา Java แล้วต้องรีบทำคอนเน็กเตอร์จากสิ่งที่มีให้แค่ .h กับ .so ฉันเลือก C แทน C++
    ถ้า C คือมีดคม ๆ สักเล่ม C++ ก็เหมือน เสามีดหมุน — เผลอเมื่อไรก็เจ็บ
    แต่เรื่องจัดการสตริงใน C นั้นทรมานเกินไป จนอยากยืมระบบสตริงของ C++ มาใช้

    • ข้อดีของ C++ คือ คุณไม่จำเป็นต้องใช้ฟีเจอร์ที่ไม่ต้องการ