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

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

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 Application แบบว่าสั้นจริง ๆ เพราะแบตกล้องมันเล่นหมดดื้อ ๆ ก็เลยถ่ายมาได้แค่นี้

httpv://www.youtube.com/watch?v=9ZlxrYeUYTg

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

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 แล้วล่ะก็ อย่าลืมหาตังค์มาเลี้ยงมันด้วยเน้อ

• การประเมินและทดสอบ Instance บน Amazon EC2 ว่าต้องใช้กี่ตัว แล้วก็ใช้ Instance ระดับไหนดี ถึงจะตอบสนองกับตัวเกมได้โดยจ่ายตังค์น้อยที่สุด
• การทำ Configuration Note เพื่อเอาไว้จัดการกับ Amazon EC2 ในกรณีที่ต้องเปลี่ยน Instance เพื่อควบคุมต้นทุน โดยให้การเปลี่ยน Instance และ Configure เสียเวลาน้อยที่สุด
• การทำ Backdoor ให้กับตัวเกม เพื่อให้ข้ามขั้นตอนในการทดสอบได้ ซึ่งเดิมไม่ได้ทำเอาไว้ ทำให้ต้องทดสอบหูตาเหลือก กว่าจะไปถึงจุดที่อยากจะทดสอบจริง ๆ ได้
• การหา Bug ทั้งหลายทั้งปวงที่ยังคงหลบซ่อนอยู่ในตัวเกม โดยเฉพาะตอนที่ผู้เล่นเข้าใช้ทรัพยากรแหล่งเดียวกัน
• การซ่อมแซมคุณสมบัติของเกม ที่เล่นแล้วทำให้ไม่ลื่นไหล ขัดหูขัดตา ไม่อำนวยความสะดวก
• การเปลี่ยนกลไกจาก PayPal มาเป็น Facebook Credits เพื่อหาเงินมาหล่อเลี้ยงตัวเกม
• การเพิ่มคุณสมบัติดึงดูดใจ ที่ทำให้ผู้เล่นไม่รู้สึกว่ากำลังเล่นเกมที่เล่นสบายหรือเล่นยากจนเกินไป

ผ่านมาจะปีนึงแล้ว ผมผลิตชิ้นงานให้กับเกมนี้ไปเป็นจำนวนมาก นับได้เป็นจำนวนเกินร้อยไฟล์ ไม่ว่าจะเป็นการโค้ด PHP + jQuery + CSS, การวาดรูป, การทำเอกสาร Configuration, การทำ Mockup, การทำ Prototype, การทำ Tools เสริม, การทำเอกสารออกแบบฐานข้อมูล, การเตรียมข้อมูลหลักสำหรับบรรจุในฐานข้อมูล เป็นต้น

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

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

ภาพหนึ่งภาพแทนคำล้านคำ ดังนั้น ผมคิดว่าคนที่กำลังศึกษา 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 นะเอ้อ