عمر رمز الإمبراطوريات للشبكة: 1500 رماة لكل مودم 28.8 كيلوبت في الثانية

ملاحظة المترجم: يبلغ عمر هذا المقال بالفعل 17 عامًا ، وهو مثير للاهتمام فقط من وجهة نظر تاريخية. من المثير للاهتمام معرفة كيف تمكن المطورون من تحقيق لعبة سلسة عبر الإنترنت في عصر أجهزة المودم 28.8k وأول Pentium.

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

عصر الإمبراطوريات المتعددة: متطلبات الهيكل

في بداية العمل على رمز Age of Empires متعدد اللاعبين في عام 1996 ، وضعنا لأنفسنا أهدافًا محددة للغاية ضرورية لتنفيذ طريقة اللعب المطلوبة.

• معارك تاريخية ملحمية واسعة النطاق مع العديد من الوحدات العسكرية المختلفة
• دعم ما يصل إلى 8 لاعبين في وضع اللعب المتعدد
• محاكاة سلسة للعب عبر الشبكة المحلية ، عبر اتصال المودم المباشر وعبر الإنترنت
• دعم النظام الأساسي المستهدف: Pentium 90 مع ذاكرة وصول عشوائي سعتها 16 ميجابايت ومودم 28.8 كيلوبت في الثانية
• يجب أن يعمل نظام الاتصال مع المحرك الموجود (Genie)
• مستقر 15 إطارًا في الثانية على الأجهزة بأقل تكوين

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

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

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

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

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

المحاكاة المتزامنة

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

في البداية ، كان من الصعب تنفيذ مثل هذه المزامنة الصعبة ، ولكن نتيجة لذلك ، جلبت مزايا غير متوقعة في مجالات أخرى.

تحسين النموذج الأساسي

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

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

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

استخدم مارك [Terrano] نظامًا لتمييز الأوامر التي يجب تنفيذها من خلال "حركات تبادل البيانات" في المستقبل (تم فصل حركات تبادل البيانات في AoE عن إطارات التقديم نفسها).

أي أن الأوامر المعطاة أثناء الدورة 1000 يتم تعيينها ليتم تنفيذها أثناء الدورة 1002 (انظر الشكل 1). في عام 1001 ، يتم تنفيذ الأوامر المعطاة في سياق 0999 ، مما سمح لنا بتلقي الرسائل وتأكيدها وإعدادها للمعالجة ، بينما استمرت اللعبة في رسم الرسوم المتحركة وإجراء المحاكاة.


الشكل 1. ترميز الأوامر التي سيتم تنفيذها من خلال "حركات تبادل البيانات".

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

"التحكم في السرعة"

الشكل 2. التحكم في السرعة.

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

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

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

بالإضافة إلى ذلك ، قام كل عميل أيضًا بقياس "وقت ping" من نفسه للعملاء الآخرين والعكس صحيح. كما أرسل متوسط ​​ping إلى أطول عميل في رسالة حول اكتمال النقل (في المجموع ، تم استخدام 2 بايت للتحكم في السرعة).

في كل خطوة ، قامت الآلة المعينة من قبل المضيف بتحليل رسائل الإنجاز ، وحساب معدل الإطارات اللازم وتصحيح التأخير في إرسال البيانات عبر الإنترنت. ثم أرسل المضيف معدل إطار جديد ومدة تبادل البيانات. توضح الأشكال 3-5 كيف تم تقسيم تدفق تبادل البيانات في ظل ظروف مختلفة.


الشكل 3. التدفق النموذجي لتبادل البيانات.


الشكل 4. نقل البيانات عالية الكمون عبر الإنترنت بسرعة الجهاز العادية.


الشكل 5. سرعة الجهاز منخفضة مع تأخير نقل البيانات العادي.

تم تقسيم "تقدم تبادل البيانات" ، الذي كان يساوي تقريبًا وقت اختبار الاتصال لرحلة ذهابًا وإيابًا للرسالة ، على عدد إطارات المحاكاة التي يمكن أن تؤديها أبطأ آلة في المتوسط ​​خلال هذا الوقت.

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

تسليم مضمون

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

الفوائد الخفية

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

المشاكل الخفية

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

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

الدروس المستفادة

عند تطوير جزء الشبكة من Age of Empires ، تلقينا العديد من الدروس التي يمكن تطبيقها لتطوير أي نظام ألعاب متعدد المستخدمين.

تعلم المستخدم الخاص بك. تعد دراسة المستخدم أهم خطوة في فهم توقعاته فيما يتعلق بسرعة اللاعبين المتعددين ، والفرامل المتصورة والتأخير في إرسال الأوامر. كل نوع هو فردي ، وتحتاج إلى فهم ما يناسب أسلوب لعبك وإدارته.

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

بالنسبة للألعاب من النوع RTS ، فإن تأخيرات إرسال الأوامر التي تبلغ 250 مللي ثانية لا يمكن ملاحظتها حتى ، في 250-500 مللي ثانية ، تكون طريقة اللعب قابلة للتشغيل تمامًا ، وتصبح الفرامل ملحوظة عند 500 مللي ثانية وأعلى. من المثير للاهتمام أيضًا ملاحظة أن اللاعبين اعتادوا على "وتيرة اللعبة" والتوقع العقلي للتأخير بين نقرات الماوس وردود فعل الوحدة. كانت الاستجابة المتأخرة المستمرة أفضل من القفزات في تأخيرات إرسال الأوامر (على سبيل المثال ، من 80 إلى 500 مللي ثانية) - في هذه الحالة ، تم اعتبار التأخيرات المستمرة لـ 500 مللي ثانية قابلة للتشغيل ، وبدا التأخير القابل للتغيير "مضطربًا" ويعقد اللعبة.

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

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

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

بشكل عام ، تسمح لك مراقبة المستخدمين بما يلي:

• تعرف على توقعات المستخدمين حول تأخيرات اللعبة
• جوانب النموذج المتعدد اللاعبين في المراحل الأولى من التطوير
• شاهد السلوك الذي يضر بسرعة وضع المستخدمين المتعددين.

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

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

جعل النظام يخطر المختبرين والمطورين بما يبدو أنه فائض من شروط الحدود - سوف يرى المبرمجون والمختبرون في عملية التطوير المهام التي تقوم بتحميل النظام ؛ هذا سوف يحل المشاكل في المراحل الأولى من حدوثها.

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

بشكل عام ، يجب أن تحتوي المقاييس على الخصائص التالية:

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

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

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

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

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

الاختبار باستخدام أجهزة المودم (ومع أجهزة محاكاة المودم) في أقرب وقت ممكن ؛ استمر في اختبار المودم (مهما كانت مؤلمة) طوال عملية التطوير. ( — , , , , - ?), dialup-, LAN. , LAN.

Age of Empires 2

في Age of Empires 2: The Age of Kings ، أضفنا ميزات متعددة المستخدمين مثل تسجيل الألعاب ونقل الملفات والتتبع المستمر للإحصاءات على موقع The Zone على الويب. قمنا أيضًا بتحسين أنظمة متعددة اللاعبين مثل تكامل DirectPlay والتحكم في السرعة للتعامل مع الأخطاء ومشكلات السرعة التي تم تحديدها بعد إصدار Age of Empires .

, , «» . -. , , . . , , , .

() The Zone Age of Empires . Age of Kings , . , , , . . The Zone , . - The Zone.

RTS3:

RTS3 — Ensemble (. .: Age of Mythology) . RTS3 , Age of Empires, .

• Age of Empires 1 2 . , , , .
• 3D: RTS3 — .
• — .
• TCP/IP: — - TCP/IP 56 /.
• — , NAT.

RTS3 , Age of Empires 1 2 — — RTS3 . AOE/AOK DirectPlay, RTS3 , .

, . , , . Genie , — BANG! , .

Age of Kings , , . , , .

RTS3

6. - RTS3.

- . RTS3 - (. 6). -, , , .

. . , (, , -). ( Channels, TimeSync ..) , .

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

تتضمن طوبولوجيا نظير إلى نظير استخدام تكوين نجمة للعملاء المتصلين في جلسة (الشكل 7). أي أن كل عميل متصل بجميع العملاء الآخرين. تم استخدام نفس المخطط في السن 1 و 2 .


الرقم 7 الشكل. نجمة تكوين العملاء الأقران في جلسة.

مزايا نظير إلى نظير:

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

عيوب نظير إلى نظير:

• المزيد من المركبات النشطة في النظام (المجموع من n = 0 إلى k-1 (n)) ، أي المزيد من الروابط الضعيفة المحتملة والتأخيرات المحتملة الأعلى.
• عدم القدرة على دعم بعض تكوينات NAT في مثل هذا المخطط.

Net.lib. RTS3 , , , , . , , , , , .


الشكل 8. أربع طبقات من الخدمات في نموذج شبكتنا.

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

جوارب المستوى 1

, Socks, API C. . . Socks .

Link, 2

2, Link, . , Link, Listener, NetworkAddress Packet, , (. 9).

• Packet (): — , / ( ) .
• Link (): . , . send receive , , void*.
• Listener (): . .
• Data stream ( ): , , , .
• Net Address ( ): , .
• Ping: . , .
• 
  
  9. Link.

Multiplayer, 3
— , API net.lib. , RTS3 , / — , .

BANG! , . API , , .

• Client (): . () ( ). , .
• Session (): , , , . . host() join(), , , . / , .
• Channel Ordered Channel: . . TimeSync, .
• Shared Data: . , , .
• Time Sync: .

Game Communications, 4

RTS3. , , . , , .

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

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

يتم تنفيذ التحقق من التزامن في RTS3 باستخدام مجموعتين من وحدات الماكرو:

#define syncRandCode(userinfo)
gSync->addCodeSync(cRandSync, userinfo, __FILE__, __LINE__)


#define syncRandData(userinfo,
v) gSync->addDataSync(cRandSync, v, userinfo, __FILE__, __LINE__)

يتلقى كل من وحدات الماكرو هذه معلمة سلسلة معلومات المستخدم ، وهي اسم أو إشارة عنصر متزامن محدد. على سبيل المثال ، قد تبدو مكالمة المزامنة كما يلي:

syncRandCode("syncing the random seed", seed);

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

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

باستخدام هاتين الأداتين ، يمكن للمطورين استخدام نظام تعدد اللاعبين دون كتابة التعليمات البرمجية. يمكنهم إضافة أدوات اختبار وتكوين جديدة بسرعة ودمجها بسهولة في بيئة شبكية.

لتلخيص

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