ในช่วงสองสัปดาห์ที่ผ่านมา ฉันได้ทำงานเกี่ยวกับเอนจิ้นออนไลน์สำหรับเกมของฉัน ก่อนหน้านี้ ฉันไม่รู้อะไรเลยเกี่ยวกับการสร้างเครือข่ายในเกม ดังนั้นฉันจึงอ่านบทความมากมายและทำการทดลองมากมายเพื่อทำความเข้าใจแนวคิดทั้งหมดและสามารถเขียนเอ็นจิ้นเครือข่ายของตัวเองได้
ในคู่มือนี้ ฉันอยากจะแบ่งปันแนวคิดต่างๆ ที่คุณต้องเรียนรู้ก่อนที่จะเขียนเอ็นจิ้นเกมของคุณเอง รวมถึงแหล่งข้อมูลและบทความที่ดีที่สุดเพื่อเรียนรู้เกี่ยวกับแนวคิดเหล่านั้น
โดยทั่วไป สถาปัตยกรรมเครือข่ายมีสองประเภทหลัก: แบบเพียร์ทูเพียร์ และไคลเอ็นต์-เซิร์ฟเวอร์ ในสถาปัตยกรรมแบบเพียร์ทูเพียร์ (p2p) ข้อมูลจะถูกถ่ายโอนระหว่างผู้เล่นที่เชื่อมต่อทุกคู่ ในขณะที่สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ ข้อมูลจะถูกถ่ายโอนระหว่างผู้เล่นและเซิร์ฟเวอร์เท่านั้น
แม้ว่าสถาปัตยกรรมแบบเพียร์ทูเพียร์จะยังคงใช้อยู่ในเกมบางเกม แต่ไคลเอนต์-เซิร์ฟเวอร์ก็เป็นมาตรฐาน: ง่ายต่อการนำไปใช้ ต้องการความกว้างของช่องสัญญาณที่เล็กลง และทำให้ป้องกันการโกงได้ง่ายขึ้น ดังนั้นในบทช่วยสอนนี้ เราจะเน้นไปที่สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์
โดยเฉพาะอย่างยิ่ง เราสนใจเซิร์ฟเวอร์เผด็จการมากที่สุด: ในระบบดังกล่าว เซิร์ฟเวอร์จะถูกเสมอ ตัวอย่างเช่น หากผู้เล่นคิดว่าเขาอยู่ที่พิกัด (10, 5) และเซิร์ฟเวอร์บอกว่าเขาอยู่ที่ (5, 3) ลูกค้าควรแทนที่ตำแหน่งด้วยตำแหน่งที่เซิร์ฟเวอร์รายงาน ไม่ใช่รอง ในทางกลับกัน การใช้เซิร์ฟเวอร์ที่เชื่อถือได้ช่วยให้ระบุผู้โกงได้ง่ายขึ้น
ระบบเกมบนเครือข่ายมีองค์ประกอบหลักสามประการ:
- โปรโตคอลการขนส่ง: วิธีการถ่ายโอนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์
- Application Protocol: สิ่งที่ส่งจากไคลเอนต์ไปยังเซิร์ฟเวอร์ และจากเซิร์ฟเวอร์ไปยังไคลเอนต์ และในรูปแบบใด
- ตรรกะของแอปพลิเคชัน: วิธีใช้ข้อมูลที่ถ่ายโอนเพื่ออัปเดตสถานะของไคลเอ็นต์และเซิร์ฟเวอร์
การเข้าใจบทบาทของแต่ละส่วนและความท้าทายที่เกี่ยวข้องเป็นสิ่งสำคัญมาก
โปรโตคอลการขนส่ง
ขั้นตอนแรกคือการเลือกโปรโตคอลสำหรับส่งข้อมูลระหว่างเซิร์ฟเวอร์และไคลเอนต์ มีอินเทอร์เน็ตโปรโตคอลสองแบบสำหรับสิ่งนี้: и . แต่คุณสามารถสร้างโปรโตคอลการขนส่งของคุณเองโดยใช้โปรโตคอลใดโปรโตคอลหนึ่งหรือใช้ไลบรารีที่ใช้โปรโตคอลเหล่านั้นได้
การเปรียบเทียบ TCP และ UDP
ทั้ง TCP และ UDP ขึ้นอยู่กับ . IP อนุญาตให้ส่งแพ็กเก็ตจากต้นทางไปยังผู้รับ แต่ไม่รับประกันว่าแพ็กเก็ตที่ส่งจะถึงผู้รับไม่ช้าก็เร็ว และจะไปถึงอย่างน้อยหนึ่งครั้ง และลำดับของแพ็กเก็ตจะมาถึงอย่างถูกต้อง คำสั่ง. ยิ่งไปกว่านั้น แพ็กเก็ตสามารถบรรจุข้อมูลได้จำนวนจำกัดตามค่าที่กำหนด .
UDP เป็นเพียงเลเยอร์บางๆ ที่อยู่ด้านบนของ IP จึงมีข้อจำกัดเหมือนกัน ในทางตรงกันข้าม TCP มีคุณสมบัติมากมาย ให้การเชื่อมต่อที่เชื่อถือได้และเป็นระเบียบระหว่างสองโหนดพร้อมการตรวจสอบข้อผิดพลาด ดังนั้น TCP จึงสะดวกมากและใช้ในโปรโตคอลอื่นๆ มากมาย เช่น , и . แต่คุณสมบัติทั้งหมดนี้มีราคา: .
เพื่อทำความเข้าใจว่าเหตุใดฟังก์ชันเหล่านี้จึงทำให้เกิดเวลาแฝงได้ เราต้องเข้าใจว่า TCP ทำงานอย่างไร เมื่อโหนดที่ส่งส่งแพ็กเก็ตไปยังโหนดที่รับ โหนดนั้นคาดว่าจะได้รับการตอบรับ (ACK) หากไม่ได้รับหลังจากช่วงระยะเวลาหนึ่ง (เนื่องจากแพ็กเก็ตหรือการตอบรับสูญหายหรือด้วยเหตุผลอื่น) ก็จะส่งแพ็กเก็ตอีกครั้ง นอกจากนี้ TCP ยังรับประกันว่าจะได้รับแพ็กเก็ตในลำดับที่ถูกต้อง ดังนั้นจนกว่าจะได้รับแพ็กเก็ตที่สูญหาย แพ็กเก็ตอื่นๆ ทั้งหมดจะไม่สามารถประมวลผลได้ แม้ว่าโฮสต์ที่รับแพ็กเก็ตจะได้รับแล้วก็ตาม
แต่อย่างที่คุณอาจจินตนาการได้ ความหน่วงในเกมหลายผู้เล่นมีความสำคัญมาก โดยเฉพาะอย่างยิ่งในประเภทที่เต็มไปด้วยแอ็คชั่นเช่น FPS นี่คือสาเหตุที่หลายเกมใช้ UDP ด้วยโปรโตคอลของตนเอง
โปรโตคอลที่ใช้ UDP ดั้งเดิมจะมีประสิทธิภาพมากกว่า TCP ด้วยเหตุผลหลายประการ ตัวอย่างเช่น สามารถทำเครื่องหมายแพ็กเก็ตบางแพ็กเก็ตว่าเชื่อถือได้ และบางแพ็กเก็ตว่าไม่น่าเชื่อถือ ดังนั้นจึงไม่สนใจว่าแพ็กเก็ตที่ไม่น่าเชื่อถือจะไปถึงผู้รับหรือไม่ หรือสามารถประมวลผลสตรีมข้อมูลหลายรายการเพื่อให้แพ็กเก็ตที่สูญหายในสตรีมเดียวไม่ทำให้สตรีมที่เหลือช้าลง ตัวอย่างเช่น อาจมีเธรดสำหรับป้อนข้อมูลของผู้เล่นและอีกเธรดสำหรับข้อความแชท หากข้อความแชทที่ไม่เร่งด่วนหายไป จะไม่ทำให้การป้อนข้อมูลเร่งด่วนช้าลง หรือโปรโตคอลที่เป็นกรรมสิทธิ์อาจใช้ความน่าเชื่อถือที่แตกต่างจาก TCP เพื่อให้มีประสิทธิภาพมากขึ้นในสภาพแวดล้อมของวิดีโอเกม
ดังนั้นหาก TCP แย่มาก เราจะสร้างโปรโตคอลการขนส่งของเราเองโดยยึดตาม UDP หรือไม่
มันซับซ้อนกว่าเล็กน้อย แม้ว่า TCP เกือบจะไม่ดีที่สุดสำหรับระบบเครือข่ายเกม แต่ก็สามารถทำงานได้ดีกับเกมเฉพาะของคุณและช่วยคุณประหยัดเวลาอันมีค่า ตัวอย่างเช่น เวลาแฝงอาจไม่เป็นปัญหาสำหรับเกมแบบผลัดกันเล่นหรือเกมที่สามารถเล่นได้บนเครือข่าย LAN เท่านั้น ซึ่งเวลาแฝงและการสูญเสียแพ็คเก็ตจะต่ำกว่าบนอินเทอร์เน็ตมาก
เกมที่ประสบความสำเร็จหลายเกม รวมถึง World of Warcraft, Minecraft และ Terraria ใช้ TCP อย่างไรก็ตาม FPS ส่วนใหญ่ใช้โปรโตคอลที่ใช้ UDP ของตัวเอง ดังนั้นเราจะพูดถึงโปรโตคอลเหล่านี้เพิ่มเติมด้านล่าง
หากคุณตัดสินใจใช้ TCP ตรวจสอบให้แน่ใจว่าได้ปิดใช้งานแล้ว เนื่องจากจะบัฟเฟอร์แพ็กเก็ตก่อนส่ง ซึ่งหมายความว่าจะเพิ่มเวลาแฝง
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับความแตกต่างระหว่าง UDP และ TCP ในบริบทของเกมที่มีผู้เล่นหลายคน คุณสามารถอ่านบทความของ Glenn Fiedler .
โปรโตคอลของตัวเอง
ดังนั้นคุณจึงต้องการสร้างโปรโตคอลการขนส่งของคุณเอง แต่ไม่รู้ว่าจะเริ่มต้นจากตรงไหนใช่หรือไม่ คุณโชคดีเพราะ Glenn Fiedler ได้เขียนบทความที่น่าทึ่งสองบทความเกี่ยวกับเรื่องนี้ คุณจะพบความคิดที่ชาญฉลาดมากมายในตัวพวกเขา
บทความแรก ปี 2008 ง่ายกว่าครั้งที่สอง 2016. ฉันขอแนะนำให้คุณเริ่มต้นด้วยอันที่เก่ากว่า
โปรดทราบว่า Glenn Fiedler เป็นผู้สนับสนุนหลักในการใช้โปรโตคอลแบบกำหนดเองตาม UDP และหลังจากอ่านบทความของเขาแล้ว คุณอาจยอมรับความคิดเห็นของเขาที่ว่า TCP มีข้อบกพร่องร้ายแรงในวิดีโอเกม และคุณจะต้องการใช้โปรโตคอลของคุณเอง
แต่ถ้าคุณยังใหม่กับระบบเครือข่าย ให้ช่วยตัวเองและใช้ TCP หรือไลบรารี หากต้องการใช้โปรโตคอลการขนส่งของคุณเองให้ประสบความสำเร็จ คุณต้องเรียนรู้ล่วงหน้ามากมาย
ห้องสมุดเครือข่าย
หากคุณต้องการบางสิ่งที่มีประสิทธิภาพมากกว่า TCP แต่ไม่ต้องการยุ่งยากในการใช้โปรโตคอลของคุณเองและลงรายละเอียดมากมาย คุณสามารถใช้ไลบรารีเครือข่ายได้ มีมากมาย:
- เกลนน์ ฟิดเลอร์
- ซึ่งไม่รองรับอีกต่อไป แต่เป็นเพียงทางแยกเท่านั้น ดูเหมือนว่ามันยังคงใช้งานอยู่
- เป็นห้องสมุดที่สร้างขึ้นสำหรับ FPS แบบผู้เล่นหลายคน
- วาล์ว
ฉันไม่ได้ลองใช้ทั้งหมด แต่ฉันชอบ ENet เพราะมันใช้งานง่ายและเชื่อถือได้ นอกจากนี้ยังมีเอกสารที่ชัดเจนและบทช่วยสอนสำหรับผู้เริ่มต้นอีกด้วย
พิธีสารการขนส่ง: บทสรุป
โดยสรุป: มีโปรโตคอลการขนส่งหลักสองแบบ: TCP และ UDP TCP มีคุณสมบัติที่มีประโยชน์มากมาย: ความน่าเชื่อถือ การเก็บรักษาลำดับแพ็กเก็ต การตรวจจับข้อผิดพลาด UDP ไม่มีทั้งหมดนี้ แต่โดยธรรมชาติแล้ว TCP ได้เพิ่มเวลาแฝง ซึ่งเป็นที่ยอมรับไม่ได้สำหรับบางเกม นั่นคือเพื่อให้แน่ใจว่ามีเวลาแฝงต่ำ คุณสามารถสร้างโปรโตคอลของคุณเองโดยใช้ UDP หรือใช้ไลบรารีที่ใช้โปรโตคอลการขนส่งบน UDP และได้รับการดัดแปลงสำหรับวิดีโอเกมที่มีผู้เล่นหลายคน
ทางเลือกระหว่าง TCP, UDP และไลบรารีขึ้นอยู่กับหลายปัจจัย ประการแรก จากความต้องการของเกม: มันต้องการเวลาแฝงต่ำหรือไม่? ประการที่สอง จากข้อกำหนดของโปรโตคอลแอปพลิเคชัน: จำเป็นต้องมีโปรโตคอลที่เชื่อถือได้หรือไม่ ดังที่เราจะได้เห็นในส่วนถัดไป เป็นไปได้ที่จะสร้าง Application Protocol ซึ่งโปรโตคอลที่ไม่น่าเชื่อถือมีความเหมาะสมทีเดียว สุดท้ายนี้ คุณต้องคำนึงถึงประสบการณ์ของผู้พัฒนาเอ็นจิ้นเครือข่ายด้วย
ฉันมีคำแนะนำสองประการ:
- สรุปโปรโตคอลการขนส่งจากส่วนที่เหลือของแอปพลิเคชันให้มากที่สุดเพื่อให้สามารถแทนที่ได้อย่างง่ายดายโดยไม่ต้องเขียนโค้ดใหม่ทั้งหมด
- อย่าเพิ่มประสิทธิภาพมากเกินไป หากคุณไม่ใช่ผู้เชี่ยวชาญด้านเครือข่ายและไม่แน่ใจว่าจำเป็นต้องใช้โปรโตคอลการรับส่งข้อมูลที่ใช้ UDP แบบกำหนดเองหรือไม่ คุณสามารถเริ่มต้นด้วย TCP หรือไลบรารีที่ให้ความน่าเชื่อถือ จากนั้นจึงทดสอบและวัดประสิทธิภาพ หากเกิดปัญหาและคุณมั่นใจว่าสาเหตุเกิดจากโปรโตคอลการขนส่ง อาจถึงเวลาที่คุณต้องสร้างโปรโตคอลการขนส่งของคุณเอง
ในตอนท้ายของส่วนนี้ผมขอแนะนำให้คุณอ่าน โดย Brian Hook ซึ่งครอบคลุมหลายหัวข้อที่กล่าวถึงที่นี่
โปรโตคอลแอปพลิเคชัน
ตอนนี้เราสามารถแลกเปลี่ยนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ได้แล้ว เราจำเป็นต้องตัดสินใจว่าจะถ่ายโอนข้อมูลใดและอยู่ในรูปแบบใด
รูปแบบคลาสสิกคือไคลเอนต์ส่งข้อมูลหรือการดำเนินการไปยังเซิร์ฟเวอร์ และเซิร์ฟเวอร์จะส่งสถานะเกมปัจจุบันไปยังไคลเอนต์
เซิร์ฟเวอร์ส่งสถานะไม่เต็ม แต่เป็นสถานะที่กรองแล้วพร้อมกับเอนทิตีที่อยู่ใกล้ผู้เล่น เขาทำเช่นนี้ด้วยเหตุผลสามประการ ประการแรก สถานะที่สมบูรณ์อาจมีขนาดใหญ่เกินกว่าจะส่งสัญญาณที่ความถี่สูงได้ ประการที่สอง ลูกค้าสนใจข้อมูลภาพและเสียงเป็นหลัก เนื่องจากตรรกะของเกมส่วนใหญ่จำลองบนเซิร์ฟเวอร์เกม ประการที่สาม ในบางเกม ผู้เล่นไม่จำเป็นต้องรู้ข้อมูลบางอย่าง เช่น ตำแหน่งของศัตรูที่อยู่อีกด้านหนึ่งของแผนที่ ไม่เช่นนั้นเขาจะสามารถดมแพ็คเก็ตและรู้ว่าจะต้องเคลื่อนที่ไปที่ไหนเพื่อฆ่าเขา
การทำให้เป็นอนุกรม
ขั้นตอนแรกคือการแปลงข้อมูลที่เราต้องการส่ง (อินพุตหรือสถานะของเกม) ให้อยู่ในรูปแบบที่เหมาะสมสำหรับการส่งข้อมูล กระบวนการนี้เรียกว่า .
ความคิดที่เข้ามาในความคิดทันทีคือการใช้รูปแบบที่มนุษย์สามารถอ่านได้ เช่น JSON หรือ XML แต่สิ่งนี้จะไม่ได้ผลโดยสิ้นเชิงและจะทำให้เสียช่องทางส่วนใหญ่
ขอแนะนำให้ใช้รูปแบบไบนารีแทนซึ่งมีขนาดกะทัดรัดกว่ามาก นั่นคือแพ็กเก็ตจะมีเพียงไม่กี่ไบต์เท่านั้น มีปัญหาที่ต้องพิจารณาที่นี่ ซึ่งอาจแตกต่างกันในคอมพิวเตอร์แต่ละเครื่อง
ในการทำให้ข้อมูลเป็นอนุกรม คุณสามารถใช้ไลบรารีได้ เช่น:
- บริษัทพายุทราย
- เชน แกรนท์ และแรนดอล์ฟ วอร์ฮีส์
เพียงตรวจสอบให้แน่ใจว่าห้องสมุดสร้างไฟล์เก็บถาวรแบบพกพาและใส่ใจเกี่ยวกับความไม่มีที่สิ้นสุด
ทางเลือกอื่นคือการนำไปประยุกต์ใช้ด้วยตนเอง ซึ่งไม่ใช่เรื่องยาก โดยเฉพาะหากคุณใช้แนวทางที่เน้นข้อมูลเป็นศูนย์กลางในโค้ดของคุณ นอกจากนี้ยังช่วยให้คุณดำเนินการปรับให้เหมาะสมที่ไม่สามารถทำได้เสมอไปเมื่อใช้ไลบรารี
Glenn Fiedler เขียนบทความสองเรื่องเกี่ยวกับการทำให้เป็นอนุกรม: и .
การบีบอัด
จำนวนข้อมูลที่ถ่ายโอนระหว่างไคลเอนต์และเซิร์ฟเวอร์ถูกจำกัดโดยแบนด์วิธของช่องสัญญาณ การบีบอัดข้อมูลจะช่วยให้คุณสามารถถ่ายโอนข้อมูลได้มากขึ้นในแต่ละสแน็ปช็อต เพิ่มความถี่ในการอัปเดต หรือเพียงแค่ลดข้อกำหนดของช่องสัญญาณ
บรรจุภัณฑ์บิต
เทคนิคแรกคือการบรรจุแบบบิต ประกอบด้วยการใช้จำนวนบิตที่จำเป็นในการอธิบายค่าที่ต้องการ ตัวอย่างเช่น หากคุณมีแจงนับที่สามารถมีค่าต่างกันได้ 16 ค่า แทนที่จะเป็นจำนวนไบต์ทั้งหมด (8 บิต) คุณสามารถใช้เพียง 4 บิตได้
Glenn Fiedler อธิบายวิธีดำเนินการในส่วนที่สองของบทความ .
การบรรจุบิตทำงานได้ดีกับการสุ่มตัวอย่าง ซึ่งจะเป็นหัวข้อของหัวข้อถัดไป
การสุ่มตัวอย่าง
เป็นเทคนิคการบีบอัดแบบ lossy ที่ใช้เพียงชุดย่อยของค่าที่เป็นไปได้ในการเข้ารหัสค่า วิธีที่ง่ายที่สุดในการใช้การแยกส่วนคือการปัดเศษตัวเลขทศนิยม
Glenn Fiedler (อีกครั้ง!) แสดงวิธีนำการสุ่มตัวอย่างไปปฏิบัติในบทความของเขา .
อัลกอริธึมการบีบอัด
เทคนิคต่อไปคืออัลกอริธึมการบีบอัดแบบไม่สูญเสียข้อมูล
ในความคิดของฉัน นี่คืออัลกอริธึมที่น่าสนใจที่สุดสามประการที่คุณต้องรู้:
- ด้วยโค้ดที่คำนวณไว้ล่วงหน้าซึ่งเร็วมากและให้ผลลัพธ์ที่ดี มันถูกใช้เพื่อบีบอัดแพ็กเก็ตในเอ็นจิ้นเครือข่าย Quake3
- เป็นอัลกอริธึมการบีบอัดอเนกประสงค์ที่ไม่เพิ่มปริมาณข้อมูล เป็นยังไงบ้างคะ. มันถูกนำไปใช้ในการใช้งานที่หลากหลาย อาจซ้ำซ้อนในการอัปเดตสถานะ แต่จะมีประโยชน์หากคุณต้องการส่งเนื้อหา ข้อความยาว หรือภูมิประเทศไปยังไคลเอนต์จากเซิร์ฟเวอร์
- - นี่อาจเป็นอัลกอริธึมการบีบอัดที่ง่ายที่สุด แต่มีประสิทธิภาพมากสำหรับข้อมูลบางประเภท และสามารถใช้เป็นขั้นตอนก่อนการประมวลผลก่อน zlib เหมาะอย่างยิ่งสำหรับการบีบอัดภูมิประเทศที่ประกอบด้วยแผ่นกระเบื้องหรือว็อกเซลซึ่งมีองค์ประกอบที่อยู่ติดกันจำนวนมากซ้ำกัน
การบีบอัดเดลต้า
เทคนิคการบีบอัดสุดท้ายคือการบีบอัดแบบเดลต้า ประกอบด้วยความจริงที่ว่ามีเพียงความแตกต่างระหว่างสถานะเกมปัจจุบันและสถานะสุดท้ายที่ไคลเอนต์ได้รับเท่านั้นที่จะถูกส่ง
ถูกใช้ครั้งแรกในเอ็นจิ้นเครือข่าย Quake3 ต่อไปนี้เป็นบทความสองบทความที่อธิบายวิธีใช้งาน:
- ไบรอัน ฮุก
- ฟาเบียน แซงกลาร์ส [ บทความเกี่ยวกับHabré ดูหัวข้อ “โมเดลเครือข่าย”]
Glenn Fiedler ยังใช้สิ่งนี้ในส่วนที่สองของบทความของเขาด้วย .
การเข้ารหัส
นอกจากนี้ คุณอาจต้องเข้ารหัสการถ่ายโอนข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ มีหลายสาเหตุนี้:
- ความเป็นส่วนตัว/ความลับ: ข้อความสามารถอ่านได้โดยผู้รับเท่านั้น และบุคคลอื่นที่ดมกลิ่นเครือข่ายจะไม่สามารถอ่านได้
- การรับรองความถูกต้อง: บุคคลที่ต้องการเล่นบทบาทของผู้เล่นจะต้องรู้รหัสของเขา
- การป้องกันการโกง: มันจะยากขึ้นมากสำหรับผู้เล่นที่เป็นอันตรายในการสร้างแพ็คเกจโกงของตนเอง พวกเขาจะต้องสร้างรูปแบบการเข้ารหัสซ้ำและค้นหาคีย์ (ซึ่งจะเปลี่ยนแปลงไปตามการเชื่อมต่อแต่ละครั้ง)
ฉันขอแนะนำอย่างยิ่งให้ใช้ห้องสมุดสำหรับสิ่งนี้ ฉันแนะนำให้ใช้ เพราะมันเรียบง่ายเป็นพิเศษและมีบทช่วยสอนที่ยอดเยี่ยม สิ่งที่น่าสนใจอย่างยิ่งคือการกวดวิชาเกี่ยวกับ ซึ่งช่วยให้คุณสร้างคีย์ใหม่ได้ด้วยการเชื่อมต่อใหม่แต่ละครั้ง
โปรโตคอลแอปพลิเคชัน: บทสรุป
นี่เป็นการสรุปโปรโตคอลการสมัครของเรา ฉันเชื่อว่าการบีบอัดเป็นทางเลือกโดยสมบูรณ์ และการตัดสินใจใช้การบีบอัดนั้นขึ้นอยู่กับเกมและแบนด์วิธที่ต้องการเท่านั้น ในความคิดของฉันการเข้ารหัสเป็นสิ่งจำเป็น แต่ในต้นแบบแรกคุณสามารถทำได้โดยไม่ต้องใช้มัน
ตรรกะของแอปพลิเคชัน
ขณะนี้เราสามารถอัปเดตสถานะในไคลเอนต์ได้แล้ว แต่อาจประสบปัญหาด้านเวลาในการตอบสนอง หลังจากป้อนข้อมูลเสร็จแล้ว ผู้เล่นต้องรอให้สถานะของเกมอัปเดตจากเซิร์ฟเวอร์เพื่อดูว่ามันมีผลกระทบต่อโลกอย่างไร
ยิ่งไปกว่านั้น ระหว่างการอัปเดตสองสถานะ โลกจะนิ่งสนิท หากอัตราการอัพเดตสถานะต่ำ การเคลื่อนไหวจะกระตุกมาก
มีเทคนิคหลายประการในการลดผลกระทบของปัญหานี้ และฉันจะกล่าวถึงในหัวข้อถัดไป
เทคนิคการปรับความหน่วงแฝง
เทคนิคทั้งหมดที่อธิบายไว้ในส่วนนี้จะกล่าวถึงโดยละเอียดในชุดข้อมูลนี้ กาเบรียล แกมเบ็ตต้า. ฉันขอแนะนำให้อ่านบทความชุดที่ยอดเยี่ยมนี้ นอกจากนี้ยังมีการสาธิตเชิงโต้ตอบที่ให้คุณเห็นว่าเทคนิคเหล่านี้ทำงานอย่างไรในทางปฏิบัติ
เทคนิคแรกคือการใช้ผลลัพธ์อินพุตโดยตรงโดยไม่ต้องรอการตอบกลับจากเซิร์ฟเวอร์ มันถูกเรียกว่า การคาดการณ์ฝั่งไคลเอ็นต์. อย่างไรก็ตาม เมื่อไคลเอนต์ได้รับการอัปเดตจากเซิร์ฟเวอร์ จะต้องตรวจสอบว่าการคาดการณ์นั้นถูกต้อง หากไม่เป็นเช่นนั้น เขาเพียงแค่ต้องเปลี่ยนสถานะของเขาตามสิ่งที่เขาได้รับจากเซิร์ฟเวอร์ เนื่องจากเซิร์ฟเวอร์นั้นเป็นเผด็จการ เทคนิคนี้ถูกใช้ครั้งแรกใน Quake คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในบทความ ฟาเบียน แซงกลาร์ส [ บนฮาเบร]
เทคนิคชุดที่สองใช้เพื่อทำให้การเคลื่อนไหวของเอนทิตีอื่น ๆ ระหว่างการอัปเดตสองสถานะราบรื่นขึ้น มีสองวิธีในการแก้ปัญหานี้: การแก้ไขและการคาดการณ์ ในกรณีของการประมาณค่า สองสถานะสุดท้ายจะถูกนำไปใช้ และการเปลี่ยนจากสถานะหนึ่งไปยังอีกสถานะหนึ่งจะปรากฏขึ้น ข้อเสียคือทำให้เกิดความล่าช้าเล็กน้อยเนื่องจากลูกค้ามักจะมองเห็นสิ่งที่เกิดขึ้นในอดีตเสมอ การคาดการณ์เป็นเรื่องเกี่ยวกับการคาดการณ์ว่าเอนทิตีควรอยู่ที่ไหนโดยพิจารณาจากสถานะสุดท้ายที่ลูกค้าได้รับ ข้อเสียของมันคือหากเอนทิตีเปลี่ยนทิศทางการเคลื่อนไหวโดยสิ้นเชิง จะเกิดข้อผิดพลาดขนาดใหญ่ระหว่างการคาดการณ์และตำแหน่งจริง
เทคนิคขั้นสูงสุดล่าสุดที่มีประโยชน์เฉพาะใน FPS คือ การชดเชยความล่าช้า. เมื่อใช้การชดเชยความล่าช้า เซิร์ฟเวอร์จะคำนึงถึงความล่าช้าของลูกค้าเมื่อยิงไปที่เป้าหมาย ตัวอย่างเช่น หากผู้เล่นยิงเฮดช็อตบนหน้าจอ แต่ในความเป็นจริงแล้ว เป้าหมายของพวกเขาอยู่ในตำแหน่งอื่นเนื่องจากความล่าช้า จึงไม่ยุติธรรมที่จะปฏิเสธสิทธิ์ในการฆ่าผู้เล่นเนื่องจากความล่าช้า ดังนั้น เซิร์ฟเวอร์จะย้อนเวลากลับไปยังช่วงเวลาที่ผู้เล่นยิงเพื่อจำลองสิ่งที่ผู้เล่นเห็นบนหน้าจอ และตรวจสอบการชนกันระหว่างการยิงกับเป้าหมาย
Glenn Fiedler (เช่นเคย!) เขียนบทความในปี 2004 โดยเขาได้วางรากฐานสำหรับการซิงโครไนซ์การจำลองทางฟิสิกส์ระหว่างเซิร์ฟเวอร์และไคลเอนต์ ในปี 2014 เขาได้เขียนบทความชุดใหม่ ซึ่งอธิบายเทคนิคอื่นๆ สำหรับการซิงโครไนซ์การจำลองทางฟิสิกส์
นอกจากนี้ยังมีสองบทความในวิกิ Valve и ซึ่งพิจารณาชดเชยความล่าช้า
ป้องกันการโกง
มีสองเทคนิคหลักในการป้องกันการโกง
ประการแรก: ทำให้ผู้โกงส่งแพ็กเก็ตที่เป็นอันตรายได้ยากขึ้น ตามที่กล่าวไว้ข้างต้น วิธีที่ดีในการนำสิ่งนี้ไปใช้คือการเข้ารหัส
ประการที่สอง: เซิร์ฟเวอร์เผด็จการควรรับเฉพาะคำสั่ง/อินพุต/การดำเนินการเท่านั้น ไคลเอ็นต์ไม่ควรสามารถเปลี่ยนสถานะบนเซิร์ฟเวอร์ได้นอกเหนือจากการส่งข้อมูล จากนั้นทุกครั้งที่เซิร์ฟเวอร์รับอินพุต จะต้องตรวจสอบว่าถูกต้องก่อนใช้งานหรือไม่
ตรรกะของการประยุกต์ใช้: ข้อสรุป
ฉันขอแนะนำให้คุณใช้วิธีการจำลองเวลาแฝงสูงและอัตราการรีเฟรชต่ำ เพื่อให้คุณสามารถทดสอบพฤติกรรมของเกมของคุณในสภาวะที่ไม่ดี แม้ว่าไคลเอนต์และเซิร์ฟเวอร์จะทำงานบนคอมพิวเตอร์เครื่องเดียวกันก็ตาม สิ่งนี้จะช่วยลดความยุ่งยากในการใช้เทคนิคการปรับความล่าช้าให้เรียบลงอย่างมาก
แหล่งข้อมูลที่เป็นประโยชน์อื่นๆ
หากคุณต้องการสำรวจแหล่งข้อมูลอื่นๆ เกี่ยวกับโมเดลเครือข่าย คุณสามารถดูได้ที่นี่:
- – บล็อกทั้งหมดของเขาน่าอ่าน มีบทความดีๆ มากมายอยู่ที่นั่น รวบรวมบทความเกี่ยวกับเทคโนโลยีเครือข่ายทั้งหมด
- โดย M. Fatih MAR เป็นรายการบทความและวิดีโอที่ครอบคลุมเกี่ยวกับเอ็นจิ้นวิดีโอเกมออนไลน์
- В นอกจากนี้ยังมีลิงค์ที่มีประโยชน์มากมาย
ที่มา: will.com