سؤال

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

مثال

لنفترض أن العميل A يتقدم على الخادم بمقدار 20 مللي ثانية، والعميل B يتقدم على الخادم بمقدار 300 مللي ثانية (مع احتساب زمن الوصول والحد الأقصى من عدم الاستقرار).وهذا يعني أنه عندما تصطدم المركبتان، سيرى كلا العميلين الآخر على بعد 320 مللي ثانية - في الاتجاه المعاكس لسرعة السيارة الأخرى.وجهاً لوجه على طريق سريع سويدي يعني فرق 16 متر/17.5 ياردة!

ما لا تحاول

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

هل كانت مفيدة؟

المحلول 5

ما انتهى بي الأمر في النهاية إلى فعله هو ببساطة تخطي التنبؤ تمامًا والقيام ببساطة بما يلي:

  1. العميل لديه الكثير ليقوله عن موقفه الخاص،
  2. يقول الخادم (تقريبًا) أي شيء عن موقع العميل المالك فقط عند حدوث تصادم "عالي الطاقة" مع كائن ديناميكي آخر (على سبيل المثال.ليست بيئة ثابتة).
  3. يأخذ العميل meshoffset=meshpos-physpos عند تلقي التحديث الموضعي من الخادم ثم يحدد meshpos=physpos+meshoffset كل إطار ويتناقص تدريجيا meshoffset.

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

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

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

نصائح أخرى

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

في تصميم واجهة المستخدم، ينص مبدأ أقل قدر من الدهشة (أو المفاجأة) على أنه عندما يتعارض عنصران من عناصر الواجهة، أو يكونان غامضين، يجب أن يكون السلوك هو الأقل مفاجأة للمستخدم البشري في وقت نشوء الصراع.

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

هنا هي الفكرة الأساسية:

  1. يتعين على الخادم اتخاذ القرار بشأن الاصطدام الوشيك.لا يجب أن تكون خوارزمية اكتشاف التصادم مثالية بنسبة 100%، بل يجب فقط أن تكون قريبة بدرجة كافية لتجنب التناقضات الواضحة.
  2. بمجرد أن يقرر الخادم أن مركبتين سوف تصطدمان، فإنه يرسل لكل من المستخدمين رسالة تشير إلى أن الاصطدام وشيك.
  3. بالنسبة للعميل أ، يتم تعديل موضع السيارة ب (بشكل واقعي) لضمان حدوث الاصطدام.
  4. بالنسبة للعميل B، يتم تعديل موضع السيارة A (بشكل واقعي) لضمان حدوث الاصطدام.
  5. خلال فترة ما بعد الاصطدام، يمكن تعديل موضع كل مركبة، حسب الضرورة، بحيث تكون النتيجة النهائية متوافقة مع بقية اللعبة.هذا الجزء هو بالضبط ما اقترحه MedicineMan إجابته.

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

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

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

وعذرا للإجابة ب "ما لا لمحاكمة"، ولكن لم اسمع ابدا من الحل الذي لا ينطوي على توقع النتيجة على جانب العميل. النظر في مثال مبسط:

والعميل (أ) هو ثابت، والمركبات مشاهدة العميل B في نهج الهاوية. سيارة العميل B هي قادرة على الحد من سرعة 0 على الفور، ويفعل ذلك في آخر لحظة ممكنة قبل الذهاب على حافة الهاوية.

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

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

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

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

أفكار قليلة.

  1. يعتبر نظام نظير إلى نظير أفضل في التعامل مع زمن الوصول والسرعات العالية.

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

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

  1. إذا كنت تريد الانتقال إلى عميل/خادم، فسيكون هذا أقل شأنا من p2p

أشياء لمحاولة O) استقراء العملاء للأمام كما هو الحال في P2P لأداء الكشف عن التصادم.س) إرسال نتائج التصادم مرة أخرى إلى العملاء واستقراءها للأمام

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top