สร้างเกมด้วย AI ไม่ต้องเขียนโค้ดเอง: สิ่งที่ควรตรวจหลัง AI เขียนให้

สรุปก่อน: ให้ AI เขียนโค้ดเกมให้ได้ แต่ในกรณีของเรา AI ไม่รู้เองว่าเกมเล่นได้ดีหรือยัง งานของเราคือสั่งให้มันรันซ้ำหลาย ๆ ครั้งแล้วดูตัวเลข ในแอปของเรา เห็นด้วยตาว่าลูกบอลลงขวาตลอด จึงสั่งให้ AI รัน 64 ครั้งเพื่อยืนยันด้วยตัวเลข ผลคือลูกบอลตกลงช่องขวาสุด 47 จาก 64 ครั้ง (73.4%) ทั้งที่มีช่องให้ตก 4 ช่อง ตัวเลขชุดนี้ใช้ยืนยันปัญหา และใช้ตรวจต่อว่าแก้แล้วได้ผลจริงหรือไม่

บทความนี้เล่าสิ่งที่เราตรวจจริงกับแอปที่ทำด้วย Godot และ AI ส่วนที่ยังไม่ได้ตรวจ เราเขียนไว้ท้ายบทความ

บทความไทยที่เราอ่านก่อนเขียน

ก่อนเขียน เราอ่านบทความภาษาไทยเรื่องสร้างเกมด้วย AI สามชิ้น (อ่านเมื่อ 2026-11-11) เพื่อดูว่าคนไทยเจอแนวไหนอยู่แล้ว

• Marketing Oops! (เผยแพร่ 2026-11-06) สอนทำเกมแบบข้อความ (text-based simulation) ด้วยแพ็กเกจฟรีของ ChatGPT, Claude, Gemini และ Grok เป็น 5 ขั้นตอน ตั้งแต่เลือก AI ไปจนถึงแชร์เกม โดยไม่ต้องเขียนโค้ดเอง
• บล็อกของ Manus (เครื่องมือที่เขาขายเอง) ให้วางแผนเกมก่อน มีพรอมต์ให้คัดลอก และบอกข้อจำกัดของ AI ไว้ด้วย
• บทความของ Jenova (เว็บบริการ AI) เน้นภาพรวมของเครื่องมือ

เราไม่ได้ลองเครื่องมือเหล่านี้ จึงไม่ขอบอกว่าใช้งานดีหรือไม่ดี สิ่งที่เราสังเกตคือ ทั้งสามชิ้นเล่าวิธีสร้าง แต่ไม่ได้เล่าว่าสร้างเสร็จแล้วตรวจอะไร กี่ครั้ง ซึ่งเป็นสิ่งที่เรามีข้อมูลจริง (ข้อสังเกตนี้จากสามชิ้นที่อ่าน ไม่ได้หมายความว่าไม่มีบทความอื่น)

ก่อนตรวจ: เริ่มจากเกมเล็ก ๆ

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

ตัวอย่างที่ 1: ลูกบอลลงช่องขวาสุดเกือบทุกครั้ง

แอปของเรามีกระดานที่ลูกบอลกระทบหมุดแล้วตกลงช่อง มี 4 ช่อง เราให้ AI สร้างกระดาน แล้วสั่งให้รันแอปเวอร์ชันเก่า 64 ครั้งเพื่อนับว่าลูกบอลลงช่องไหน ผลคือ

ช่องขวาสุดได้ 47 ครั้ง คิดเป็น 73.4% เราตรวจสอบต่อ น่าจะเป็นเพราะเพดานของกระดานทำจากสี่เหลี่ยมสั้น ๆ ซ้อนกัน 24 ชิ้น เพื่อประมาณรูปโค้ง ขอบของสี่เหลี่ยมพวกนี้ดันลูกบอลกลับลงด้านล่าง ค่าการเด้ง (bounce) ของลูกบอลคือ 0.36 และแรงเสียดทาน (friction) คือ 0.18 ซึ่งทำให้ลูกบอลช้าลงด้วย

เราลองแก้สองวิธีและรันเทียบกัน

เราเก็บผลที่ไม่ผ่านไว้ เพราะแสดงว่าการเพิ่มการเด้ง ซึ่งเป็นวิธีที่คนมักนึกถึงเป็นอย่างแรก ไม่ได้ผล (2,032 ครั้งแบ่งเป็นรันแบบกำหนดจำนวนเฟรมไว้ล่วงหน้า (ไม่ขึ้นกับเวลาจริง) 2,000 ครั้ง และรันแบบเวลาจริง 32 ครั้ง)

ตัวอย่างที่ 2: บางครั้งตัวทดสอบเองที่ผิด

หลังเปลี่ยนเพดาน เราอยากรู้ว่าแอปยังทำงานถูกเมื่อเฟรมสะดุด โดยจำลองเวลาจริงที่ 30 และ 60 เฟรมต่อวินาที (fps) เราให้ AI สร้างตัวทดสอบที่รันกระดาน 16 อันพร้อมกันเพื่อประหยัดเวลา ผลคือล้มเหลว 19 ครั้งจาก 64 ครั้ง (ที่ 30 fps)

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

จำนวนครั้งไม่เท่ากัน จึงเปรียบเทียบ 19 กับ 0 ตรง ๆ ไม่ได้ ข้อสรุปของเราคือ ความล้มเหลว 19 ครั้งน่าจะมาจากตัวทดสอบ ไม่ใช่ตัวแอป เพราะกระดานแต่ละอันปรับ Engine.time_scale ซึ่งเป็นค่าที่ใช้ร่วมกันทั้งเอนจิน เมื่อรันพร้อมกันจึงรบกวนกัน ตอนนี้เป็นเพียงข้อสันนิษฐาน เรายังไม่ได้แยกตัวแปรมาทดสอบเพื่อยืนยัน

รายการตรวจ 4 ข้อ ที่เราใช้

1. สั่งให้ AI รันเกมเองหลายครั้ง และให้พิมพ์ตัวเลขออกมา ไม่ใช่แค่ดูว่า "ดูปกติ"
2. ลองแก้ทีละอย่าง แล้วรันซ้ำ เก็บผลของวิธีที่ไม่ผ่านไว้ด้วย
3. ถ้าผลทดสอบแย่ ให้ลองตรวจตัวทดสอบเองด้วย ก่อนสรุปว่าเกมพัง
4. เขียนไว้เสมอว่าอะไรยังไม่ได้ตรวจ

สิ่งที่ยังไม่ได้ตรวจ

• ผลทั้งหมดมาจาก Godot 4.5 บน Windows ยังไม่ได้วัดบน iPhone หรือ Android จริง
• ความถี่ของแต่ละช่องว่าเท่ากันหรือไม่
• ข้อสันนิษฐานเรื่อง Engine.time_scale ยังไม่ได้พิสูจน์