Transcript Brainstorming

Process of creating
games
Game Design
Vishnu Kotrajaras, PhD
กระบวนการโดยย่อ

Brainstorming
– คิดไอเดียออกมาให้มากที่สุดเท่าที่ทาได้
– ตีกรอบลงมาให้เหลือ 3
– เขียนอธิบาย 1 หน้ากระดาษ สาหรับแต่ละไอเดีย

Physical prototype
–
–
–
–
ใช้กระดาษและปากกา
Playtests (ลองเล่นดูจริ งๆ ว่าเล่นแล้วเป็ นไง ต้องปรับยังไง)
ต้องทาการเล่นและปรับหลายรอบ
เมื่อเสร็จแล้ว เขียนรายงาน 3-6 หน้าเกี่ยวกับเกมและวิธีการเล่น
กระบวนการโดยย่อ (2)

นาเสนอผลงาน(optional)
– ทาเพื่อให้ได้เงินทุน
– เป็ นอีกโอกาสหนึ่งที่จะได้รับความเห็นตอบรับ
– นาเสนอ artwork ตัวอย่าง และวิธีการเล่นโดยละเอียด
– ดัดแปลงเกมให้เป็ นไปตามความต้องการของ sponsor หรื อยกเลิก
โครงการถ้ามีทีท่าว่าจะไปไม่รอด
– จริ งๆขั้นนี้อาจไม่ได้ทา เพราะบริ ษทั เกมเจ้าใหญ่ๆ ไม่รับงานจากมือใหม่
เราจึงต้องทาเกมต่อไปเพื่อขายเองแบบ indie จะมีโอกาสมากกว่า
กระบวนการโดยย่อ (3)

Software prototype
– ไม่ตอ้ งทาส่ วน graphics ให้ใช้ภาพที่มีอยูแ่ ล้ว ที่นามาใช้ได้ง่าย
– ทดสอบ Prototype ซ้ าๆ
Design document (ร่ าง)
 Production

– ทางานร่ วมกันกับทุกคน ต้องแน่ใจได้วา่ ไอเดียการออกแบบแต่ละส่ วนได้ถูกนาเสนอ
อย่างถูกต้องในเอกสาร
– เขียนโปรแกรมจริ ง และทารู ปที่จะใช้จริ ง
– ทดสอบและประเมินผลงานในทุกขั้นตอน
– อย่าเพิม่ concept ลงไป เว้นแต่จะจาเป็ นจริ งๆ.
กระบวนการโดยย่อ (4)

Quality control
– Playtest ซ้ าๆ หลายๆครั้ง ก่อนจะนาออกเผยแพร่
Physical Prototype
ควรทา ถ้าเป็ นไปได้
 เหมาะที่จะใช้ในการปรับแต่งสิ่ งต่างๆ ก่อนจะนาไปเขียนเป็ นโค้ด
จริ ง

– จะได้ feedback ทันที

ถ้าพบข้อบกพร่ อง จะสามารถแก้ไขได้ง่ายเมื่อยังอยูใ่ นขั้นนี้
สิ่ งที่ควรรู้เกี่ยวกับการ prototype





มนุษย์สามารถจา 7+-2 concepts ได้ในขณะใดขณะหนึ่ง
(1956, George Miller)
หมายเลขโทรศัพท์ยาว 7 หลัก
Tetris มีตวั บล็อก 7 แบบ
ดังนั้น concept ของเกมต้องเรี ยบง่ายพอที่จะทาให้มนุษย์เข้าใจได้
Prototyping ช่วยทาให้เข้าใจได้ ด้วยการทดลองเล่น
– กฎที่ดูหลวม จะดูชดั เจนขึ้น

พยายามดัดแปลง Prototype ให้สามารถเล่นได้ดีข้ ึน
จากกระดานสู่คอมพิวเตอร์

Diablo 2, baldur’s gate, EverQuest,
Asheron’s Call, Dark Age of Camelot.
– มีพ้นื ฐานมาจาก D&D.

Civilization.
Civilization
Wooden Ships & Iron Men
Shockforce
BattleTech
ตัวอย่าง prototype ของเกม FPS
ใช้กระดาษกราฟ เป็ นช่องหกเหลี่ยม
 สร้างกาแพงและกาหนดจุดเกิด

– ทาให้สามารถเปลี่ยนย้ายตาแหน่งได้
– ใช้ไม้ขีดไฟก็ดี ประหยัด

จากนั้นจึงวาง unit ลงไป โดยต้องสามารถระบุได้วา่ แต่ละ unit
กาลังหันหน้าไปในทิศทางใด

ผูเ้ ล่นแต่ละคนได้รับการ์ด 9 ใบ
–
–
–
–
–
–
“เดิน 1 ช่อง” x1
“เดิน 2 ช่อง” x1
“เดิน 3 ช่อง” x1
“เดิน 4 ช่อง” x1
“หันไปทางไหนก็ได้” x2
“ยิง” x3
ผูเ้ ล่นแต่ละคนเลือกการ์ ด 3 ใบ แล้วนามาวางควา่ ซ้อนกันไว้บนโต๊ะ
 ผูเ้ ล่นแต่ละคนเปิ ดการ์ ดใบบนสุ ด

– ดาเนินการยิง:
• ผูเ้ ล่นที่เปิ ดการ์ดยิง ทาการยิงไปในทิศทางที่ unit หันหน้าไป
• ถ้าแนวการยิงตัดกับช่องที่ unit อื่นยืนอยู่ ถือว่ายิงโดน
• การยิงเกิดขึ้นพร้อมกันสาหรับผูเ้ ล่นทุกคน
– หันหน้า:
• ผูเ้ ล่นที่เปิ ดการ์ดหันทิศทาง เลือกหัน unit ของตนเองไปในทิศที่ตอ้ งการ
– ทาการเคลื่อนที่:
• ผูเ้ ล่นเคลื่อนที่ไปตามที่การ์ด เดิน ระบุไว้
ทาซ้ ากับการ์ ดใบที่ 2 และ 3
 ถ้า unit ถูกยิง ให้นาออกจากเกม แล้วไปเกิดใหม่ที่ตาแหน่งจุดเกิดเมื่อเริ่ ม
การเล่นในรอบถัดไป


ส่ วนเพิ่มเติมอื่นๆ ที่เป็ นไปได้
– ระบบนับคะแนน อาจจะนับจานวนครั้งที่ฆ่าได้
– อัตราการยิงโดนหรื อไม่โดน ตามระยะการยิง.
• ใช้ลูกเต๋ า 10 หน้า
• 100% ที่ช่องติดกัน และลดลง 10% สาหรับระยะที่ห่างออกไปแต่ละช่อง
– พลังชีวิต
• เช่น 5 แต้ม แล้วลดลงครั้งละ 1 เมื่อถูกยิง
– มีจุดปฐมพยาบาลบนฉาก
– กระสุ นและจุดเติมกระสุ น
– อาวุธอื่นๆ
แต่มนั มีขอ้ จากัดอยูม่ ากไม่ใช่หรื อ?
ไม่ใช่ 3D, ไม่เป็ น real time?
 ไม่ตอ้ งเป็ นห่ วง โครงสร้างของเกมมีความสาคัญมากกว่าในช่วงนี้
 Physical prototyping บังคับให้เราคิดถึงรายละเอียด
การออกแบบในส่ วนต่างๆ และนิยามออกมาให้ชดั เจน
 โปรแกรมเมอร์ จะสามารถเข้าใจวิสัยทัศน์ของเราได้จาก
prototype

Mage knight
คาแนะนาสาหรับ physical prototype

เริ่ มจากกลไกหลักของเกม
– ในตัวอย่างเกม FPS, เราอนุญาตให้มีการเคลื่อนที่พร้อมกันได้ เพื่อให้เกิด
gameplay แบบ real time

เพิ่มสิ่ งที่สาคัญก่อน
– เมื่อใดก็ตามที่เพิม่ features กฎของเกมโดยรวมจะต้องถูกเปลี่ยนเพื่อมารองรับ
ระบบใหม่
– กฎต้องมาก่อน features
– สามารถทดลองเอากฎออกเพื่อดูวา่ เกมจะยังทางานได้หรื อไม่
หลังจาก gameplay อยูต่ วั ดีแล้ว จึงเพิ่มรายละเอียดลงไป
เพิ่มรายละเอียดครั้งละหนึ่ ง feature เท่านั้น ทดสอบ feature อันต่อ
อัน
 ถ้า gameplay ไม่ดี ลองเอา feature ออก แล้วทดสอบใหม่
 ใช้ flowchart ในการช่วยให้เห็นภาพของเกมชัดขึ้น


ถ้าตัน ไม่รู้ทาไงดี
ลองเปลี่ยน resource จากจากัด เป็ นไม่จากัด หรื อจากไม่จากัดเป็ นจากัด
ดู
 เพิ่มแอคชัน
่ ให้ผเู ้ ล่นหยุดหรื อเปลี่ยนแอคชัน่ ของผูเ้ ล่นอีกคนได้

– จะได้เกิดแผนการในการเล่นเพิม่ ขึ้น เช่นการ counter หรื อ การร่ วมมือกัน

ให้ผเู ้ ล่นทาการเปลี่ยนลาดับของสิ่ งที่เกิดในเกมได้
– เช่น เร่ งให้ตาเดินเร็ วขึ้นหรื อทาให้คู่ต่อสู ้ตอ้ งข้ามตาเดิน
เอากฎออกไป โดยเฉพาะกฎที่ไม่เกี่ยวกับส่ วนหลักของเกม
 เปลี่ยนค่าตัวแปร ตัวเดียว ให้เป็ นสองเท่า หรื อเป็ นครึ่ งหนึ่ ง แล้วลองเล่นใหม่

Software prototype

Software prototype เป็ นส่ วนเพิ่มเติมเล็กๆ ไม่ใช่เกมทั้งเกมใน
ตัวเอง
– Demo
– A level

ต้องแสดงให้เห็นถึง gameplay.
– ประกอบด้วยสิ่ งที่พดู ถึงในโฟกัสของเกม

การให้ส่วนเล็กๆของเกมทางาน ทาให้เราพอจะรู ้ได้วา่ ท้ายสุ ดแล้ว เกมจะสนุก
หรื อไม่
– สามารถปรับแต่ง หรื อแม้แต่ยกเลิกโครงการได้
Non-intuitive
, need fixing
ถ้าโปรโตไทป์ ยังไม่สนุก อย่า
ทา design document อย่างละเอียด
 แต่งข้อความและบทสนทนาในเกม
 ทาฉากแผนที่อย่างละเอียด
 สร้างด่านที่สมบูรณ์ออกมา
 วาดรู ปที่จะใช้จริ ง

ข้อเสี ยของการทาด่าน ภาพ และเอกสารอย่างละเอียด

สิ่ งเหล่านี้อาจจะสร้างความเข้าใจที่คลาดเคลื่อนเกี่ยวกับ
gameplay ได้
– ความพยายามเสี ยเปล่า เพราะยังไงเกมต้องเปลี่ยนแน่ๆ
– คนที่ลงแรงทางานไปแล้ว จะยึดติดกับผลงานนั้น (เก็บไว้ แม้จะใช้งาน
ไม่ได้กต็ าม)
• ทาให้เกมแย่ถา้ ยังเอาของที่ใช้ไม่ได้ใส่ ในเกมอยู่

จาไว้วา่ ยิง่ มีคนมาก ก็ยงิ่ ยากที่จะเปลี่ยนแปลงเกมได้
ตัวอย่าง 1: Odyssey: The Legend of
Nemesis
Richard Rouse ได้รับ game engine และ
บางส่ วนของเกมมาจากผูพ้ ฒั นากลุ่มก่อนหน้า
 เริ่ มจากเอกสาร 6 หน้าไปยังผูจ้ ดั จาหน่าย

– หนึ่งหน้าต่อหนึ่งฉาก
– เมื่อถึงจุดที่สร้างเกาะที่ 2 เขาก็รู้ตวั ว่าควรจะทิ้งเกาะอื่นๆบางเกาะไป
– ไม่เสี ยงานไปมาก เพราะการออกแบบช่วงแรกไม่ได้ลงรายละเอียดมาก
นัก
Odyssey: The Legend of Nemesis
จากนั้นก็สร้างเกม โดยใช้รูปภาพชัว่ คราว (นามาจาก project
อื่น).
 ไม่ตอ้ งกลัวเสี ยรู ปที่ได้วาดไปแล้ว
 จ้าง artist มาทารู ปทดแทนทีหลัง

ตัวอย่าง 2: Centipede 3D
Original gameplay idea.
 แต่สร้างมาถึง 6 ด่าน!!
 และมีด่านที่ออกแบบไว้อีก!!
 แล้วมาค้นพบทีหลังว่ามันไม่สนุก

– ปรับแต่ง gameplay
– แต่ตอ้ งทิ้งด่านที่สร้างไว้แล้วบางด่าน รวมถึงด่านที่ออกแบบไว้ดว้ ย
– ถ้าผูอ้ อกแบบตัดสิ นใจเก็บด่านเหล่านั้นไว้ จะแย่ยงิ่ กว่านี้
Centipede 3D
ระยะ prototype

ระยะทดสอบกลไกหลัก
– ทดสอบส่วนหลักเท่านั้น
– ดูวา่ สนุกหรื อไม่
– อาจจะต้องทดสอบคนเดียว (ซ้ าๆ)

ทดสอบกับคนนอก
– เพิ่มโครงสร้างส่วนต่างๆ ให้เพื่อน (คนที่ยงั ไม่เห็นภาพเต็มของเกม) ให้เล่นได้
– ทดสอบการทางาน และความสนุก ซึ่งอาจต้องทดสอบซาๆหลายที

ทดสอบเกมที่กฎการเล่นครบแล้ว
– ทดสอบจุดอ่อนและความสมดุลของเกม ต้องทาซาๆ

Refinement
– ทดสอบในส่วนของความสนุกและการเข้าถึงได้ ต้องทาซ้ าๆ
Software หรื อ programming
environments ที่มีประโยชน์




Flash
Macromedia Director
Game Maker
NeverWinter’s Aurora toolset
– เหมาะมากสาหรับการออกแบบเกม 3D






TorchEd
Panda3D
Unity
Unreal 3
Counter-Strike เป็ น mod ของ Half-Life.
Warcraft 3 มี level editor ที่สลับซับซ้อนมาก
– ต้องลองเล่นดูถา้ อยากออกแบบเกม RTS.
Game maker
Aurora
บางเกมจาเป็ นต้องมี software prototype
Tetris.
 Space war game.
 เมื่อใดที่โมเดลกระดาษใช้ยากเกินไป
 อย่าลืมใช้เครื่ องมือที่ทาให้สามารถเปลี่ยนแปลงได้เร็ วที่สุด
 อย่าคิดจะนาโค้ดมาใช้ใหม่

สาหรับบริ ษทั ใหญ่ๆอาจมีปัญหาพวกนี้
ศิลปิ น ผูอ้ อกแบบด่าน และคนเขียนโค้ด เริ่ มทางานตั้งแต่ระยะแรกๆ
 ผูจ้ ดั จาหน่ายอาจจะต้องการเห็น design document ทั้งหมด ก่อนที่
จะการอื่นใด

– ไม่มีทางเลือก ต้องทาตามที่ sponsor บอก
– ถ้าเป็ นไปได้ ใช้ทุนของตัวเองจนกว่าจะได้ gameplay prototype ที่
ทางานได้
– Prototype ที่ดีจะช่วยให้หาเงินทุนได้ในภายหลัง
การสร้างเกม (Production)
ก่อนอื่นต้องสร้างเทคโนโลยีที่เป็ นตัวยืนพื้นก่อน
 สร้างระบบหนึ่ ง หรื ออย่างหนึ่ งในเกมให้เสร็ จก่อน ก่อนที่จะเริ่ มทา
ระบบที่ตอ้ งพึ่งพาระบบหรื อสิ่ งที่สร้างนี้ต่อไป
ั ระบบที่ตอ้ ง
 ยากที่จะให้หลายทีม เขียนโค้ดขนานกันไปให้กบ
ทางานร่ วมกัน ทาเป็ นลาดับ แต่ช่วยกันทา ง่ายกว่า

สร้าง core technology

ต้องสร้าง Game engine เป็ นอันดับแรก
– ไม่จาเป็ นต้องเสร็ จสมบูรณ์ก่อนที่จะเริ่ มทา prototype
– เราไม่รู้ถึงขีดจากัดของเทคโนโลยีเสมอไป
• เราอาจจะเริ่ มจากการออกแบบศัตรู 10 ตัวบนหน้าจอ แต่ engine รองรับได้
แค่ 3 ตัว ดังนั้นเราจึงต้องออกแบบใหม่
ขั้นตอนต่อๆไป

แบ่งส่ วนการออกแบบออกเป็ นงานย่อยๆ งานส่ วนหลัก และงานที่ตอ้ งพึ่งพา
งานส่ วนอื่น
– Sidescroll platform: ทาให้ระบบเคลื่อนที่ของผูเ้ ล่นทางานได้ เป็ นงาน
อันดับแรก
•
•
•
•
เดินหน้า ถอยหลัง หันหน้า
ทาจนกว่าจะดูดี
จากนั้นเพิ่มการเคลื่อนที่แบบอื่นๆ: ก้ม, กระโดด.
ต้องแน่ใจได้วา่ จะไม่ทาให้การเคลื่อนที่ก่อนหน้าเสี ย ทั้งหมดต้องทางานร่ วมกันได้
– จากนั้นเพิ่มการโจมตี: ทดสอบจนกว่าจะรู้สึกว่าถูกต้อง
– จากนั้นเพิ่มศัตรู
ตัวอย่างขั้นตอนการเติมศัตรู และ item






ขั้นแรก ให้ใส่ ตวั ศัตรู ลงไปในเกม เพื่อที่ผเู ้ ล่นจะสามารถโจมตีได้.
จากนั้นให้มนั เริ่ มเคลื่อนที่ไปรอบๆ
จากนั้นให้มนั ทาการโจมตีของตัวเอง
จากนั้นเพิ่ม Item เข้าไปในเกม
ต่อจากนั้น ทาให้ผเู ้ ล่นสามารถหยิบของขึ้นมาได้ โยนของได้ ฯลฯ
ในแต่ละขั้นตอน เกมจะต้อง เล่นได้ และ สนุก
– เมื่อเพิ่มอะไรลงไปในเกมแล้วทาให้ของเก่าพัง ให้รีบแก้ทนั ที
ควรเล่นเกมที่สร้าง ตลอดช่วงการสร้าง
เป็ นการง่ายที่จะลืมความสาคัญของ gameplay ถ้าหากใช้เวลาไปมาก
ในการพัฒนาเกมในช่วงที่ไม่สามารถเล่นได้
 ถ้าสมาชิกของทีมสามารถหยิบเกมมาเล่นได้ทุกเมื่อ จะทาให้ได้ไอเดียที่ชดั เจน
เกี่ยวกับเกมที่กาลังทาอยู่
 ถ้าบางอย่างที่ถกู เพิม
่ เข้าไปในเกม ทาให้เกมสนุกน้อยลง จะเห็นผลได้ทนั ที

ด่านด่านแรกที่สร้างในเกม
เมื่อระบบทุกส่ วนสามารถทางานได้ตามที่ตอ้ งการแล้ว ก็เริ่ มสร้างด่าน
 เมื่อเริ่ มทดสอบเกมในแต่ละด่าน จะค้นพบ feature ที่ขาดหายไปจากเกม
 สร้างแต่ละด่านให้ใกล้เคียงกับสถานะสุ ดท้ายตามที่ตอ้ งการมากที่สุด ก่อนที่
จะเริ่ มสร้างด่านถัดไป

– จะเรี ยนรู้ได้มากจากแต่ละด่าน และทาไประหยัดเวลาในการสร้างด่านต่อๆไป
– แต่เนื่องจากมีการดัดแปลงแก้ไขด่านแรกนี้มาก ด่านนี้จึงจะไม่ดีนกั เมื่อเทียบกับด่านที่
สร้างมาในอนาคต
– เป็ นเรื่ องปกติที่จะทิ้งด่านนี้ไป
ระวังเกี่ยวกับระดับความยากของเกม
ในขณะที่กาลังสร้างด่านแรก เราจะมีโอกาสในการปรับแต่งระดับ
ความยากโดยทัว่ ไปของเกม
 ให้เพื่อนมาช่วยเล่นเกม

– สังเกตการณ์ดูวา่ หัดเล่นได้ง่ายแค่ไหน
– ถ้าเกมเล่นได้ยากกว่าที่คิดไว้ ต้องเปลี่ยนแนวทางการออกแบบทันที

ระวังจะเกิดความเคยชินกับจุดบกพร่ องต่างๆ:
– การควบคุมที่เข้าใจได้ยาก
– การเคลื่อนไหวของศัตรู ในแบบที่ไม่ยตุ ิธรรม
เผชิญกับการเปลี่ยนแปลง
การทิ้งรู ปภาพ โค้ด ด่าน และแม้แต่แผนการออกแบบ เป็ นสิ่ งที่
เกิดขึ้นเป็ นปกติ
 ทุกคนต้องกล้าพอที่จะโยนมันทิ้งไป
 จาไว้วา่ งานที่ดีบางอย่างอาจจะไม่เข้ากันกับเกมนี้ กไ็ ด้

แต่อย่าทาเกินไป
ผูอ้ อกแบบอาจจะเบื่อกับลักษณะของด่านที่ตอ้ งออกแบบ และ
อาจจะตัดสิ นใจทาด่านใหม่ เพียงเพื่อให้ได้อะไรใหม่ๆ
 ต้องหยุดเขาไม่ให้ทาอย่างนั้น! สาหรับผูเ้ ล่นแล้ว ด่านนี้ จะใหม่
เสมอเมื่อเขาเริ่ มเล่นเป็ นครั้งแรก
 ถ้า gameplay ดีอยูแ่ ล้ว อย่าเปลี่ยนอะไร

การเขียนโปรแกรม และการออกแบบ
เราต้องการ feedback ระหว่างคนออกแบบ และ
โปรแกรมเมอร์ อย่างสม่าเสมอ
 ผูอ้ อกแบบที่สามารถเขียนโปรแกรมได้ดว้ ย จะ
ได้เปรี ยบ:

– สามารถทดลองความคิดใหม่ๆได้ดว้ ยตัวเอง
– เข้าใจข้อจากัดของเทคโนโลยี
• ตัวอย่าง: ดาบสามารถเปลี่ยนรู ปร่ างได้ เมื่อถูกเสก
มนตร์…(engine ทาไม่ได้).
– ใช้ Engine แสดง particle รอบๆดาบ ผูอ้ อกแบบเกม
อาจจะพอใจกับแนวทางการแก้ปัญหานี้ดว้ ยซ้ า (แม้วา่ เขาจะไม่รู้ถึง
ข้อจากัดของ engine ก็ตาม)
ความคิดที่แตกต่างระหว่างผูอ้ อกแบบ และ
โปรแกรมเมอร์ เกี่ยวกับ gameplay
โปรแกรมเมอร์อาจจะแกล้งทาเป็ นว่ายาก ทั้งที่จริ งแล้วเขาไม่ชอบ
ไอเดีย
 ผูอ้ อกแบบที่ไม่รู้เกี่ยวกับเทคโนโลยีจะถูกเอาเปรี ยบได้

ถ้าผูอ้ อกแบบเกม ไม่เขียนโปรแกรมเอง
หัวหน้าโปรแกรมเมอร์ จะต้องเข้าใจ gameplay ได้อย่างดี
 ไม่เช่นนั้น โครงการอาจจะล้มเหลวได้

สรุ ป: Iterative & incremental process
No problem
problem
Generate ideas
Make prototype
Evaluate results
playtest
Iterative process diagram [FSH]