HN เผยแพร่: เปิดซอร์สเอนจินเกมของผม
(github.com/moddio)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 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในหน้าสมัครใช้งานของแอป Android มีการให้กรอก ชื่อผู้ใช้และรหัสผ่าน Google ลงในช่องที่ดูเหมือนเว็บฟอร์มภายในแอป ซึ่งผู้ใช้ไม่มีทางรู้ได้ว่าแอปแอบดูรหัสผ่านอยู่หรือไม่
ปกติแล้วแอปน่าจะใช้โฟลว์ที่พาไปยังหน้าล็อกอินแล้วค่อยกลับมาอีกที เลยสงสัยว่าการทำแพตเทิร์นแบบนั้นยากหรือเปล่า และสงสัยด้วยว่าเป็นปัญหาจากการรองรับข้ามแพลตฟอร์มหรือไม่
อย่างไรก็ตาม วิธีที่พูดถึงข้างต้นเป็นสิ่งที่ไม่ควรเกิดขึ้นจริง ๆ และผมนึกว่า Google ห้ามไปแล้วด้วยซ้ำ
การทำให้ผู้ใช้เลือกใช้เกมเอนจินไม่ใช่เรื่องง่ายเลย โดยเฉพาะถ้าเป็น ซอร์สปิด ก็ยิ่งยากขึ้น
ดูจากแกลเลอรีเกมบนเว็บไซต์แล้ว ดูเหมือนว่าทำมาได้ค่อนข้างดีจนถึงตอนนี้ แต่สงสัยว่าเป็นผลงานของเพื่อน ๆ ไม่กี่คน หรือว่ามีชุมชนที่ค่อนข้างคึกคักอยู่จริง ๆ
ลองนึกถึงโครงสร้างที่ใช้เวลาเล่น ๆ แค่ไม่กี่วันหรือไม่กี่ชั่วโมงก็ได้ผลลัพธ์ที่มีความหมาย ลองนึกถึง Flash ดู
การที่อุปสรรคในการเริ่มต้นต่ำทั้งสำหรับนักพัฒนาเกมและผู้เล่นช่วยได้อย่างชัดเจน ไม่ต้องดาวน์โหลดหรือสมัครสมาชิก
แค่เห็นชื่อเรื่องก็ไม่คิดเลยว่านี่จะเป็น modd.io มันเป็นเฟรมเวิร์ก/แพลตฟอร์มยอดนิยมที่ใช้สร้างเกม IO
ผมลองเข้าไปเล่นในเซิร์ฟเวอร์ Brains เซิร์ฟเวอร์หนึ่ง แล้วอยากรู้ว่าประสบการณ์ตอนมีผู้เล่นราว 50 คนเป็นอย่างไร การเคลื่อนไหวดูสะดุด ๆ อย่างที่คาดได้จากเว็บซ็อกเก็ต และเพราะผมกำลังทำของคล้าย ๆ กันอยู่ เลยสนใจเรื่อง การบีบอัดข้อมูลเครือข่าย ด้วย
ไม่แน่ใจว่าแค่ใช้การบีบอัด LZ-string จะพอหรือไม่ มีการใช้ข้อมูลประมาณ 20KB ต่อวินาทีสำหรับผู้เล่น 50 คน ขณะที่ Warzone ใช้แค่ประมาณ 48KB ต่อวินาทีสำหรับผู้เล่น 150 คน ถ้าไม่ใช่ข้อมูลแบบไม่จำกัด ค่าแบนด์วิดท์บนคลาวด์อาจสูงพอสมควร
ที่บัฟเฟอร์ไบต์ที่ถูกบีบอัดออกมาดูเหมือน
埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼ก็น่าสนใจ ไม่รู้ว่าผลลัพธ์ของการบีบอัด LZ-string ปกติเป็นแบบนี้หรือเปล่า แต่ดูแปลกตาทีเดียวอย่างไรก็ดี ถ้าต้องการลดต้นทุนที่อาจเกิดขึ้น ฝั่ง networking ยังมีพื้นที่ให้ปรับปรุงอีกมาก ตัวโปรเจกต์โดยรวมแล้วน่าประทับใจมากและทำออกมาได้ดี
หัวใจหลักคือ client-side prediction และอัลกอริทึม rollback networking สถานะเกมของเราอยู่ที่ประมาณ 1KB ที่ 30Hz จึงมักอยู่ในแพ็กเก็ตเดียวได้ ดังนั้นเว็บซ็อกเก็ตก็ไม่ได้แย่มาก แน่นอนว่าโปรโตคอลแบบไม่เชื่อถือได้จะดีกว่า
เมื่อไม่กี่เดือนก่อนผมลองทดสอบ WebSockets นิดหน่อย เท่าที่เข้าใจคือการใช้ TCP กับการสื่อสารที่ไวต่อ latency อย่างเกมมีข้อเสียค่อนข้างมาก TCP header ใหญ่กว่า UDP มากกว่า 2 เท่า มีแพ็กเก็ตควบคุมเพิ่มเติม และการส่งข้อมูลใหม่จะถูกหน่วงระหว่างที่ข้อมูลเก่ากำลังถูกส่งซ้ำ WebSockets ก็ทำงานบน TCP จึงมีข้อเสียแบบเดียวกัน
ถึงอย่างนั้นหลายคนก็บอกว่า TCP รับประกันการส่งข้อความของ WebSocket แต่ผมสามารถจำลอง packet loss ได้อยู่ดี สุดท้ายข้อเสียก็ยังอยู่เหมือนเดิม และถ้าต้องการการส่งที่รับประกันจริง ๆ ก็ต้องสร้างอะไรบางอย่างทับลงไปเอง ซึ่งถ้าจะทำแบบนั้น ก็น่าจะเริ่มจาก UDP แล้วทำเฉพาะข้อความที่จำเป็นให้เป็นแบบนั้นตั้งแต่แรกก็ได้
ผมแทบไม่มีความรู้และประสบการณ์ด้าน networking นอกจากเคยลองแตะ ๆ นิดหน่อย ดังนั้นอ่านโดยคำนึงถึงจุดนี้ด้วย
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
วิธีที่แน่นอนที่สุดที่จะไม่มีวันทำเกมเสร็จ คือเริ่มจาก การเขียนเอนจิน
การสร้างเทคโนโลยีของตัวเองนั้นทำได้แน่นอน แต่ในทุกขั้นตอน เทคโนโลยีนั้นควรถูกปรับให้เข้ากับโปรเจกต์ของตัวเอง ไม่ใช่เป็นแพลตฟอร์มเกมอเนกประสงค์
ในที่นี้ “เริ่มทำบล็อก” หมายถึงการสร้าง บล็อกเอนจินใหม่ ตั้งแต่ศูนย์จริง ๆ
เคยเห็นแบ็กเอนด์มัลติเพลเยอร์ที่ใช้ Node.js พอจำนวนการเชื่อมต่อเพิ่มขึ้น สุดท้ายก็ช้าลงจนแทบคลาน เลยสงสัยว่าแก้ปัญหานี้อย่างไร
ในกรณีแบบนี้ ทางเลือกอย่าง Go จะไม่ดีกว่าหรือ?
และก็ไม่น่าที่แบ็กเอนด์จะทำงานฟิสิกส์หนัก ๆ ให้ฟรอนต์เอนด์ด้วย
ในการทดสอบง่าย ๆ มันทำงานได้ดีกว่าไลบรารี WebSocket ยอดนิยมอื่น ๆ ที่ช้าลงอย่างรวดเร็วมาก
ดังนั้น Node จึงรู้สึกว่าเป็นตัวเลือกที่ดี
แต่ละเกมจำกัดผู้เล่นสูงสุด 64 คน แต่ตอนทดสอบไปถึงมากกว่า 100 การเชื่อมต่อ ก็ไม่พบปัญหาด้านประสิทธิภาพ แต่ละเกมรันอยู่ในคอนเทนเนอร์ที่แยกกัน
อยากรู้แรงจูงใจในการสร้างเอนจินใหม่
ดูจาก README แล้ว มีของที่ค่อนข้างเฉพาะเจาะจงฝังมา เช่น ระบบอาวุธ (ประชิด/กระสุน), ร้านค้า, projectile prediction ฝั่งไคลเอนต์ และการเคลื่อนที่ของยูนิต
สงสัยว่าทำไมถึงฝังสิ่งเหล่านี้ไว้ในเอนจิน แทนที่จะทำเป็นปลั๊กอินที่คัดลอกไปใช้ได้ แน่นอนว่าหลายเกมไม่ต้องการฟีเจอร์พวกนี้ แล้วนี่เป็นเกมเอนจินหรือเปล่า? หรือเป็นเอนจินสำหรับ FPS/RPG/แนวเฉพาะอื่น ๆ?
ไม่ได้ไม่ชอบเทคโนโลยีนี้ แต่ก็ยังมีคำถามว่า “ทำไม?” เหลืออยู่ มันมีไว้เพื่ออะไร? ทำไมควรใช้สิ่งนี้แทน Three.js กับเซิร์ฟเวอร์ที่ทำเอง?
ตัวอย่างเช่น เราสร้าง 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 น่าจะรวบรวมในตัวแก้ไขแบบโต้ตอบ
อยากรู้ว่าแนวทางนี้สมเหตุสมผลไหม และมีเครื่องมือที่ช่วยได้หรือเปล่า
ผู้สร้างคนหนึ่งในคอมมูนิตี้ของเรากำลังใช้ ChatGPT สร้างแผนที่แบบไดนามิก เขากำลังทำเกมซ่อนหา โดยส่งพรอมป์ให้สร้าง JSON แผนที่ 2D แล้วโหลดแผนที่นั้นทุกครั้งที่เริ่มรอบใหม่ เกมยังไม่เปิดเผยต่อสาธารณะ เลยแชร์เกมให้ดูได้ยาก
นอกจากนี้ สมาชิกคอมมูนิตี้อีกคนกำลังทำอินเทอร์พรีเตอร์สำหรับ JSON ของเกมเราอยู่ ตัวอย่าง: https://pypi.org/project/pymodd/
ดีใจที่เห็น โปรเจกต์โอเพนซอร์ส แบบนี้ออกมาเพิ่มขึ้น แปลกใจที่ GitHub star ยังไม่ถึง 100