ผมถามลูกว่าอยากเล่นเกมที่พ่อสร้างเองไหม

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

ลูกสองคนมองงานของผมคนละแบบ

คนโตมาดู ถาม แล้วหยิบ Concept ที่เห็นไปลองใช้ ส่วนคนเล็กเพิ่งอยู่ ป.2 เห็นผมนั่งทำอะไรก็ถามโน่นถามนี่ตามประสาเด็ก ผมอยากเติมเต็มความฝันเรื่องการสร้างเกมอยู่แล้ว จึงถามเขาเล่น ๆ ว่า “อยากเล่นเกมที่พ่อสร้างขึ้นเองไหม?” พอถามจบผมก็ตอบตัวเองในใจว่า “เราได้อีกหนึ่ง Project แล้วสิ”

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

เราช่วยกันคิดว่าเกมนี้จะเล่นกันอย่างไร

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

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

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

ก่อนเริ่มทำเกม ผมวางโครงเอกสารของ Project ก่อน

ในชุดแรก ผมแยกเรื่องที่ต้องคิดออกเป็นเอกสารคนละด้าน: ความจริงและภาพฝันของเกม, ขอบเขตของรุ่นแรก, วงจรการเล่น, หน้าจอและอุปกรณ์เป้าหมาย, การควบคุมด้วยการเคลื่อนไหว, เนื้อหาและความก้าวหน้าของผู้เล่น, ทิศทางเทคนิค, ความเป็นส่วนตัว และเกณฑ์รับงาน เอกสารยังบอกด้วยว่าเกมจะเริ่มบนแท็บเล็ต ใช้กล้องเป็นอินพุตหลัก และมี Touch เป็นทางสำรอง ผมแยกสิ่งที่ตัดสินใจแล้วออกจากคำถามที่ยังเปิดไว้ เพื่อให้ AI เห็นทั้งทิศทางที่เราตกลงกันและส่วนที่ยังต้องคิดต่อ

จากนั้นผมจัดเอกสารใหม่ให้เห็นหน้าที่ของมันชัดขึ้น docs/current เป็นที่รวมข้อเท็จจริงและแนวทางที่ยอมรับเป็นฐานของเกม ส่วน docs/releases เป็นพื้นที่ของงานที่กำลังจะทำ มี README เป็นทางนำทางและ Roadmap บอกลำดับภาพใหญ่: เริ่มจากพิสูจน์การควบคุมบนแท็บเล็ตก่อน แล้วค่อยไปสู่เกมที่เล่นได้ เติมเนื้อหาและความก้าวหน้า ก่อนเก็บงานภาพ

ภายในงานช่วงแรก ผมไม่ปล่อยให้โจทย์กว้าง ๆ ว่า “ทำเกม” แต่แตกมันลงไปอีกชั้น: Release มีแผน Sprint; Sprint มีหน้า README กับ Plan; แล้วงานทดลองชิ้นแรกมี README, Plan, Developer Packet และ Result ของตัวเอง README ช่วยบอกว่าควรเริ่มอ่านตรงไหน, Plan กำหนดเป้าหมายกับสิ่งส่งมอบ, Packet บอกรายละเอียดและข้อห้ามให้ AI ทำตาม ส่วน Result เตรียมไว้บันทึกสิ่งที่ตรวจพบเมื่อทำงานแล้ว แผนกับผลจึงไม่ถูกเขียนทับกัน

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

เอกสารส่งต่องานระบุขอบเขตกับวิธีตรวจไว้ก่อน ส่วน Result ตอนนั้นบอกว่า Developer Packet พร้อม แต่การลงมือทำยัง pending อยู่ ไม่นานหลังจากจัดเอกสาร ผมกับ AI ก็เริ่มทำ Motion Spike เล็ก ๆ เพื่อทดลองโจทย์นี้ ตัวเกมที่ลูกจะเล่นยังต้องรอการพัฒนาขั้นต่อไป

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

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

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