เขียน Game Design Document ให้ดีได้อย่างไร?

เกริ่น

ความเดิมต่อจากตอนที่แล้ว ก่อนจะเขียน Game Design Document ตอบคำถามเหล่านี้ก่อน

อันนี้บอกก่อนว่าเป็นความคิดเห็นของผมที่ตรวจงานทั้งในสถานศึกษาและในการทำงานจริงมาหลายปี เห็นปัญหาในการเขียน Game Design Document (GDD) อยู่ จึงมาเล่าสู่กันฟัง

ปัญหาที่พบบ่อยในการเขียน GDD

• อ่านไม่รู้เรื่อง
  • เอกสารใดใดคือเครื่องมือสื่อสาร ผู้รับสารต้องรับสารได้เข้าใจ
  • ถ้าเขียนแล้วเค้าอ่านไม่รู้เรื่อง เขียนใหม่
• ยาวไป
  • น้ำท่วมทุ่ง ผักบุ้งโหรงเหรง คือมีแต่น้ำไม่มีเนื้อ เขียน GDD ไม่ใช่นิยาย ไม่ต้องพรรณนามาก เอาที่จำเป็น
    • บางคนร่ายยาวมากใจความสำคัญไม่มีเลย
  • รายละเอียดเยอะจนเกินไป นักออกแบบบางคนคิดเยอะ เขียนเยอะ เกินไป
    • บางทีเราอาจจะต้องปล่อยให้คนอื่นเอาไป คิด/ทำ ต่อบ้าง
    • ให้รายละเอียดพอเป็นแนวทางให้เพื่อนร่วมงานเอาไปทำต่อ
    • เรามีหน้าที่ guide ไม่ใช่จับมือเค้าทำงาน
• สั้นไป
  • คือไม่มีไอเดียเลยซะจนสั้นมากมาก
  • ไม่มีรายละเอียดเลย
  • เราต้องอธิบายว่า ไอเดียที่เราต้องการนั้น จะทำได้อย่างไร?
• ไม่มีไอเดียที่จับต้องได้ เอาไปใช้งานได้
  • ไม่มีไอเดียเช่น เขียนว่า “ส่วนนี้ต้องสนุก”
    • เหมือนเราออกแบบรถแล้วเราบอกว่า “รถคันนี้ต้องวิ่งได้” อ่ะครับ ไม่ต้องบอกก็ได้
    • มันต้องมีไอเดียที่จะนำไปทำงานต่อได้ หรือมีไอเดียที่ ทำให้เกมนี้มีจุดขาย
  • Design decision อยู่ที่ใด?
    • สิ่งที่อยากได้นั้น ต้องทำอะไรถึงจะได้มา?
    • นี่มันงานของนักออกแบบตรง ๆ เลยคือต้องคิดมาว่าต้องทำอะไร อย่างน้อยต้องมีแนวทางชัดเจน
  • ไอเดียย้อนแย้ง กันเอง เช่น
    • พบได้บ่อยถ้าไม่ได้มี Design Goal ที่ชัดเจน แบบส่วนนี้ไปทางส่วนนี้ไปอีกทาง
    • บางทีในออฟฟิคแบ่งกันเขียนแล้ว
      • A เขียนส่วนนึง เอามาจากเกมนึง, B เขียนอีกส่วน เอามาจากอีกเกมนึง แล้วไปคนละทาง
    • หรือบางทีเขียนคนเดียวนี่แหละแต่ส่วนต่าง ๆ ไม่สัมพันธ์กัน
    • การมี Design Goal ที่ชัดเจนจึงจำเป็นมาก หรือมี design director ช่วยควบคุมทิศทางการออกแบบ

เป้าหมายในการเขียน GDD

ง่าย ๆ ไม่มีอะไรมาก

• อธิบายความคิด
• อ่านง่าย กระชับ ครบถ้วน

อธิบายความคิด

• คิดอะไรอยู่? ดีอย่างไร? อยากขายอะไร?
• Design Goal ที่ชัดเจน เกมจะไปทางไหน? ขายอะไร? อยากได้อะไร?
  • ทั้งส่วนใหญ่ ส่วนย่อย ต้องชัดเจนว่าอยากได้อะไร?
  • goal ของแต่ละส่วนสัมพันธ์กันอย่างไร?
• Design details, design decisions ที่สนับสนุน design goal ทำอย่างไรถึงจะไปถึงสิ่งที่อยากได้?
  • เช่น สมมุติว่าอยากทำเกมตลก เป็นจุดขายของเกม เกมนี้เล่นแล้วคนเล่นต้องหัวเราะ เราก็คิดว่าแต่ละส่วนของเกมมันจะสนับสนุนกันทำให้คนเล่นขำได้อย่างไร?

อ่านง่าย กระชับ ครบถ้วน

ทำอย่างไรให้อ่านง่าย

• อธิบายความคิด ชัดเจน เป็นขั้นเป็นตอน
  • อย่าร่ายยาว ไม่ได้เขียนนิยาย
  • คิดอะไรอยู่? design goal คือ design decision คือ
  • เพราะมีสิ่งนี้จึงมีสิ่งนี้
  • เช่นเราบอกว่า อยากได้ A (design goal) คิดว่าต้องทำ B + C + D นะ (design decision)
    • เราก็อธิบาย A ว่าดีอย่างไร?
    • อธิบาย B, C, D อย่างชัดเจน ชี้ให้เห็นว่ามันสนับสนุน A อย่างไร
  • ไปให้ถึง design goal และ design decision GDD นี้ถึงจะมีประโยชน์เอาไปทำงานต่อได้
• ใช้ Format ในการเขียนเข้าช่วยให้อ่านง่าย
  • ถ้าเขียน Document ก็ใช้ Header/ Footer, Heading, Bullet points, Table, Callout, etc… เข้ามาช่วย
• ใช้ภาพหรือ diagram ในการช่วยอธิบาย
• ใช้ Slide presentation
  • ทำให้ใช้ diagram หรือ infographic อธิบายความคิดได้ง่าย
  • ใส่ vdo / screenshot ได้ง่าย
  • PowerPoint / Canva / Google Slide แล้วแต่ถนัด

• ใช้ Spread sheet
  • บางส่วนรายละเอียดเยอะ เขียนด้วยโปรแกรม spread sheet แบบ Excel หรือ Google sheet ก็จะทำให้สะดวกกว่า
  • จัดหมวดหมู่ข้อมูลใน spread sheet ให้ชัดเจน ไม่รกรุงรัง
  • ของบางอย่างก็ต้องอธิบายด้วย ตัวเลขกับ graph

• แก้แล้วแก้อีก ตั้งใจทำอย่างปราณีต
  • draft แรกแล้วเสร็จเลยไม่มีจริง มันต้องโน่น draft ที่ 100 ไรงิ
  • “Cut” ถ้าเห็นว่ายาวไป ตัดออก, ตัดคำสร้อย คำที่ไม่จำเป็นออก
  • จัดหมวดหมู่ให้ดี
  • ทำให้อ่านง่ายสวยงาม ไม่ว่าจะทำด้วยเครื่องมืออะไร

ข้อแนะนำจิปาถะ

• ถ้าจะเอาไอเดียมาจากเกมโน้นเกมนี้ ดูด้วยว่ามันไปด้วยกันได้มั๊ย
  • กำหนดทิศทางของเกมเราให้ดี อย่าเปะปะ ไม่งั้นจะเป็นหัวมังกุดท้ายมังกร
• คิดเสมอว่าจะอธิบายไอเดียให้คนอ่านเข้าใจได้อย่างไร
  • คนเราไม่เหมือนกัน สิ่งที่เราคิดในหัวไม่เหมือนกัน เช่นผมบอกว่าสีแดง ในหัวผมสีแดงนี้ไม่เหมือนสีแดงในหัวคุณแน่ ๆ
• ไปถามคนรับสารว่าเค้าอยากได้อะไร?
  • เช่น จะเขียนส่วนนี้อธิบายให้ concept artist เอาไปทำ concept art ไปถามเค้าเลยว่าอยากได้แบบไหน? ร่ายพรรณาพร้อม reference ภาพประกอบ หรือเขียนมากว้าง ๆ ก็พอเดี๋ยวเค้าเอาไปคิดต่อเอง
  • หรือไปถาม programmer ที่จะรับงานไปทำต่อเลยว่าอยากได้รายละเอียดถึงขนาดไหน แค่ไหนพอ ต้องคิด algorithm ให้เลยมั๊ย? ต้องการตัวเลขขนาดไหน?
  • ถ้าส่งไปให้แล้วเค้าอ่านไม่รู้เรื่อง ความผิดเรา ไม่ใช่ความผิดเค้า
• ถ้าใช้ Google doc ในการเขียน จัดหมวดหมู่ ทำสารบัญให้ดี บางทีเขียนแล้วหาไม่เจอว่า doc นั้นนั้นอยู่ที่ไหน
• ทำงานอย่างปราณีต
  • งานสร้างสรรค์อ่ะ มันต้องแก้แล้วแก้อีก ทำอย่างตั้งใจ เขียน GDD ก็เหมือนกัน
  • บางคนเขียนมาเหมือนแค่ได้เขียน นึกว่าเขียนแล้ว เราเป็น Game designer แล้วนะ มันต้องเขียนให้ดีด้วย
• บางทีการเชิญทุกคนที่เกี่ยวข้องมาฟังคำอธิบายร่วมกัน ทีเดียว จะได้เข้าใจตรงกัน แล้วจึงแจกจ่าย document ก็เป็นวิธีที่ดีนะ
• มันจะมีวิธีเขียนอีกหลายแบบจิปาถะ เช่น
  • เขียนด้วย Wiki format
  • เขียนแบบ หน้าเดียวจบ แต่หน้านั้นอาจจะใหญ่เท่าทั้งห้อง ใครอยากรู้ก็เข้ามาดูห้องนี้แปะไว้ทั้งห้อง เคยเห็นคนนำเสนอใน GDC แต่ทำยากอยู่ เพราะเหมือนจะไม่ค่อย flexible
  • ใช้ note taking program ต่าง ๆ
    • เดี๋ยวนี้ note taking program สมัยใหม่จะมี features มาช่วยให้ลำดับข้อมูล หรือบริหารความคัด จัดเก็บความคิด ได้ง่ายขึ้น
    • เช่น
      • Notion
      • Roam Research
      • Obsidian (ผมใช้ Obsidian, diagram ข้างล่างนี้ก็ทำใน Obsidian)
      • etc…

Diagram

TL;DR (too long; didn’t read)

• เขียน GDD ให้ดี ต้อง
  • มีความคิด เอาไปใช้งานต่อได้
  • อ่านง่าย กระชับ ได้ใจความ ไม่สั้นไม่ยาวจนเกินไป
  • แก้เยอะ ๆ งานสร้างสรรค์อ่ะ มันต้องปราณีต ดูก็รู้แล้วว่าเขียนกี่รอบ จงแก้แล้วแก้อีก

---

หวังว่าจะเป็นประโยชน์บ้างไม่มากก็น้อยนะครับ ไว้จะมาลงรายละเอียดสั้น ๆ แต่ละส่วนอีกที ขอบคุณมากครับ