وسام البهنسي

السلام عليكم ورحمة الله وكل عام وأنتم بخير،

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

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

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

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

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

محصلة كل ما ذُكِر هو المشهد التقليدي لمبرمج مستجدّ يرى الكود لأول مرة فتنمو علامات الاستفهام على رأسه قبل أن تتحول لغابة من علامات التعجب. والسؤال الملحّ: "لماذا؟! لماذا يفعلون هذا؟! هذا خطأ!" والإجابة تكون غالباً هي تلك الإجابة الأزلية من قِبَل المبرمجين المخضرمين في المشروع:

إنها كذلك لأسباب تاريخية.

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

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

نظم الإحداثيات في نيد فور سبيد:

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

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

نظام إحداثيات السطوح في يونيتي:

تعود أصول يونيتي كمحرك يعمل في بداياته فقط على ماك أو إس (MacOS) ومكتبة أوبن جي إل (OpenGL) للرسوميات، وقد ورث من هذه التركيبة نظام إحداثيات أوبن جي إل في السطوح، حيث مبدأ الإحداثيات 0،0 يقع في الزاوية اليسرى السفلى من أية صورة أو إكساء (texture) أو سطح رسم (render surface). للأسف لم تعتمد أية مكتبة رسوميات أخرى هذا المبدأ. وعندما توسع المحرك ليدعم المنصات الأخرى اضطر لمواجهة معضلة التعامل مع سطوح رسم بمبدأ إحداثيات يقع في الزاوية اليسرى العليا. وقد كان القرار هو الاستمرار باعتماد الزاوية السفلى وإجبار كافة المنصات التي لا تستخدم أوبن جي إل على التحويل. نتقدم بالزمن إلى اليوم وعدد المنصات الكبير التي يدعمها المحرك، وجميعها باستثناء أوبن جي إل تأخذ الزاوية العليا كمبدأ إحداثيات. هذا إضافة إلى اضمحلال أهمية هذه المكتبة أمام المكتبات الحديثة مثل فولكان (Vulcan). لكن مع يونيتي أنت كالمحكوم عليه بجريمة حرب، لا تسقط عنك بالتقادم. هذا يعني حتى لو تم تغييب دعم أوبن جي إل وأصبحت كل المنصات التي يدعمها يونيتي تعتمد الزاوية العليا اليسرى فإن يونيتي سيستمر بإجبار كافة هذه المنصات على أخذ الإحداثيات من مستخدميه اعتماداً على الزاوية السفلى... لماذا؟ لأسباب تاريخية بالطبع 🙂

نظام الإحداثيات في هايبر فويد:

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

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

 والسلام عليكم ورحمة الله!

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