เครือข่าย Pong Clone

ฉันมีพื้นฐานของซ็อกเก็ต TCP การสื่อสาร UDP และอื่น ๆ แต่ไม่สามารถหาวิธีใช้สิ่งเหล่านี้กับสภาพแวดล้อมเกมแบบเรียลไทม์ได้

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

เป็นสิ่งที่ดีที่จะส่งสแปมปริมาณการใช้งาน UDP จำนวนมากหรือไม่ ฉันควรตรวจสอบ DCCP เพื่อดูว่ามีความแออัดหรือไม่ หรือนี่ไม่ใช่ปัญหาของโครงการขนาดเล็กเช่นนี้ใช่หรือไม่

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

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

ฉันถามคำถามเหล่านี้ในบริบทของโป่ง แต่ก็สนใจว่าจะเอาชนะปัญหาเหล่านี้ได้อย่างไรในเกมอื่นหรือแก้ไขปัญหาทั่วไป

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

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

มีการอัปเดตตำแหน่งบอลอ้างอิง gametime ในไคลเอนต์ทั้งหมดเพื่อให้คุณสามารถละทิ้งแพ็คเก็ตคำสั่งและทำให้การแก้ไขตำแหน่งลูกบอลแม่นยำยิ่งขึ้น (คุณทราบตำแหน่งและความเร็วในเวลาที่กำหนดในอดีตเพื่อให้คุณสามารถแทรกใหม่ ตำแหน่ง).

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

เกี่ยวกับปัญหาการจราจร - คุณต้องการหลีกเลี่ยงการส่งมากกว่า 20-30 แพ็กเก็ตต่อวินาทีต่อเพียร์ ในกรณีทั่วไปหากคุณส่งแพ็คเก็ตที่มีขนาดเล็กลงน้อยลงคุณจะได้รับความล่าช้าน้อยลง (เล็กน้อย) และโอกาสที่แพ็คเก็ตจะลดลง

แน่นอนว่าคุณไม่ต้องการส่งการอัปเดตด้วยความเร็วที่เร็วกว่าการรวมเฟรมเนื่องจากผู้เล่นจะไม่สามารถบอกความแตกต่างได้ - แน่นอนว่าถ้าคุณส่งแพ็คเก็ตเพียง 10 ครั้งต่อวินาที ผู้เล่นส่วนใหญ่จะไม่สังเกตเห็นความแตกต่าง

นี่เป็นคำถามที่ค่อนข้างกว้าง แต่ฉันจะพยายามสรุปประเด็นสำคัญ

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

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

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

แน่นอนว่าคุณไม่ต้องการอัปเดต "สแปม" ในทุกทิศทาง อัปเดตหนึ่งรายการจากเซิร์ฟเวอร์ต่อเฟรมเป็นสิ่งที่จำเป็นทั้งหมดและเซิร์ฟเวอร์ของคุณควรทำงานในอัตราเฟรมคงที่ สิ่งที่ขึ้นอยู่กับคุณ แต่ไม่จำเป็นต้องไปลงน้ำ เฟรม 50ms (20 FPS) นั้นมีมากมายสำหรับการเล่นเกมที่ราบรื่น เพื่อให้ทุกอย่างราบรื่นบนไคลเอนต์คุณต้องการใช้การแก้ไข ไคลเอนต์ควรมีการเปลี่ยนระหว่างสแนปชอตเฟรมของเซิร์ฟเวอร์อย่างต่อเนื่องซึ่งอาจเป็นหัวข้อของคำถามแยกต่างหากได้อย่างง่ายดาย

การอัปเดตไคลเอ็นต์ควรถูก จำกัด เช่นกันแม้ว่าหนึ่งเฟรมต่อเฟรมจะมากเกินไปหากลูกค้าของคุณใช้อัตราเฟรมที่เหมาะสม

คุณสนใจเรื่องการโกงไหม

ถ้าไม่ทำแบบ peer-to-peer จะทำให้ความล่าช้าของคุณลดลงเนื่องจาก A <-> C แทนที่จะเป็น A <-> B <-> C ถ้าเป็นเช่นนั้นเพื่อความเป็นธรรมในการซิงโครไนซ์คุณอาจต้องการตอบสนองค่อนข้างล่าช้าสำหรับผู้เล่นท้องถิ่นหรือเกมส่วนใหญ่ทำอะไร - ให้ผู้เล่นทำอะไรก็ได้ในพื้นที่แล้วสแน็ปอินกลับ

พงษ์พงษ์นั้นค่อนข้างยุ่งยากเพราะต่างจากเกมส่วนใหญ่ที่คุณไม่สามารถโกง (โดยเป็นนักพัฒนาซอฟต์แวร์) โดยให้ด้านหนึ่งมองเห็นการตีและอีกอันไม่

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

Google คำนวณบัญชีที่ตายแล้ว การส่งอัปเดตสำหรับผู้เล่น 4 คนจะไม่มีนัยสำคัญ จำนวนข้อมูลที่ส่งจะเป็นไปตามลำดับของไบต์ ดังนั้นหมายความว่าการอัปเดตบ่อยครั้งควรจะไม่เป็นไร ด้วยการคำนวณที่ตายตัวคุณจะย้ายผู้เล่นไปยังไคลเอนต์และเซิร์ฟเวอร์ เซิร์ฟเวอร์เป็นสิทธิ์ เมื่อตำแหน่งลูกค้าไกลเกินกว่าจะซิงก์จากเซิร์ฟเวอร์จะต้องเลื่อนกลับไปที่การจัดตำแหน่ง http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking การใช้ UDP เป็นวิธีที่จะไป Bupdates จะถูกส่งไปยังบ่อยครั้งที่ข้อมูลที่สูญหายจะถูกแทนที่ด้วยข้อมูลขาเข้าในไม่ช้า การส่งแพ็กเก็ต TCP ใหม่นั้นไม่คุ้มกับตำแหน่งของผู้เล่น ดูบทความนี้สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีทำให้ไคลเอ็นต์และเซิร์ฟเวอร์ซิงค์กัน

ฉันได้ตั้งโปรแกรมเกมปิงปองเครือข่ายผู้เล่น 2 คนเมื่อสองสามสัปดาห์ก่อนนี่คือวิธีที่ฉันทำ:

- ด้านหนึ่งเปิดเซิร์ฟเวอร์อีกฝั่งหนึ่งเชื่อมต่อโดยอัตโนมัติ - ทั้งคู่กำลังส่งสแปมตำแหน่ง x ของพวกเขาต่อกันที่ @ 60fps หรือน้อยกว่า [UDP] - หากด้านใดด้านหนึ่งชนกับลูกบอลที่พวกเขาตัดสินใจเกี่ยวกับความเร็วและตำแหน่งใหม่ของลูกบอล ไปที่อีกหนึ่ง [TCP] - ถ้าลูกบอลลอยผ่านไม้พายผู้เล่นที่พลาดมันจะติดต่อกับอีกคนหนึ่งพร้อมกับเพิ่มคะแนนข้อความและลูกบอลถูกรีเซ็ต [TCP] - ลูกบอลกำลังถูกจำลองอย่างอิสระตลอดเวลาซึ่ง เหมาะกับฟิสิกส์บอลที่เรียบง่ายของปิงปอง

สิ่งนี้จะสร้างปริมาณการเข้าชมประมาณ 0.3 ถึง 0.5 กิโลไบต์ต่อวินาทีที่ 60fps และผู้เล่นไม่มีความล่าช้าในการรับรู้ของพวกเขา แต่ถ้า ping นั้นต่ำกว่าเกณฑ์ที่กำหนดเนื่องจากลูกบอลต้องส่งตำแหน่งใหม่

การโกงเป็นเรื่องง่ายด้วยระบบนี้และมีความเป็นไปได้สูงที่จะหลุดพ้นจากการเชื่อมต่อที่สูญเสียไปมาก แต่ใครจะสนใจการโกงในปิงปอง?