MMO เทคนิคอัลกอริธึมและทรัพยากรเพื่อรักษาแบนด์วิดธ์ต่ำ?


9

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

ฉันสนใจเป็นพิเศษกับผู้ที่มีการเคลื่อนไหว wsad และมุ่งเน้นที่การรักษาเวลาแฝงให้ต่ำนอกจากนี้อัตราและแพ็คเก็ตสำหรับ MMO ประเภทต่างๆ (เครือข่ายฉลาด) คืออะไร

มีวิธีการปรับขนาดอัตราแพ็คเก็ตหรือปิดใช้งานแพ็กเก็ตบางกรณีหากผู้เล่นไม่สามารถเข้าถึงหรือในกรณีต่อมาเห็นพวกเขา?

คำตอบ:


9

ตอนนี้มีหนังสือเล่มนี้ - ซึ่งค่อนข้างเก่าและฉันไม่เคยอ่านเลย แต่มาจากสำนักพิมพ์ที่มีชื่อเสียง ฉันพบสิ่งนี้ซึ่งใหม่กว่า แต่ฉันไม่เคยได้ยินมาก่อน ทั้งสองอ้างว่าครอบคลุมประเด็นการพัฒนาเกม MMO (หรืออย่างน้อยออนไลน์) ที่กล่าวว่าการคาดการณ์ฝั่งไคลเอ็นต์นั้นมากหรือน้อยเหมือนกันโดยไม่คำนึงว่าขนาดฐานผู้เล่นของคุณพร้อมกันและGoogle มีข้อมูลมากมายเกี่ยวกับเรื่องนี้

เป็นเรื่องสำคัญที่จะต้องตระหนักว่าจากมุมมองของภาคปฏิบัติมันค่อนข้างยากสำหรับนักพัฒนาอินดี้ / งานอดิเรกที่จะรวบรวมเกมที่จะได้รับความนิยมมากพอที่จะรวบรวมผู้เล่นมากพอที่จะบรรลุจุดสูงสุดพร้อมกันทางทฤษฎี แต่เทคนิคยังสามารถให้ความรู้เพื่อการวิจัย

มีการจำแนกประเภทที่สำคัญสองอย่างที่คุณสามารถทำได้:

  • มีความมั่นใจในการส่งข้อมูลจำนวนน้อยที่สุดไปยังชุดลูกค้าขั้นต่ำที่ต้องการ
  • ออกแบบเกมที่ไม่ให้แรงจูงใจแก่ผู้เล่นในการรวมกลุ่มมากเกินไปช่วยให้คุณ "ลูกค้าที่ต้องการ" สิ่งเล็ก ๆ โดยทั่วไป

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

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

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

อัตราแพ็คเก็ตและขนาดแตกต่างจากเกมต่อเกมเช่นเดียวกับเกมที่ไม่ใช่ MMO มันเป็นสิ่งที่เฉพาะเจาะจงตามความต้องการและไม่มีมาตรฐานทั่วไป


1
นอกจากนี้ยังมีภาคต่อของหนังสือเล่มแรก (การพัฒนาเกมผู้เล่นหลายคนจำนวนมาก 2) มันไม่ใช่ชุดหนังสือที่มีประโยชน์อย่างมากในความคิดของฉัน (มันไม่ใช่หนังสือเริ่มต้นที่จะทำให้จบแบบ MMO-in-x-hours เหมือนหนังสือเกม dev ส่วนใหญ่) แต่มันจะพูดถึงปัญหาทางทฤษฎีบางอย่าง ถามในคำถามนี้ และบางทีมันอาจจะมีประโยชน์มากกว่าสำหรับคนที่พัฒนา MMO ไปแล้วบางส่วน
Ricket

5

นอกเหนือจากคำตอบข้างต้นแล้วอ่านบน TCP_NODELAY และวิธีการปรับขนาดหน้าต่าง การทำความเข้าใจกับรายละเอียดของ TCP (และใช่คุณต้องการใช้ TCP ไม่ใช่ UDP เว้นแต่ว่าโอกาสในการจัดการกับการอัปเดตที่แตกต่างกันจะทำให้คุณฟังสนุก) และการส่งสัญญาณใหม่นั้นมีความสำคัญต่อการควบคุมเวลาแฝง


4
ฉันจะทำซ้ำว่าถ้าคุณใช้การปรับปรุงที่แตกต่างกัน (โดยปกติจะเป็นเลขฐานสองของโครงสร้างในเกม) และคุณใช้สิ่งใดก็ตามที่มีการส่งมอบตามลำดับ (เชื่อถือได้หรือไม่) คุณจะต้องเสียใจ คนที่ไม่ชอบ TCP ในการเล่นเกมโดยทั่วไปก็ไม่รู้พอ (เช่นรู้ว่า NODELAY ทำอะไร) UDP เหมาะสมกับข้อมูลต่างๆเช่นข้อมูลเสียงที่แพ็คเก็ตที่ล้าสมัยสามารถทิ้งได้ง่ายๆนี่เป็นกรณีของเกม
coderanger

1
"ไม่ค่อยมีในเกม"? หากเซิร์ฟเวอร์ให้เกมที่มีสิทธิ์แก่ฉันทุกเฟรมฉันไม่สนใจสิ่งที่เกิดขึ้นในอดีต หมายเลขเฟรมที่เพิ่มขึ้นอย่างน่าเบื่อง่ายจากแพ็กเก็ต UDP เหมาะสำหรับสิ่งนี้ คุณต้องส่งข้อมูลปริมาณเท่าใดเชื่อถือได้จริง ๆ ?
ChrisE

2
"โดยมีเงื่อนไขว่าเซิร์ฟเวอร์มอบเกมที่มีสิทธิ์ให้ฉันทุกเฟรม" แน่นอนถ้าคุณถือว่ามันเป็นแบบนั้น โปรดทราบว่าฉันพูดว่า "หากคุณกำลังใช้การอัปเดตที่แตกต่าง" ซึ่งจะตรงกันข้ามกับการแสดงสถานะเต็มทุกเฟรม ใน MMO ที่มีความซับซ้อนไม่ว่าในระดับใดในโลกมันจะเป็นไปไม่ได้อย่างรวดเร็วในการจัดส่งการอัพเดทเต็มรูปแบบที่บ่อยครั้ง
coderanger

1
แม้ว่าการส่งสิ่งที่เปลี่ยนแปลงอย่างสมบูรณ์คุณจะพบกับปัญหาการจัดส่งที่ไม่เป็นไปตามคำสั่งซึ่งการรวมสิ่งต่าง ๆ เข้าด้วยกันอาจเป็นไปไม่ได้ นึกถึงการอัปเดต "x = 1, y = 2" แล้ว "y = 1, z = 2" หากสิ่งเหล่านั้นมาถึงข้างหลังคุณต้องการดร็อป "แรก" เพื่อให้ค่าของ y ถูกต้อง แต่คุณสูญเสียการเปลี่ยนแปลงเป็น x
coderanger

1
@ อดัมซึ่งเป็นเหตุผลที่ฉันบอกว่าคุณควรไปอ่านข้อมูลจำเพาะ TCP และเข้าใจวิธีการปรับขนาดหน้าต่างและวิธีการโต้ตอบกับ retransmission ;-) การเขียนใหม่ TCP เป็นสิ่งที่ผิดเสมอโดยทั่วไป หากคุณต้องการความน่าเชื่อถือการส่งมอบตามคำสั่งคุณไม่ควรใช้ UDP
coderanger
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.