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

กำหนดขอบเขตโปรเจกต์ก่อนแก้ไข

เริ่มจากไดเรกทอรีโปรเจกต์ที่เป็นของคุณและรายการการเปลี่ยนที่อนุญาตเป็นลายลักษณ์อักษร ตรวจ inventory ของ scene, script, asset และ plugin ที่มีอยู่ เพื่อให้เอเจนต์ต่อยอดโครงสร้างเดิมแทนการสร้าง implementation ที่สอง เก็บสถานะเริ่มต้นให้กู้คืนได้และบันทึกว่า engine binary ใดเปิดโปรเจกต์

เลือกส่วนที่เล่นได้ขนาดพอเหมาะพร้อม transition ชัดเจน ตัวอย่างเช่น title screen ไปยังห้องเดียวและกลับผ่าน win หรือ loss จะให้ test ที่ทำซ้ำได้ ตัดสินใจว่าใครจะรีวิว visual composition และ controls เพราะ parser ที่สำเร็จหรือ completion message ของโมเดลไม่ได้พิสูจน์ว่า experience สอดคล้อง

ระบุ executable และ arguments ที่รองรับ

เอกสาร stable CLI ของ Godot มีคำสั่งด้านล่าง GODOT_BIN และ PROJECT เป็น shell variables ที่เลือกสำหรับตัวอย่างนี้ ไม่ใช่ settings ของ Godot ให้แทนที่ path placeholder ด้วย executable และโปรเจกต์ที่มีอยู่ พาธโปรเจกต์ต้องมี project.godot

เก็บ version และ help output ก่อนเขียน script flag เพิ่ม วิธีนี้ป้องกันการคิดว่าคำสั่งในเอกสารออนไลน์ปัจจุบันมีอยู่ใน build ที่ติดตั้ง จด identity ของ binary คู่กับผล test ภายหลังและคงไว้ระหว่างตรวจ failure คำสั่งตัวอย่างใช้รูปแบบ CLI ตามเอกสาร

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

แยก import, parsing และการเล่นจริง

headless import ตรวจขอบเขตการประมวลผล asset parser check ตรวจ script การ launch ปกติไปถึงตัวเกมและอาจเผยปัญหาการต่อ scene กับ runtime แยกผลลัพธ์เหล่านี้ในบันทึก review แทนการสรุปทั้งสามว่า tests passed

พาธ script ตัวอย่างด้านล่างต้องมีอยู่ในโปรเจกต์อยู่แล้ว parser check เป็นการตรวจที่แคบโดยตั้งใจ ไม่สามารถพิสูจน์ collision ที่ทำงาน input ที่ตอบสนอง หรือ persistence ที่ถูกต้อง หลังแก้ให้เล่นพฤติกรรมที่เปลี่ยนและ transition ก่อนหน้าและถัดไป การทำเช่นนี้มักให้ข้อมูลมากกว่าการสร้าง checks โดดเดี่ยวจำนวนมากสำหรับ helper functions ที่สร้างขึ้น

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

เลือกใช้ CLI tools หรือ MCP อย่างมีเจตนา

เอเจนต์ที่ใช้ shell ได้สามารถรันลำดับ CLI ที่รีวิวแล้ว Godot MCP เป็น tool interface เพิ่มเติมที่โปรเจกต์ดูแล โดยมีหน้าเฉพาะสำหรับ setup ไม่ว่ากรณีใด ผู้ปฏิบัติงานต้องรู้ว่าโปรเจกต์ใดเป็น target ก่อนอนุมัติ write หรือ launch process

แยก settings ของ model provider ในเอเจนต์ออกจากเครื่องมือเอนจิน การเชื่อมต่อ local ที่ทำงานไม่ได้พิสูจน์ว่าโมเดลหนึ่งใช้ได้ หรือเอเจนต์รองรับทุกฟีเจอร์ของ gateway ที่เข้ากันได้ เริ่มจาก read ที่อนุญาตและเล็กที่สุด ต่อด้วย scene change ที่ย้อนกลับได้ และจึงค่อยรัน gameplay cycle เต็มใน experiment ที่ได้รับอนุญาต

ให้บริบท scene แก่ failure อย่างเพียงพอ

เมื่อ interaction ล้มเหลว ให้เก็บ scene tree, script, input action และ runtime error แรกที่มีความหมาย อธิบาย transition ที่คาดหวังและ state ที่สังเกตได้ รายงานว่า player ขยับไม่ได้ควรบอกว่าเกมมี focus หรือไม่ ตรวจ input ได้หรือไม่ และตำแหน่ง player เปลี่ยนหรือไม่

ขอ correction ขนาดเล็กพร้อมคำอธิบายที่ผูกกับหลักฐานนั้น หลังใช้ให้ทำ action เดิมซ้ำและตรวจ regression ใน restart กับ scene transitions อย่ารับการซ่อมเพียงเพราะ error หาย การปิดฟีเจอร์ที่มีปัญหาอาจลบ error แต่ยังไม่ทำตาม requirement เดิม

เตรียมข้อกำหนด export อย่างชัดเจน

การ export ต้องมี preset ที่ตรงกันและ export templates ที่ติดตั้งแล้ว ตรวจ export_presets.cfg และการรวม resource ก่อน build เก็บ export credentials เป็นความลับ ชื่อ preset ในตัวอย่างเป็นเพียงตัวอย่างและต้องตรงกับโปรเจกต์ ไดเรกทอรี output ต้องมีอยู่แล้ว

มอง template หรือ preset ที่หายเป็นปัญหา environment ไม่ใช่หลักฐานว่า game logic ที่สร้างผิด เก็บ export logs และ artifact hash เพื่อให้ผลบน target อ้างถึง build เฉพาะ การ export สำเร็จเป็น checkpoint สำคัญ แต่ไม่ได้พิสูจน์ว่า player ที่ส่งมอบจะ start หรือจบรอบ

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

รัน delivery miniflow บน target

เปิดเกมที่ export แล้วบน OS ที่ตั้งใจรองรับ ทดสอบ start, input, รอบที่สมบูรณ์, restart, settings และ persistence หลัง relaunch สำหรับแต่ละผลลัพธ์ให้เก็บ artifact identity, device context และผลที่สังเกตได้ export ที่สร้างบน macOS ไม่ได้ยืนยันพฤติกรรมบน Windows

สำหรับ web target ให้ตรวจ browser loading และ runtime errors และใช้ input จริงกับ canvas ยืนยันว่า content แสดงและเคลื่อนที่เมื่อควรเป็น ทดสอบ hosting configuration ที่ตั้งใจ แทนการคิดว่า editor run ในเครื่องครอบคลุมการโหลด resource ของ browser และข้อจำกัดแพลตฟอร์ม

ตรวจสอบ source project และ native capture

ตัวอย่าง Switchyard ภายในเครื่องมี puzzle Godot 3 ห้อง gameplay checks อัตโนมัติ save-reopen checks raw logs source ZIP และ Godot PCK native captures แสดงโปรเจกต์ที่กำลังทำงานจริงใน viewport สองขนาด การทำคำสั่งตามเอกสารซ้ำเป็นการตรวจที่แข็งแรงกว่าการตัดสินจาก screenshot อย่างเดียว

โปรเจกต์ใช้ Godot 4.5.1 ใน Codex run ที่ไม่ได้ยืนยัน generation model ที่แน่นอน จึงแสดง local engine workflow ไม่ใช่ Astra benchmark browser export ถูก block เพราะ export templates หาย และ PCK ไม่ใช่ standalone Windows executable ขอบเขตเหล่านี้บันทึกคู่กับ source เพื่อให้ developer ถัดไปรู้ว่ายังต้องทดสอบอะไร

ปิดลูปด้วย handoff ที่รีวิวได้

handoff ควรระบุขอบเขตที่เล่นได้ source identity เวอร์ชันเอนจินและ template คำสั่ง build ผลที่ยอมรับแล้ว และ defect ที่ยังไม่แก้ รวม capture จริงจาก artifact ที่ทดสอบและ provenance ของ asset ที่ส่งมอบ เก็บความพยายามซ่อมและ manual interventions แทนการแสดงเพียง code dump สุดท้าย

เมื่อ basic loop ผ่านแล้ว ให้เพิ่ม asset และ localization ผ่าน import และ gameplay checks ของตัวเองก่อนพิจารณาส่งแพลตฟอร์ม walkthrough นี้อิงเอกสารเอนจิน ให้ใช้กับ version ที่ติดตั้งและเก็บผลจริง เก็บรายการ unresolved issues สั้นๆ พร้อม reproduction steps เพื่อให้ development session ถัดไปเริ่มจาก state ที่ทราบแน่

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