Mace Duel Mobile: เกมดวล 3 มิติบนมือถือที่ให้เซิร์ฟเวอร์ตัดสินผล

ภาพรวม: เกมดวลที่มือถือเล่นได้จริง และเซิร์ฟเวอร์เป็นผู้ชี้ขาด

Mace Duel Mobile คือแนวทางทำเกมดวลสามมิติแบบ 1 ต่อ 1 ที่เปิดเล่นได้ทั้งมือถือและคอมพิวเตอร์ โดยวางเทคโนโลยีไว้ดังนี้

• ฝั่งผู้เล่น: TypeScript, Vite และ Three.js
• ฝั่งเซิร์ฟเวอร์: Node.js, TypeScript และไลบรารี ws
• การเชื่อมต่อ: WebSocket สำหรับส่งอินพุตและสถานะเกมแบบสองทาง

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

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

สิ่งที่ระบบเกมรองรับ

ตัวเกมถูกวางให้รองรับผู้เล่นสองคนจากคนละอุปกรณ์ ผ่านห้องส่วนตัวที่ใช้รหัสห้อง โดยมีองค์ประกอบหลัก ได้แก่

• สร้างห้องและเข้าร่วมห้องด้วยรหัส
• ระบบกดพร้อมเล่นและนับถอยหลังก่อนเริ่มรอบ
• การเดิน วิ่ง กระโดด และควบคุมมุมมอง
• การฟาดด้วยคทาในระยะประชิด
• การโจมตีจากที่สูง ซึ่งเพิ่มความแรงตามระยะตก
• พลังลมแบบใช้ชาร์จ สร้างแรงผลักและแรงยกเมื่อระเบิดใกล้ผู้เล่น
• รอบละ 120 วินาที และต้องชนะ 3 รอบเพื่อชนะทั้งแมตช์
• รีแมตช์หลังเกมจบ
• การตรวจสอบรูปแบบข้อความและจำกัดข้อมูลอินพุตพื้นฐาน

ระบบจำลองเกมตั้งเป้าอัปเดตที่ 30 Hz ซึ่งเหมาะกับเกมต่อสู้ออนไลน์ขนาดเล็กที่ต้องการการตอบสนองสม่ำเสมอโดยไม่เพิ่มภาระฝั่งเซิร์ฟเวอร์เกินจำเป็น

คอนโทรลบนมือถือ: ต้องกดได้พร้อมกันมากกว่าหนึ่งอย่าง

เกมต่อสู้บนจอสัมผัสจะใช้งานลำบากทันที หากผู้เล่นเดิน มอง และกดโจมตีพร้อมกันไม่ได้ ดังนั้นรูปแบบควบคุมที่เหมาะกับ Mace Duel Mobile คือ

• จอยเสมือนฝั่งซ้ายสำหรับเคลื่อนที่
• ลากนิ้วฝั่งขวาเพื่อหมุนมุมมอง
• ปุ่มกระโดด
• ปุ่มวิ่ง
• ปุ่มโจมตีคทา
• ปุ่มปล่อยพลังลม
• แนะนำให้เล่นในแนวนอน

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

กติกาการต่อสู้: ระยะ มุม และแรงตกต้องตรวจที่เซิร์ฟเวอร์

การโจมตีด้วยคทาไม่ควรเชื่อคำสั่ง “โดนแล้ว” จากไคลเอนต์ แต่เซิร์ฟเวอร์ควรตรวจเองอย่างน้อย 3 เรื่อง

1. ระยะโจมตี — เป้าหมายอยู่ในระยะที่กำหนดหรือไม่
2. มุมการโจมตี — เป้าหมายอยู่ในกรวยด้านหน้าของผู้เล่นหรือไม่
3. สภาพการตก — ผู้โจมตีกำลังร่วงลงและตกมาจากความสูงมากพอหรือไม่

ในแนวคิดนี้ การฟาดปกติสร้างความเสียหายพื้นฐาน 16 หน่วย แต่หากโจมตีขณะตกจากความสูงเกินเกณฑ์ จะกลายเป็นการโจมตีแบบกระแทกจากด้านบน ความเสียหายจะเพิ่มขึ้นตามระยะตก โดยมีเพดานความเสียหายเพื่อไม่ให้รุนแรงเกินควบคุม

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

ทำไมต้องมีการชดเชยความหน่วง

เกมออนไลน์มีความหน่วงเสมอ หากเซิร์ฟเวอร์ตรวจตำแหน่งเป้าหมายเฉพาะ “เวลาปัจจุบัน” ผู้เล่นที่มีค่า ping สูงอาจเห็นว่าฟาดโดน แต่ผลกลับไม่ติด เพราะตำแหน่งบนเซิร์ฟเวอร์ขยับไปแล้ว

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

โครงสร้างโปรเจกต์ที่ควรแยกชัดเจน

การแยกโค้ดเป็นสามส่วนช่วยให้ดูแลง่ายและลดความคลาดเคลื่อนของกติกา

client/ หรือ src/
  เรนเดอร์ 3 มิติ, หน้าจอเกม, การควบคุมสัมผัส, เสียง,
  การคาดการณ์การเคลื่อนที่ในเครื่อง และการแสดงผลคู่ต่อสู้

server/
  ห้องเกม, ลูปจำลอง 30 Hz, ฟิสิกส์, การโจมตี,
  กระสุน, คะแนน, heartbeat และการตรวจสอบข้อความ

shared/
  ค่ากติกา, ชนิดข้อมูลของโปรโตคอล และฟังก์ชันคำนวณร่วมกัน

โฟลเดอร์ shared/ สำคัญมาก เพราะช่วยให้ทั้งไคลเอนต์และเซิร์ฟเวอร์ใช้ค่าคงที่เดียวกัน เช่น ความเร็วเดิน ระยะโจมตี เวลาคูลดาวน์ และกติกาความเสียหาย แต่ถึงจะใช้กติกาชุดเดียวกัน การตัดสินผลสุดท้ายยังต้องอยู่ที่เซิร์ฟเวอร์

ภาพและประสิทธิภาพ: อย่าทำให้สนามเป็นภาระของมือถือ

สำหรับฉากที่มีวัตถุซ้ำจำนวนมาก เช่น แผ่นพื้น เสาหรือหินประดับ การใช้ InstancedMesh ของ Three.js ช่วยให้เรนเดอร์วัตถุที่ใช้เรขาคณิตและวัสดุเดียวกันผ่านระบบ instancing ได้ 2 ซึ่งเหมาะกับการลดภาระการวาดฉากในเกมเบราว์เซอร์

ส่วนเงาเป็นตัวเลือกด้านคุณภาพภาพที่แลกกับประสิทธิภาพ WebGLRenderer.shadowMap สามารถเปิดหรือปิดได้ โดยค่าเริ่มต้นของการใช้ shadow map เป็นปิดอยู่ 4 เกมมือถือจึงควรมีตัวเลือกกราฟิก เช่น

• ปิดเงา เพื่อเพิ่มเฟรมเรตบนเครื่องระดับเริ่มต้น
• เปิดเงาแบบพื้นฐานสำหรับเครื่องที่แรงพอ
• ลดความละเอียดหรือความซับซ้อนของฉากเมื่อเฟรมเรตตก

เอกสาร Three.js ระบุชนิดของ shadow map หลายรูปแบบ เช่น BasicShadowMap, PCFShadowMap, PCFSoftShadowMap และ VSMShadowMap ซึ่งมีคุณภาพและต้นทุนต่างกัน 3 สำหรับเกมแนวนี้ การให้ผู้เล่นเลือกเปิดหรือปิดเงามักใช้งานได้จริงกว่าการบังคับกราฟิกระดับเดียวทุกอุปกรณ์

ความปลอดภัยและความเสถียรของห้องเกม

แม้จะเป็นเกมขนาดเล็ก ก็ควรทำสิ่งพื้นฐานเหล่านี้ตั้งแต่ต้น

• จำกัดขนาดข้อความ WebSocket
• ตรวจชนิดข้อมูลและขอบเขตตัวเลขทุกข้อความ
• ปฏิเสธลำดับอินพุตที่ย้อนกลับหรือกระโดดผิดปกติ
• จำกัดจำนวนผู้เล่นต่อห้องเป็น 2 คน
• ลบห้องที่ไม่มีผู้เล่น
• ส่ง heartbeat เป็นระยะเพื่อรู้ว่าการเชื่อมต่อยังใช้งานได้
• แยกข้อมูลสถานะที่ใช้แสดงผลออกจากข้อมูลภายในของเซิร์ฟเวอร์

ในฝั่งโปรดักชัน ควรให้การเชื่อมต่อเว็บและ WebSocket ทำงานผ่าน HTTPS/WSS และตั้งค่า reverse proxy ให้รองรับการอัปเกรดการเชื่อมต่อ WebSocket อย่างถูกต้อง

บทสรุป

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

เมื่อเติมระบบห้องส่วนตัว คอนโทรลแบบหลายสัมผัส การชดเชยความหน่วง และการตั้งค่ากราฟิกที่เหมาะกับมือถือ เกมดวล 1 ต่อ 1 ก็สามารถให้ประสบการณ์ที่กระชับ แข่งขันได้ และเล่นข้ามอุปกรณ์ได้อย่างเป็นรูปธรรม 124