2 คะแนน โดย GN⁺ 2023-12-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

Moddio เกมเอนจิน 2

  • Moddio เป็นเกมเอนจินที่ให้ความสำคัญกับมัลติเพลเยอร์เป็นอันดับแรก
  • มีโค้ดเครือข่ายแบบ server-authoritative, snapshot interpolation และความสามารถด้าน client-side reconciliation มาให้ในตัว
  • รองรับผู้เล่นพร้อมกันมากกว่า 50 คน หรืออ็อบเจ็กต์ที่เคลื่อนไหวมากกว่า 300 ชิ้น บน VM ราคา 5 ดอลลาร์ต่อเดือน

เดโม

  • สิ่งที่มีมาให้ในชุด: เอนจินฟิสิกส์ Box2D, โค้ดเครือข่ายแบบ server-authoritative, ระบบอินเวนทอรีและไอเท็ม, คุณสมบัติที่มีมาในตัว (HP, พลังงาน เป็นต้น) และอัตราการฟื้นฟู, ระบบบทสนทนา, ร้านค้า, การควบคุมยูนิต, โปรเจกไทล์และการเคลื่อนที่ของยูนิตแบบ client-side prediction, AI ของยูนิตและการหาเส้นทางแบบ A*, การควบคุมบนมือถือ เป็นต้น

วิธีรันเกม

  • ต้องใช้ Node 18 ขึ้นไป
  • หลังตั้งค่า repository แล้ว ให้ไปที่ไดเรกทอรี /src, เปลี่ยนชื่อ game-sample.json เป็น game.json แล้วกลับไปที่ไดเรกทอรีรากเพื่อรันเซิร์ฟเวอร์
  • จากนั้นสามารถเล่นเกมได้ที่ http://localhost:80

วิธีสร้างเกมใหม่ตั้งแต่ต้น

  • เกม Moddio ถูกสร้างและแก้ไขโดยใช้ Moddio Game Editor ที่ให้บริการบน https://www.modd.io
  • หลังสร้างเกมแล้ว สามารถ export game.json สำหรับใช้กับการติดตั้งแบบโลคัลได้
  • เปลี่ยนชื่อไฟล์เกม JSON ที่ export มาเป็น game.json แล้วนำไปไว้ในไดเรกทอรี ./src

วิธีมีส่วนร่วม

  • Moddio ฟรีทั้งหมดและเป็นโอเพนซอร์สภายใต้ไลเซนส์ MIT
  • หากต้องการดูวิธีเป็นผู้มีส่วนร่วม ให้ไปที่หน้าวิธีมีส่วนร่วม

เครดิต

  • ใช้งาน Isogenic game engine, Phaser, PlanckJS, uWebsocket, Box2D, Kenney assets, Hero Icons และอื่น ๆ

ความเห็นของ GN⁺

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

1 ความคิดเห็น

 
GN⁺ 2023-12-22
ความคิดเห็นจาก Hacker News
  • ในหน้าสมัครใช้งานของแอป Android มีการให้กรอก ชื่อผู้ใช้และรหัสผ่าน Google ลงในช่องที่ดูเหมือนเว็บฟอร์มภายในแอป ซึ่งผู้ใช้ไม่มีทางรู้ได้ว่าแอปแอบดูรหัสผ่านอยู่หรือไม่
    ปกติแล้วแอปน่าจะใช้โฟลว์ที่พาไปยังหน้าล็อกอินแล้วค่อยกลับมาอีกที เลยสงสัยว่าการทำแพตเทิร์นแบบนั้นยากหรือเปล่า และสงสัยด้วยว่าเป็นปัญหาจากการรองรับข้ามแพลตฟอร์มหรือไม่

    • โดยหลักการแล้วไม่ใช่เรื่องยากมาก ผมเคยทำงานกับผู้ผลิตรถยนต์ที่ต้องให้ผู้ใช้ล็อกอินด้วย บัญชี OEM ซึ่งในทางทฤษฎีทุกเจ้าบอกว่าทำตามข้อกำหนด แต่ในทางปฏิบัติหลายส่วนกลับทำไม่ได้ และการแก้ไขก็ใช้เวลานาน
      อย่างไรก็ตาม วิธีที่พูดถึงข้างต้นเป็นสิ่งที่ไม่ควรเกิดขึ้นจริง ๆ และผมนึกว่า Google ห้ามไปแล้วด้วยซ้ำ
    • สิ่งนี้เรียกว่า OAuth 2.0 และถ้าใช้ของอย่าง Okta ก็ทำได้ไม่ยาก
  • การทำให้ผู้ใช้เลือกใช้เกมเอนจินไม่ใช่เรื่องง่ายเลย โดยเฉพาะถ้าเป็น ซอร์สปิด ก็ยิ่งยากขึ้น
    ดูจากแกลเลอรีเกมบนเว็บไซต์แล้ว ดูเหมือนว่าทำมาได้ค่อนข้างดีจนถึงตอนนี้ แต่สงสัยว่าเป็นผลงานของเพื่อน ๆ ไม่กี่คน หรือว่ามีชุมชนที่ค่อนข้างคึกคักอยู่จริง ๆ

    • การผสมกันของฟีเจอร์ที่ดี เรียนรู้ง่าย และภาระในการเริ่มต้นต่ำ สามารถพาไปได้ไกลพอสมควร
      ลองนึกถึงโครงสร้างที่ใช้เวลาเล่น ๆ แค่ไม่กี่วันหรือไม่กี่ชั่วโมงก็ได้ผลลัพธ์ที่มีความหมาย ลองนึกถึง Flash ดู
    • มีชุมชนที่คึกคัก และสร้าง เกมใหม่ 150~300 เกม ทุกวัน
      การที่อุปสรรคในการเริ่มต้นต่ำทั้งสำหรับนักพัฒนาเกมและผู้เล่นช่วยได้อย่างชัดเจน ไม่ต้องดาวน์โหลดหรือสมัครสมาชิก
  • แค่เห็นชื่อเรื่องก็ไม่คิดเลยว่านี่จะเป็น modd.io มันเป็นเฟรมเวิร์ก/แพลตฟอร์มยอดนิยมที่ใช้สร้างเกม IO

    • ผมเล่นเกมเยอะและเคยขายเกมมาก่อนด้วย แต่ไม่เคยได้ยินคำนี้เลย เกม IO คืออะไร?
  • ผมลองเข้าไปเล่นในเซิร์ฟเวอร์ Brains เซิร์ฟเวอร์หนึ่ง แล้วอยากรู้ว่าประสบการณ์ตอนมีผู้เล่นราว 50 คนเป็นอย่างไร การเคลื่อนไหวดูสะดุด ๆ อย่างที่คาดได้จากเว็บซ็อกเก็ต และเพราะผมกำลังทำของคล้าย ๆ กันอยู่ เลยสนใจเรื่อง การบีบอัดข้อมูลเครือข่าย ด้วย
    ไม่แน่ใจว่าแค่ใช้การบีบอัด LZ-string จะพอหรือไม่ มีการใช้ข้อมูลประมาณ 20KB ต่อวินาทีสำหรับผู้เล่น 50 คน ขณะที่ Warzone ใช้แค่ประมาณ 48KB ต่อวินาทีสำหรับผู้เล่น 150 คน ถ้าไม่ใช่ข้อมูลแบบไม่จำกัด ค่าแบนด์วิดท์บนคลาวด์อาจสูงพอสมควร
    ที่บัฟเฟอร์ไบต์ที่ถูกบีบอัดออกมาดูเหมือน 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼 ก็น่าสนใจ ไม่รู้ว่าผลลัพธ์ของการบีบอัด LZ-string ปกติเป็นแบบนี้หรือเปล่า แต่ดูแปลกตาทีเดียว
    อย่างไรก็ดี ถ้าต้องการลดต้นทุนที่อาจเกิดขึ้น ฝั่ง networking ยังมีพื้นที่ให้ปรับปรุงอีกมาก ตัวโปรเจกต์โดยรวมแล้วน่าประทับใจมากและทำออกมาได้ดี

    • เว็บซ็อกเก็ตของเราการเคลื่อนไหวค่อนข้างแน่น: https://gooberdash.winterpixel.io/
      หัวใจหลักคือ client-side prediction และอัลกอริทึม rollback networking สถานะเกมของเราอยู่ที่ประมาณ 1KB ที่ 30Hz จึงมักอยู่ในแพ็กเก็ตเดียวได้ ดังนั้นเว็บซ็อกเก็ตก็ไม่ได้แย่มาก แน่นอนว่าโปรโตคอลแบบไม่เชื่อถือได้จะดีกว่า
    • ช่วยอธิบายเพิ่มได้ไหมตรงที่ว่า “การเคลื่อนไหวดูสะดุด ๆ อย่างที่คาดได้จากเว็บซ็อกเก็ต”? ผมเคยลองเล่น “เกม IO” อยู่บ้าง และนอกจากผู้เล่นบางคนที่ latency สูงมากเป็นครั้งคราวแล้ว มันก็ดูค่อนข้างลื่น
      เมื่อไม่กี่เดือนก่อนผมลองทดสอบ WebSockets นิดหน่อย เท่าที่เข้าใจคือการใช้ TCP กับการสื่อสารที่ไวต่อ latency อย่างเกมมีข้อเสียค่อนข้างมาก TCP header ใหญ่กว่า UDP มากกว่า 2 เท่า มีแพ็กเก็ตควบคุมเพิ่มเติม และการส่งข้อมูลใหม่จะถูกหน่วงระหว่างที่ข้อมูลเก่ากำลังถูกส่งซ้ำ WebSockets ก็ทำงานบน TCP จึงมีข้อเสียแบบเดียวกัน
      ถึงอย่างนั้นหลายคนก็บอกว่า TCP รับประกันการส่งข้อความของ WebSocket แต่ผมสามารถจำลอง packet loss ได้อยู่ดี สุดท้ายข้อเสียก็ยังอยู่เหมือนเดิม และถ้าต้องการการส่งที่รับประกันจริง ๆ ก็ต้องสร้างอะไรบางอย่างทับลงไปเอง ซึ่งถ้าจะทำแบบนั้น ก็น่าจะเริ่มจาก UDP แล้วทำเฉพาะข้อความที่จำเป็นให้เป็นแบบนั้นตั้งแต่แรกก็ได้
      ผมแทบไม่มีความรู้และประสบการณ์ด้าน networking นอกจากเคยลองแตะ ๆ นิดหน่อย ดังนั้นอ่านโดยคำนึงถึงจุดนี้ด้วย
    • อักขระ CJK เป็นส่วนที่ใหญ่มากของอักขระ Unicode ที่พิมพ์แสดงผลได้ [1] บล็อกที่ใหญ่ที่สุดสองบล็อกมีช่วง U+3400~U+4DBF, U+4E00~U+9FFF รวมอยู่ด้วย
      สตริงดังกล่าวถอดรหัสได้เป็น \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c
      [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs
  • วิธีที่แน่นอนที่สุดที่จะไม่มีวันทำเกมเสร็จ คือเริ่มจาก การเขียนเอนจิน
    การสร้างเทคโนโลยีของตัวเองนั้นทำได้แน่นอน แต่ในทุกขั้นตอน เทคโนโลยีนั้นควรถูกปรับให้เข้ากับโปรเจกต์ของตัวเอง ไม่ใช่เป็นแพลตฟอร์มเกมอเนกประสงค์

    • ผมควรเริ่มทำบล็อกแล้ว!
      ในที่นี้ “เริ่มทำบล็อก” หมายถึงการสร้าง บล็อกเอนจินใหม่ ตั้งแต่ศูนย์จริง ๆ
    • ช่วยอธิบายเพิ่มได้ไหมว่าหมายถึงส่วนไหนของ modd.io? หมายความว่านี่เป็นผลลัพธ์จากการพยายามทำเกมแล้วล้มเหลวหรือเปล่า?
    • คนส่วนใหญ่ที่ใช้เอนจินอาจไม่ได้อยากทำเกมตั้งแต่แรก แต่จริง ๆ แล้วเป็นคนที่ อยากทำเอนจิน มากกว่า
  • เคยเห็นแบ็กเอนด์มัลติเพลเยอร์ที่ใช้ Node.js พอจำนวนการเชื่อมต่อเพิ่มขึ้น สุดท้ายก็ช้าลงจนแทบคลาน เลยสงสัยว่าแก้ปัญหานี้อย่างไร
    ในกรณีแบบนี้ ทางเลือกอย่าง Go จะไม่ดีกว่าหรือ?

    • ไม่ค่อยแน่ใจว่าทำไมถึงเป็นแบบนั้น ในแง่การเชื่อมต่อ ด้วย event loop ของ Node ปัญหา I/O blocking ฝั่ง HTTP request/response น่าจะไม่ใช่ประเด็น
      และก็ไม่น่าที่แบ็กเอนด์จะทำงานฟิสิกส์หนัก ๆ ให้ฟรอนต์เอนด์ด้วย
    • ใช้ uWebSockets(https://github.com/uNetworking/uWebSockets) แม้จะเขียนด้วย C แต่มีอินเทอร์เฟซที่ใช้จาก NodeJS ได้
      ในการทดสอบง่าย ๆ มันทำงานได้ดีกว่าไลบรารี WebSocket ยอดนิยมอื่น ๆ ที่ช้าลงอย่างรวดเร็วมาก
    • ในเกม IO ส่วนใหญ่ คอขวดน่าจะอยู่ที่ I/O ชื่อแนวมาจาก top-level domain ก็จริง แต่ก็ดูเหมือนเล่นคำอยู่เหมือนกัน
      ดังนั้น Node จึงรู้สึกว่าเป็นตัวเลือกที่ดี
    • ความสามารถในการสเกลอาจเป็นสิ่งที่ต้องพิจารณาจริง โดยเฉพาะเมื่อมีจำนวนการเชื่อมต่อมาก ในกรณีของเรา เราได้ปรับแต่งแบ็กเอนด์ให้รองรับ การเชื่อมต่อพร้อมกัน จำนวนมากได้อย่างมีประสิทธิภาพ
      แต่ละเกมจำกัดผู้เล่นสูงสุด 64 คน แต่ตอนทดสอบไปถึงมากกว่า 100 การเชื่อมต่อ ก็ไม่พบปัญหาด้านประสิทธิภาพ แต่ละเกมรันอยู่ในคอนเทนเนอร์ที่แยกกัน
  • อยากรู้แรงจูงใจในการสร้างเอนจินใหม่
    ดูจาก README แล้ว มีของที่ค่อนข้างเฉพาะเจาะจงฝังมา เช่น ระบบอาวุธ (ประชิด/กระสุน), ร้านค้า, projectile prediction ฝั่งไคลเอนต์ และการเคลื่อนที่ของยูนิต
    สงสัยว่าทำไมถึงฝังสิ่งเหล่านี้ไว้ในเอนจิน แทนที่จะทำเป็นปลั๊กอินที่คัดลอกไปใช้ได้ แน่นอนว่าหลายเกมไม่ต้องการฟีเจอร์พวกนี้ แล้วนี่เป็นเกมเอนจินหรือเปล่า? หรือเป็นเอนจินสำหรับ FPS/RPG/แนวเฉพาะอื่น ๆ?
    ไม่ได้ไม่ชอบเทคโนโลยีนี้ แต่ก็ยังมีคำถามว่า “ทำไม?” เหลืออยู่ มันมีไว้เพื่ออะไร? ทำไมควรใช้สิ่งนี้แทน Three.js กับเซิร์ฟเวอร์ที่ทำเอง?

    • ขอบคุณสำหรับคำถาม เราตัดสินใจอย่างตั้งใจว่าจะทำให้เอนจินมี โครงสร้างที่ยึดแนวทางชัดเจน มากกว่าทางเลือกแบบโมดูลาร์อื่น ๆ เพราะอยากให้การพัฒนาเกม 2D มัลติเพลเยอร์ทำได้รวดเร็วอย่างยิ่ง
      ตัวอย่างเช่น เราสร้าง MMORPG ง่าย ๆ ได้ใน 2 ชั่วโมง: https://www.youtube.com/watch?v=GZVsxkALR5U
      เรามองว่าความใช้งานง่ายกับระดับการปรับแต่งมีความสัมพันธ์แบบผกผันกัน เราเลือกอย่างแรกเพื่อช่วยลดช่องว่างระหว่างเกมมัลติเพลเยอร์ที่ขึ้นชื่อว่าสร้างยาก กับนักพัฒนาเกมแคชชวล
    • “มันมีไว้เพื่ออะไร?”
      ดูเหมือนไม่ได้มีไว้สำหรับคุณ แต่มันมีไว้สำหรับคนที่อยากสร้าง เกมแบบเฉพาะเจาะจง เหล่านั้น ไม่ใช่ทุกเอนจินจำเป็นต้องเป็นเอนจินอเนกประสงค์
  • เคยมีโปรเจกต์งานอดิเรกอยู่หลายตัวที่น่าจะเข้ากับสิ่งนี้ได้ดี ผมเขียนโค้ดได้ แต่ตอนทำโปรเจกต์งานอดิเรกก็มีบางช่วงที่ไม่อยากจดจ่อขนาดนั้น ดังนั้น low-code กับตัวแก้ไขแบบโต้ตอบจึงดูดีสำหรับนักพัฒนาสายงานอดิเรก
    โดยส่วนตัว สิ่งที่ตั้งตารอที่สุดคือแผนที่กับการสร้างโลก ดูเหมือนวิธีที่ดีที่สุดคือ export เกมเป็น JSON แก้ไขด้วยโปรแกรม แล้ว import กลับเข้าไป เลยสงสัยว่าเข้าใจถูกไหม
    แต่ออกจะน่าหนักใจอยู่บ้าง tutorial world ที่ยังไม่ได้แก้ไขมี JSON 3,500 บรรทัด จึงมีหลายอย่างที่ต้องทำความเข้าใจ
    วิธีแรกที่คิดได้คือจงใจลองแก้ใน editor แล้วดูว่า JSON เปลี่ยนไปอย่างไร คงต้องหา JSON diff viewer ดี ๆ ด้วย แบบนั้นน่าจะช่วยให้เจอส่วนที่อยากแตะได้ คิดว่าสินทรัพย์กับ map tile น่าจะรวบรวมในตัวแก้ไขแบบโต้ตอบ
    อยากรู้ว่าแนวทางนี้สมเหตุสมผลไหม และมีเครื่องมือที่ช่วยได้หรือเปล่า

    • ไม่แนะนำให้แก้ JSON โดยตรง มันค่อนข้างอ่านยากและพองเกินจำเป็น ใน modd.io มี actions ที่ใช้แก้แผนที่โดยตรงได้
      ผู้สร้างคนหนึ่งในคอมมูนิตี้ของเรากำลังใช้ ChatGPT สร้างแผนที่แบบไดนามิก เขากำลังทำเกมซ่อนหา โดยส่งพรอมป์ให้สร้าง JSON แผนที่ 2D แล้วโหลดแผนที่นั้นทุกครั้งที่เริ่มรอบใหม่ เกมยังไม่เปิดเผยต่อสาธารณะ เลยแชร์เกมให้ดูได้ยาก
      นอกจากนี้ สมาชิกคอมมูนิตี้อีกคนกำลังทำอินเทอร์พรีเตอร์สำหรับ JSON ของเกมเราอยู่ ตัวอย่าง: https://pypi.org/project/pymodd/
  • ดีใจที่เห็น โปรเจกต์โอเพนซอร์ส แบบนี้ออกมาเพิ่มขึ้น แปลกใจที่ GitHub star ยังไม่ถึง 100

    • อย่าเข้าใจผิดนะ ถามเพราะสงสัยจริง ๆ ทำไมถึงแปลกใจที่ GitHub star ยังน้อยกว่า 100?
    • อาจเป็นเพราะเพิ่งเปิดตัวไปเมื่อกี้ก็ได้