1. การที่ Facebook ขอให้ใคร ๆ เลิกใช้ FBML ซึ่งตัวเองปั้นมาเองกับมือ แต่ยังคงสนับสนุนอยู่อีกพักใหญ่ ๆ และไม่รู้ว่าจะถึงเมื่อไหร่ที่จะให้เลิกใช้เด็ดขาดไปเลย
2. บังคับให้แอปทุกตัวต้องเปลี่ยนการชำระเงินในทุก ๆ วิธี มาเป็นใช้ Facebook Credits แทน โดยทาง Facebook จะหักหัวคิวอร่อยเหาะที่ 30% ของมูลค่าการซื้อขายในแต่ล่ะครั้ง และถ้าใครไม่ทำตามแล้วตรวจเจอก็จะโดนแบน เรียกว่าโดนไม่ใช่น้อย
3. สั่งให้ทุกแอปต้องมี HTTP Secure เพื่อการรักษาความปลอดภัยที่ล้ำลึก จนไม่ว่าหน้าไหนก็ไม่สามารถจะล่วงล้ำก้ำเกินเข้าไปได้ (ทำให้เหมือนว่าแอปที่สร้างขึ้นมา สำคัญขนาดแอปของสถาบันการเงินเลยทีเดียวเชียว)

พวกเราเคยเอะใจกันมั้ยครับว่า การที่เราต้องเปลี่ยนโน่นนี่นั่นตามเจ้าของ Platform มันทำให้เราเกิดต้นทุน แถมต้นทุนดังกล่าวก็ไม่มีใครมาจ่ายให้เราซะด้วย เราต้องเป็นคนแบกรับเอาไว้เอง!!!

ผมเลยเริ่มมองว่า การทำแอปเพื่อเชื่อมกับ Facebook นั้น เราต้องมากำหนดความสัมพันธ์กันแล้วล่ะ ว่าเราจะสนิทสนมสนุกสนานกับ Facebook แค่ไหน จะเกาะ Facebook ทั้งตัว หรือจะเกาะแค่ลำไส้ใหญ่ หรือจะเกาะแค่ไส้ติ่งของ Facebook ดี?

พอมอง ๆ ไปว่ากลไกในการต่อเชื่อมกับ Facebook มันมีกี่ระดับบ้าง ก็พอจะคลี่ออกมาได้เป็นสามแบบเหมือนกัน ได้แก่

1. ใช้ Authentication, ใช้ Graph API, วางไว้ใน Canvas และต้องใช้ Facebook Credits – แบบนี้เห็นกันอย่างเยอะ เช่น พวกเกมที่ต้องเล่นผ่านหน้าจอของ Facebook เป็นต้น
2. ใช้ Authentication, ใช้ Graph API, ไม่วางไว้ใน Canvas แต่ใช้หน้าเว็บของตัวเอง และไม่ใช้ Facebook Credits – แบบนี้เป็นเฉพาะบางเกมหรือบางแอป ที่ต้องการระบบเครือข่ายสังคมของ Facebook แต่ปฏิเสธที่จะอยู่ในอาณาบริเวณหน้าจอของ Facebook เพราะว่าหน้าจอของ Facebook มันไม่เหมาะสมหรือสอดคล้องกับภาพลักษณ์ของเกมหรือแอป
3. ใช้ Authentication, ไม่ใช้ Graph API, ไม่วางไว้ใน Canvas แต่ใช้หน้าเว็บของตัวเอง และไม่ใช้ Facebook Credits – เราจะไม่เห็นแบบนี้ในเกมหรือแอป แต่จะเห็นในเว็บจำพวก BLOG ที่เขาเอาไว้เขียนเล่าเรื่องราวส่วนตัว อะไรประมาณนั้น

ทั้งสามแบบล้วนต้องใช้ Authentication ของ Facebook และต้องลงทะเบียนแอปกับ Facebook อยู่ดี ซึ่งมันก็คงหนีไม่พ้นที่จะต้องทำตามนโยบายของ Facebook ต่อไป ไม่ว่าจะเป็นการเพิ่ม HTTP Secure เพื่อให้เกิดความปลอดภัย บลา ๆ ๆ เป็นต้น

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

• ความน่าสนใจของเกมบน Facebook จะขึ้นอยู่กับ คุณภาพ, แบรนด์ และราคา
• เกมบน Facebook จะไม่มีทางเปิดตัวได้เลย ถ้าไม่มีการโฆษณา
• การโฆษณาบน Facebook มีราคาสูง ไม่เหมือนกับการโฆษณาผ่าน Adwords แต่ถึงแม้มันจะมีราคาสูง มันก็เข้าถึงผู้ใช้งานบน Facebook ได้ดีกว่าวิธีอื่น ๆ
• มันมีเทคนิคในการโฆษณาบน Facebook ที่ราคาต่ำ ๆ แต่เป็นเทคนิคที่ผู้ทดลอง ต้องลองเจ็บตัวซ้ำ ๆ ซาก ๆ เองก่อนถึงจะได้รู้
• ไม่มีทางที่เกมบน Facebook จะเปิดตัวมาแล้วดังเปรี้ยงปร้าง หรือมีคนเข้ามาเล่นอย่างล้นหลามในทันที ยุคสมัยนั้นมันจบไปแล้ว ต้องรับรู้ไว้เลยว่ามีคู่แข่งขันเยอะมาก ๆ
• ในโลกมีคนเก่ง ๆ อยู่เยอะแยะ ออกไปสู้กับคนอื่นเขา ต้องกินให้น้อยกว่าเขา แต่ต้องทำให้ได้พอ ๆ กับเขา หรือด้อยกว่านิดหน่อยก็ยังดี
• การลอกเลียนแบบเกมที่กำลังเป็นที่นิยมอยู่ คือการฆ่าตัวตาย เพราะผู้เล่นย่อมเลือกเล่นเกมต้นแบบซึ่งมันดีกว่าอยู่แล้ว
• ผู้เล่นจะมีเกมในดวงใจอยู่ 2 ถึง 3 เกม จงทำให้เกมของเราเป็นเกมในดวงใจเกมที่ 4 หรือ 5 เพราะเวลาของผู้เล่นก็ไม่ได้มีมากมายอะไร เขาย่อมไม่มาสนใจเกมได้เป็นสิบ ๆ เกมหรอก
• การเตรียม Infrastructure ใหญ่โตเอาไว้ เพราะคิดว่าจะมีผู้เล่นมากมาย กรูกันเข้ามาเล่นในฉับพลันทันที คือความเสี่ยง เพราะถ้าไม่มีผู้เล่นมากมายตามที่คิดเอาไว้ ต้นทุนของ Infrastructure มันจะย้อนกลับมาทำให้เราล่มจมทันที
• การใช้ Cloud Computing เป็น Infrastructure นี่มันโคตรดีมาก ๆ เพราะถึงแม้ราคาปอนด์ต่อปอนด์จะแพงกว่าพวก Virtual Private Server หรือ Dedicated Server แต่ถ้าถึงเวลากลียุคทางต้นทุน มันก็ยืดหยุ่นจนนำพาให้เรารอดได้เหมือนกัน
• การลดต้นทุนการพัฒนา, ลดต้นทุน Infrastructure และลดต้นทุนโฆษณา โดยไม่ทำให้การขับเคลื่อนเกมบน Facebook ได้รับผลกระทบ คือ ปัจจัยสำคัญที่จะทำให้เกมบน Facebook อยู่รอดไปได้เรื่อย ๆ โดยไม่เจ๊งบ๊งไปซะก่อน
• คนอเมริกาเล่นเกมบน Facebook เยอะก็จริง แต่คนฟิลิปปินส์และคนอินโดนีเซีย ก็เล่นเกมเยอะไม่แพ้ชาติใดในโลกเหมือนกัน
• การเขียนโปรแกรมคอมพิวเตอร์เก่ง, การวาดรูปเก่ง และการทำเสียงประกอบเกมได้เก่ง แทบกลายเป็นปัจจัยรองไปเลยในการทำเกมบน Facebook เพราะสิ่งที่สำคัญมันคือการจับกลุ่มผู้เล่นแบบเฉพาะเจาะจง และการทำให้ผู้เล่นจงรักภักดีต่อเกมต่างหาก ซึ่งทักษะที่จะทำได้มันเป็นทักษะทาง “การตลาด” เฟ้ย ไม่ใช่ทักษะทาง “วิทยาศาสตร์” เล้ย
• ถ้าลูกเล่นหรือรูปแบบของเกมมันไม่โดน ต้องกล้าหาญที่จะรื้อถึงแก่นในทันที และถ้าการรื้อมันทำให้ผู้เล่นเกิดผลกระทบ ก็ต้องเตรียมการเพื่อชดใช้ให้แก่ผู้เล่น อย่างสมน้ำสมเนื้อเหมือนกัน
• ผู้เล่นที่จงรักภักดีเป็นสิ่งที่สำคัญมาก เพราะเขาจะพยายามโน้มน้าว ชักชวน เผยแพร่ เพื่อให้เพื่อน ๆ ของเขาเข้ามาเล่นเกมที่เขากำลังเล่น ถึงแม้เพื่อนของเขาจะเล่นเกมอื่นอย่างติดหนึบอยู่แล้วก็ตาม
• ภาษาอังกฤษเป็นสิ่งที่สำคัญมาก ในการสื่อสารกับผู้เล่นเกมบน Facebook ดังนั้น ต้องเขียนให้เป็นภาษาเขียน ใช้ไวยากรณ์ให้ถูกต้องแบบที่ฝรั่งเขาใช้ ไม่ใช่แบบที่คนไทยใช้สื่อสารกันเอง
• การแปลข้อความในเกม ให้เป็นภาษาท้องถิ่นต่าง ๆ ยังไม่ใช่สิ่งสำคัญในตอนนี้

ภาพหนึ่งภาพแทนคำล้านคำ ดังนั้น ผมคิดว่าคนที่กำลังศึกษา Facebook Credits อยู่คงจะเข้าใจ ส่วนคนที่ยังไม่เคยศึกษาแต่กำลังคิดจะศึกษา เห็นแล้วก็คงจะพอเข้าใจได้เหมือนกันว่า จุดสำคัญของการเชื่อมโยงกับ Facebook Credits อยู่ตรงการ Callback ซึ่งจะแอบซ่อนอยู่ในส่วนของ PHP เป็นสำคัญ

ทาง Facebook ได้กำหนดลำดับขั้นของ Facebook Credits ไว้ 3 ขั้นอันได้แก่ Info, Placed และ Settled โดยให้ Callback ของแอ็ปของเรา เป็นตัวกำหนดและปรับเปลี่ยนลำดับขั้นโดยการตัดสินใจของแอ็บเราเอง

ส่วนจะข้ามขั้นตอนจาก Info ไป Settled ได้เลยหรือเปล่า อันนี้ไม่เคยลองเหมือนกัน

ผมเองก็ต้องเปลี่ยนกลไกของเกมของผมเหมือนกัน คือเปลี่ยนจาก “วิธีการชำระเงิน” ด้วย PayPal มาเป็น Facebook Credits โดยขอคงสิทธิ์ของ “เงินตราเสมือนจริง” ในเกมของตนเองเอาไว้ ไม่ใช้ Facebook Credits เพื่อเป็น “เงินตราเสมือนจริง” แต่ประการใด!!!

ทีนี้โดยทางเทคนิคต้องทำยังไงบ้างล่ะ? ก็ต้องโยนโค้ดที่ใช้เชื่อมโยงกับ Web Services ของ PayPal ทิ้งไปสินะ แล้วจากนั้นก็เชื่อมโยงกับ Facebook Credits ผ่านทาง SDK (Javascript + PHP) ที่ทาง Facebook จัดเตรียมเอาไว้ให้ พร้อมทั้งเข้าไปอ่านเอกสารของ Facebook เพื่อทำความเข้าใจว่ากลไกของ Facebook Credits อ่ะมันเป็นยังไง

Facebook เองก็ทำ Flowchart เพื่ออธิบายกลไกให้เราเข้าใจ Facebook Credits เอาไว้บ้างเหมือนกัน แต่ประทานโทษอ่ะ มันไม่เห็นจะสอดคล้องกับความเป็นจริงในทางเทคนิคของโค้ดโปรแกรมเล้ย ดังนั้น ผมก็เลยต้องวาดเพื่อทำความเข้าใจเอง แบบข้างล่างนี้

และนอกจากนี้ ผมยังได้พบจุดสังเกตในทางเทคนิค เกี่ยวกับ Facebook Credits อีกหลายอย่าง ไม่ว่าจะเป็น …

• ไม่ว่าผู้เล่นจะซื้อหรือไม่ซื้อของ Facebook ก็จะสร้างหมายเลข Order ให้ ถ้ามีการร้องขอ Dialog จาก Facebook
• Facebook Credits API จะส่งข้อมูลที่ไม่ถูกเข้ารหัสมาหนึ่งชุด และข้อมูลที่ถูกเข้ารหัสมาอีกหนึ่งชุด กลับมาที่ Callback ของเรา (ภายหลังจากการร้องขอ Dialog) และเมื่อนำข้อมูลชุดที่สองที่ถูกเข้ารหัสมาถอดรหัสออก เราจะพบว่าข้อมูลที่ได้มันเหมือนเป๊ะกับชุดที่หนึ่งที่ไม่ถูกเข้ารหัสเลยว่ะ ซึ่งก็หมายความว่า Facebook จะให้เราตรวจสอบนั่นเอง ว่าเรากำลังโดน Hack หรือเปล่า โดนโกงโดยการปลอม JSON หรือเปล่า อะไรประมาณนี้
• ตอนวาง Order ผ่านมาเป็น Callback เข้า PHP แต่ตอนจบ Order ดันผ่านมาเป็น Callback ใน Javascript แหม ทำได้ยอกย้อนจริง ๆ
• ต้องไม่เขียนโค้ดให้เว่อร์เกินกว่าที่ Facebook Credits API กำหนดไว้ ยกตัวอย่างเช่น ถ้าเขาให้กำหนด Callback เป็น Function แยกต่างหาก ก็ต้องทำตามเขา อย่าบ้าพลังไปผนวก Callback เข้ากับ Function ที่จะเรียกมัน หรือพูดง่าย ๆ ก็คือ Facebook Credits API มันยังอ่อนแออยู่ ยังมีจุกจิกปัญหาเล็ก ๆ น้อยอยู่

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

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

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

สุดท้าย ผมเลือกแบบที่สองอ่ะ เพราะมันง่ายดี แต่คงต้องลองตอนทดสอบใหญ่อีกทีว่ามันจะโอเคป่าว?

แต่ถึงมันจะเป็นรุ่น Alpha แต่มันก็มีคุณสมบัติใกล้เคียงกับตัว Production นะเอ้อ

Container

1. EasyPHP เอาไว้ทดสอบโปรแกรม

Editor

1. Notepad++ เอาไว้เขียนโปรแกรม
2. Photoshop CS5 เอาไว้วาดรูป

Software Developerment Kits

1. Facebook PHP SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย PHP
2. Facebook Javascript SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย Javascript เพื่อเสริมลูกเล่นในการตอบโต้
3. jQuery ใช้เพราะขี้เกียจมาทำ Javascript Framework เอง (โดยเฉพาะ AJAX นี่ ขี้เกียจทำเองมากกกกกกกกก)
4. jQueryUI เอาไว้ทำพวก Dialog, Slide และ Tab

Manual (อันนี้สำคัญมาก ถ้าไม่มีนี่ ถึงขนาดหูหนวกตาบอดเลยทีเดียว)

1. Tags HTML เอาไว้หารายละเอียดของ Tag HTML เพราะผมไม่เคยจำ
2. Javascript ไอ้เจ้า Javascript ผมก็ไม่เคยจำ
3. MySQL 5.1 ลำพังคำสั่ง SQL พื้น ๆ น่ะจำไม่ยากหรอก แต่ถ้าเป็นพวกคำสั่งเล็ก ๆ น้อย ๆ เนี่ย จำไม่ได้อ่ะ T-T
4. CSS นี่ผมก็ไม่จำ เวลาจะใช้ก็ค้น ๆ เอา
5. Facebook Graph API พอดีผมเริ่มมาทำ Facebook App ตอนที่ Facebook เปลี่ยน Core API มาเป็น Graph API พอดี ก็เลยไม่ต้องไปอ่านของเก่า ดีเหมือนกัน
6. Facebook Javascript API จำไม่ได้อ่ะ ไม่เคยจำ อาศัยอ่าน ๆ แล้วทำตาม
7. Regular Expression เอาไว้ค้นไวยากรณ์ประหลาด ๆ ที่ไม่ค่อยได้ใช้บ่อยนัก
8. PHP ต้องใช้ เพราะไม่เคยจำคำสั่ง

ส่วนที่เหลือก็เป็นจินตนาการ ความคิดสร้างสรรค์ และก็ความอึด (เพราะต้องทำซ้ำเป็นร้อย ๆ ครั้ง เพื่อให้ได้ผลลัพธ์ที่ถูกต้องแม่นยำ ทำซ้ำได้ และเป็นวิทยาศาสตร์)

มารที่มารบกวนผม ทำให้ผมพัฒนาเกมฯที่ว่าไปไม่ถึงไหน ไม่ใช่กลไก Facebook, ไม่ใช่ jQuery และไม่ใช่ PHP หากแต่เป็น Web Browser!!!

มันเป็นเรื่องที่แย่มาก ที่ Web Browser ที่ใช้โดยคนส่วนน้อย ไม่ว่าจะเป็น Firefox, Chrome, Opera หรือ Safari ไม่เคยสร้างปัญหาจุกจิกให้กับผมเลย ในขณะที่ Internet Explorer ซึ่งเป็น Web Browser ที่ใช้โดยคนส่วนใหญ่ กลับสร้างปัญหาจุกจิกให้กับผมได้มากมายอย่างยิ่ง

ไอ้อะไรที่ทำบน IE ได้ จะทำบนตัวอื่น ๆ ไม่ได้ และไอ้อะไรที่ทำบนตัวอื่น ๆ ได้ กลับไม่สามารถทำบน IE ได้!!!

เคล็ดอย่างหนึ่งที่ผมพบก็คือ IE เป็น Art ตัวแม่!!! มันจะคอยจับผิดไอ้โน่นไอ้นี่อยู่ตลอดเวลา แต่ไม่เคยบอกเราจริง ๆ แม่น ๆ หรือตรง ๆ ตำแหน่ง ว่าไอ้ที่มันบอกว่าผิดอ่ะ มันตรงไหนกันแน่ บอกอ้อม ๆ อยู่นั่นแหล่ะ ที่สำคัญยังเถรตรงติงต๊องอีกต่างหาก ไอ้บางอย่างที่ Web Browser ตัวอื่นเขาหยวน ๆ มันก็ไม่หยวน

ส่วนไอ้บางอย่างที่ชาวบ้านเขาไม่หยวนแต่มันกลับหยวน!!!

T-T ผมเพิ่งจะได้เข้าใจอย่างลึกซึ้งก็ช่วงนี้นี่แหล่ะ ว่าความรู้สึกเสน่หาต่อ IE ของเหล่าคนไอทีไทยนั้นมันเป็นแบบนี้นี่เอง!

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

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

1. ผมยินดีที่จะสร้าง Framework แบบ Model (เฉย ๆ) มากกว่าที่จะเลือกใช้ Framework แบบ Model-View-Controller เพราะมันเบาสบายอย่างที่ไม่เคยรู้สึกมาก่อน
2. โปรแกรม Photoshop เป็นโปรแกรมยอดนิยมชนิดเดียวที่ผมไม่เคยศึกษา เพราะรู้สึกว่ามันใช้ยาก สับสน และน่ากลัว แต่หลังจากที่ได้ลองใช้มันอย่างจริงจัง ทำให้ผมรู้ว่า สิ่งที่น่ากลัวไม่ใช่เครื่องมือของ Photoshop (หัดแค่สองวันก็เป็นแล้ว) หากแต่เป็นจินตนาการทางจิตรกรรมอันตีบตันของผมต่างหาก (สรุปคือผมกลัว Photoshop เพราะผมกระจอกเรื่องศิลปะนั่นเอง)
3. ผมเรียนโปรแกรมคอมพิวเตอร์ทุกตัว โดยการทดลองใช้งานมันด้วยตัวเองหรืออ่านจากคู่มือ (ไม่ต้องให้ใครมาสอนเฟ้ย) แต่กับโปรแกรม Blender ผมกลับต้องไปดาวน์โหลดคลิปวีดีโอที่สอนเรื่องนี้โดยเฉพาะมานั่งเรียน (เป็นคลิปวีดีโอที่ดีมาก ต้องขอบคุณ SIPA มา ณ ที่นี้) มันโคตรเป็นเครื่องมือที่ซับซ้อนจนไม่มีปัญญาหัดเองจริง ๆ เลย (ว่ะ) ขอบอก
4. การเขียนโปรแกรมเพื่อให้ทำงานบน Platform เฉพาะ แม้จะมีข้อเสียร้ายแรงตรงที่เราต้องผูกยึดกับ Platform ดังกล่าว แต่ก็มีข้อดีสุดโต่งอยู่ที่เราไม่จำเป็นต้องจัดการเรื่อง Authentication และ Theme เองอีกต่อไป (อันนี้ดีโคตร ๆ เชียวแหล่ะ)
5. ผมเพิ่งจะค้นพบว่า การใช้งาน array บน php สามารถพลิกแพลงได้อย่างสลับซับซ้อน เกินจินตนาการอย่างไม่มีที่สิ้นสุด
6. ไม่น่าเชื่อว่า ทักษะในการออกแบบฐานข้อมูล จะสำคัญพอ ๆ กับทักษะในการเขียนโปรแกรม และทักษะในการกำหนด Infrastructure ที่เราใช้ (ตอนแรกผมนึกว่าฐานข้อมูลน่าจะสำคัญน้อยกว่านิดนึง)

ที่สำคัญ มันทำให้ผมเรียบเรียงได้ว่า การเขียนเกมบน Facebook นั้น เราจะต้องรู้และมีทักษะหลาย ๆ อย่างมากมายเลย ซึ่งได้แก่ …

รู้ภาษา HTML, เขียน CSS เป็น, เขียนภาษา Script เป็น (เช่น PHP, JavaScript, ActionScript, ECMAScript), รู้หลักการ OOP, รู้หลักการ Model-View-Controller, เขียน SQL เป็น, รู้กลไกของ RDBMS ที่ใช้ (เช่น mySQL), ออกแบบฐานข้อมูลได้ (เช่น แบบ RDS), เข้าใจใน Facebook Platform, เข้าใจใน Web Service (เช่น REST, JSON), ใช้ Graphic Editor คล่อง (เช่น Photoshop), ทำ 3D Modeling เป็น (เช่น Blender), เขียน Adobe Flash ได้, ใช้ Javascript Framework เป็น (เช่น jQuery), วาดรูปเก่ง, ติดตั้ง Infrastructure ได้ (เช่น Shared Hosting, Dedicated Server, Co-Location, Virtual Private Server, Cloud Computing) เป็นต้น

ต่อไปไม่แน่ว่า อาจจะต้องใช้ความรู้ชั้นสูงจำพวก AI ด้วยก็เป็นได้!!!

สรุปว่า การเขียนเกมบน Facebook นั้นไซร้ ช่างใช้ทักษะได้ครอบจักรวาลจริง ๆ เลย พับผ่าสิ!!!

อธิบายภาพข้างบนสั้น ๆ ได้ดังนี้

1. คุณต้องติดตั้ง Facebook Canvas เป็น, เข้าใจใน Facebook Graph API และเข้าใจใน Facebook Client Libraries (ทั้งหมดฟรี)
2. คุณต้องจดทะเบียน Domain (เสียตังค์) กับ Domain Registrar (Domain ที่ว่าก็คือ ไอ้พวก http://www.yourdomain.com อะไรเทือกนั้นแหล่ะ) เช่น Godaddy เป็นต้น
3. คุณต้องจดทะเบียน DNS (เสียตังค์) กับ DNS Provider เพื่อที่คุณจะได้ผูก Domain ของคุณเข้ากับ Amazon EC2 ได้
4. คุณต้องสมัครเพื่อใช้งาน Amazon EC2 (ไม่ต้องเสียตังค์) แล้วเข้าไปสร้าง Application + Db Instance (เสียตังค์ตามการใช้งาน) โดยสร้างขึ้นมาแค่ Instance เดียวก็พอ (ต่อไปถ้าคุณเก่ง คุณสามารถสร้างเยอะ ๆ ก็ได้นะเออ)
5. คุณต้องสร้าง Elastic IP ขึ้นมา (เสียตังค์) เพื่อให้ Instance ของคุณ สามารถติดต่อกับโลกภายนอกได้ โดยสร้างแค่ IP เดียวก็พอ (ก็ใช้แค่ Instance เดียวไง ก็เลยใช้แค่ IP เดียวก็พอ)
6. บังเอิญว่า Instance ใน Amazon EC2 เป็นพวกความจำสั้น ดังนั้น ถ้ามันโดน Restart หรือ Terminate เมื่อไหร่ล่ะก็ มันจะลืมทุกอย่างไปหมดเลย (รวมทั้ง Code และ DB ด้วย) ดังนั้น น่าจะเป็นการดี หากเราจะสร้าง Elastic Block Store ขึ้นมา (เสียตังค์) เพื่อเอามาเป็นที่พักข้อมูลจาก Instance เผื่อว่า Instance มันล่มหรืออะไรยังไง มันจะได้มีตัวสำรอง
7. แต่ถ้าคุณคิดว่า Elastic Block Store จะไม่ชัวร์ กลัวว่าตัวมันเองก็อาจจะล่ม คุณก็สามารถจะติดตั้ง Snapshot To S3 (เสียตังค์) เพื่อให้มันทยอยโอนข้อมูลของคุณ ไปเก็บไว้ใน Bucket (เสียตังค์) ของ Amazon S3 ก็ได้ (คุณต้องสมัครเพื่อขอใช้ Amazon S3 อันนี้ฟรี ไม่เสียตังค์)

สรุปว่าจะประมวลผล Facebook Application บน Amazon EC2 ก็ต้องจ่ายพอตัวเหมือนกัน แต่ถ้าทำออกมาดี ๆ ก็น่่าจะคุ้มอ่ะนะ เพราะถ้าให้ไปประมวลผลบน Shared Hosting ก็คงไม่ได้ เพราะทรัพยากรจำกัดจำเขี่ยเหลือเกิน เกิดผีเข้าผีออก มีคนเข้า Facebook Application ของเราเยอะขึ้นมา ไปทำ Shared Hosting เขาล่ม เดี๋ยวเขาจะเฉดหัวออกมาแทบไม่ทัน

ส่วนจะไปประมวลผลบน Dedicated Server หรือ Virtual Private Server ก็ยุ่งยาก ต้องติดตั้งทุกอย่างเองทั้งหมด (Amazon EC2 มันเทพ สั่งสร้าง Instance โป้งเดียว มันติดตั้งระบบปฏิบัติการและปรับแต่งทุกอย่างให้หมดเลย)

ยิ่งเป็น Co-Location ก็ยิ่งแล้วใหญ่ เพราะเดี๋ยวนี้ฮาร์ดแวร์มันทันสมัยขึ้นแทบทุกวี่ทุกวัน จะให้เช่าซื้อ Server มาเป็นของตัวเองมันจะไม่คุ้ม แบบว่ายังไม่ทันไร Server ที่มีก็ตกยุคซะแล้ว หรือถ้าไม่ตกยุค แต่ต้องมาอัด RAM ทำ Server Farm เองก็หลังแอ่นเหมือนกัน