การสร้างเกมดี ๆ ขึ้นมาสักหนึ่งเกมนั้นประกอบด้วยหลายส่วน เริ่มตั้งแต่การสร้างเรื่องราวของเกมให้น่าสนใจ, การออกแบบและการสร้างตัวละครทั้งในรูปแบบ 2D/3D ให้สวยงามมีชีวิตชีวา, การออกแบบและพัฒนารูปแบบการเล่นในเกมให้สนุกตื่นเต้น, การออกแบบ level กำหนดค่าความสมดุลภายในระบบของเกมเพื่อให้ผู้เล่นยังคงสนุกกับเกม เล่นเกมได้นาน ๆ, การออกแบบและพัฒนาส่วนติดต่อผู้ใช้ UI/UXหรือ Frontend ใช้เข้าใจง่าย และถ้าหากเกมนั้นมีการเล่นร่วมกับผู้เล่นหลายคนแบบ Multi-player, Social game ก็ต้องมีการทำงานฝั่ง Backend ซึ่งรับ/ส่งข้อมูลนำไปเก็บไว้บน Server

ในปัจจุบันเกมบน Mobile devices เป็นที่นิยมเพราะสามารถพกพาไปเล่นได้ทุกที่และส่วนมากก็เป็นเกมแบบ Multi-player ผู้เล่นต้องเล่นร่วมกับผู้เล่นคนอื่น คำถามสำหรับคนทำเกม (ซึ่งในที่นี้จะเน้นส่วนของ Backend เป็นหลัก) คือ

“ทำอย่างไรเกมนั้นจึงจะสามารถเชื่อมผู้เล่นแต่ละคนที่ใช้ Mobile devices ต่างกันให้สามารถเล่นเกมด้วยกันได้?”

คำตอบคือการสร้าง Interface ให้ client และ server ติดต่อกันได้และทุกวันนี้ Mobile devices สามารถเชื่อมต่ออินเทอร์เน็ตรับส่งข้อมูลผ่าน HTTP protocol ได้แทบทุกเครื่องอยู่แล้ว platform ที่เราเลือกใช้จึงต้องสามารถทำงานบน HTTP ได้ หน้าที่ของ Backend developer คือการสร้าง Webservices หรือ API (Application Programming Interface) เพื่อให้ Frontend หรือตัวเกมเรียกใช้ได้อย่างราบรื่น

ความน่าสนใจในงานฝั่ง Backend ไม่ใช่แค่การพัฒนา API ให้ทำงานได้ถูกต้องแต่หมายถึงการจะทำอย่างไรให้ API ยังทำงานได้ดีเมื่อมีผู้ใช้งานจำนวนมากพร้อมกัน ทำอย่างไรให้ API ทำงานอยู่ตลอดเวลาและทำอย่างไรให้ API มีคุณสมบัติ Zero downtime ซึ่งหมายถึงระบบต้องไม่ล่มเลยขณะที่ทำการ deploy หรือ update API version ใหม่ คำถามเหล่านี้เป็นความท้าทายที่ Backend developer ต้องพบเจอและหาคำตอบที่ดีที่สุดมาตอบให้ได้

วัฒธรรมการทำงานของเรา

กระบวนการทำงาน

ที่ Infinity Levels Studio วิธีการทำงานของเราอยู่บนพื้นฐานแนวคิดแบบ Agile ทุกเช้าก่อนเริ่มงานจะมี Scrum meeting หรือ Stand up meeting สั้น ๆ ประมาณ 10-15 นาทีเพื่อให้ทุกคนเล่าถึงการทำงานในวันที่ผ่านมาว่ามีปัญหาในการทำงาน (Blocker) หรือไม่ อะไรที่ทำไปแล้วและวันนี้จะทำอะไรบ้างทำให้เห็นปัญหาและแก้ปัญหาได้รวดเร็ว การตั้งเป้าหมายก่อนการทำงานทำให้โฟกัสอยู่กับงาน การ Scrum ตอนเช้าเป็นการพูดคุยกันคร่าว ๆ หากมีรายละเอียดซึ่งต้องลงลึกในเชิงเทคนิคก็จะมีการประชุมทีมย่อยอีกครั้ง

เราแบ่งการทำงานออกเป็น Sprint แต่ละ Sprint มีระยะเวลาประมาณ 1-2 สัปดาห์เมื่อจบแต่ละ Sprint จะต้องมีผลงานที่สามารถทำงานออกมาเสมอ การที่มีผลงานออกมาหลังจบ Sprint ทำให้รู้ได้ว่าสิ่งที่เราทำนั้นมาถูกทางหรือไม่ซึ่งหากไม่เป็นไปตามที่เราวางแผนไว้ก็สามารถปรับเปลี่ยนได้ กระบวนการทำงานมียืดหยุ่นสามารถรับมือกับการเปลี่ยนแปลงได้ดีและไม่ต้องเสียเวลาสร้างสิ่งที่ไม่จำเป็น เมื่อผ่านไปหลาย Sprint ผลงานก็จะเป็นรูปเป็นร่างมากขึ้น

กระบวนการเชิงเทคนิค

“การสร้าง Software คือการทำงานเป็นทีม”

เพื่อให้การทำงานเป็นไปในทิศทางเดียวกันจึงต้องมีแนวปฏิบัติร่วมกันคือ developer ต้องเขียนโปรแกรมตาม Coding Standard ของแต่ละภาษาโปรแกรมที่ใช้งานเพราะเราเชื่อว่าซอฟต์แวร์ที่ดีนอกจากจะทำงานได้ถูกต้อง ทำงานอย่างมีประสิทธิภาพแล้ว ต้องทำให้คนอื่นสามารถอ่านโค้ดเราแล้วเข้าใจด้วย เช่นการตั้งชื่อคลาส, การตั้งชื่อตัวแปรต้องสื่อความหมาย อ่านโค้ดแล้วเข้าใจการทำงานว่าส่วนนี้ใช้ทำอะไรบ้างซึ่งช่วยลดการเขียน document เราเขียน comment เฉพาะที่จำเป็นในส่วนที่โค้ดไม่สามารถบอกได้เท่านั้น

“เราเชื่อใน Software testing”

ฟังก์ชันและคลาสที่เขียนควรจะผ่านการ test ก่อนเสมอเพื่อลดความเสี่ยงที่จะเกิดบั๊กให้น้อยที่สุด สำหรับ Backend จะมีการเขียน Unit test สำหรับแต่ละฟังก์ชันและเมื่อนำไป Implement เป็น API แล้วก็ต้องมีการทำ Integration test หรือ HTTP Functional test ของแต่ละ API เพื่อทดสอบว่าเมื่อ API นั้นถูกใช้งานโดยเรียกผ่าน HTTP จริง ๆ แล้วยังทำงานได้ถูกต้องอยู่หรือไม่ ก่อนการ commit และ push โค้ดไปที่ repository บน GitHub

กระบวนการในการทำงานที่กล่าวมาทั้งหมดมีจุดประสงค์เดียวกันคือการ release ซอฟต์แวร์ที่มีคุณภาพ ไม่เพียงแค่ทำให้ผู้ใช้งานได้รับประสบการณ์การใช้งานที่ดีเท่านั้นแต่ทีม developer เองก็ต้องมีความสุขเมื่อต้องทำงานกับโค้ดเหล่านั้นด้วย

เครื่องมือที่ใช้ในการทำงาน

Node.js – เป็น platform ที่ทำให้เขียน JavaScriptให้ทำงานในฝั่ง Server ได้
ActionHero – Framework ที่พัฒนาด้วย Node.js การใช้ Framework ทำให้สามารถเริ่มต้นพัฒนา API ได้รวดเร็วขึ้นเพราะไม่ต้องเริ่มพัฒนา Application ใหม่ตั้งแต่ต้น
MySQL – ฐานข้อมูลแบบ Relational ใช้เก็บข้อมูลของผู้เล่นและข้อมูลต่าง ๆ ภายในเกม
Redis – ฐานข้อมูล NoSQL แบบ Key-Value ใช้เป็น Cache server และเก็บข้อมูลที่มีการเปลี่ยนแปลงบ่อย ๆ เนื่องจาก Redis อ่าน/เขียนข้อมูลได้รวดเร็ว
GitHub – เราใช้ Git เป็น Version control ดังนั้นการจัดการ source code, Code review, สร้าง Pull-Request และ merge code จะทำผ่าน GitHub ทั้งหมด
CircleCI – เครื่องมือสำหรับ Continuous Integration เมื่อ CircleCI build เสร็จแล้วหากไม่พบข้อผิดพลาดก็จะ Deploy ไปยัง Server โดยอัตโนมัติ
Amazon Web Services (AWS) – บริการ Cloud server รวมถึง infrastructure ต่าง ๆ ที่เรานำ API ขึ้นไปทำงานและให้บริการ
Newrelic – สำหรับติดตามการทำงานของ application และ server developer สามารถเข้าดู metrics ต่างๆ ของระบบได้ผ่าน dashboard สามารถตั้งค่าให้แจ้งเตือนเมื่อมีความผิดปกติได้
Hipchat – สำหรับการติดต่อสื่อสารภายในองค์กรแบบ Real-time โดยจะแบ่งห้องตามทีมและ project ที่รับผิดชอบ
JIRA – สำหรับการทำงานร่วมกัน สามารถติดตามการทำงาน สร้าง Task, Sub-task, ดูสถานะของแต่ละ Task และ Sub-task ได้ว่าทำงานถึงขั้นตอนไหนแล้วบ้าง
Google Apps – สำหรับอีเมลภายในองค์กร, เก็บไฟล์เอกสาร, แบ่งปัน document, spreadsheet และ presentation
Trello – เป็นเว็บสำหรับสร้าง Task board สามารถสร้างแบ่งกลุ่มของ task ผู้ใช้สร้าง card สำหรับ task ต่าง ๆ ได้คล้าย Post-It

การทำงานและสถาปัตยกรรมเบื้องหลัง

ด้านการพัฒนา API

เราเลือกใช้ Node.js ด้วยเหตุผลหลัก ๆ คือสามารถทำงานแบบ Asynchronous ได้ รองรับผู้ใช้งานพร้อมกันจำนวนมากได้ดี เขียนด้วยภาษา JavaScript ซึ่งเป็นภาษาที่ได้รับความนิยม มี library จำนวนมาก ยังมีอนาคตไปได้อีกไกลเพราะได้รับการสนับสนุนทั้งจากบริษัทไอทีและชุมชน Open Source

โค้ด JavaScript ที่เขียนขึ้นจะถูกตรวจสอบด้วย JSHint โดยจะเป็นการตรวจสอบเบื้องต้นว่า syntax ที่เขียนถูกต้องเป็นไปตาม Coding standard หรือไม่ JSHint สามารถแจ้งเตือนให้เราลบ module และหรือตัวแปรที่ไม่มีการใช้งานได้

API ของเราเป็น REST API เพื่อให้เริ่มทำงานได้อย่างรวดเร็วและเป็นระบบเราจึงเริ่มต้นพัฒนา API จาก Framework โดยเลือกใช้ ActionHero API Framework ที่รองรับทั้ง TCP, Sockets, Web sockets มี plug-in สามารถ integrate ใช้งานร่วมกับ ORM (Object Relational Mapping) ของ MySQL ซึ่งเราใช้เป็นฐานข้อมูลหลักและติดต่อกับ Redis ซึ่งเราใช้เป็น Cache layer ได้ง่าย นอกจากนี้ยังสามารถเพิ่ม Middleware, Initializer เพื่อทำงานเฉพาะเจาะจงตามที่เราต้องการได้ เช่น การจัดการ session, การ authorization เพื่อตรวจสอบสิทธิในการใช้งาน API

ฟังก์ชัน คลาสและ API ที่เขียนขึ้นมาจะมี test กำกับเสมอซึ่งเราใช้ Test Framework อย่าง Mocha ในการรัน Automate testing ก่อนนำโค้ดไปใช้งานทุกอย่างต้องจะเป็นสีเขียวหมายความว่าโค้ดนั้นทำงานถูกต้องผ่านทุก test cases แล้ว ทุกครั้งที่มีการแก้บั๊กหรือเพิ่มฟีเจอร์จะมีการเพิ่ม test cases เสมอ การเขียน test สำหรับ Mocha ใช้แนวคิดแบบ BDD (Behavior-Driven Development) ซึ่งข้อดีคือเราสามารถแปลง requirement ให้เป็น spec ได้ง่าย หลังจากนั้นค่อยลงมือ implement โปรแกรมเพื่อให้แต่ละ spec ผ่านก็เพียงพอแล้ว ทำให้เราทำงานเฉพาะส่วนที่จำเป็นและไม่เสียเวลาสร้างส่วนที่ไม่ได้ใช้งาน

ด้านการจัดการ source code และ Workflow การทำงาน

สถาปัตยกรรมของ API ถูกออกแบบให้สามารถ Reuse code ได้ง่ายโดยเราจะนำ API ที่มีการใช้งานบ่อยหรือ API ที่ทุกเกมน่าจะต้องใช้งานไปเก็บไว้ใน repository ที่เรียกว่า Backend Library และเมื่อต้องการพัฒนา API ที่ใช้เฉพาะเกมใดเกมหนึ่งก็จะแยกเป็นอีก repository หนึ่งเรียกว่า Game server โดย Game server สามารถนำมา plug-in ทำงานร่วมกับ Backend Library ได้ทันที

เนื่องจาก project หนึ่งจะมีการทำงานร่วมกันหลายคนเราจึงต้องมี Version control ในการจัดการ source code ซึ่งเราเลือกใช้ Git ทำงานบน GitHub developer สามารถสร้าง Pull-Request, การทำ Code review และ merge code ได้ โดยเราแบ่งเป็น 2 branches หลักคือ

Development branch สำหรับใช้ในขั้นตอนการพัฒนา staging server
Master branch สำหรับใช้งานจริงบน production server เมื่อเกม release

การเพิ่ม feature ใหม่ต้องแตก branch ออกจาก development branch เสมอ เมื่อทำเสร็จและได้รับการตรวจสอบแล้ว developer จึงสร้าง Pull-Request เพื่อขอรวมโค้ดเข้าไปที่ development branch และหาก development branch ทำงานได้ดีไม่มีปัญหาก็จะทำการสร้าง Pull-Request เพื่อขอ merge code จาก development branch ไป master branch อีกครั้งหนึ่ง

เมื่อมีการ merge code เข้าในที่ branch หลักทั้งโค้ดจะถูกนำไป build โดยอัตโนมัติด้วย CircleCI บน server ที่มี environment เหมือนกับ server ที่เราจะนำไป deploy ระหว่าง build เราสามารถติดตามสถานะการทำงานแบบ Real-time ผ่านหน้าเว็บได้ เมื่อ CircleCI build ผ่านแล้วโค้ดจะถูก deploy ไปบน target server โดยอัตโนมัติ โดยโค้ดจาก development branch จะถูกนำไป deploy บน staging server และ โค้ดจาก master branch จะถูกนำไป deploy บน production server

ด้าน Infrastructure

ระบบทั้งหมดจะทำงานบน Cloud server โดยเลือกใช้ AWS เนื่องจากมีเครื่องมือในการพัฒนาซอฟต์แวร์ที่พร้อมใช้งาน สามารถจัดการ infrastructure ของระบบผ่านหน้าเว็บได้ บริการที่เราเลือกใช้ใน AWS ได้แก่

Simple Storage Service (S3) สำหรับเก็บไฟล์ media และ static content
Elastic Compute Cloud (EC2) สำหรับเป็น server รัน application
Relational Database Service (RDS) สำหรับ database โดยใช้ engine เป็น MySQL
ElasticCache สำหรับ Cache layer โดยใช้ engine เป็น Redis
Elastic Load Balance (ELB) สำหรับการกระจาย load ไปยัง instances ต่าง ๆ
OpsWorks สำหรับงานด้าน DevOps และ Automate deployment
Instances สำหรับ Application server, Database server, Cache server จะถูกวางไว้หลัง Load Balance หากมี load เข้ามาเป็นจำนวนมากขึ้นจน instance ที่มีอยู่รับ load ไม่ไหว สามารถเพิ่ม instance ใหม่ขึ้นมาและสั่ง deploy ผ่าน OpsWorks ได้ทันที การ deploy ด้วย OpsWorks จะทำให้ application ยังคงคุณสมบัติ Zero downtime

ส่วนdatabase อย่าง MySQL ก็มีการปรับจูนเพื่อให้รองรับข้อมูลจำนวนมากได้อย่างมีประสิทธิภาพเช่นกัน โดยจะทำ Partition table แบ่งข้อมูลตาม ID ของผู้ใช้ เมื่อมีการ query ข้อมูล MySQL ไม่ต้อง lookup ข้อมูลใน table ทั้งหมดทำให้คืนผลการ query ได้เร็วขึ้น

ด้านการ monitoring และการแจ้งเตือน

Application server ที่พัฒนาขึ้นจะมีการ integrate ให้ส่งข้อมูลไปยัง Newrelic โดย developer สามารถเข้าไปดู metrics ต่าง ๆ ของระบบผ่าน dashboard ได้ เมื่อเกิด error จนเกิน threshold ที่ตั้งค่าไว้โดยจะมีแจ้งเตือนตามอีเมลที่กำหนดได้ นอกจากนี้เรายัง integrate การแจ้งเตือนจาก Newrelic ให้แจ้งเตือนไปยัง Hipchat ได้ รวมถึง CircleCI ก็สามารถแจ้งเตือนสถานะการ build ไปยัง Hipchat ได้เช่นเดียวกัน

ด้านการจัดการ project และติดตามการทำงาน

เริ่มแรกเราใช้ Trello ในการติดตามการทำงานโดยสร้างบอร์ดสำหรับแต่ละ project ในบอร์ดจะมี column สถานะการทำงาน เช่น Backlog, To Do, Doing, Done, Sprint 1 เป็นต้น แต่ละ column จะมีการสร้าง task งานเป็น card ซึ่งสามารถระบุรายละเอียดของ task และผู้รับผิดชอบ task นั้น ๆ ได้ แต่เมื่อในทีมมีคนมากขึ้นกระบวนการทำซับซ้อนมากขึ้น ผ่านไปหลาย Sprint Trello จึงไม่เหมาะอีกต่อไปเพราะจะเกิด column ใหม่ขึ้นเป็นจำนวนมากทำงานร่วมกับ QA (Quality Assurance) ได้ลำบาก เราจึงทยอยย้ายข้อมูลไปทำงานบน JIRA ซึ่งทำงานได้มีประสิทธิภาพกว่าแต่ก็ต้องแลกด้วย learning curve ในช่วงเริ่มต้นเล็กน้อย

ถ้าคุณมี passion ในงานด้าน Backend, อยากสร้างระบบที่มีคนใช้ระดับแสนคนต่อวันก็ไม่ยั่น เรายังมีเปิดรับอีกหลายตำแหน่งครับ ส่งข้อมูลส่วนตัว/portfolio มาได้ที่ info@infinitylevels.com