เกม engine Godot ยังคงดึงดูดนักพัฒนาที่มองหาทางเลือกจากแพลตฟอร์มพัฒนาเกมเชิงพาณิชย์ แต่การสนทนาล่าสุดเผยให้เห็นทั้งความตื่นเต้นเกี่ยวกับศักยภาพและความกังวลเกี่ยวกับความสามารถด้านเครือข่าย การสนทนาได้ทวีความรุนแรงขึ้นหลังจากการวิเคราะห์ทางเทคนิคโดยละเอียดของการพัฒนาเกมแบบผู้เล่นหลายคนโดยใช้ฟีเจอร์เครือข่ายในตัวของ Godot
การรวม Steam จุดประกายการสนทนาทางเทคนิค
นักพัฒนากำลังสำรวจวิธีการรวมฟีเจอร์เครือข่ายของ Steam เข้ากับโปรเจ็กต์ Godot อย่างแข็งขัน ชุมชนกำลังหารือว่าควรใช้ networking sockets ของ Steam ควบคู่ไปกับหรือแทนที่การใช้งาน ENet เริ่มต้นของ Godot นักพัฒนาบางคนได้สร้างแนวทางแบบผสมผสานที่ใช้ ENet สำหรับเกมเครือข่ายท้องถิ่นในขณะที่เปลี่ยนไปใช้ Steam networking สำหรับการเล่นแบบออนไลน์หลายคน ทำให้โค้ดเกมส่วนที่เหลือยังคงไม่เปลี่ยนแปลง
ความยืดหยุ่นนี้ดึงดูดนักพัฒนาที่ต้องการใช้ประโยชน์จากโครงสร้างพื้นฐานของ Steam ในขณะที่รักษาความเข้ากันได้กับแพลตฟอร์มที่ไม่ใช่ Steam อย่างไรก็ตาม คำถามยังคงมีอยู่เกี่ยวกับประโยชน์ในทางปฏิบัติของการสนับสนุน networking backends หลายตัวเมื่อเทียบกับการมุ่งเน้นไปที่โซลูชันเดียวที่แข็งแกร่ง
โซลูชันเครือข่ายของ Godot จากบุคคลที่สาม
- netfox: เฟรมเวิร์กเครือข่ายที่พัฒนาโดยชุมชน
- Steam Networking: การรวมเข้ากับ Steam SDK ผ่าน Godot Steamworks
- ENet: ไลบรารีเครือข่ายแบบ UDP เริ่มต้นใน Godot
- แนวทางแบบผสม: ENet สำหรับ LAN, Steam networking สำหรับการเล่นออนไลน์
ข้อจำกัดของเครือข่ายหลักผลักดันโซลูชันจากบุคคลที่สาม
ความกังวลที่สำคัญที่เกิดขึ้นจากชุมชนมุ่งเน้นไปที่ความสามารถด้านเครือข่ายในตัวของ Godot ที่มีน้อยมาก แม้ว่าเอนจินจะให้การซิงโครไนซ์สถานะพื้นฐานและการเรียกกระบวนการระยะไกล แต่นักพัฒนาสังเกตว่าฟีเจอร์ที่จำเป็นเช่น prediction, rollback และ lag compensation ต้องการการใช้งานแบบกำหนดเองอย่างมาก
แกนหลักของ netcode ของ Godot มีน้อยเกินไป มันให้วิธีการซิงโครไนซ์สถานะและทำ RPC เท่านั้น
ข้อจำกัดนี้ได้นำไปสู่การพัฒนาโซลูชันจากบุคคลที่สามเช่น netfox ซึ่งมีจุดมุ่งหมายเพื่อจัดการกับฟังก์ชันเครือข่ายระดับสูงที่ซับซ้อนซึ่งเกมแบบผู้เล่นหลายคนจำนวนมากต้องการ การมีอยู่ของโปรเจ็กต์ดังกล่าวเน้นย้ำทั้งความต้องการเครื่องมือเครือข่ายที่ดีกว่าและความเต็มใจของชุมชนในการเติมเต็มช่องว่างในความสามารถของเอนจิน
การยอมรับที่เพิ่มขึ้นแม้จะมีความกังวลเรื่องภาษาสคริปต์
แม้จะมีความท้าทายทางเทคนิค Godot ยังคงได้รับความนิยมในหมู่นักพัฒนาอิสระ หลายคนเปรียบเทียบเส้นทางของมันกับความสำเร็จของ Blender ในการทำลายอุตสาหกรรมแอนิเมชัน 3D โดยแนะนำว่า Godot อาจเปลี่ยนแปลงการเข้าถึงการพัฒนาเกมในทำนองเดียวกัน
อย่างไรก็ตาม นักพัฒนาบางคนแสดงความลังเลเกี่ยวกับ GDScript ภาษาสคริปต์แบบกำหนดเองของ Godot โดยเลือกที่จะรอการสนับสนุน C# ที่มีฟีเจอร์เท่าเทียมกันอย่างเต็มรูปแบบ การผูกภาษาทางเลือกรวมถึงการสนับสนุน TypeScript ที่ไม่เป็นทางการกำลังเกิดขึ้นเพื่อตอบสนองความต้องการเหล่านี้
เอนจินดึงดูดนักพัฒนาที่แสวงหาความเป็นอิสระจากโมเดลการให้สิทธิ์เชิงพาณิชย์และผู้ที่ทำงานในโปรเจ็กต์ขนาดเล็กกว่าที่แนวทางที่เรียบง่ายให้ข้อได้เปรียบเหนือทางเลือกที่ซับซ้อนกว่าเช่น Unity หรือ Unreal Engine
การถกเถียงทางเทคนิคเกี่ยวกับอำนาจไคลเอนต์ในแบบผู้เล่นหลายคน
การสนทนาเรื่องเครือข่ายยังเผยให้เห็นความแตกต่างทางปรัชญาเกี่ยวกับสถาปัตยกรรมเกมแบบผู้เล่นหลายคน นักพัฒนาบางคนสนับสนุนอำนาจเซิร์ฟเวอร์ที่เข้มงวดเพื่อป้องกันการโกง ในขณะที่คนอื่นสนับสนุนการตรวจจับการโจมตีฝั่งไคลเอนต์พร้อมการตรวจสอบเซิร์ฟเวอร์เพื่อประสบการณ์ผู้เล่นที่ดีกว่า
การถกเถียงนี้สะท้อนแนวโน้มอุตสาหกรรมที่กว้างขึ้นที่เกมแข่งขันใช้ระบบที่ไคลเอนต์มีอำนาจมากขึ้นร่วมกับซอฟต์แวร์ป้องกันการโกง โดยให้ความสำคัญกับการเล่นเกมที่ตอบสนองมากกว่าแนวทางการตรวจสอบฝั่งเซิร์ฟเวอร์แบบดั้งเดิม
การสนทนาที่กำลังดำเนินอยู่แสดงให้เห็นถึงความเป็นผู้ใหญ่ที่เพิ่มขึ้นของ Godot ในฐานะแพลตฟอร์มพัฒนาเกมในขณะที่เน้นพื้นที่ที่ชุมชนยังคงทำงานเพื่อเพิ่มประสิทธิภาพ เมื่อนักพัฒนาจำนวนมากขึ้นแบ่งปันประสบการณ์และโซลูชัน ระบบนิเวศรอบ Godot ยังคงขยายตัวเพื่อจัดการกับความท้าทายในการพัฒนาในโลกแห่งความเป็นจริง
อ้างอิง: TESTING A ROBUST NETCODE WITH GODOT