كمونية (اتصالات)

في الألعاب عبر الإنترنت، الكمونية هي تأخير ملحوظ بين حركة اللاعبين ورد فعل الخادم الذي يدعم لعبة الفيديو.

المسموح به مع الكمونية يعتمد على نوع اللعبة. على سبيل المثال، قد تنطوي لعبة استراتيجية أو لعبة قائمة على الدوران بوتيرة منخفضة على عتبة عالية أو قد لا تتأثر في الغالب بالكمونيات العالية، في حين أن لعبة اللعب نشل مثل مطلق النار من منظور الشخص الأول مع وتيرة أعلى بكثير قد تتطلب إلى حد كبير انخفاض الكمونية لتكون قادرة على توفير تجربة لعب مرضية. ومع ذلك، فإن الخصائص المحددة للعبة يهم. على سبيل المثال، لعبة الشطرنج السريعة هي لعبة تعتمد على الدوران وهي حركة سريعة وقد لا تتسامح مع الكمونية الشديدة. أيضًا، يمكن تصميم بعض ألعاب twitch بحيث لا تكمونية إلا الأحداث التي لا تؤثر على نتيجة اللعبة، مما يتيح استجابة محلية سريعة في معظم الأوقات.

بينج

يشير بينج بينج إلى زمن انتقال الشبكة بين عميل اللاعب وخادم اللعبة كما تم قياسه باستخدام أداة بينج أو ما يعادلها. يتم الإبلاغ عن بينج كمياً كمتوسط متوسط بالمللي ثانية (مللي ثانية). بينغ واحد هو أقل، وأقل زمن الوصول هو وأقل كمونية سوف تجربة اللاعب. يشيع استخدام بينج العالي وبينج المنخفض في مصطلحات الألعاب عبر الإنترنت، حيث يشير بينج العالي إلى لعبة بينج التي تسبب مقدارًا كبيرًا من الكمونية؛ في حين أن أي مستوى من مستويات بينج قد يتسبب في كمونية، إلا أن الكمونية الشديد يحدث عادة نتيجة بينج لأكثر من 100   الآنسة.[1] هذا الاستخدام عبارة عن لغة عامية ثقافية للألعاب ولا يتم العثور عليها أو استخدامها بشكل شائع في دوائر شبكات الكمبيوتر الاحترافية. في الألعاب التي يكون التوقيت فيها أمرًا أساسيًا، مثل ألعاب إطلاق النار من منظور الشخص الأول والألعاب الاستراتيجية في الوقت الفعلي، من المفضل دائمًا استخدام لعبة بينج المنخفضة، حيث أن لعبة بينج المنخفضة تعني طريقة أكثر سلاسة في اللعب من خلال السماح بتحديثات أسرع لبيانات اللعبة بين عملاء اللاعبين وخادم اللعبة.

الكمون العالي يمكن أن يسبب كمونية. قد تقوم خوادم اللعبة بفصل العميل إذا كان زمن الوصول مرتفعًا جدًا وقد يمثل ضررًا لألعاب اللاعبين الآخرين. وبالمثل، يفرض برنامج العميل غالبًا قطع الاتصال إذا كان زمن الوصول مرتفعًا للغاية. قد يؤدي الأمر بينج العالي أيضًا إلى تعطل الخوادم نظرًا لعدم الاستقرار.

في بعض ألعاب إطلاق النار من أول شخص، قد يتسبب ارتفاع البينجات في أن يكتسب اللاعب ميزات غير عادلة عن غير قصد، مثل الاختفاء من موقع ما وإعادة الظهور في موقع آخر على الفور، ومحاكاة تأثير النقل عن بعد، مما يجعل من الصعب على اللاعبين الآخرين الحكم على شخصياتهم وضعه وبالتالي جعل اللاعب أكثر صعوبة في الاستهداف. للتصدي لهذا، تقوم العديد من خوادم الألعاب تلقائيًا بركل اللاعبين بمعدل أعلى من المتوسط. على العكس من ذلك، فإن بينج عالي يمكن أن يجعل من الصعب للغاية على اللاعب ممارسة اللعبة بسبب الآثار السلبية التي تحدث، مما يجعل من الصعب على اللاعب تتبع اللاعبين الآخرين وحتى تحريك شخصياتهم.

بدلاً من استخدام طلب ارتداد ICMP التقليدي والرد على حزم الشبكة لتحديد أوقات الاختبار، غالبًا ما يقوم مبرمجو ألعاب الفيديو بإنشاء اكتشاف زمن الوصول الخاص بهم إلى حزم ألعاب موجودة (تعتمد عادةً على بروتوكول UDP) بدلاً من ذلك.

تتضمن بعض العوامل التي قد تؤثر على اختبار بينج بينج: بروتوكول الاتصال المستخدم، سرعة نقل الإنترنت (سرعة الاتصال)، جودة مزود خدمة الإنترنت للمستخدم وتهيئة جدران الحماية. يتأثر البينج أيضًا بالموقع الجغرافي. على سبيل المثال، إذا كان هناك شخص ما في الهند، يلعب على خادم موجود في الولايات المتحدة، فالمسافة بين الاثنين أكبر مما ستكون عليه للاعبين الموجودين داخل الولايات المتحدة، وبالتالي فإن إرسال البيانات يستغرق وقتًا أطول. ومع ذلك، فإن مقدار تبديل الحزمة وأجهزة الشبكة الموجودة بين جهازي الكمبيوتر غالبًا ما يكون أكثر أهمية. على سبيل المثال، يجب أن تعدل بطاقات واجهة الشبكة اللاسلكية الإشارات الرقمية إلى إشارات راديو، والتي تكون غالية في كثير من الأحيان أكثر تكلفة من الوقت الذي تستغرقه الإشارة الكهربائية لاجتياز نطاق نموذجي من الكابلات. على هذا النحو، يمكن أن يؤدي انخفاض مستوى البينجات إلى سرعة تنزيل الإنترنت وتحميله.

الأسباب
مخطط بنية لعبة مبسطة

بينما تحافظ لعبة اللاعب الفردي على حالة اللعبة الرئيسية على الجهاز المحلي، تتطلب اللعبة على الإنترنت الاحتفاظ بها على خادم مركزي لتجنب التناقضات بين العملاء الفرديين. على هذا النحو، لا يتمتع العميل بالتحكم المباشر في حالة اللعبة المركزية وقد يرسل فقط طلبات التغيير إلى الخادم، ويمكنه فقط تحديث حالة اللعبة المحلية من خلال تلقي التحديثات من الخادم. هذه الحاجة إلى التواصل تسبب تأخيرًا بين العملاء والخادم، وهي السبب الأساسي وراء الكمونية. بينما قد يكون هناك العديد من الأسباب الكامنة وراء كمونية المشغل، يمكن تلخيصها على أنها أجهزة غير كافية في العميل أو الخادم، أو اتصال رديء بين العميل والخادم.[2]

تسبب المشكلات المتعلقة بالأجهزة كمونية بسبب البنية الأساسية لهندسة اللعبة. بشكل عام، تتكون الألعاب من تسلسل حلقات من الدول، أو «إطارات». خلال كل إطار، تقبل اللعبة إدخال المستخدم وتنفذ الحسابات اللازمة (الذكاء الاصطناعي والرسومات وغيرها). عند الانتهاء من المعالجة، ستقوم اللعبة بتحديث حالة اللعبة وتنتج ناتجًا، مثل صورة جديدة على الشاشة و / أو حزمة لإرسالها إلى الخادم. وغالبًا ما يشار إلى التردد الذي يتم به إنشاء الإطارات باسم معدل الإطارات. نظرًا لوجود حالة اللعبة المركزية على الخادم، يجب إرسال المعلومات المحدثة من العميل إلى الخادم حتى تصبح نافذة المفعول. بالإضافة إلى ذلك، يجب أن يتلقى العميل المعلومات الضرورية من الخادم من أجل تحديث الحالة بالكامل. لا يمكن إنشاء الحزم لإرسالها إلى الخادم ومعالجة الحزم المستلمة إلا بقدر تمكن العميل من تحديث حالته المحلية. على الرغم من أنه من الناحية النظرية يمكن إنشاء الحزم وإرسالها بشكل أسرع من ذلك، فإن ذلك لن يؤدي إلا إلى إرسال بيانات زائدة إذا تعذر تحديث حالة اللعبة بين كل حزمة. وبالتالي، فإن معدل الإطارات المنخفض سيجعل اللعبة أقل استجابة للتحديثات وقد يجبرها على تخطي البيانات القديمة.

على العكس، ينطبق الشيء نفسه على الخادم. يحدد معدل الإطارات (أو معدل التجزئة) للخادم عدد مرات معالجة البيانات من العملاء وإرسال التحديثات. من الصعب التنبؤ بهذا النوع من المشاكل والتعويض عنه. بصرف النظر عن فرض الحد الأدنى من متطلبات الأجهزة ومحاولة تحسين اللعبة للحصول على أداء أفضل، لا توجد طرق ممكنة للتعامل معها.

ربما يكون السبب الأكثر شيوعًا في التأخير هو مشاكل أداء الشبكة. قد تتسبب جميع الخسائر أو الفساد أو الارتعاش (أي رزمة قديمة في الواقع خسارة) في حدوث مشكلات، ولكن هذه المشكلات نادرة نسبيًا في شبكة ذات نطاق ترددي كافٍ ولا يوجد بها ازدحام أو لا تذكر. بدلاً من ذلك، يلعب الكمون الذي ينطوي عليه نقل البيانات بين العملاء والخادم دورًا مهمًا. يختلف زمن الوصول حسب عدد من العوامل، مثل المسافة المادية بين الأنظمة الطرفية، حيث أن المسافة الطويلة تعني طول الإرسال الإضافي والتوجيه المطلوبين وبالتالي زمن انتقال أعلى. قد يكون التوجيه عبر الإنترنت غير مباشر للغاية، مما يؤدي إلى طول نقل أكبر بكثير (وتبعًا زمن انتقال) من مسار مباشر، على الرغم من أن خدمة الألعاب السحابية OnLive قد طورت حلاً لهذه المشكلة من خلال إنشاء علاقات نظير مع عدة مزودي خدمة إنترنت لشبكة المستوى 1 واختيار الطريق الأمثل بين الخادم والمستخدم.[3] بالإضافة إلى ذلك، قد يؤدي عدم كفاية عرض النطاق الترددي والازدحام، حتى لو لم يكن شديد بما يكفي لإحداث خسائر، إلى تأخير إضافي بغض النظر عن المسافة. كما هو الحال مع مشكلات الأجهزة، فإن الحزم التي تصل ببطء أم لا على الإطلاق ستجعل العميل والخادم غير قادر على تحديث حالة اللعبة في الوقت المناسب.

قد تخضع أنظمة الألعاب عبر الإنترنت التي تستخدم شبكة لاسلكية إلى ويب اكس كبير، اعتمادًا على بنية الشبكة اللاسلكية والتداخل الكهرومغناطيسي المحلي الذي يؤثر على هذه الشبكة. التداخل الكهرومغناطيسي (على سبيل المثال من فرن الميكروويف) يمكن أن يسبب فقدان الحزم المرسلة، مما يتطلب إعادة الإرسال الذي يتحمل الكمون. على الرغم من أن الانتشار اللاسلكي عبر الهواء أسرع من الضوء عبر الألياف الضوئية، إلا أن الأنظمة اللاسلكية غالباً ما تتم مشاركتها بين العديد من المستخدمين وقد تعاني من الكمون الناتج عن ازدحام الشبكة أو بسبب بروتوكولات الشبكة التي توفر زمن الوصول.

تأثيرات

تختلف الآثار الملحوظة للكمونية ليس فقط وفقًا للسبب الدقيق، بل وأيضًا على أي وجميع أساليب تعويض التأخير التي قد تنفذها اللعبة (الموضحة أدناه). نظرًا لأن بعض العملاء يواجهون بعض التأخير، فإن تنفيذ هذه الأساليب لتقليل التأثير على اللاعبين يعد أمرًا مهمًا في اللعب السلس. يتسبب الكمونية في العديد من المشكلات في مسائل مثل التقديم الدقيق لحالة اللعبة واكتشاف النتائج.[4] في العديد من الألعاب، يكون الكمونية في كثير من الأحيان مستهجنًا لأنه يعطل اللعب العادي. تعتمد شدة الكمونية على نوع اللعبة والتسامح المتأصل فيها. يمكن أن تتسامح بعض الألعاب ذات السرعة البطيئة مع التأخير الكبير دون الحاجة إلى التعويض على الإطلاق، في حين أن الألعاب الأخرى ذات السرعة الأسرع تكون أكثر حساسية وتتطلب استخدامًا مكثفًا للتعويض حتى يكون قابلاً للعب (مثل نوع أول شخص يطلق النار). نظرًا للعديد من المشكلات التي يمكن أن يتسبب فيها الكمونية، لا يُسمح أحيانًا للاعبين الذين لديهم اتصال إنترنت سريع بما فيه الكفاية، أو لا يُسمح لهم باللعب مع لاعبين آخرين أو خوادم لها مضيف خادم بعيد أو لديها كمون عالٍ لبعضها البعض. الحالات الشديدة للتخلف قد تؤدي إلى عدم التزامن الواسع لحالة اللعبة.

قد يتسبب الكمونية بسبب عدم كفاية معدل التحديث بين العميل والخادم في حدوث بعض المشكلات، ولكن هذه المشكلات تقتصر عمومًا على العميل نفسه. قد يلاحظ اللاعبون الآخرون حركة متشنجة ومشاكل مماثلة مع اللاعب المرتبط بالعميل المتأثر، لكن المشكلة الحقيقية تكمن في العميل نفسه. إذا لم يتمكن العميل من تحديث حالة اللعبة بوتيرة سريعة كافية، فقد يتم عرض اللاعب على عمليات ترحيل قديمة للعبة، والتي بدورها تتسبب في حدوث مشكلات متعددة في الكشف عن الاصطدام والاصطدام.[5] إذا كان معدل التحديث المنخفض ناتجًا عن انخفاض معدل الإطارات (على عكس الإعداد على العميل، كما تسمح بعض الألعاب)، فإن هذه المشكلات عادة ما تطغى عليها مشاكل عديدة تتعلق بمعالجة جانب العميل نفسه. ستكون كل من الشاشة وأجهزة التحكم بطيئة وغير مستجيبة. في حين أن هذا قد يزيد من الكمونية الملحوظ، من المهم الإشارة إلى أنه من نوع مختلف عن التأخيرات المرتبطة بالشبكة. في المقارنة، قد تسبب نفس المشكلة على الخادم مشاكل كبيرة لجميع العملاء المعنيين. إذا كان الخادم غير قادر أو غير راغب في قبول الحزم من العملاء بسرعة كافية ومعالجتها في الوقت المناسب، فقد لا يتم تسجيل إجراءات العميل مطلقًا. عندما يرسل الخادم بعد ذلك تحديثات للعملاء، فقد يتعرضون للتجميد (لعبة لا تستجيب) و / أو الاستعادة، اعتمادًا على أنواع تعويض التأخير، إن وجدت، التي تستخدمها اللعبة.

الكمونية بسبب تأخير الشبكة في كثير من الأحيان أقل مشكلة. على الرغم من أنها أكثر شيوعًا، إلا أن التأثيرات الفعلية أصغر عمومًا، ومن الممكن التعويض عن هذه الأنواع من التأخيرات. بدون أي شكل من أشكال التعويض المكمونية، سوف يلاحظ العملاء أن اللعبة لا تستجيب إلا لفترة قصيرة بعد إجراء أي إجراء. هذا يمثل مشكلة خاصة في ألعاب الرماية من شخص أول، حيث من المرجح أن يتحرك الأعداء عندما يحاول اللاعب إطلاق النار عليهم ويكون هامش الأخطاء ضئيلًا في الغالب.

الحلول والتعويضات الكمونية

هناك طرق مختلفة لتقليل التأخيرات أو تمويهها، على الرغم من أن العديد منها لها عيوبها وقد لا تكون قابلة للتطبيق في جميع الحالات. إذا كانت اللعبة نفسها غير ممكنة، فقد يكون بإمكان العملاء اختيار اللعب على خوادم قريبة جغرافيا من أنفسهم من أجل تقليل زمن الوصول، أو قد تختار الخوادم ببساطة إسقاط العملاء بميزات عالية من الوقت لتجنب التعامل مع المشاكل الناتجة. ومع ذلك، هذه هي الحلول الأمثل بالكاد. بدلاً من ذلك، سيتم تصميم الألعاب غالبًا مع مراعاة الكمونية.[6]

يمكن حل العديد من المشكلات ببساطة عن طريق السماح للعملاء بتتبع حالتهم وإرسال حالات مطلقة إلى الخادم أو مباشرة إلى عملاء آخرين.[7] على سبيل المثال، يمكن للعميل تحديد بالضبط موقف اللاعب أو من هو الشخص الذي أطلق النار عليه. يعمل هذا الحل وسيؤدي إلى القضاء على معظم المشكلات المتعلقة بالتخلف. لسوء الحظ، يعتمد أيضًا على افتراض أن العميل صادق. لا يوجد ما يمنع اللاعب من تعديل البيانات التي يرسلها، مباشرة على العميل أو بشكل غير مباشر عبر وكيل، من أجل ضمان وصوله إلى أهدافه دائمًا. في الألعاب عبر الإنترنت، قد يؤدي خطر الغش إلى جعل هذا الحل غير ممكن، وسوف يقتصر العملاء على إرسال الحالات ذات الصلة (أي الموجه الذي انتقل إليه أو أطلق عليه)

من جانب العميل

نظرًا لعدم السماح للعملاء في العادة بتحديد حالة اللعبة الرئيسية، بل تلقيها من الخادم، فإن المهمة الرئيسية للتعويض من جانب العميل هي تقديم العالم الافتراضي بأدق ما يمكن. نظرًا لأن التحديثات تأتي مع تأخير وقد يتم إسقاطها، فمن الضروري في بعض الأحيان أن يتوقع العميل تدفق اللعبة. نظرًا لتحديث الحالة بخطوات منفصلة، يجب أن يكون العميل قادرًا على تقدير الحركة بناءً على العينات المتاحة. يمكن استخدام طريقتين أساسيتين لإنجاز هذا؛ الاستقراء والاستيفاء.[7]

الاستقراء هو محاولة لتقدير حالة اللعبة المستقبلية. بمجرد استلام حزمة من الخادم، يتم تحديث موضع كائن إلى الموضع الجديد. في انتظار التحديث التالي، يتم استقراء الموضع التالي بناءً على الموضع الحالي والحركة في وقت التحديث. بشكل أساسي، سوف يفترض العميل أن الجسم المتحرك سيستمر في نفس الاتجاه. عند تلقي حزمة جديدة، قد يتم تصحيح الموقف قليلاً.

يعمل الاستيفاء بشكل أساسي عن طريق تخزين حالة اللعبة وتقديم حالة اللعبة للاعب مع تأخير بسيط وطفيف. عند وصول حزمة من الخادم، بدلاً من تحديث موضع كائن فورًا، سيبدأ العميل في استيفاء الموقف ، بدءًا من آخر موضع معروف. خلال فترة الاستيفاء ، سيتم تقديم الكائن يتحرك بسلاسة بين الموضعين. من الناحية المثالية ، يجب أن يتطابق هذا الفاصل الزمني تمامًا مع التأخير بين الحزم ، ولكن بسبب الفقد والكمونية المتغير ، نادرًا ما يحدث هذا.

كلتا الطريقتين لها مزايا وعيوب.

  • يضمن الاستيفاء أن الكائنات ستتحرك بين المواضع الصالحة فقط وستحقق نتائج جيدة مع تأخير مستمر وبدون خسارة. في حالة إسقاط الحزم أو تجاوزها للطلب ، يجب على العميل إما تجميد الكائن في موضعه حتى وصول حزمة جديدة ، أو التراجع عن الاستقراء بدلاً من ذلك. الجانب السلبي في الاستيفاء هو أنه يجعل العالم يمنح العالم مهلة إضافية ، مما يزيد من الحاجة إلى تطبيق شكل من أشكال التأخير.
  • مشكلة استقراء المواقف واضحة إلى حد ما: من المستحيل التنبؤ بدقة بالمستقبل. لن تقدم الحركة بشكل صحيح إلا إذا كانت الحركة ثابتة ، ولكن هذا لن يكون دائمًا ما يحدث. يمكن للاعبين تغيير السرعة والاتجاه بشكل عشوائي. قد ينتج عن ذلك مقدار صغير من «الالتواء» عند وصول التحديثات الجديدة وتصحيح المواضع المقدرة ، كما يتسبب ذلك في حدوث مشكلات في اكتشاف النتائج ، حيث قد يتم تقديم اللاعبين في مواقع ليسوا فيها بالفعل.

في كثير من الأحيان ، للسماح باللعب السلس ، يُسمح للعميل بإجراء تغييرات بسيطة على حالة اللعبة. في حين أن الخادم قد يتابع في النهاية الذخيرة ، والصحة ، والموقع ، وما إلى ذلك ، فقد يُسمح للعميل بالتنبؤ بحالة اللعبة الجديدة من جانب الخادم بناءً على تصرفات اللاعب ، مثل السماح للاعب بالبدء في التحرك قبل استجابة الخادم إلى الأمر. سيتم قبول هذه التغييرات بشكل عام في ظل الظروف العادية وجعل التأخير شفافًا في الغالب. سوف تنشأ المشاكل فقط في حالة التأخير أو الخسائر العالية ، عندما يتم التراجع بشكل ملحوظ للغاية عن توقعات العميل. في بعض الأحيان ، في حالة الاختلافات الطفيفة ، قد يسمح الخادم حتى بإجراء تغييرات «غير صحيحة» على الحالة استنادًا إلى تحديثات من العميل.

من جانب الخادم

بخلاف العملاء ، يعرف الخادم حالة اللعبة الحالية بدقة ، وبما أن هذا التوقع غير ضروري. الغرض الرئيسي من تعويض كمونية جانب الخادم هو توفير تأثيرات دقيقة لإجراءات العميل. هذا أمر مهم لأنه بحلول وقت وصول أمر اللاعب ، سيكون الوقت قد مضى ، ولن يكون العالم في الحالة التي رأى فيها اللاعب عند إصدار أمره. ومن الأمثلة الواضحة على ذلك اكتشاف نتائج الأسلحة التي تم إطلاقها في شخصيات الرماية من الدرجة الأولى ، حيث الهوامش صغيرة ويمكن أن تسبب مشاكل كبيرة إذا لم يتم التعامل معها بشكل صحيح.

الترجيع الوقت

هناك طريقة أخرى لمعالجة المشكلة وهي تخزين حالات اللعبة السابقة لفترة زمنية معينة ، ثم الترجيع إلى مواقع اللاعب عند معالجة أمر ما.[7] يستخدم الخادم كمون المشغل (بما في ذلك أي تأخير متأصل بسبب الاستيفاء ؛ انظر أعلاه) لاسترجاع الوقت بمقدار مناسب لتحديد ما رأى عميل التصوير في وقت إطلاق اللقطة. سيؤدي هذا عادةً إلى رؤية الخادم وهو يطلق النار على الموضع القديم للهدف ومن ثم يضرب. في أسوأ الحالات ، سيكون اللاعب مكمونية اً إلى حد أن الخادم ينفد من البيانات التاريخية وعليه أن يبدأ في قيادة أهدافه.

هذا هو حل WYSIWYG الذي يسمح للاعبين بالتوجه مباشرة إلى ما يرونه. لكن الثمن هو تفاقم آثار الكمون عندما يتعرض اللاعب للنيران: لا يلعب الكمون الخاص بهم دوراً فحسب ، بل المهاجم أيضاً. في العديد من المواقف ، لا يكون هذا ملحوظًا ، لكن اللاعبون الذين احتفظوا بالتغطية سوف يلاحظون أنهم يواصلون تلقي رسائل التلف / الوفاة من الخادم لفترة أطول من الكمون الذي يمكنهم تبريره. يمكن أن يؤدي هذا في كثير من الأحيان إلى الانطباع (الخاطئ) بأنه تم إطلاق النار عليه من خلال الغطاء والانطباع (غير الدقيق تمامًا) عن «صناديق ضرب laggy».[7]

إحدى مشكلات التصميم التي تنشأ عن اللف هي ما إذا كان يجب التوقف عن لف الأوامر المكمونية ة للاعب الميت بمجرد وفاته على الخادم ، أو الاستمرار في تشغيلها حتى «يلحق» وقت الموت. يؤدي قطع التعويضات فورًا إلى منع الضحايا من مهاجمة القتلة بعد وفاته ، وهو ما يفي بالتوقعات ، ولكنه يحافظ على الميزة الطبيعية المتمثلة في تحريك اللاعبين الذين يدورون حول زاوية ، والحصول على هدف وقتلهم في وقت أقل من رحلة ذهابًا وإيابًا إلى عميل الضحية الثابتة.

يمكن انتقاد اللف لسماحه للاختفاء العالي للاعب الواحد بالتأثير سلبًا على تجربة اللاعبين ذوي الكمون المنخفض. في بعض الأحيان تقلل الخوادم ذات التعويض المكمونية من طول سجل المشغل المخزن ، أو تفرض حدود بينج ، لتقليل هذه المشكلة.

ثقة العملاء

من الممكن للعملاء إخبار الخادم بما يقومون به وللخادم أن يثق في البيانات التي يتلقاها. يتم تجنب هذه الطريقة إذا كان ذلك ممكنًا بسبب تعرضها للغش : إنها مسألة بسيطة لتوجيه بيانات الشبكة عبر جهاز كمبيوتر ثانٍ يقوم بإدراج رسائل ناجحة ملفقة أو يعدل الرسائل الموجودة ، وهي تقنية لا يمكن اكتشافها بواسطة أدوات مكافحة الغش .[7]

ومع ذلك ، فإن الحجم الهائل لبعض الألعاب يجعل الحلول المكلفة حسابياً مثل اللف مستحيلة. في Battlefield 3 ، على سبيل المثال ، يتم استخدام نظام «الكشف المختلط عن الاصطدامات» حيث يخبر العملاء الخادم أنهم قد ضربوا ويقوم الخادم بإجراء اختبار غامض حول المعقولية قبل قبول المطالبة.[8]

استقراء العملاء

حل الكمونية الأقل شيوعًا هو عدم القيام بأي شيء على الخادم والحصول على استقراء لكل عميل (انظر أعلاه) لتغطية زمن الوصول.[9] ينتج عن هذا نتائج غير صحيحة إلا إذا حافظ اللاعبون عن بُعد على سرعة ثابتة ، مما يمنح ميزة لأولئك الذين يتفادون جيئة وذهابا أو ببساطة بدء / إيقاف الحركة.

يؤدي الاستقراء المطول أيضًا إلى ظهور اللاعبين عن بُعد (على الرغم من عدم تعرضهم للمخاطر) عندما لا ينبغي أن يكونوا: على سبيل المثال ، إذا امتد المشغل البعيد إلى الزاوية ثم توقف فجأة عند الحافة ، فإن العملاء الآخرين سيجعلهم يركضون إلى الأمام ، في العراء ، لمدة الكمون الخاصة بهم. على الجانب الآخر من هذه المشكلة ، يتعين على العملاء إعطاء اللاعبين البعيدين الذين بدأوا للتو في تحريك موجة إضافية من السرعة لدفعهم إلى موقع متوقع من الناحية النظرية.

التصميم

من الممكن تقليل تصور الكمونية من خلال تصميم اللعبة . تتضمن التقنيات تشغيل الرسوم المتحركة من جانب العميل كما لو أن الإجراء قد حدثت فورًا ، مما يؤدي إلى التقليل / إزالة أجهزة ضبط الوقت المدمجة على الجهاز المضيف ، واستخدام انتقالات الكاميرا لإخفاء تزييفها.[10]

الألعاب السحابية

Cloud gaming هي نوع من الألعاب عبر الإنترنت حيث يتم استضافة اللعبة بأكملها على خادم ألعاب في مركز بيانات، ويقوم المستخدم بتشغيل عميل رفيع فقط محليًا يقوم بإعادة توجيه إجراءات التحكم في اللعبة إلى خادم اللعبة. يعرض خادم اللعبة بعد ذلك الإطار التالي من فيديو اللعبة المضغوطة باستخدام ضغط فيديو منخفض التأخير ويرسله العميل المصغر ويتم فك ضغطه. لكي تكون تجربة الألعاب السحابية مقبولة ، فإن كمونية رحلة الذهاب والعودة لجميع عناصر نظام الألعاب السحابية (العميل رفيع المستوى ، و / أو الإنترنت و / أو LAN اتصال خادم اللعبة ، وتنفيذ اللعبة على خادم اللعبة ، والفيديو والصوت يجب أن يكون الضغط وإلغاء الضغط وعرض الفيديو على جهاز عرض منخفضًا بدرجة كافية بحيث يكون تصور المستخدم هو أن اللعبة تعمل محليًا.[3][11] نظرًا لهذه المتطلبات الضيقة للكمونية ، فإن الاعتبارات المتعلقة بسرعة الضوء عبر الألياف الضوئية تدخل حيز التنفيذ ، مما يحد من المسافة بين المستخدم وخادم ألعاب الألعاب السحابية بحوالي 1000 ميل ، وفقًا لـ OnLive الشركة الوحيدة التي تعمل حتى الآن خدمة الألعاب السحابية.[12] وهناك أيضًا الكثير من الجدل حول الكمونية المرتبط بألعاب السحاب. في الألعاب متعددة اللاعبين التي تستخدم بنية شبكة العميل / الخادم ، يعرض الكمبيوتر الخاص بالمشغل رسومات اللعبة محليًا ويتم إرسال المعلومات حول الإجراءات الخاصة باللاعب فقط إلى الخادم. على سبيل المثال ، عندما يقوم المشغل بالضغط على زر ، فإن الحرف الذي يظهر على الشاشة ينفذ الإجراء المقابل على الفور. ومع ذلك ، فإن عواقب التصرف مثل عدو يقتل لا تُرى إلا بعد تأخير قصير بسبب الوقت الذي يستغرقه الإجراء للوصول إلى الخادم. هذا مقبول فقط طالما كانت الاستجابة لمدخلات اللاعب سريعة بدرجة كافية.

عند استخدام الألعاب السحابية ، يمكن أن تؤدي مدخلات المشغل إلى تأجيلات قصيرة حتى يمكن رؤية استجابة لها. يجب أولاً إرسال المدخلات إلى الخادم البعيد ، ثم يجب أن يبدأ الخادم في تقديم رسومات الإجراء الذي يتم تنفيذه وإعادة بث الفيديو إلى المشغل عبر الشبكة ، مع قضاء وقت إضافي. وبالتالي ، يواجه اللاعب تأخيرًا ملحوظًا بين الضغط على زر ورؤية شيء ما يحدث على الشاشة. اعتمادًا على مهارة وخبرة اللاعب ، يمكن أن يسبب هذا الارتباك والارتباك مشابهة لردود الفعل السمعية المؤجلة ويعيق التنقل ويهدف إلى عالم اللعبة. عند إدخال حركة مجموعة طويلة بسرعة ، لن تتم مزامنة الشخصية التي تظهر على الشاشة مع الضغط على الزر. هذا عادة ما يسبب ارتباكًا شديدًا في اللاعب مما يؤدي إلى فشل حركة المجموعة.

كما أن كمونية الإدخال الإضافي يمكن أن يجعل من الصعب للغاية لعب بعض ألعاب لاعب واحد. على سبيل المثال ، إذا قام العدو بالرجوع إلى اللاعب وكان من المتوقع أن يقوم اللاعب بحظره ، فعندما تظهر شاشة اللاعب أن العدو بدأ الهجوم ، كان العدو قد قام بالفعل بضرب اللاعب على الخادم وقتله.

انظر أيضا

المراجع
  1. "How to Get Rid of Lag | GeForce". www.geforce.com (بالإنجليزية). Archived from the original on 2018-09-13. Retrieved 2018-09-13.
  2. Cronin، Eric؛ Filstrup، Burton؛ Anthony، Kurc. "A Distributed Multiplayer Game Server System" (PDF). University of Michigan. مؤرشف من الأصل (PDF) في 2016-08-04. اطلع عليه بتاريخ 2014-07-16.
  3. "The Process of Invention: OnLive Video Game Service". The FU Foundation School of Engineering & Applied Science (Columbia University). مؤرشف من الأصل في 2012-12-20. اطلع عليه بتاريخ 2010-01-23.
  4. Smith، Joshua. "Distributed Game Architecture To Overcome System Latency" (PDF). United States Patent. مؤرشف من الأصل (PDF) في 2017-10-28. اطلع عليه بتاريخ 2014-07-16.
  5. Claypool، Mark؛ Claypool، Kajal. "Latency Can Kill: Precision and Deadline in Online Games". مؤرشف من الأصل في 2019-12-13. اطلع عليه بتاريخ 2014-07-16.
  6. Roelofs، Gregory. "Compensating For Network Latency In A Multi-Player Game" (PDF). United States Patent. مؤرشف من الأصل (PDF) في 2016-04-28. اطلع عليه بتاريخ 2014-07-16.
  7. Bernier، Yahn (2001). "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization". فالف. مؤرشف من الأصل في 2019-06-30. اطلع عليه بتاريخ 2011-09-17.
  8. Kertz، Alan (11 ديسمبر 2011). "Re: We need someone to create a guide for the new Network Interpolation Setting slider". مؤرشف من الأصل في 2017-03-14. اطلع عليه بتاريخ 2013-11-04. BF3's hit model uses a combined client server model, a Hybrid Hit Detection. The client says to the server "Hey, I shot him!" and the server does a check against the position of the two targets and determines if the player could reasonably have hit that target and then applies the damage.
  9. Gibson، John (5 ديسمبر 2010). "Re: Will HoS present the netcode disadvantages of UE3?". تريبواير إنتراكتيف. مؤرشف من الأصل في 2016-03-10. اطلع عليه بتاريخ 2011-09-18.
  10. Aldridge، David (2011). "I Shot You First: Networking the Gameplay of HALO: REACH". Game Developers Conference 2011. GDC Vault. مؤرشف من الأصل في 2019-05-19.
  11. "D8 Video:OnLive demoed on iPad, PC, Mac, Console, iPhone". Wall Street Journal. 9 أغسطس 2010. مؤرشف من الأصل في 2011-02-12. اطلع عليه بتاريخ 2010-08-19.
  12. "Beta Testing at the Speed of Light". OnLive. 21 يناير 2010. مؤرشف من الأصل في 2012-12-16. اطلع عليه بتاريخ 2010-01-23.
  • أيقونة بوابةبوابة ألعاب فيديو
  • أيقونة بوابةبوابة اتصال عن بعد
  • أيقونة بوابةبوابة تقانة المعلومات
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.