وسام البهنسي

مدونة مبرمج معماري

في الوحدة

السلام عليكم،

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

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

وقد يسأل أحدهم، لماذا أنا مضطر للانضمام ليونيتي لدراسة محركها ولم تضطر لذلك مع أنريل؟

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

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

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

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

ممتاز، فلنبدأ... لكن في تدوينات قادمة 😊

السلام عليكم

التعليقات (3) -

  • ياسر ابوبكر

    24/04/2019 07:18:40 م | الرد

    في انتظار التدوينة القادمة بفارغ الصبر Smile

  • Mohamed Touiti

    06/06/2019 02:19:56 ص | الرد

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

    • وسام البهنسي

      13/07/2019 11:08:18 ص | الرد

      أهلاً بك محمد. جامع القمامة يستخدم في هذه المحركات لمتابعة حياة الكائنات وخصوصاً تلك التي تؤشر إلى بعضها البعض. مثلاً، كائن سيارة يؤشر إلى كائن راكب، أو مجسم يؤشر إلى إكساء...الخ. هذه المسألة يمكن حلها ببساطة وبدون مشاكل جامع القمامة باستخدام تكنيك عدّ المراجع (reference counting). من أهم مزايا هذا الأسلوب أنه لا يدع الذاكرة الهائمة (القمامة) تتراكم حتى تحين لحظة التجميع القاسية، وإنما يحرر ذاكرة الكائنات اليتيمة مباشرة عند لحظة تيتمها. في كل من يونيتي وأنريل يوجد صنف أساس (Object أو UObject) تنحدر منه كافة الأصناف الأخرى في المحرك، وهذا الصنف مفروض على المستخدم كي يدعمه جامع القمامة. كل هذا يشمل عبئاً على الأداء وفي الكثير من الأحيان ليس ضرورياً. فقد تكون فقط أجزاء محدودة ومعينة من اللعبة التي تحتاج إلى متابعة المؤشرات بينما بقية الكود لا يأبه بها.
      في حالة محركي الخاص كنت أستخدم ال reference counting إلى أن تخلصت منه إلى حد كبير والآن فقط أستخدم ما يدعى المؤشر المشترك والمؤشر الضعيف (shared pointer and weak pointer) فقط في جزئية ال gameplay بين الكائنات التي تؤشر إلى بعضها البعض (مثلاً كوكب له أقمار).

أضف تعليقاً

Loading