AI สามารถสร้าง Prototype ให้เราได้ภายในไม่กี่ชั่วโมง แต่เมื่อโปรเจกต์ใหญ่ขึ้น โค้ดที่ดูเหมือนทำงานได้ อาจกำลังสะสมปัญหาอยู่ข้างในโดยที่เจ้าของเกมไม่รู้ตัว
มีกระทู้หนึ่งจากชุมชนคนทำเกมที่น่าสนใจ เลยอยากนำมาเล่าให้เพื่อน ๆ ฟังครับ
เจ้าของเรื่องเป็นชายวัย 38 ปี คุณพ่อลูกห้า ทำงานด้าน Cybersecurity มาประมาณ 15 ปี เขาเคยเขียนโปรแกรมมาบ้าง แต่ไม่เคยใช้ Godot และไม่เคยเขียน GDScript มาก่อน
เหมือนคนทำเกมจำนวนมาก เขามีเกมในฝันอยู่ในหัวมานานแล้ว
เกมที่อยากสร้างเป็นแนว Metroidvania ซึ่งได้แรงบันดาลใจจาก La-Mulana มีทั้งการสำรวจ ปริศนา ศัตรู การต่อสู้ ไอเทม และแผนที่หลายพื้นที่ที่เชื่อมโยงกัน
ปัญหาคือ เขาไม่มีเวลามากพอจะเริ่มเรียนทำเกมใหม่ทั้งหมดจากศูนย์
เมื่อเห็นกระแสว่า AI สามารถเขียนโค้ดและช่วยสร้างเกมได้ เขาจึงเกิดความคิดว่า
ถ้าเราเป็นคนคิดเกม ออกแบบระบบ และทดสอบ ส่วนงานเขียนโปรแกรมทั้งหมดปล่อยให้ AI ทำ จะเป็นไปได้ไหม?
เขาจึงตัดสินใจทดลองด้วยตัวเอง
ช่วงแรก ทุกอย่างดูเหมือนปาฏิหาริย์
ภายในเวลาเพียงสามถึงสี่ชั่วโมง เขามีฉากสำหรับทดสอบ มีตัวละครที่วิ่ง กระโดด ปีนบันได อ่านข้อความ ใช้อุปกรณ์สแกน รวมถึงบันทึกและโหลดเกมได้แล้ว
สำหรับคนที่ไม่เคยใช้ Engine นี้มาก่อน ผลลัพธ์ถือว่าน่าประทับใจมาก
จากโปรเจกต์ว่างเปล่า กลายเป็นเกมที่กดเล่นได้ภายในเวลาไม่กี่ชั่วโมง
ช่วงนั้นเขาเริ่มเชื่อว่า คนธรรมดาอาจสร้างเกมของตัวเองได้โดยไม่ต้องเป็นโปรแกรมเมอร์จริง ๆ
แต่การทำให้ตัวละครเดินหรือกระโดดได้ ยังไม่ใช่ส่วนที่ยากที่สุดของการสร้างเกม
ส่วนที่ยากกว่าคือ ทำอย่างไรให้ระบบทั้งหมดทำงานร่วมกันได้โดยไม่พัง
ปัญหาเริ่มเมื่อมีศัตรูและระบบต่อสู้
เมื่อเขาเริ่มทำศัตรูและระบบต่อสู้ AI ก็เริ่มหลงทาง
เขาลองเปลี่ยนคำสั่ง เพิ่มรายละเอียด และให้ AI แก้โค้ดซ้ำแล้วซ้ำอีก
บางครั้ง Bug เดิมหายไป แต่ Bug ใหม่กลับโผล่ขึ้นมาแทน บางครั้ง AI บอกว่าแก้เสร็จแล้ว แต่พอเปิดเกมกลับพบว่า ระบบอื่นที่เคยใช้งานได้พังตามไปด้วย
คืนหนึ่งเขานั่งแก้เกมจนถึงตีสาม และเกือบตัดสินใจลบโปรเจกต์ทั้งหมดทิ้ง
แต่แทนที่จะยอมแพ้ เขากลับคิดว่า
หรือปัญหาไม่ใช่เพราะ AI ทำไม่ได้ แต่เป็นเพราะเรายังใช้ AI ไม่เก่งพอ?
จากผู้ช่วยหนึ่งตัว กลายเป็นกองทัพ AI
เขาใช้เวลาประมาณสองสัปดาห์ศึกษาเรื่อง Context Window, MCP, Pipeline และ Project Management
จากนั้นนำไอเดียเกมที่สะสมไว้นานหนึ่งปีมาจัดเป็นแผนงานอย่างจริงจัง มีทั้งเนื้อเรื่อง Roadmap, Milestone, Sprint และรายการงานที่ต้องทำ
เขายังแบ่ง AI ออกเป็นหลายบทบาท
ตัวหนึ่งช่วยออกแบบเกม
ตัวหนึ่งช่วยวางแผนโครงการ
ตัวหนึ่งเขียนโปรแกรม
อีกตัวตรวจสอบผลงาน
ฟังดูเหมือนเขามีทีมพัฒนาเกมขนาดเล็กที่พร้อมทำงานตลอด 24 ชั่วโมง
แต่มีเรื่องหนึ่งที่เขายังคงพยายามหลีกเลี่ยง
เขายังไม่ยอมเรียน Godot และ GDScript อย่างจริงจัง
State Machine ที่มีเพียงป้ายชื่อ
ต่อมา Player Script เริ่มมีขนาดใหญ่และซับซ้อนขึ้น AI จึงเสนอให้ปรับระบบเป็น Finite State Machine เพื่อแยกสถานะของตัวละคร เช่น ยืน วิ่ง กระโดด ปีนบันได และโจมตี
หลังจากแก้อยู่นาน ระบบก็ดูเหมือนจะใช้งานได้
เขาเริ่มคิดว่า Workflow ใหม่ของตัวเองประสบความสำเร็จแล้ว
แต่ก่อนเดินหน้าต่อ เขาลองให้ AI อีกตัวตรวจสอบโครงสร้างทั้งหมดอย่างละเอียด
ผลที่พบคือ State Machine ที่สร้างขึ้นไม่ได้แยกการทำงานออกมาจริง ๆ
มันมีเพียงตัวแปรไว้บอกว่าตัวละครกำลังอยู่ในสถานะอะไร ส่วน Logic เกือบทั้งหมดก็ยังกองอยู่ใน Player Script เหมือนเดิม
ภายนอกดูเหมือนมี Architecture ใหม่ แต่ภายในแทบไม่มีอะไรเปลี่ยน
เหมือนเรียกช่างมาซ่อมเสาบ้าน แล้วช่างเพียงนำป้ายคำว่า “เสาใหม่” ไปติดไว้บนเสาต้นเดิม
ยิ่งให้ AI แก้ เกมก็ยิ่งพัง
เมื่อเขาพยายามให้ AI แก้ State Machine ให้ถูกต้อง โค้ดกลับเสียหายหนักกว่าเดิม
เขาเปลี่ยนไปใช้ AI อีกตัว แต่ก็ยังพบปัญหาคล้ายกัน
แก้ระบบหนึ่ง แล้วอีกระบบพัง
ย้ายโค้ดแล้วลืมเชื่อมกลับ
เขียนข้อกำหนดไว้ชัดเจน แต่ AI ก็ยังทำไม่ครบตามที่สั่ง
ปัญหาสำคัญคือ AI มองเห็นโค้ดได้เพียงบางส่วน
มันอาจเข้าใจไฟล์สองหรือสามไฟล์ที่กำลังแก้อยู่ แต่ไม่เข้าใจความสัมพันธ์ทั้งหมดของโปรเจกต์เหมือนนักพัฒนาที่รู้จักระบบทั้งเกม
เมื่อโปรเจกต์ใหญ่ขึ้น การแก้ไฟล์เดียวอาจกระทบระบบอื่นอีกหลายส่วน
AI อาจไม่รู้ด้วยซ้ำว่าสิ่งที่กำลังแก้ ทำให้ระบบไหนพังไปบ้าง
และเจ้าของโปรเจกต์ก็ไม่รู้เช่นกัน เพราะเขาไม่เข้าใจโค้ดที่ AI เขียนให้อย่างแท้จริง
เกมไม่ได้พังทันที แต่มันค่อย ๆ พังอยู่ข้างใน
นี่คือส่วนที่น่าสนใจที่สุดของเรื่อง
ในช่วงแรก เกมยังเปิดได้ ตัวละครเดินได้ กระโดดได้ ปีนบันไดได้ และบันทึกเกมได้ ทุกอย่างจึงดูเหมือนกำลังไปได้สวย
แต่ภายใน Codebase เริ่มสะสมโค้ดซ้ำ ทางลัด ระบบที่เชื่อมต่อกันผิด และโครงสร้างที่ขยายต่อได้ยาก
ปัญหาเหล่านี้ไม่ได้แสดงตัวออกมาทันที
มันจะรอจนถึงวันที่เราต้องเพิ่มระบบใหม่ หรือปรับโครงสร้างครั้งใหญ่ แล้วทุกอย่างก็เริ่มพังพร้อมกัน
สิ่งที่น่ากลัวจึงไม่ใช่ AI เขียนโค้ดผิดแบบที่เห็นได้ชัด
แต่คือ AI เขียนโค้ดที่ดูเหมือนถูก และทำงานได้ดีพอที่จะทำให้เราเชื่อว่าโปรเจกต์ยังปกติ
สุดท้ายเขาต้องกลับมาเรียนสิ่งที่พยายามหลีกเลี่ยง
หลังจากใช้เวลาประมาณ 40 ชั่วโมงตลอดหลายเดือน เขายอมรับว่า หากต้องการทำเกมนี้ต่อให้สำเร็จ เขาจำเป็นต้องเรียน Godot และ GDScript ให้เข้าใจ
เขาต้องอ่านโค้ดเป็น
ต้องเข้าใจ Architecture
ต้องรู้ว่า State Machine ควรทำงานอย่างไร
และต้องตรวจสอบได้ว่า AI กำลังสร้างระบบที่ถูกต้องจริงหรือไม่
ทั้งหมดนี้คือสิ่งที่เขาพยายามใช้ AI เพื่อหลีกเลี่ยงมาตั้งแต่ต้น
สุดท้ายเขาจึงตัดสินใจยุติโปรเจกต์
ไม่ใช่เพราะ AI ไม่มีประโยชน์ แต่เพราะเขาพบว่า AI พาเราไปถึง Prototype ได้เร็วมาก ทว่ายังไม่สามารถทดแทนความรู้ของคนที่ต้องดูแลโปรเจกต์ทั้งระบบได้
ความคิดเห็นที่น่าสนใจจากคนทำเกม
หลังจากเรื่องนี้ถูกเผยแพร่ออกมา มีคนเข้ามาแสดงความคิดเห็นหลายมุม
“40 ชั่วโมงยังน้อยเกินไป”
หลายคนมองว่า 40 ชั่วโมงถือว่าน้อยมากสำหรับเกมแนว Metroidvania
เกมประเภทนี้อาจใช้เวลาหลายพันชั่วโมง แม้แต่ทีมที่มีประสบการณ์ก็ยังต้องทำกันหลายเดือนหรือหลายปี บางคนใช้เวลา 40 ชั่วโมงกับระบบ UI หรือระบบย่อยเพียงระบบเดียว
แต่อีกฝ่ายก็แย้งว่า เจ้าของเรื่องไม่ได้คาดหวังว่าจะสร้างเกมเสร็จใน 40 ชั่วโมง
สิ่งที่เขาพบคือ หลังจากผ่านช่วง Prototype ไปแล้ว วิธีปล่อยให้ AI รับผิดชอบโค้ดทั้งหมดเริ่มพาโปรเจกต์เดินหน้าต่อไม่ได้
“AI เหมือนโปรแกรมเมอร์ Junior ที่ทำงานเร็วมาก”
มีคนเปรียบ AI เหมือนโปรแกรมเมอร์มือใหม่ที่อ่านเอกสารเก่ง ทำงานเร็ว และสามารถสร้างของออกมาได้ไว
แต่ยังไม่มีประสบการณ์พอจะออกแบบระบบขนาดใหญ่ด้วยตัวเอง
หากไม่มี Senior คอยวาง Architecture ตรวจโค้ด และหยุดมันเมื่อเริ่มใช้ทางลัด สุดท้ายโค้ดอาจกลายเป็นของที่ไม่มีใครกล้าแตะ
AI จึงไม่ได้ไร้ประโยชน์ เพียงแต่มันยังต้องมีคนที่รู้เรื่องมากพอคอยควบคุม
“คนที่ใช้ AI สำเร็จ มักมีพื้นฐานอยู่แล้ว”
นักพัฒนาที่ใช้ AI ทำงานได้ผลเล่าว่า พวกเขาไม่ได้ปล่อยให้ AI ทำทุกอย่างเอง
พวกเขาแบ่งงานออกเป็นชิ้นเล็ก เขียนข้อกำหนดให้ชัด ตรวจโค้ด ใช้ระบบทดสอบ และลงมือแก้เองเมื่อ AI เริ่มหลงทาง
จุดสำคัญคือ พวกเขารู้ว่าโค้ดที่ดีควรมีหน้าตาอย่างไร จึงมองออกว่า AI กำลังทำถูก หรือเพียงสร้างบางอย่างที่ดูเหมือนถูกต้อง
AI ช่วยให้คนมีพื้นฐานทำงานเร็วขึ้นได้มาก แต่ยังไม่สามารถมอบพื้นฐานนั้นให้เราโดยอัตโนมัติ
“เขาใช้เวลาสร้างระบบ AI มากกว่าสร้างเกม”
อีกมุมหนึ่งมองว่า เวลาที่เขาใช้ศึกษา MCP, Agent, Context และ Pipeline อาจนำไปเรียนพื้นฐาน Godot และ GDScript ได้มากพอสมควรแล้ว
เขาเหมือนคนที่เรียนวิธีบริหารทีมช่างหลายสิบคน แต่ยังไม่เคยเรียนว่าบ้านหนึ่งหลังควรสร้างอย่างไร
“ไม่มีโค้ดฟรี”
อีกความคิดเห็นหนึ่งสรุปไว้ได้น่าสนใจว่า ไม่มีโค้ดใดได้มาฟรีจริง ๆ
แม้ AI จะสร้างโค้ดให้เราได้ภายในไม่กี่วินาที แต่เรายังต้องจ่ายต้นทุนในอนาคตด้วยการแก้ Bug เพิ่มระบบ ปรับ Performance และดูแลมันไปตลอดอายุของโปรเจกต์
ยิ่งเราไม่เข้าใจโค้ด ต้นทุนในการดูแลก็ยิ่งสูง
โค้ดที่ได้มาเร็วที่สุด อาจกลายเป็นโค้ดที่เสียเวลาแก้นานที่สุดในภายหลัง
เรื่องนี้กำลังบอกอะไรเรา?
เรื่องนี้ไม่ได้พิสูจน์ว่า AI ใช้สร้างเกมไม่ได้ และไม่ได้หมายความว่าทุกคนจะล้มเหลวเหมือนกัน
เจ้าของเรื่องไม่มีพื้นฐานใน Engine ที่เลือก ใช้เวลาทดลองไม่มากนัก และเริ่มจากเกมที่มีความซับซ้อนสูง
แต่สิ่งที่เรื่องนี้แสดงให้เห็นชัดคือ AI ทำให้ช่วงเริ่มต้นง่ายและเร็วมาก จนเรารู้สึกว่าสามารถข้ามพื้นฐานทั้งหมดไปได้
ปัญหาจะเริ่มขึ้นเมื่อ Prototype ต้องกลายเป็นเกมจริง
เมื่อระบบมีจำนวนมากขึ้น
เมื่อไฟล์เริ่มเชื่อมโยงกัน
เมื่อเพิ่มฟีเจอร์หนึ่งแล้วกระทบอีกหลายฟีเจอร์
และเมื่อโค้ดต้องถูกดูแลต่อไปอีกหลายเดือนหรือหลายปี
AI อาจช่วยให้เราเดินทางไปถึง 80% แรกได้รวดเร็ว
แต่ 20% สุดท้ายอาจเต็มไปด้วย Bug, Architecture, Performance, Edge Case และหนี้ทางเทคนิคที่สะสมมาตั้งแต่วันแรก
ถ้าเราไม่เข้าใจสิ่งที่ AI สร้างขึ้น เราอาจไม่รู้เลยว่าเกมกำลังพัง
จนกระทั่งวันที่ทุกอย่างพังพร้อมกัน
บทเรียนจากเรื่องนี้จึงไม่ใช่
“อย่าใช้ AI ทำเกม”
แต่คือ
อย่าใช้ AI เพื่อหลีกหนีการเรียนรู้สิ่งที่จำเป็นต่อการสร้างเกม
เราสามารถใช้ AI ช่วยสร้าง Prototype ช่วยอธิบายโค้ด ช่วยค้นหา Bug หรือช่วยทำงานซ้ำ ๆ ได้
แต่คนสร้างเกมยังต้องเข้าใจ Engine, Programming Logic และ Architecture ของโปรเจกต์ตัวเอง
เพราะ AI สามารถเสนอคำตอบให้เราได้เป็นสิบแบบ
แต่คนที่ต้องรู้ว่าคำตอบไหนถูก และรับผิดชอบเมื่อเกมพัง ยังคงเป็นเราอยู่ดี
ที่มา