คลังเก็บป้ายกำกับ: facebook

เกาะไส้ติ่ง 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 ดังนั้น ต้องเขียนให้เป็นภาษาเขียน ใช้ไวยากรณ์ให้ถูกต้องแบบที่ฝรั่งเขาใช้ ไม่ใช่แบบที่คนไทยใช้สื่อสารกันเอง
  • การแปลข้อความในเกม ให้เป็นภาษาท้องถิ่นต่าง ๆ ยังไม่ใช่สิ่งสำคัญในตอนนี้

Callback ของ Facebook Credits

คราวที่แล้วผมเพิ่งจะอธิบายกลไกของ Facebook Credits ไป แต่ว่ามันยังไม่ค่อยจะละเอียดซักเท่าไหร่ งั้นคราวนี้เอาใหม่เลยแล้วกัน เอาแบบละเอียด ๆ ถึงกึ๋นไปเลย บอกกันเจ๋ง ๆ ไปเลยว่ากลไกต่าง ๆ มันเกิดจังหวะไหนบ้าง แล้วก็เกิดตรงไหนบ้าง

Callback ของ Facebook Credits

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

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

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

ใช้ Facebook Credits

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

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

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

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

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 มันยังอ่อนแออยู่ ยังมีจุกจิกปัญหาเล็ก ๆ น้อยอยู่

เข้ามาพร้อม ๆ กันเลยพวก

ช่วงนี้ผมกำลังนั่งซ่อม Beelony ครับ เพราะเจอกับปัญหา Concurrent!!!

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

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

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

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