อยากรู้เหมือนกันครับ มาลงชื่อด้วยคน

ผมอาจตอบไม่ตรงคำถามนะครับ ถ้าไม่สนใจผ่านไปเลยนะครับ

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

Game Programer คุณต้องมีจินตนาการ และ ความคิดสร้างสรรค์ ที่เยอะกว่ากว่า Programer สายโปรแกรมประยุกต์ พอสมควร อาจต้องมีทักษะพวก 3D หรือ Painting บ้างเล็กน้อยด้วย ถ้าเป็นบริษัทเล็กๆ

ส่วนสายเว็บ ก็ต้องมีหัวออกแบบ ดีไซน์ ถนัดเรื่องการใช้ฟอนต์ และ User Interface พอสมควร

น้องนิยามให้ได้ก่อน ว่า Game Programmer คืออะไร และ Programmer คืออะไร
ผมลองยกตัวอย่างงานด้าน Programming ของเกมส์ที่แตกต่างกันนะ

• Game & Application Developer
• Web Developer
• Network Developer
• UI Engineer
• Game Backend Developer
• Sound and Audio Programmer
• Animation Pipeline Engineer
• Tools Engineer

แล้วตำแหน่งงานพวกนี้ต่างจากโปรแกรมเมอร์ธรรมดายังไง มันก็คือโปรแกรมเมอร์ธรรมดาที่เชี่ยวชาญเฉพาะด้านนั่นแหละครับ

มาช่วยตอบ เอาประเด็นที่เห็นจะๆ ก่อน

Game Programmer เป็นงานที่ค่อนไปทางมัลติมีเดีย กราฟิก เราเองชอบและทำได้โอเคขนาดไหน อันนี้เป็นจุดที่ทำให้ก้าวหน้าด้วย เช่น งานโค้ดเกมส์ ถ้ายังไม่ได้เข้าไปทำ บ.ใหญ่ๆ ที่ตำแหน่งคุณอาจจะทำบางเรื่องจริงๆ ส่วนใหญ่ก็ต้องเจอกับ game engine, graphic software (2D/3D) เป็นประจำ ดีไซน์สวยอาจจะไม่ต้อง มีคนทำให้ แต่ว่าถ้าดีไซน์ได้บ้าง หรือรสนิยมได้ งานต่างๆ ก็ลดการแก้ไขจากเจ้านายลง อันนี้ทำให้นายชอบ :D

Programmer ทั่วๆ ไปนี่นิยามไม่ค่อยออกครับ คือคิดว่า ทำอะไรดีกว่า Web (front end หรือ back end) หรือไปทาง Database เลย หรือทำ app mobile แน่นอนว่าอะไรที่พูดมามันเกี่ยวข้องกัน ยากนะครับ ที่ทั่วไปแล้วจะเลือกอย่างใดอย่างหนึ่ง คือรู้น่ะต้องรู้ทั่วๆ ไปด้วย แต่ว่าพอเก่งเรื่องใดเรื่องหนึ่งแล้วก็ค่อยมาทำเฉพาะส่วนชำนาญก็ว่ากันไปทีหลัง

โดยส่วนตัว ทำแอป ทำเวป ถนัดทาง Java รู้สึกว่า โลกทำเกมส์ เป็นอีกโลกนึง ที่ความรู้แทบเป็น 0 เลยครับ

เลือกสิ่งที่ทำแล้วชอบครับ แต่จริงๆแล้วสามารถย้ายสายกลับไปกลับมาได้นะถ้ามีความตั้งใจมากพอ

เดี๋ยวผมอัญเชิญคุณตาหวานมาตอบให้ครับ

คำตอบส่วนตัวก่อนครับ ... ผมเคยเขียนเกมง่ายๆ บน Qbasic เพราะได้รับแรงบันดาลใจจากพี่ชายและจากเกมนี้

ผมก็ไม่เห็นว่ามันต่างอะไรกันนะ ระหว่างโปรแกรมเมอร์ และเกมโปรแกรมเมอร์

โปรแกรมเมอร์ที่ดีต้องเข้าใจ tool ที่ใช้, output, API , technology, และปัจจัยต่างๆ รวมถึงทฤษฎีที่เกี่ยวข้อง จึงจะเขียนโปรแกรมให้มีประสิทธิภาพที่ดีได้ ไม่ว่าจะเขียนเกม หรือเขียนอะไรก็ตามครับ

เดี๋ยวนี้เขียนง่ายขึ้นเยอะนะ ... แต่ก่อนต้องติดต่อกับ VGA memory กันโดยตรงด้วยซ้ำไป

ลองพูดถึงค่าตอบแทนก่อนละกันนะครับ

เกมโปรแกรมเมอร์ทำงานหนักกว่าโปรแกรมเมอร์สายอื่น ๆ ประมาณนึง ผลตอบแทนก็ต่ำกว่าประมาณนึงเหมือนกัน (ถ้าเอาไปเทียบกับบ.ข้ามชาติ บ.เกมไทยจ่ายค่าแรงให้ต่ำกว่าประมาณ 40-60%)

ที่เหลือผมจะมาพูดทีหลังละกันครับ :)

-- จากคนที่ทำมาแล้วทั้งสองอย่าง 555

มาตามสัญญาละ :)

ผมเล่าเกี่ยวกับตัวเองเล็กน้อยก่อนนะครับ เอาไว้ตัดสินใจว่าความคิดผมมีน้ำหนักมากน้อยแค่ไหน (คือจะบอกว่าตอนนี้ความเห็นผมคงใช้ไม่ค่อยได้แล้วล่ะ 555) ผมจบม.อัสสัมชัญ คณะ CS เมื่อ 7 ปีที่แ้ล้ว โปรเจคจบเป็นเรื่องเกี่ยวกับ directx shader (เป็นทูลง่ายๆ) ก่อนหน้านั้นผมก็คลุกอยู่กับวงการนักพัฒนาเกมในบ้านเราอยู่ประมาณนึง โดยเป็นหนึ่งใน moderator ของเวปบอร์ด Thai Game Developer Exchange (TGDX) ซึ่งโปรแกรมเมอร์บ้าเกมยุคผมบางคนน่าจะรู้จักนะ 555 แต่ถึงกระนั้นผมก็ไม่เคยมีผลงานเกมเป็นชิ้นเป็นอันสักกะเกม คือด้วยนิสัยผม ผมมักจะทำเป็นแค่ concept prove พอเล่นได้แล้วหยุดไปทำเกมอื่นต่อน่ะครับ 555

ตอนผมเรียนจบ ผมก็ไปสมัครงาน บ.เกมไทยแห่งแรก เสนอเงินเดือนเขาไป 12,000 บาท เพราะเข้าใจว่าบ.เกมไทยไม่ค่อยมีตังค์จ่าย ผมถูกต่อเงินเดือนเหลือ 10,000 บาท ... ก็เลยไม่เอา สรุปว่าได้ไปได้งานที่บริษัทเกมชื่อไทยสัญชาติฝรั่งเศส (แต่ออฟฟิศหลักอยู่ปากเกร็ด) ได้เงินเดือนสูงกว่านั้นเท่าตัว สาเหตุหลักที่ผมได้งานที่นี่คงเป็นเพราะว่าผมพูดภาษาอังกฤษได้ดีระดับนึง (ผมจบเอแบคก็เลยได้พูดเยอะกว่าม.อื่น ๆ นิดหน่อย) ผมบอกได้เลยว่าทักษะด้านภาษาไม่ใช่เรื่องจำเป็นสำหรับโปรแกรมเมอร์ แต่ สำหรับคนที่ต้องการความก้าวหน้า ไม่ว่าในสาขาวิชาใดก็ตาม ทักษะด้านภาษาเป็นเรื่องที่สำคัญมากครับ (ส่วนตัวผมสอบ BULATS ได้ระดับ 12-13 นะ ก็ไม่รู้หรอกว่ามันดียังไง 555)

ยุคของผมเป็นช่วงที่นักพัฒนาบ้านเราเริ่มที่จะเปลี่ยนทิศทางไปทางด้านเกมคอนโซล เพราะว่า เกมมือถือในยุคนั้น (J2ME) เริ่มที่จะมีปัญหา นักพัฒนาบ้านเรามีความขัดแย้งกับ operator ในขณะที่ operator เองก็เริ่มซื้อเกมจากต่างประเทศเข้ามาขายมากขึ้น แต่นั่นก็ไม่เกี่ยวกับผม เพราะบ.ผมทำเกมส่งค่ายใหญ่ต่างประเทศ :P

โปรเจคแรกที่ผมทำเป็นการพอร์ทเกมจาก J2ME MIDP จากเครื่องที่เป็น S60 ลงไปบนเครื่อง S40 ซึ่งก็ฟังดูเหมือนยาก แต่พอดีเกมมันไม่ได้ซับซ้อนอะไรเลย (สมัยก่อนเกม J2ME จากค่ายไทยจะหรูหรากว่าเกมต่างประเทศมากครับ) ก็เลยสบายหน่อย ผมได้ความรู้ใหม่ว่า มือถือ Sony เป็นยี่ห้อเดียวที่เล่นไฟล์ midi เป็นลูปได้โดยที่ไม่ขาดช่วง

จากนั้นก็มีโปรเจคที่เป็น Tool สำหรับใช้ในการพัฒนาเกม ทูลตัวนี้ถูกสร้างขึ้นมาเพื่อใช้กับเกมระดับ AAA เกมหนึ่งจากค่ายยักษ์ใหญ่ของฝรั่งเศส (จริง ๆ จะบอกชื่อเกมก็ได้มั้ง แ่ต่ผมลืมไปแล้วว่าเกมอะไร) ใช้ .Net เขียน ไม่ได้เป็นอะไรน่าตื่นเต้นครับ ถ้าให้พูดว่ามันคือทูลอะไร ... ผมเรียกว่า BLOB Editor ละกัน

โปรเจคต่อไป ผมได้ทำโปรเจคเป็นโปรโตไทป์เกมพัซเซิลง่าย ๆ ที่ตั้งเป้าไว้ว่าจะขายใน XBLA ครับ ซึ่งก็ทำบน PC นั่นแหละ ในขณะที่คนอื่นเขาเริ่มที่จะเปลี่ยนไปใช้ XNA กัน แต่บอสผมเลือกใช้ DirectX แทนโดยพยายามเลือกใช้เฉพาะ API ที่มีให้ใช้บน XBox 360 (รวมถึง XInput, XAudio, XACT, และอื่น ๆ) เพื่อเวลาที่จะเปลี่ยนไปทำงานบน XB จะได้ไม่มีปัญหามากครับ ซึ่งผมว่าตัดสินใจถูกนะเพราะว่า XNA ก็ล้มไปแล้ว (บอสผมเค้ากังวลเรื่องที่ว่า XNA จะล้มหรือเปล่านี่แหละเลยไม่ใช้) โปรเจคนี้สนุกมากเพราะว่าเป็นโปรเจคที่ผมมีอิสระเต็มที่มาก ทำงานคู่กับ Game Designer (ที่เรียนด้านนี้โดยตรง) และ Lead Artist ของบริษัทเอง ออกแบบเอนจินเอง ทุกอย่างทำเองหมด เป็นความภาคภูมิใจของผมเลยนะ ผมยังมี Design Doc เก็บไว้อยู่เลย เสียดายว่าโปรเจคนี้ถูกพับไปเพราะ ....

เพราะโปรเจคหลักของบริษัทเกิดล้ม ซีเนียร์โปรแกรมเมอร์ที่เพิ่งรับเข้ามาใหม่ไม่นานเกิดหนีออกจากบริษัท ทุกคนที่ทำงานไม่สำคัญอยู่ต้องหยุดงานของตัวเองแล้วมาอุ้มโปรเจคนี้กันหมดครับ เป็นโปรเจค CAI บน PSP ผมไม่ขอพูดรายละเอียดมากละกัน แต่โปรเจคนี้เองก็สนุกครับ เพราะว่าได้เล่นกับ PSP Devkit ของแท้ ซึ่งน่าจะเป็นเครื่องเดียวในเมืองไทยด้วยมั้ง ผมได้เรียนรู้เกี่ยวกับการทำเกมบน console มากมายทีเดียว

โปรเจคตัวต่อไป เป็นเดโมของเกมบน NDS เป็นอะไรที่ตื่นเต้นมากครับ เพราะว่าได้ใช้งาน Nitro Debugger (บอกชื่อได้เนอะ?) ตัวแรกของประเทศไทย! ผมว่ามันเป็นความฝันของเกมเมอร์อายุพอ ๆ กับผมส่วนใหญ่เลยนะ ผมดูแลส่วนที่เกี่ยวกับเสียงทั้งหมด เพราะผมเป็นคนชอบฟังเพลงแล้วก็เล่นดนตรีได้นิดหน่อย ก็โคงานกับนักแต่งเพลง แล้วก็เอาเพลงที่เขาทำมาแก้ให้เล่นบน NDS ได้ (ผมทำ sample file กับ sequence โดยแปลงจากไฟล์ wave กับ midi ที่เขาทำมา) ทำตรงนี้แล้วได้ความรู้เกี่ยวกับระบบเสียงบนเครื่องเกมคอนโซล ซึ่งแตกต่างกับบนพีซีโดยสิ้นเชิง (แต่ยุคปัจจุบันมันเหมือนกันแล้วล่ะ 55) ผมอยู่ถึงแค่เดโมแรกเสร็จก็ลาออกมาครับ แต่หลังจากนั้นอีกประมาณเกือบปีได้มั้ง เดโมตัวนี้ก็ทำเสร็จแล้วก็ได้วางขาย ผมเองก็ไม่รู้นะว่าโค๊ดส่วนที่ผมเขียนจะยังอยู่มากแค่ไหน 555

ทั้งหมดนี้เป็นประสพการณ์การทำงานในบริษัทเกมของผมนะครับ ผมทำงานอยู่กับบ.นี้เป็นเวลา 1 ปี กับอีก 3 เดือน ได้เรียนรู้อะไรเยอะมาก แล้วก็ได้ทำโปรเจคเยอะมาก (เทียบกับที่ทำงานปัจจุบันที่แทบจะไม่ค่อยมีอะไรให้ทำ วันๆ ก็แก้บั๊กแล้วเขียนเอกสาร) แต่ว่าต้องอึดพอสมควร ตอนนั้นผมทำงานตั้งแต่ 10 โมงเช้า พักเที่ยง ทำต่อถึง 6 โมง พักข้าวเย็น ทำต่อถึงสี่ทุ่ม-เที่ยงคืน โดยเฉพาะตอนโปรเจคเร่ง ๆ คือถ้าผมไม่เช่าหอแถวนั้นอยู่ ผมตายแน่ ๆ 555 แต่ด้วยความที่ออฟฟิศอยู่ค่อนข้างบ้านนอกก็ปราศจากสิ่งรบกวนดีนะครับ ก็เลยทำงานได้เยอะ (เดี๋ยวนี้คงไม่ได้แล้วเพราะว่ามีห้างมาเปิดตรงข้ามออฟฟิศ)

อ้อ ผมได้ไปสัมนาที่สิงคโปร์ (และท้องร่วงเกือบตายอยู่นั่น 555) มาด้วย ก็ได้ไปฟังคนสิงคโปร์ที่เคยไปทำงานกับ Polyphony Digital เขาว่า ระหว่างที่เขาอยู่ที่นั่น ทำงานโปรเจค Gran Turismo 4 เขาแทบจะไม่ได้กลับบ้าน นอนกันที่ทำงาน สามเดือนกลับบ้านทีนึง พนักงานบางคนที่กำลังจะแต่งงานก็ยกเลิกงานแต่งไปเลยก็มี ทุกโต๊ะทำงานจะมีม่านที่ใต้โต๊ะ ง่วงนอนก็หมุดลงไปนอนใต้โต๊ะกันเลย

ผมคิดว่า ก็คงคล้าย ๆ กับบ.ไอทีเล็ก ๆ บ้านเราหลาย ๆ ที่นะ ถ้าเป็นบริษัทใหญ่จะค่อนข้างเอื่อย ๆ พอบริษัทจะเจ๊งทีนึงก็ขยับตัวพลิกตัวทีนึง 555 ยิ่ง ไอทีใหญ่ ๆ บ้านเราจะเป็นพวกระบบการเงิน ธนาคาร กองทุน ฯลฯ การพัฒนาอะไรขึ้นมาสักอย่างก็ช้ายังกับเรือเกลือ ผมว่าน้อง ๆ โปรแกรมเมอร์ที่ชอบอะไรท้าทาย ๆ ไม่น่าจะชอบกับงานลักษณะนี้ครับ แต่ก็เหมาะกับคนไทยดีเพราะคนไทยกลัวการเปลี่ยนแปลง

ปล. บางคนคงสงสัยว่าทำไมถึงลาออก สาเหตุหลักคือ (ไม่อยากบอกเลยแฮะ 555) เรื่องผู้หญิงครับ แต่ก็มีประเด็นรอง ๆ เรื่องความเครียด ความกดดันด้วยเหมือนกัน ถ้าให้กลับไปทำอีกก็อยากทำนะ แต่ผมว่าเขาคงไม่รับผมกลับเข้าไปแล้วล่ะ 555

ล๊อกอินเข้ามาเพื่อจะบอกว่าอ่านแล้วสนุก ตื่นเต้น น่าติดตาม อยากรู้ตอนต่อไปตลอดเวลาที่อ่าน

ขอบคุณมากครับ

มาต่อภาคสองนะครับ

ผมคิดว่ามีน้องหลายคนน่าจะอยากเป็น "เกมโปรแกรมเมอร์" แต่ตำแหน่งนี้จริง ๆ คืออะไร ... จริง ๆ ก็คือโปรแกรมเมอร์ที่เขียนเกมนั่นเอง ความแตกต่างมันอยู่ที่ว่าผลิตภัณฑ์ที่เราสร้างขึ้นมามันต่างกับผลิตภัณฑ์อื่นยังไงมากกว่า

ลักษณะพิเศษของเกมคือ เกมเป็น real-time application ที่ไม่เน้นความถูกต้องแม่นยำมากนัก แต่ต้องทำทุกอย่างให้เสร็จภายใน 16.66 ms ไม่งั้นภาพจะกระตุก เช่น ถ้าใช้ฟิสิกส์ F=mg คุณอาจจะใช้ g=10 แทนที่จะเป็น 9.8 แต่เกมโปรแกรมเมอร์บางคนอาจจะใช้แค่ g=8 ด้วยเหตุผลที่ว่าตัวคอมไพล์เลอร์จะทำการแปลงให้เป็น F=m<<3; ให้เลย เท่ห์ไหมล่ะ คือฟิสิกส์ที่ใช้ในเกมมันอาจจะเป็นฟิสิกส์ที่...เป็นไปไม่ได้ในโลกความจริงเลยก็ได้

โครงสร้างของแอพประเภทเกมจะเหมือนกับแอพ GUI ทั่วไป แต่คุณต้องเขียนตั้งแต่ระดับรากหญ้าของโปรแกรม โดยพื้นฐานก็จะหน้าตาแบบนี้

{syntaxhighlighter class="c"}
while(true)
{
getInput();
process();
render();
waitForNextFrame();
}
{/syntaxhighlighter}

(แน่นอนว่ามันก็มีเทคนิคแอดวานซ์อย่างพวก multithreading อะไรพวกนี้ด้วย ถ้าสนใจก็ลองศึกษาเพิ่มละกันครับ) อ่านถึงตรงนี้อยากถามว่าคนที่เขียนแอพ GUI แบบอื่น ๆ เคยทราบไหมครับว่าโปรแกรมคุณก็หน้าตาแบบนี้เหมือนกัน ? ผมว่าหลายคนไม่รู้นะ บางคนลากวาง widget กดดับเบิ้ลคลิ๊กแล้วใส่ event handler จบ ... เกมโปรแกรมเมอร์จะไม่ได้ทำแบบนั้นครับ (ยกเว้นแต่คุณใช้เอนจินคนอื่นที่แพง ๆ หน่อยก็อาจจะทำแบบนี้เหมือนกัน)

ในการวนหนึ่งลูป คุณมีเวลา 33.33 มิลลิวินาที ถ้าเกมคุณรันที่ 30 fps และ 16.66 มิลลิวินาที ถ้าเกมคุณรันที่ 60 fps คุณอาจจะคิดว่าเวลาเยอะแยะ แน่นอนว่าถ้าคุณเขียนเกมลง Core i7 ก็คงไม่ต้องกังวลอะไรมาก แต่ถ้าคุณเขียนเกมลง ARM9 ความเร็ว 60MHz คุณจะเริ่มรู้สึกว่าคุณกำลังอยู่ในโลกสโลว์โมชั่นเลยล่ะ

ภายในฟังก์ชั่น 3-4 ตัวข้างบน คุณก็ต้องเขียนโค๊ดที่เป็น low-level api ทั้งหมดเอง ทั้งการวาด (ที่เรียกใช้ OpenGL/Direct3D) การรับอินพุต (platform-dependent ครับ) หรือการเล่นเสียง (OpenAL/OpenSL/DirectInput/etc.) ซึ่งแน่นอนว่าคุณต้องเรียนรู้คอนเซพท์ที่แต่ละแพลตฟอร์มใช้ เช่นถ้าคุณเขียนเกมลง NDS คุณต้องวาดทุกอย่างเป็น Tile หรือถ้าคุณเขียนเกมลง XBox 360 คุณต้องรู้ว่า 3D audio source นั้นต้องเป็นโมโนเท่านั้น อะไรแบบนี้

สำหรับเกมโปรแกรมเมอร์ ผมคุยกับมืออาชีพปัจจุบันหลาย ๆ คนก็ยังคงฟันธงเป็นเสียงเดียวกันว่า คุณต้องเขียนภาษา C++ ได้ (บางคนถึงขั้นบอกว่าคนที่เขียนภาษานี้ไม่เป็นไม่นับว่าเป็นโปรแกรมเมอร์ แรงมาก 555) ไม่มากก็น้อย เพราะแม้ว่าคุณจะใช้เอนจินของคนอื่น ใช้ภาษาสคริปท์ (ที่ดังในวงการเกมคือ lua เพราะเล็กและ bind ง่าย) ก็ตาม แต่หลาย ๆ ครั้งคุณต้องมานั่งแก้โค๊ดของเอนจินพวกนี้เอง และส่วนใหญ่ก็ถูกเขียนมาด้วยภาษา C++ ถ้าคุณไม่สามารถเขียน C++ ได้เลย คุณจะประสพปัญหาประเภท platform ที่คุณใช้อยู่ดี ๆ ก็ถูกประกาศว่าจะหยุดพัฒนา (XNA ยังจำได้ไหม ~) แล้วช่วงที่คุณย้ายไป platform อื่นคุณจะต้องใช้เวลาเรียนรู้มาก ในขณะที่คนที่เขียน C++ เป็นนั้นจะเขียนโปรแกรมอะไรภาษาไหนก็ทำได้ เพราะเขาชำนาญภาษาระดับสูงที่ซับซ้อนที่สุดมาแล้วนั่นเอง

ความรู้ต่อไปที่เกมโปรแกรมเมอร์ควรรู้ ก็คือ ความรู้ด้าน real-time computer graphics ที่รวมถึงการวาดแบบ tile base และกราฟิค 3 มิติด้วย แค่คำสั่ง blit ภาพเป็น pixel นั้นไม่พอครับ เรื่องนี้จริง ๆ ไม่ได้ยากและมีหนังสือมากมายให้ศึกษา ผมแค่อยากย้ำว่าหาหนังสือที่ถูกต้องมาอ่านละกัน เพราะหนังสือเขียนเกมในตลาดเกินครึ่งใช้งานจริงไม่ได้เลย

ความรู้ด้าน audio นั้นก็ควรมีบ้าง เอาแค่ให้เล่นเสียงออกได้ ทำสตรีมมิ่งเป็น ผมว่าก็โอเคละนะ แพลตฟอร์มส่วนใหญ่จะมี mixer library ให้มาอยู่แล้ว คุณแค่เล่นเสียงก็พอ แต่ถ้าเกิดไม่มีก็ต้องเขียนเองล่ะนะ คือ hw เสียงส่วนใหญ่จะรับ input ที่มี channel จำกัดครับ อาจจะ 4 - 16 ch ก็แล้วแต่ ตรงนี้หมายความว่ามันจะเล่นได้พร้อม ๆ กันแค่ 4- 16 เสียงครับ ดังนั้นบนแพลตฟอร์มที่ซีพียูพอจะมีแรงหน่อยเราก็จะเขียน mixer ให้สามารถรวมเอา sound source หลาย ๆ อันมาสตรีมใส่ input channel เดียวกันได้เพื่อเพิ่มจำนวนเสียงที่จะเล่นพร้อม ๆ กันได้นั่นเอง (บน Windows มี mixer ให้มาอยู่แล้วครับ) อ้อ บนแพลตฟอร์มเก่า ๆ นี่ ทุกอย่างทำงานเป็น sequence+sampler ครับ ดังนั้นก็ต้องศึกษาตรงนี้เพิ่มอีก

ตอนผมทำเกมอยู่ บนโต๊ะทำงานผมจะมีหนังสือ C++ in a Nutshell (ผมเป็นสาย Java ครับ มาศึกษา C++ เองทีหลัง ก็เลยต้องมี reference วางไว้) หนังสือสอนเขียนเกมบ้างนิดหน่อย (เน้นเชิงเทคนิค) แล้วก็หนังสือสรุปสูตรคณิศาสตร์ม.ปลาย กับ หนังสือสรุปสูตรฟิสิกส์ม.ปลาย เกมส่วนใหญ่ใช้ความรู้ไม่ค่อยเกินมัธยมครับ เพราะพอขึ้นมหาลัยก็มีแต่แคลคูลัส 555

สิ่งสำคัญอย่างหนึ่ง ก็คือ ทีมเวิร์ค คือสมาชิกในทีมทุกคนต้องเก่งพอจะพึ่งตัวเองได้ และใช้ความสามารถร่วมกันเพื่อที่จะดันให้ทีมขับเคลื่อนไปได้ ผมเคยเจอคนที่แบบว่าทำทุกอย่างต้องถาม ไปเองไม่ได้ ติดนิดนึงถามตลอด ไม่ค่อยมีความพยายาม จะไม่ค่อยเหมาะกับงานนี้ครับ (จริง ๆ ก็ไม่เหมาะกับอะไรเลยแหละ) เพราะว่าคุณจะเจออุปสรรคมากกว่าโปรแกรมเมอร์สายอื่นเขาเจอกัน (ส่วนหนึ่งเพราะเราเขียนโค๊ดระดับล่างกัน) ถ้าเกิดว่าเป็นคนไม่มีความพยายามเลยผมแนะนำว่าไปขายกล้วยทอดเถอะ คุณต้องรับผิดชอบงานในส่วนของคุณ และต้องโคงานกับ Game Designer และ Artist ตลอด สิ่งหนึ่งที่ผมแนะนำ ถึงแม้ว่าอาจจะเป็นการเพิ่มภาระให้ในระยะเริ่มแรกก็ตาม ก็คือทำ Tool ที่ GD กับ Artist สามารถนำไปใช้เพื่อแก้ไขเกมของคุณได้ คือต้องออกแบบเอนจินให้ดีแต่แรก ไม่เช่นนั้นในระยะยาวจะเป็นตัวคุณเองที่เหนื่อย เพราะว่าพอจะแก้อะไรทีโปรแกรมเมอร์ก็ต้องทำให้ที คือ GD เองก็มีหน้าที่ทำเลเวล เขาต้องปรับแต่งเลเวล ส่วน Artist เองก็ต้องทำ content ถ้าเกิดว่าเขาจะปรับทีต้องคอมไพล์ใหม่ทีเราก็ตายครับ วัน ๆ ไม่ต้องทำอะไรเลย คือมันเป็นการไปซัพพอร์ทให้เขาสามารถทำงานของเขาได้โดยที่ไม่ต้องพึ่งพาเรานั่นเอง

ผมว่าการเขียนทูลก็เหมือนเป็นการพักผ่อนจากงานหลักด้วยประมาณนึงนะ

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

ถ้ายังไม่เคยเขียนภาษาไหน เขียนเกมส์อะไร ลอง pygame ดูก่อนครับ ผมว่าเข้าใจง่ายดีครับ

อ่อ อีกอย่าง ผมไม่เข้าใจความหมายคำว่า "programmer ธรรมดา" ของ จขกท อะครับ หมายถึงยังไงเหรอครับ

อ่านแล้วคันมือ แต่ติดว่าต้องแก้ Bug อยู่ ไว้จะเล่าเรื่องการเขียนเกม Facebook บ้าง อิอิ ผมทำทั้ง Flash เป็น frontend และ nodejs, php เป็น backend ต่อ socket สนุกอยู่เลยตอนนี้ (เกมป็อกเด้งใน Facebook ครับ) ยุคผมเป็นยุค Cloud หัวใจสำคัญคือ Server ทำยังไงไม่ให้ล่ม บริษัท Levelup Studio ใครสนใจมาสมัครงานได้นะครับ เปิดรับ Programmer สายเกมเต็มที่อยู่ อิอิ

สภาำพเกม Developer กับคนเล่นเกมมันต่างกันมากนะ ถ้าต้องทำเกมที่ตัวเองไม่สนุกคงทำเกมออกมามีคุณภาพไม่ไหว

PC Console เหนื่อย ต้องเล่นกับระดับล่าง...

แต่ถ้าเป็น Flash / Pussel ยังพอถูไถ

ผมเป็นผู้ได้รับผลกระทบจาก XNA ครับ ฮ่าๆ

เมื่อก่อนตอนเรียกผมเคยเขียนเกมออนไลน์(Multiplayer) 2 มิติบน Java Swing โดยการวาดภาพลงไปบน Component ดื้อๆ เนี่ยแหละ เป็นประสบการณ์ที่สุดยอดมากครับ ผมได้ออกแบบทั้งวิธีสื่อสารระหว่าง Server กับ Client ออกแบบวิธีวาดและลำดับก่อนหลังของการวาด แล้วก็ระบบแพทช์ของเกม มันเป็นอะไรที่สนุกและได้ความรู้มหาศาลเลยครับ การเขียนเกมเนี่ย ต่อจากนั้นมาผมได้เข้าสู่สังคมของ XNA ได้ทำเกมเล็กๆ บนวินโดวส์โฟน และทำโปรเจคจบเป็นเกม RPG+Puzzle บนวินโดวส์โฟนด้วย(ต่อกับ WCF Service ซึ่งเป็นเรื่องที่ทำให้ผมผิดหวังกับวินโดวส์โฟนมากๆ) ผมบอกตามตรงคือผมไม่มีความรู้เรื่องการเขียนเกมจริงๆแม้แต่น้อย ผมรู้แค่ว่าจะทำ หรืออยากทำ ช่วงต่อมาผมพยายามลองอ่านตามชุมชนทำเกมต่างๆ ก็พบว่าพวกเค้าไม่ได้เขียนเหมือนผม มี Tool ต่างๆ เกิดขึ้นมากมาย ที่ทำให้การเขียนเกมง่ายขึ้น และก็พบว่าผมอ่านสิ่งที่พวกเขาพูดกันไม่ค่อยจะรู้เรื่อง หลังจากนั้นก็เลยไม่ได้เขียนอีกเลย แล้ว XNA ก็ประกาศหยุดพัฒนาไปเฉยๆ = ="

ทุกวันนี้ผมก็เขียนแอพทั่วๆ ไปแหละครับ ความสนุกมันคนละเรื่องกับตอนที่เขียนเกมเลย แต่ก็ต้องทำ ><

ชีวิตการทำเกมบน Facebook ตอนนี้ทำมา 4 ปีแล้ว ยังไม่ต้องจับ C++ ตรงๆ มากนัก แต่จริงๆ ถ้าจะลงลึกถึงพวก extension PHP, NodeJS ก็ต้องใช้ครับ มีองค์ประกอบสำคัญ 4 ส่วนหลักๆ ได้แก่

1. PHP เป็น Backend ติดต่อกับ Facebook เขียน REST Webservice มันส์ครับ :) (เหมาะกับพวกชอบเสือกเรื่องชาวบ้าน :P)
2. NodeJS หรือก็คือ Javascript ฝั่ง Server-side อันนี้จริงๆ ใช้เฉพาะเกมที่ต้องใช้ Socket อันที่จริงแล้วเกมทั่วๆ ไป ที่ไม่ต้องเล่นพร้อมกันกับเพื่อนไม่ค่อยจำเป็นต้องใช้ครับ แต่ถ้าใช้ก็จะช่วยเพิ่มประสิทธิภาพการทำงานเป็นอย่างมาก เพราะมันเป็นการเขียนโปรแกรมแบบ Event-Driven มันส์มากเหมือนกัน 55+ และถ้าใช้เก่งๆ สามารถแปลงร่าง NodeJS ให้เป็นได้ทุกอย่างตั้งแต่เขียน app, เขียน log ในแบบเราเอง, Socket Real-time application, Streaming ไปจนถึงเขียน Load Balancer ด้วยตัวเอง (Javascript) เลยนะเออ!
3. Database อันนี้สำคัญเป็นอันดับต้นๆ ไม่แพ้ส่วนอื่น เป็นหัวใจของเกมแบบ Web-base เลยทีเดียว Database หลักของผมยังคงใช้ MySQL เป็นหลัก แต่ Challenge หลักคือ Application ทั่วๆ ไปจะเน้น Read เป็นหลัก แต่เกมไม่ใช่ครับ คนจะเล่นเกมมันต้องมีการเปลี่ยนแปลงค่าต่างๆ ตลอดเวลา อัตราการ Write จะมากกว่า Read และในวงการคนทำ Database Admin จะทราบดีว่าถ้า Read เยอะๆ เรายังทำ Replication แบบ Master-Slave ออกไปแบบง่ายๆ ได้ แต่ถ้า Write เยอะๆ นี่ต้อง Replication แบบ Master-Master ซึ่งบอกได้คำเดียวว่า "โคตรยุ่งครับ" ซึ่งตรงนี้ผมหนีไปทาง NoSQL แทนครับ Redis, MongoDB ช่วยได้มาก (แต่ยังไม่ได้เลิกใช้ MySQL เพราะต้อง Choose the right tools at the right job ครับ)
4. Flash เป็น Frontend ทั่วไป Challenge หลักคือการทำอย่างไรให้เกมไม่กระตุกถ้าคุณมี Object บนจอเยอะๆ ภาพจะมีให้เลือกสองแบบคือ Vector และ Bitmap ซึ่งก็มีข้อดีข้อเสียต่างๆ กันไป ทำอย่างไรให้ update ค่าจาก Backend แล้วลื่นไหล ไม่มีสะดุด อันนี้ระดับความยากแพ้พวก C++ ครับ C++ ยากกว่าแน่นอน confirm 55+

วันนี้ขอเกริ่น NodeJS ก่อนละกันครับ เพราะ PHP ใครๆ ก็เขียนเป็น ไม่ใช่เรื่องยาก NodeJS นี่เหมือนมิติใหม่ของการเขียนโปรแกรมครับ มันช่วยเรื่อง performance ได้เป็นอย่างดี ผมจะเทียบกับ PHP แบบนี้นะครับ ปกติ PHP และภาษาอื่นๆ ทั่วไปเช่น C#, Java, C++ จะ Query Database สมมติเราต้องการข้อมูล user ทุกคน และ item ทุกชิ้น (ขอเขียนเป็น PHP นะครับ และชื่อ Function ต่างๆ ไม่มีอยู่จริงนะครับ แค่จำลองให้พอเข้าใจหลักการทำงานเฉยๆ)

PHP

$a_user = my_mysql_query("SELECT * FROM user");
$a_item = my_mysql_query("SELECT * FROM item");

NodeJS

my_mysql_query("SELECT * FROM user", function (err, aUser){
  // do result with aUser here
});
my_mysql_query("SELECT * FROM item", function (err, aItem){
  // do result with aItem here
});

ใน NodeJS ทุกอย่างจะทำผ่าน callback function ครับ ไม่ใช้ค่า return แบบปกติที่เราเคยใช้ๆ กัน ถามว่าดียังไง? เหมือนจะเขียนยากกว่า มันมีข้อดีก็คือถ้าเป็น PHP การทำงานจะเป็นแบบจากบนลงล่างตามปกติ หากตาราง User ใช้เวลา Query 10 วินาที หมายความว่า query item จะไม่มีวันได้รันเลยจนกว่าตาราง user จะ query เสร็จ แม้ว่าจริงๆ แล้วตาราง item อาจจะใช้เวลา query แค่ 1 วินาที ซึ่งหากใช้ NodeJS มันจะสามารถทำงาน "ไปพร้อมๆ กัน" ได้ครับ คือตาราง user ยัง query ไม่เสร็จไม่เป็นไร แต่ตาราง item จะทำไปพร้อมกัน และได้ผลลัพธ์ก่อนตาราง user เสียอีก โดยไม่ต้อง "รอ" ให้ตาราง user query เสร็จ และเราสามารถนำผลลัพธ์จากตาราง item ไปแสดงผลได้เลยโดยไม่เสียเวลา ทีนี้ถามว่าถ้ามี operation ประเภทนี้ซัก 100 operation และทุกคำสั่งสามารถทำงานไปพร้อมๆ กันได้โดยไม่ต้องรอคำสั่งก่อนหน้าเสร็จก่อนจะเป็นยังไงครับ? นั่นหมายถึง performance ที่ดีขึ้นหลายเท่าตัวเลยทีเดียวครับ!! ยิ่งถ้า Database ติด Table Lock การใช้ NodeJS จะช่วยลดผลกระทบตรงส่วนนี้ไปได้มาก แต่ทั้งนี้ทั้งนั้นก็ต้องยอมรับครับว่ามันเขียนยากกว่า PHP จริงๆ แต่มันก็คือ Javascript ตัวเดียวกับที่เราเห็นๆ กันใน Web Browser นั่นแหละครับ แถมใช้ V8 Engine ในการรันทำให้ได้ความเร็วที่สุดยอดครับ :) ผมชอบแนวคิดภาษานี้มากๆ เลยแหละ อิอิ

วันนี้พอแค่นี้ ไว้เดียวค่อยมาต่อ

ภาคสอง ว่าด้วยเรื่องของ Flash (จะยังมีคนอ่านอยู่ไหมเนี่ย ทิ้งช่วงยาว)
ก่อนอื่นต้องท้าวความย้อนไปตั้งแต่ต้นกำเนิด Flash (ผมใช้ Flash มา 10 ปีแล้วครับ ตั้งแต่ Flash 5 ของ Macromedia) Flash แต่แรกเริ่มเดิมทีถูก design มาสำหรับการทำ Animation และเนื่องจากสมัยก่อน Internet เมื่อ 10 กว่าปีที่แล้วก็ช้าเหลือเกิน ทำให้ Flash ถูกบังคับให้ใช้การ Render ภาพแบบ Vector (คือไม่ได้เก็บข้อมูลเป็นเม็ดสี แต่เก็บเป็นสูตรคณิตศาสตร์) ซึ่งส่งผลให้ขยายรูปแล้วไม่แตก (นึกถึง Illustrator ครับ เหมือนกัน) เนื่องจากการส่งข้อมูลแบบ Vector ผ่าน network มันมีขนาดเล็กกว่าส่งข้อมูลเป็น bitmap ตรงๆ มาก (ถ้าใครทำเว็บเมื่อ 10 ปีที่แล้วคุ้นเคยจะจำได้ว่าสมัยก่อนการใส่รูปภาพใหญ่มากๆ พวก jpg ซึ่งนับเป็นการเก็บข้อมูลแบบ bitmap ลงบนเว็บเพจจะนิยมซอยภาพออกเป็นชิ้นเล็กๆ เพื่อที่ว่าเวลาเน็ตกากๆ รูปโหลดไม่สำเร็จ รูปจะได้ไม่ต้องโหลดใหม่ทั้งหมด โหลดแค่ชิ้นที่หายไปก็พอ) Flash จึงเน้นการวาดภาพแบบ Vector มาโดยตลอด ซึ่งก็ส่งผลให้แม้จะเน็ตช้า แต่ก็ยังมี Animation ที่สามารถโหลดได้รวดเร็วพอ ทำให้ Flash เริ่มติดตลาดแต่นั้นมา (ส่วน Shockwave ซึ่งเป็นตัวทำ 3D สมัยนั้นก็จบชีวิตลงเพราะขนาดไฟล์ใหญ่มาก ไม่เหมาะกับอินเตอร์เนตสมัยนั้น)

อย่างไรก็ตามการใช้ภาพแบบ Vector มิได้มีแต่ข้อดีเพียงอย่างเดียว มันก็มีข้อเสียด้วยเพราะเนื่องด้วยการสร้างรูปอาศัยสูตรสมการทางคณิตศาสตร์ นั่นหมายความว่าหากมีวัตถุหลายๆ ชิ้นบนหน้าจอ การคำนวณจะยิ่งมากขึ้นเป็นเงาตามดัว ส่งผลให้ "กระตุกโคตรๆ" นั่นเอง ด้วยเหตุนี้วิธีทำเกมให้ "ไม่กระตุก" จึงต้องย้อนกลับสู่การใช้ Bitmap ซึ่งขยายรูปไม่ได้ แต่ performance ดีกว่าแทน (ไม่มีการคำนวณใดๆ เพราะเก็บแต่เม็ดสี เสียแค่ว่าขยายแล้วภาพแตก) ซึ่งก็จะย้อนมาว่าต้องใช้เทคนิค "Double Buffering" มาช่วยในการ Render ภาพซึงเทคนิคตัวนี้คนทำเกมมือเก๋าน่าจะรู้จักแทบทุกคนอยู่แล้ว มันก็คือการ draw ผืนภาพทุกอย่างลงบน Bitmap หนึ่งภาพซึ่งมีขนาดเท่าหน้าจอเกมพอดีไว้ 2 รูป (Bitmap 2 ก้อน) รูปแรกเอาไว้แสดงให้คนเล่นเห็น ส่วนรูปที่สองแอบเอาไว้ก่อน พอ draw ผืนภาพเม็ดสีครบแล้วค่อยสลับมาแสดงแทน Bitmap ที่โชว์อยู่ ส่วน Bitmap รูปเก่าก็จะถูกนำไป draw ภาพใหม่เป็น frame ถัดไปนั่นเอง วิธีนี้จะช่วยให้การแสดงผลใช้ bitmap แค่รูปเดียวเท่านั้น โดยไม่สนใจว่าจะมีวัตถุใน Bitmap นั้นอยู่กี่ชิ้นเพราะสุดท้ายมันก็คือ Bitmap 1 Bitmap อยู่ดี วิธีนี้จะช่วยเพิ่ม performance ในการวาดรูปได้เป้นอย่างดี

อย่างไรก็ตามเทคนิคนี้ใช่ว่าจะมีแต่ข้อดีเสมอไป เพราะการที่ Bitmap 1 ชิ้นบรรจุ Object หลาย 100 ตัวไว้ด้วยกัน เราจะไม่สามารถแยกได้ออกว่า "Object ไหนเป็น Object ไหน" เวลาคลิก mouse เพราะในทางโปรแกรมจะมองสุดท้ายเป็นเพียง Bitmap 1 ชิ้นเหมือนกันหมด จึงทำให้ต้องมีการคำนวณอยู่ดีว่า mouse คลิกที่ตำแหน่งใดของภาพ และตำแหน่งนั้นมี object ใดอยู่ ซึ่งแน่นอนว่าจะใช้ Event Mouse Click ของ Flash ไม่ได้เลย เพราะมันได้แปลงร่างเป็น Bitmap ไปแล้วเรียบร้อย ซึ่งจะส่งผลให้ Event ใน Flash พวก Mouse Click, Mouse Over, Mouse out ทั้งหลายใช้การไม่ได้ด้วยเช่นกัน function ที่เคยใช้ได้กับ MovieClip, Sprite, DisplayObject ใน Flash ก็จะใช้ไม่ได้ทั้งหมด ต้องมีคนเขียน Engine เพื่อพัฒนาระดับ low level ตรงส่วนนี้เพื่อให้ Event mouse ต่างๆ ยังทำงานได้ครับ จึงเป็นที่มาของสารพัด Engine ในปัจจุบัน

เสมัยนี้มี Game Engine (ทั้งฟรี และไม่ฟรี) ให้เลือกใช้มากมาย Game Engine ก็จะมีหลายประเภทเช่น

• Display Engine - คืออันที่กล่าวไว้ข้างต้น ยิ่งเดี๋ยวนี้มี Engine ที่ใช้ GPU โผล่มาเพิ่มเช่น Starling ยิ่งมันส์ครับ อิอิ
• Physic Engine - ตามชื่อเลยครับ และปกติแล้ว Physic Engine มักจะ Design มาโดยใช้ Display Engine ของตัวเอง หรือไม่ก็ใช้ของ Flash ซึ่งโอกาสจะนำไปรวมกับ Display Engine ตัวดังๆ ตัวอื่นค่อนข้างมีน้อยครับ
• Engine อื่นๆ เช่น Isometric Engine - หรือก็คือการทำเกม 2D ให้มีภาพเอียงๆ เหมือนเกม Farmville นั่นแหละครับ ตัวนี้ก็เช่นกัน มักจะผูกกับ Display Engine ตัวใดตัวหนึ่งไว้

สุดท้ายก็มาอยู่ที่ตัวเราเองว่าจะเลือก Engine ประเภทไหนให้เหมาะสมกับงานของเรา ซึ่งจะดีที่สุดคือต้องหา Engine ที่เป็นแบบ All-in-one ซึ่งมันจะปรับจูนให้ใช้ได้ทุกอย่างแบบเหมาะสมมาแล้ว แต่แน่นอนครับมันหาไม่ได้ง่ายๆ หรอก ยิ่งฟรียิ่งหายาก

จบสำหรับวันนี้ครับ

มาลงชื่ออ่านครับ สนุกดี :D