ตอนเริ่มทำเกมด้วย Claude Code เราอาจคุยเรื่องระบบต่อสู้ตอนเช้า แก้ shader ตอนบ่าย แล้วปิดวันด้วยการเพิ่ม UI ทุกอย่างเกิดขึ้นเร็ว แต่เมื่อโปรเจกต์โต คำถามที่ยากขึ้นกลับไม่ใช่ “AI เขียนโค้ดนี้ได้ไหม”

ใครกำลังเฝ้าว่าระบบต่อสู้ยังตรงกับทิศทางของเกม? การเปลี่ยนข้อมูลหนึ่งชุดกระทบ UI หรือระบบเซฟตรงไหน? งานไหนต้องผ่าน QA ก่อน merge? และข้อตกลงจากเมื่อวานถูกเก็บไว้ที่ใด?

Claude Code Game Studios ของ Donchitos พยายามตอบคำถามเหล่านี้ด้วยการเพิ่ม โครงสร้างการทำงานแบบสตูดิโอ ให้โปรเจกต์ Claude Code ภายในมี agents หรือบทบาท AI เฉพาะทาง 49 ตัว, skills สำหรับเวิร์กโฟลว์ 73 รายการ, hooks 12 ตัว, rules ตามตำแหน่งไฟล์ 11 ชุด และเทมเพลตเอกสาร 41 แบบ

ชื่อ “Game Studios” อาจทำให้นึกถึง AI จำนวนมากที่สร้างเกมแทนเรา แต่ระบบนี้ตั้งใจทำตรงกันข้าม: แยกให้ชัดว่าเอเจนต์ใดรับผิดชอบเรื่องไหน ผลงานต้องส่งให้ใครตรวจ และจุดใดต้องรอผู้ใช้เลือกหรืออนุมัติ

สิ่งที่เพิ่มไม่ใช่สมองอีก 49 ก้อน แต่คือผังความรับผิดชอบ

เอเจนต์ 49 ตัวถูกแบ่งเป็นสามระดับคล้ายสายงานในสตูดิโอจริง

• Directors ได้แก่ creative-director, technical-director และ producer ทำหน้าที่ดูทิศทางภาพรวม
• Department leads รับผิดชอบโดเมน เช่น game design, programming, art, audio, narrative, QA, release และ localization
• Specialists ลงมือในงานเฉพาะตั้งแต่ gameplay, engine และ UI ไปจนถึง performance, accessibility และ live ops

ยังมีชุดผู้เชี่ยวชาญสำหรับ Godot 4, Unity และ Unreal Engine 5 แยกตามเทคโนโลยีของแต่ละเอนจินด้วย

ประโยชน์ของผังนี้ไม่ใช่จำนวนชื่อ แต่คือการรู้ว่า คำถามหนึ่งควรไปหาใคร และเมื่อสองฝ่ายเห็นไม่ตรงกันต้องส่งขึ้นไปที่ใด director มอบหมายงานต่อให้ lead และ specialist ส่วนคนระดับเดียวกันปรึกษากันได้ แต่ไม่มีสิทธิ์ตัดสินใจแทนอีกโดเมน เมื่อเกิดข้อขัดแย้ง ระบบกำหนดให้ยกระดับไปหา director ที่ดูแลเรื่องนั้น

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

สี่ชั้นที่ทำให้รายชื่อเอเจนต์กลายเป็นระบบ

หากดูเฉพาะ 49 agents เราจะพลาดส่วนสำคัญ เพราะ repository นี้ยังมีอีกสามส่วนที่คอยกำหนดขั้นตอน ตรวจงาน และเก็บผลลัพธ์ไว้ใช้ต่อ

1. Agents แยกมุมมองและเจ้าของงาน

แต่ละ agent มีหน้าที่ ขอบเขต วิธีขอคำตัดสินเมื่อมีข้อขัดแย้ง และจุดตรวจของตัวเอง Director ดูภาพรวม Lead ดูมาตรฐานของโดเมน ส่วน Specialist ลงรายละเอียดในงาน การแยกบทบาททำให้คนวางทิศทาง คนลงมือ และคนตรวจไม่ถูกปนเป็นหน้าที่เดียวกันทั้งหมด

2. Skills กำหนดทางเดินของงาน

skills 73 รายการคือคำสั่งที่ผู้ใช้เรียกด้วย / ใน Claude Code ครอบคลุมเส้นทางตั้งแต่ตั้งต้นจนเปิดตัว ตัวอย่างกลุ่มงานที่ README ระบุไว้มี:

• เริ่มและสำรวจสถานะด้วย /start, /brainstorm, /project-stage-detect
• วางแบบเกม งานศิลป์ UX และสถาปัตยกรรม
• แตกงานเป็น epic, story และ sprint
• พัฒนา รีวิว ทดสอบ และตรวจความพร้อมของงาน
• เตรียม release, launch, patch และ hotfix

นอกจากนี้ยังมีคำสั่ง team-* สำหรับประสานหลายบทบาทในฟีเจอร์เดียว คำสั่งเหล่านี้ทำให้ลำดับการเรียกเอเจนต์เป็นส่วนหนึ่งของเวิร์กโฟลว์ แทนที่จะให้ผู้ใช้นึกใหม่ทุกครั้ง

3. Hooks และ rules ดักสิ่งที่ไม่ควรขึ้นกับความจำ

hooks ทำงานตามเหตุการณ์ เช่น ก่อน commit หรือ push, หลังแก้ asset, ตอนเปิดหรือปิด session, ก่อนและหลัง compact รวมถึงตอนเริ่มหรือจบ subagent

rules อีก 11 ชุดเลือกใช้ตามตำแหน่งไฟล์ โค้ดใต้ src/gameplay/** จึงเจอกติกาเรื่องค่าที่ขับด้วยข้อมูลและการใช้ delta time ขณะที่ src/networking/** เน้น server-authoritative, version ของ message และ security ส่วน src/ui/** ต้องไม่เป็นเจ้าของ game state และต้องเตรียมพร้อมสำหรับ localization กับ accessibility

สองชั้นนี้ทำงานต่างกันชัดเจน: skill บอกว่าควรทำขั้นใดต่อ ส่วน hook และ rule ตรวจเงื่อนไขเดิมให้ทุกครั้งโดยไม่ต้องหวังว่าคนทำจะจำได้

4. Templates และโครงโฟลเดอร์เก็บผลของการตัดสินใจ

เทมเพลต 41 แบบรองรับเอกสารอย่าง GDD, UX spec, ADR, sprint plan, HUD design และ accessibility ขณะที่โครงโปรเจกต์แยก src/, assets/, design/, tests/, prototypes/ และ production/ ออกจากกัน

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

ระบบประสานงาน แต่ไม่ใช่ autopilot

จุดที่ควรอ่านให้ชัดก่อนติดตั้งคือโปรโตคอลการร่วมงานของเอเจนต์ ผู้สร้างกำหนดลำดับไว้ว่า:

1. Ask — ถามก่อนเมื่อข้อมูลยังไม่พอ
2. Present options — เสนอ 2–4 ทางเลือกพร้อมข้อดีข้อเสีย
3. You decide — ผู้ใช้เป็นคนเลือก
4. Draft — แสดงร่างก่อนทำให้เป็นผลลัพธ์สุดท้าย
5. Approve — ไม่เขียนไฟล์จนกว่าจะได้รับอนุมัติ

ดังนั้นคำว่า “full game development studio” หมายถึงมีโครงสร้างหลายบทบาทและหลายช่วงงาน ไม่ได้หมายถึงปล่อยให้ AI เดินจากไอเดียไปถึงเกมเสร็จเอง

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

โปรเจกต์แบบไหนน่าจะได้ประโยชน์

Claude Code Game Studios น่าพิจารณาเมื่อเกมเริ่มมีหลายโดเมนที่ต้องส่งงานถึงกัน เช่น gameplay แตะ animation, UI, audio และ QA หรือเมื่อทีมพบอาการเหล่านี้ซ้ำ ๆ:

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

ในทางกลับกัน prototype อายุหนึ่งวันซึ่งกำลังพิสูจน์กลไกเดียวอาจไม่ต้องการ director, เอกสาร และจุดตรวจทุกชั้น การเรียกทุกบทบาทเพียงเพราะมีให้ใช้จะเปลี่ยนโครงสร้างที่ช่วยงานให้กลายเป็นพิธีการ

repository เตรียมระดับการรีวิวไว้สามแบบคือ full, lean และ solo ผู้ใช้เลือกได้ระหว่าง /start หรือแก้ production/review-mode.txt และ override รายคำสั่งด้วย --review solo ได้ จึงไม่จำเป็นต้องใช้ความเข้มเท่ากันกับทุกช่วงของโปรเจกต์

วิธีคิดที่ใช้ง่ายคือ เริ่มจากปัญหาที่เกิดจริง ไม่ใช่เริ่มจากจำนวนสิ่งที่ติดตั้งมา ถ้าเกมยังอยู่ในช่วงหาแกนสนุก ให้ใช้ /brainstorm และพื้นที่ prototype ก่อน หากแบบเริ่มนิ่งแต่โค้ดกระจาย ค่อยเพิ่มขั้นออกแบบ สถาปัตยกรรม และการรีวิวเฉพาะจุดที่ทีมพลาดบ่อย

ลองให้เห็นหนึ่งรอบก่อนปรับทั้งทีม

ข้อกำหนดพื้นฐานมี Git และ Claude Code ส่วน jq กับ Python 3 เป็นเครื่องมือแนะนำสำหรับ validation หากไม่มี ระบบจะข้ามการตรวจส่วนนั้นและทำงานต่อแทนที่จะทำให้โปรเจกต์หยุด

เริ่มจาก clone repository หรือกดใช้เป็น GitHub template:

git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
cd my-game
claude

จากนั้นเรียก:

/start

คำสั่งนี้ไม่ได้สมมติว่าเรากำลังเริ่มเกมใหม่ แต่จะถามก่อนว่าสถานะปัจจุบันคือยังไม่มีไอเดีย มีแนวคิดคร่าว ๆ มีแบบชัดแล้ว หรือมีโปรเจกต์เดิมอยู่ หากรู้แล้วว่าต้องเริ่มจากขั้นไหน เราข้ามไป /setup-engine godot 4.6, /project-stage-detect หรือ /brainstorm ได้ทันที

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

• คำถามก่อนลงมือช่วยให้ขอบเขตชัดขึ้นหรือเพียงทำให้ช้า
• ผลลัพธ์ของขั้นหนึ่งถูกเก็บในที่ที่ขั้นถัดไปใช้ต่อได้หรือไม่
• rule และ hook ดักข้อผิดพลาดที่ทีมเคยพลาดจริงหรือสร้างเสียงเตือนเกินจำเป็น
• ระดับ full, lean หรือ solo แบบใดพอดีกับความเสี่ยงของงาน

เมื่อได้คำตอบจึงค่อยลบ agent ที่ไม่ใช้ ปรับ prompt ให้ตรงโดเมน เพิ่ม rule ของทีม หรือปรับ hook ให้เข้มเฉพาะจุด repository นี้สร้างมาเป็น template ที่แก้ได้ ไม่ใช่ framework ที่ห้ามแตะ

ขอบเขตที่ควรรู้ก่อนฝาก workflow ไว้กับมัน

ข้อมูลที่เปิดเผยใน README อธิบายองค์ประกอบและเจตนาได้ละเอียด แต่ยังไม่ใช่หลักฐานว่าโครงสร้างนี้ทำให้ทุกทีมพัฒนาเกมเร็วขึ้น ลดบั๊ก หรือคุ้มค่า token กว่าวิธีอื่น เราจึงควรประเมินจากรอบทดลองของโปรเจกต์ตัวเอง ไม่ใช่จากตัวเลข agents และ skills เพียงอย่างเดียว

ด้านแพลตฟอร์ม ผู้สร้างระบุว่าพัฒนาและทดสอบหลักบน Windows 10 กับ Git Bash ตัว hooks ใช้รูปแบบที่เข้ากับ POSIX และมี fallback สำหรับ macOS/Linux แต่การทดสอบข้ามแพลตฟอร์มยังดำเนินอยู่ อีกทั้ง desktop notification บน macOS/Linux ยังไม่ได้ต่อใช้งาน หากทีมอยู่บนสองระบบนี้ ควรลอง hooks ที่พึ่งพาจริงก่อนนำไปใช้ทั้งโปรเจกต์

ตัวระบบยังตั้ง permission rules ให้ผ่านคำสั่งปลอดภัยอย่าง git status หรือการรันทดสอบ และบล็อกการกระทำเสี่ยง เช่น force push, rm -rf และการอ่านไฟล์ .env แต่คำว่า “บล็อก” ไม่ควรถูกตีความเป็นหลักประกันความปลอดภัยทั้งหมด กติกาเหล่านี้เป็น guardrail ของเวิร์กโฟลว์ ไม่ได้แทนการแยก secret, จำกัดสิทธิ์เครื่องมือ และตรวจโค้ดตามปกติ

สตูดิโอที่มีค่าคือสตูดิโอที่เราปรับให้พอดี

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

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

ที่มา: Claude Code Game Studios โดย Donchitos บน GitHub