ما على كل مبرمج أن يعرفه عن ألعاب الشبكة

أنت مبرمج. هل تساءلت يوماً عن كيفية لعب الألعاب مع عدة لاعبين في الوقت نفسه “multiplayer games” ؟

من الخارج قد يبدو الأمر كالسحر: لاعبَّين اثنين أو أكثر يتشاركان تجربة متزامنة عِبر الشبكة ليبدوان كأنهما يتواجدان سوياً في العالم الافتراضي ذاته. لكن كمبرمجين نعلَم أن حقيقة ما يحدث وراء الكواليس يختلف عن ما تراه. تبين أن الأمر هو عبارة عن وهم. خفة يد باحتراف. ما تصورته على أنه واقع مشترك هو في الحقيقة تقريب فريد من نوعه للمكان و لوجهة نظرك في الوقت المناسب.

في البدء ارتبطت الألعاب عبر الشبكة بشكل ند-لند، تتبادل الحاسبات المعلومات مع بعضها البعض و هي متصلة بشكل كامل على الشبكة باستخدام النموذج الشبكي(1). ما زال بامكانك مشاهدة هذا النموذج اليوم في الألعاب الاستراتيجية التي تُلعب على الشبكات “RST games”، و ربما لأن هذا النموذج كان هو الوسيلة الأولى، لايزال أغلب الناس يعتقد أن طريقة عمل الألعاب على الشبكات يجري بهذا الأسلوب (أي ال”peer to peer”).

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

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

تبدو الفكرة بسيطة للغاية و رائعه، و لكن للأسف هناك عدة محددات لهذه الطريقة.

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

(1)النموذج الشبكي أو طوبولوجيا الشبكة “mesh topology” هو أحد نماذج ربط الأجهزة على الشبكة، يكون فيها كل حاسوب مربوط بجميع الحواسيب الأخرى على الشبكة.

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

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

رغم هذه القيود، يناسب هذا النموذج الألعاب الاستراتيجية ولازالنا نراها اليوم في ألعاب مثل “Command and Conquer” و “Age of Empires” و “Starcraft”. السبب أن في هذا النوع من الألعاب تكون حالة اللعبة متكونه من ألاف الوحدات (من جنود و آاليات و أبنية و غيرها) و هي كبيرة جداً ليتم مبادلتها بين اللاعبين. فلا تمتلك الا خيار تبادل الأوامر و الذي يقود تقدم و تطور حالة اللعبة.

لكن بالنسبة للأنواع الأخرى من الألعاب، فقد تجاوزت هذه التقنية. اذاً هنا انتهى دور نموذج التشابك المتماثل الند-الى-الند “Peer-to-Peer” المحدود. سننظر الأن الى تطور ألعاب الحركة ابتداءاً ب”Doom” و “Quacke” الى “Unreal”.

نموذج العميل/الخادم “Client/Server“

في عصر ألعاب الحركة، ظهرت بشكل واضح محدودية نموذج الند-الى الند، و التي بالرغم من انها كانت تُلعب بشكل جيد على الشبكات الأرضية المحلية “LAN” كانت مروعه في حال لعبها على شبكة الانترنت، كما يصفها أحد اللاعبين:

((بالرغم انه من الممكن ربط جهازين يُشغلان لعبة “DOOM” مع بعضهم على الانترنت باستخدام مودم، فان اللعبة ستكون بطيئة، لتتراوح بين مستوى كونها غير قابلة للعب (على سبيل المثال بسرعة 14.4 كيلو بايت في الثانية باستخدام اتصال ppp(2)) الى قابلة للعب بصعوبة (28.8 كيلو بايت في الثانية كمثال باستخدام مودم يُشغل سواقة SLIP مضغوطة(3) ))

(2)في علم شبكات الحاسوب بروتوكول النقطة لنقطة أو “Point to Point Protocol” هو وصلة بينات (بروتوكول في الطبقة الثانية) يُستعمل لتحقيق اتصال مباشر بين نقطتين.

المشكلة كانت أن اللعبة “Doom” مُصممة من أجل الشبكات المحلية “LAN” فقط، و تستعمل النموذج الأول “Peer-to-Peer”المستعمل في الألعاب الاستراتيجية. في كل دور يتم تبادل مدخلات اللاعب (مثلا الضغط على مفتاح معين في لوحة المفاتيح) مع بقية أقرانه، و قبل أن يتمكن أحد اللاعبين من محاكاة أي اطار في اللعبة يجب استلام جميع مدخلات اللاعبين الآخرين.

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

من أجل تجاوز اتصال ال”LAN” و كذلك اتصال النخبة المتوفر في الجامعات و الشركات الكبيرة، كان ضرورياً تغيير النموذج. و هذا ما حدث بالفعل عام 1996، عندما أصدر جون كارماك لعبة “Quacke” مُستعملاً نموذج “Client/Server” بدلاً عن “Peer-to-Peer”.

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

في نموذج “Client/Server” الصرف لن تحتاج الى تشغيل كود لعبة على جهازك، بدلاً عن ذلك يتم استلام مدخلاتك كضغطك على مفتاح أو تحريك أو نقر الفأرة و ارسالها الى الخادم. بالنتيجة يقوم الخادم بتحديث حالة الشخصية في لعبتك في العالم الافتراضي و يرد اليك برزمة “Packet” تحتوي على هذه الحالة و حالة اللاعبين بالقرب منك. كل ما على الزبون “clients” القيام به هو التفاعل بين هذه التحديثات ليتكون بذلك وهم وجود حركة سلسة و هكذا، بهذه البساطة يكون لديك لعبة “Client/Server” على الشبكة.

كانت هذه خطوة عظيمة الى الأمام. جودة تجربة اللعب أصبحت تعتمد الآن على جودة الاتصال بين الخادم و الزبون بدلاً من اعتماده على اللاعب الأكثر تأخراً في اللعب. كما أصبح بامكان اللاعبين الانضمام و الخروج من اللعبة خلال اللعب، و ازداد عدد اللاعبين بقيام تقنية الزبون/الخادم بتقليل عرض النطاق الترددي “Bandwidth” المطلوب لكل لاعب.

لكن كان لايزال هناك مشكلة في نموذج “client/server” الصرف، يقول جون كارماك:

((في حين أن يمكنني تذكر و تبرير قراراتي حول الشبكات بدءاً بلعبة “Doom” ومن خلال لعبة “Quacke”، لكن خلاصة القول انني كنت أعمل مع الأخذ بافتراضات خاظئة بالأساس من أجل اتمام لعبة انترنت جيدة. كان تصميمي يستهدف اتصال بتأخيرأقل من 200 مل ثانية. الناس الذين يملكون اتصال انترنت رقمي من خلال مزود جيد يحصلون على تجربة لعب جيدة، لسوء الحظ فان 99% من العالم يحصل اتصال “ppp” أو “SLIP” باستخدام مودم، و غالباً ما يكون من خلال مزود خدمة انترنت سيئ و مزدحم للغاية. مُعطياً بذلك تأخير يصل الى أكثر من 300 مل ثانية في الاتصال كأقل تقدير. سيكون ردة فعل المستخدمين لهذه الخدمات سيئة لغاية.

حسناً، أعترف بانني قمت بأخذ قرار خاطئ. أمتلك خط اتصال نوع “T1(4)”، لهذا لم أكن على دراية بأنواع الاتصالات الأخرى. و أقوم الآن بدراسة الموضوع))

المشكلة كانت التأخير في الاتصال بالطبع.

ما قام به جون فيما بعد عندما أصدر لعبة “QuackeWorld” سغير مجال الصناعة الى الأبد.

في لعبة “Quacke” الأصلية كان اللاعب يشعر بتأخرالاتصال بين حاسوبه و الخادم. يضغط مفتاح التقدم الى الأمام و سيترتب عليه الانتظار زمن استغراق سفر الحزمة الى الخادم و منه عائدة الى حاسوبه قبل أن يبدأ بالتحرك بالفعل. اضغط على مفتاح اطلاق النار و سيكون عليك انتظار الزمن عينه قبل اطلاق النار.

اذا كنت قد لعبت أي لعبة رماية “FPS” حديثة مثال على ذلك لعبة “Call of Duty: Modern Warfare”، ستعلم أن هذا لم يعد يحدث. اذاً كيف استطاع مودم ألعاب الرماية الحديثة أن يزيل مشكلة تأخير الاتصال عند اللعب أكثر من لاعب على الشبكة؟

حُلت هذه المشكلة بشكل تاريخي بجزئين. الجزء الأول كان توقع الحركة و يتم من جهة الزبون طُور من قبل جون كارماك من أجل لعبة “QuackeWorld”، ليتم استعماله لاحقاً في نموذج التشبيك للعبة “Unreal” من قبل تيم سويني. الجزء الثاني كان تطوير تقنية تعويض التأخيرفي الاتصال من قبل يان بيرنيه من شركة “Valve” من أجل لعبة “Counterstricke”. في هذا الجزء من المقالة سنركز على الجزء الأول و هواخفاء التأخير على حركة اللاعب.

عندما قام جون كارماك بالكتابة عن مخططاته عن ما لعبة “Quackeworld” و التي كانت حينها على وشك الصدور، قال:

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

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

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

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

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

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

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

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

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

بهذه الطريقه يبدو اللاعب متحكماً بالشخصية بدون أي تأخير، فنحصل على محاكاة حتمية لكود شخصية اللعبة؛ أي معطياً النتيجة نفسها تماماً للمدخلات نفسها عند الزبون و الخادم، و نادراً ما يتم تصحيحها، كما يصف تيم سويني :

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

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

المصدر: هنا