คลังเก็บหมวดหมู่: Facebook

โม้เกี่ยวกับ Facebook Platform และ Facebook Application

เลิกทำเกม Beelony

หลังจากที่ผมเปิดตัวเกม Beelony บน Facebook ไปได้สองเดือน ผมก็ตัดสินใจเลิกทำมันต่อด้วยเหตุผลดังต่อไปนี้

  1. ไม่สนุก อันนี้น้องชายผมซึ่งเล่นเกมเก่งยืนยัน เขาบอกว่าเกมสนุกคือเกมที่ต้องมีภาพสวย ๆ และมีด่านให้เล่นเยอะ ๆ ซึ่งเกมที่ผมสร้างมันตอบโจทย์ตรงนี้ไม่ได้ มันไม่สวยเด่น มันมีด่า่นน้อยจริง ๆ
  2. ผมวาดรูปไม่เก่ง ถ้าอยากได้ภาพสวย ผมมีทางเลือกสองทาง คือ หัดวาดรูปให้เก่ง กับ จ้างคนเก่ง ๆ มาทำงานให้
  3. การหัดวาดรูปให้เก่ง ต้องใช้ความมานะพยายาม หัดซ้ำแล้วซ้ำเล่าจนเก่งขึ้นมา ซึ่งมันเสียเวลาอย่างมาก ในขณะที่การจ้างคนเก่ง ๆ มาทำงานให้ มันเสียเวลาน้อยกว่า แต่มันก็ต้องมีต้นทุนเงินตราเกิดขึ้น ซึ่งผมไม่ได้ตั้งงบประมาณสำหรับเรื่องนี้เอาไว้
  4. ผมพอจะเขียนโปรแกรมคอมพิวเตอร์เองได้ ไม่ต้องจ้างใครให้มาทำ แต่เมื่อเกมมีความซับซ้อนมากขึ้น กลายเป็นว่าต้องทดสอบมากขึ้นหลายเท่าตัว ทำให้เสียเวลาถึงสองในสามของเวลาในการพัฒนาเกมในแต่ล่ะช่วง เพราะผมไม่ใช่นักทดสอบโปรแกรมฯมืออาชีพ (ซักเท่าไหร่)
  5. การปรับรูปแบบของเกมเพื่อให้ตอบสนองต่อเกมเมอร์ เป็นเรื่องง่ายในทางทฤษฎี แต่เป็นเรื่องยากในทางปฏิบัติ เพราะทุกครั้งที่เปลี่ยน มันต้องรื้อแหลกและต้องใช้เวลา
  6. น้องชายผมบอกผมว่า ใน Facebook ยังมีเกมเจ๋ง ๆ อีกเยอะที่ไม่ดัง ไม่มีคนเล่น ดังนั้น การตั้งหน้าตั้งตาทำเกมให้ “เจ๋ง” แค่อย่างเดียว มันก็ยังไม่พอ ดังนั้น ต้องทำให้มัน “โดน”
  7. ผมต้องใช้เงินเพื่อทุ่มเทในเรื่องอื่นซึ่งกะทันหันกว่า การจ่ายเงินกับ Infrastructure และโฆษณา เพื่อใช้ขับเคลื่อนเกมที่คุณภาพยังไม่ถึงขั้น ถือเป็นความฟุ่มเฟือยเกินไป ไม่ควรดื้อรั้น หลอกตัวเอง
  8. การทำเกมให้ “โดน” เป็นศาสตร์ลี้ลับ ไม่มีสอนในโรงเรียน หาไม่เจอจากประสบการณ์ พรสวรรค์ก็ไม่ช่วยอะไร มีแต่บุญวาสนาอย่างเดียว ที่จะชี้นำพาไปได้

สรุปค่าเสียหายสำหรับการขับเคลื่อน Beelony ตลอดสองเดือน ผมเสียเงินไปประมาณ 24,000+ บาท เป็นการเสียไปเพื่อได้ประสบการณ์เพียงอย่างเดียวจริง ๆ นะเนี่ย!!!!

เกาะไส้ติ่ง Facebook Platform for Developer

Facebook Platform for Developer มีการปรับเปลี่ยนอยู่เรื่อย ๆ ครับ ออกแนวสามวันจาก Facebook เป็นอื่น แต่ถึงจะปรับเปลี่ยนบ่อยยังไง มันก็ต้องมีอยู่จุด ๆ หนึ่งที่ถือว่าเป็นการปรับเปลี่ยนใหญ่ ซึ่งผมนับได้เป็นจำนวนสามจุด ได้แก่

  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 มันเปลี่ยนบ่อยซะเหลือเกิน แถมเปลี่ยนแต่ล่ะครั้งก็เกิดต้นทุนเงินตราและต้นทุนแรงงาน อันนี้เราก็คงต้องมาพิจารณากันแล้วล่ะมั้ง ว่าเราจะเกาะลำไส้ใหญ่เขา หรือเราจะเกาะเขาแค่ปลายไส้ติ่งดี เพื่อเวลาที่เราจะฉีกตัวออกมาใหญ่ของเราเอง พังผืดจากลำไส้ใหญ่ของเขา มันจะได้ไม่มายึดติดเราจนเราขยับไม่ได้อ่ะ

การยืนบนพื้นที่แคบ ๆ โดยไม่ให้ล้ม

หลังจากผมปล่อย Beelony ออกมาให้ผู้เล่นได้เล่นมาเป็นเวลาหนึ่งเดือน ผมก็ได้เจอเรื่องน่าสนใจหลาย ๆ อย่าง เลยว่าจะเล่าให้อ่านกันดังนี้

  • ความน่าสนใจของเกมบน 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 Application

พอดีผมเพิ่งซื้อขาตั้งกล้องมา เห่อมาก เลยเอามาลองทำ Video Log ดู เพราะเปิดบล็อกแห่งนี้มาก็ 6 ปีแล้ว ไม่อยากนำเสนอแบบซ้ำซากจำเจแล้ว เลยซัดซะหนึ่งดอก

โดยจะชวนพวกเราคุยสั้น ๆ เกี่ยวกับ Facebook Application แบบว่าสั้นจริง ๆ เพราะแบตกล้องมันเล่นหมดดื้อ ๆ ก็เลยถ่ายมาได้แค่นี้

การติดตั้ง Web Application บน Infrastructure แบบเปิด

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

งั้นมาดูวิธีของผมกันดีกว่า เอาแบบจากประสบการณ์จริงกันไปเลย

  1. ต้องเลือกก่อนว่าจะเอา Web Application ของเราไปขับเคลื่อนที่ไหน อย่างกรณีของผม ผมใช้บริการ Cloud Computing ของ Amazon Web Services เป็นตัวจัดการเรื่องนี้ โดยเน้นใช้งานแต่บริการของ Amazon EC2 เพื่อเอามาทำเป็น Instance Server จำนวน 2 Instance ให้ Instance นึงไว้ขับเคลื่อน Application และอีก Instance นึงไว้ขับเคลื่อน Database โดยผมเลือกใช้งานโซนแคลิฟอร์เนียเหนือ และเลือกใช้ Image แบบ LAMP หมายเลข ami-1d6a3858 ซึ่งเป็น LAMPStack ที่มีระบบปฏิบัติการเป็น Ubuntu รุ่น 10.04 แบบ 32 bit สอดไส้ด้วย PHP รุ่น 5.3 มี Virtual Core 1 ECU และ RAM 1.7 GB (เล็กชิบเป๋ง)
  2. จากนั้นก็โยนโค้ดไว้ที่ Application Instance และโยนฐานข้อมูลไปไว้ที่ Database Instance โดยที่ Database Instance จะพิเศษหน่อย เพราะผมจะไม่ใช้เนื้อที่ของ Database Instance เพื่อเก็บฐานข้อมูล แต่จะใช้ Amazon Elastic Block Store ที่ผมผูกไว้กับ Database Instance เป็นตัวเก็บข้อมูลแทน
  3. พอได้ขุมพลังในการขับเคลื่อนและได้ทำการเชื่อมโยง Application Instance กับ Database Instance ผ่านการ Configure อะไรหลาย ๆ อย่างแล้ว ทีนี้ก็ต้องมาดูเรื่อง Domain บ้าง โดยผมได้จดโดเมนเอาไว้ก่อนเรียบร้อยแล้วที่ Go Daddy
  4. คราวนี้ก็ต้องเอา Domain ที่จดทะเบียนไว้ ไปผูกโยงเข้ากับ Application Instance ที่เตรียมเอาไว้ก่อนแล้ว โดยผมได้เลือกใช้บริการของ Dynamic DNS แบบ Custom DNS Package จากนั้นก็ Configure ไำอ้เจ้า CNAME กับ A-Records เพื่อเชื่อมโยงระหว่างชื่อ Domain กับเลข IP ของ Application Instance เข้าไว้ด้วยกัน
  5. และท้ายที่สุด ก็ต้องกลับไป Configure ที่ Go Daddy เพื่อบอกให้มันรู้ว่า ตกลง Domain ที่ผมจดทะเบียนไว้ มันเชื่อมโยงไปยัง Primary Name Server ใด ซึ่งในที่นี้ก็คือ Primary Name Server ของ Dynamic DNS นั่นเอง โดยผมใส่ลงไป 5 Name Server เลย ใช้มันให้คุ้ม ทำ Load Balancing แบบเว่อร์ ๆ เพราะผมเสียดายมาก เนื่องจาก Package ที่จ่ายตังค์ไป มันเปิดให้เรากำหนด DNS ได้ถึง 75+ Domain แต่ประทานโทษ ผมใช้มันสำหรับ Domain เดียว โคตรเสียดายตังค์เลย T-T

เมื่อเราทำมาถึงขั้นตอนนี้ ก็ถือว่าทุกอย่างเรียบร้อยหมดแล้ว คราวนี้เราก็จะสามารถลองใช้งาน Web Application ของเราได้ โดยการเปิด Web Browser แล้วพิมพ์ URL ของ Domain เราเข้าไป แล้วรอซักชั่วอึดใจมด จากนั้น Web Application ของเราก็จะปรากฎขึ้นมา … อย่างสวยงามเลยทีเดียวเชียว!!!

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