การพัฒนาเกมด้วย AI

เริ่มด้วยลูปเกมขนาดเล็กที่สมบูรณ์

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

เลือกแพลตฟอร์มเป้าหมายหนึ่งแบบและอุปกรณ์อินพุตจำนวนน้อย ให้เลเวลเพิ่มเติม เครือข่าย และคอนเทนต์แบบ procedural เป็นขอบเขตภายหลัง วิธีนี้ทำให้วินิจฉัยต้นแบบที่ล้มเหลวได้ และแยกกฎ collision ที่เสียออกจากฟีเจอร์ที่ยังไม่เสร็จโดยไม่ต้องขยายพรอมป์ซ้ำๆ

เลือกเวิร์กโฟลว์ก่อน แล้วจึงเลือกเอนจิน

สำหรับโปรเจกต์ 2D ขนาดเล็กที่สร้างใหม่ ให้เริ่มประเมิน CLI ของ Godot ที่มีเอกสารรองรับสำหรับลูปตรวจสอบ-แก้ไข-รัน Unity เป็นจุดเริ่มที่ดีเมื่อโปรเจกต์หรือทีมพึ่งพาเวิร์กโฟลว์ใน editor อยู่แล้ว ความสามารถในการดูแลผลลัพธ์ควรมีน้ำหนักพอๆ กับต้นแบบแรก

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

แยกการเข้าถึงโมเดลออกจากเครื่องมือเอนจิน

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

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

ทำ brief แรกให้ทดสอบได้

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

บันทึก brief แรกโดยไม่แก้ไข เมื่อเพิ่มข้อกำหนดให้ระบุว่าเป็นการเปลี่ยนขอบเขต เมื่ออธิบายข้อผิดพลาดหรือแก้ไฟล์ด้วยตนเองให้ระบุว่าเป็น intervention วิธีนี้คงความแตกต่างระหว่างพรอมป์แรกกับการวนซ้ำของโมเดลและเครื่องมือที่ตามมา

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

ทำงานด้วยการเปลี่ยนแปลงที่รีวิวได้

หลังสร้างโครงเริ่มต้น ให้ขอทีละพฤติกรรม: การเคลื่อนที่ ตามด้วย collision แล้วจึงการเปลี่ยนสถานะจบรอบ ตรวจไฟล์ที่เปลี่ยนและรันเส้นทางยอมรับเดิมหลังแต่ละการเปลี่ยน เก็บสถานะโปรเจกต์ที่รู้ว่าทำงานก่อนเพิ่มแพ็กเกจภายนอกหรือเปลี่ยน import settings

เอเจนต์ควรได้รับ error ที่เกี่ยวข้อง บริบทของ scene และพฤติกรรมที่สังเกตได้ ไม่ใช่เพียงคำขอให้พยายามใหม่ เมื่ออาการเดิมยังอยู่หลังการแก้ซ้ำ ให้หยุดและแยกขอบเขต resource ที่ import ไม่ครบและ node reference ที่ผิดต้องแก้ต่างกัน แม้ทั้งคู่จะทำให้ scene ว่าง

ถือว่า asset และ localization เป็นอินพุตการผลิต

เก็บ asset manifest ที่มีแหล่งที่มา สิทธิ์ ตัวตนของผู้สร้างหรือเครื่องมือ การแก้ไข และการใช้งานที่ตั้งใจ ตรวจ sprite ที่ขนาดการเล่นจริง รวม transparency การจัดเฟรม contrast และความพอดีกับ collision รูปภาพที่ดูเหมาะไม่ได้แปลว่าเป็น sprite sheet ที่ใช้ได้ทันที

เก็บ string ที่ผู้เล่นเห็นให้เรียกด้วย identifier ที่เสถียร ให้บริบทการแปลและปกป้อง format arguments รูปภาพ เสียง ฟอนต์ และข้อความแปลต้องได้รับการรีวิวก่อนแจกจ่าย บันทึกค่าใช้จ่ายการสร้างภาพแยกจากงานเขียนโค้ดด้วย text model เพราะ license ของ asset หรือเอนจินไม่ได้ยืนยันสิทธิ์ของทุกไฟล์ในโปรเจกต์

พิสูจน์สถานะการส่งมอบแต่ละแบบแยกกัน

เดโมที่เล่นได้ต้องมีคนเล่นลูปที่ตั้งใจให้จบ การ export ต้องมี artifact ที่สร้างขึ้น การ export ที่ทดสอบแล้วต้องเปิด artifact บนแพลตฟอร์มเป้าหมายได้ การส่ง Steam และการวางจำหน่ายเป็นสถานะของแพลตฟอร์มที่เกิดภายหลัง ใช้คำเรียกเหล่านี้ให้ตรงเมื่อรายงานความคืบหน้า

เก็บตัวตน build อินพุตทดสอบ ภาพหน้าจอจากการเล่นจริง และ failure ที่ยังเหลือ capture จากเบราว์เซอร์ควรแสดง gameplay ที่เปลี่ยนหลังอินพุต ไม่ใช่แค่หน้ากำลังโหลด ไฟล์ Windows ที่ export จาก OS อื่นยังต้องตรวจบน Windows ดูข้อกำหนดบัญชีและตารางเวลาของ Steam จากคู่มือแยกต่างหาก

สิ่งที่ตัวอย่าง Playco แสดงเกี่ยวกับเวิร์กโฟลว์

เรื่องราวลูกค้าของ OpenAI วันที่ 3 กันยายน 2026 อธิบายว่า Playco ใช้ Astra ใน Playbot ซึ่งเป็น IDE ที่เชื่อมกับเอนจินเกม ทีมทำซ้ำบนพื้นฐาน grey-box ก่อนสร้างต้นแบบที่มีธีม นี่คือเรื่องราวจากผู้ขาย ไม่ใช่ benchmark ของ APIsRouter

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

ตรวจสอบต้นแบบ Godot ภายในเครื่อง

Switchyard เป็นปริศนาวงจรขนาดเล็ก 3 ห้องที่สร้างจากการรันพัฒนาด้วย Codex ภายในเครื่อง โปรเจกต์มีการเคลื่อนที่ของตัวละคร สวิตช์ ประตู cell ที่เก็บได้ การจบห้อง แพ้และเริ่มใหม่ settings และ progress ที่บันทึกไว้ การตรวจเอนจินอัตโนมัติทดสอบลูปเกม และอีก process เปิด save กลับได้ ภาพด้านล่างคือ capture จาก Godot viewport จริง ไม่ใช่ concept art

การรันที่บันทึกไว้ใช้ Godot 4.5.1 ไม่สามารถสังเกตตัวตนโมเดลและการคิดเงิน API จึงไม่นำเสนอเป็น benchmark ด้านประสิทธิภาพหรือต้นทุนของ Astra source และ PCK ที่ดาวน์โหลดได้แสดงโปรเจกต์ภายในเครื่อง โดย PCK ต้องใช้ Godot ส่วน Windows build แบบ standalone browser export human playtest และ Steam release เป็นงานคนละส่วน ตัวอย่างนี้ชี้ให้เห็น artifact ที่ควรขอจากเอเจนต์ก่อนอ้างว่ามีการส่งมอบ

เลือกคู่มือถัดไปตามคอขวด

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

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

คำถามที่พบบ่อย