كيف يساعد تحليل الكود الثابت في مساحة GameDev

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



" أهم شيء فعلته كمبرمج في السنوات الأخيرة هو السعي الحثيث لتحليل الكود الثابت. والأكثر قيمة من مئات الأخطاء الجسيمة التي منعتها من خلال التغيير في طريقة تفكيري حول طريقة عرض موثوقية البرنامج ورمزه الجودة. "- John Carmack



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



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



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

PVS-Studio و Unity

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



بدأ تعارفنا الجاد الأول مع Unity في عام 2016 ، عندما أصدر مطورو محرك اللعبة هذا الكود المصدري للعديد من المكونات والمكتبات والعروض التوضيحية في مستودعهم الرسمي. بطبيعة الحال ، لم نتمكن من تجاوز مثل هذه الحالة "اللذيذة" وأردنا كتابة مقال حول التحقق من الشفرة الموضوعة.



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



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



ومع ذلك ، فإن كتابة المقالات بعيدة كل البعد عن كل شيء. نواصل العمل على PVS-Studio ، وتعد GameDev أحد أهم مجالات التطوير بالنسبة لنا. لذلك ، نريد أن يتمكن مطورو ألعاب Unity من الحصول على أفضل تحليل ممكن لمشاريعهم.



كانت إحدى خطوات تحسين جودة تحليل مشاريع Unity بالنسبة لنا هي كتابة التعليقات التوضيحية للطرق المحددة في Unity Scripting API.



طريقة التعليقات التوضيحية هي آلية خاصة مستخدمة في PVS-Studio. يسمح لك بتزويد المحلل بجميع المعلومات التي يحتاجها حول طريقة معينة. هو مكتوب في كود خاص من قبل مطوري المحلل أنفسهم (أي من قبلنا).



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



لقد كتبنا بالفعل مجموعة كبيرة ومتنوعة من التعليقات التوضيحية المختلفة (على سبيل المثال ، للطرق من مساحة اسم النظام) ، ويسعدنا تكميلها بتعليقات توضيحية للطريقة من Unity Scripting API.



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



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

• UnityEngine.Vector3
• UnityEngine.Mathf
• UnityEngine.Debug
• UnityEngine.GameObject
• UnityEngine.Material
• UnityEditor.EditorGUILayout
• UnityEngine.Component
• UnityEngine.Object
• UnityEngine.GUILayout
• UnityEngine.Quaternion
• ...

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



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

MeshRenderer renderer = cube.GetComponent<MeshRenderer>();
Material m = renderer.material;
List<int> outNames = null;
m.GetTexturePropertyNameIDs(outNames);

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



إذن ، التعليقات التوضيحية مكتوبة. بعد بدء التحليل ، اكتشفنا على الفور محفزات جديدة. على سبيل المثال ، اكتشف المحلل استدعاءًا غريبًا لطريقة GetComponent :

void OnEnable()
{
  GameObject uiManager = GameObject.Find("UIRoot");

  if (uiManager)
  {
    uiManager.GetComponent<UIManager>();
  }
}

تحذير المحلل: V3010 يجب استخدام قيمة الإرجاع الخاصة بالوظيفة "GetComponent". - ADDITIONAL IN CURRENT UIEditorWindow.cs 22



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



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



إذا كنت ترغب في قراءة المزيد من التفاصيل حول عملنا مع التعليقات التوضيحية لطرق Unity ، فيمكنك القيام بذلك في مقالتنا: كيف بدأ محلل PVS-Studio في العثور على المزيد من الأخطاء في مشاريع Unity .

محرك غير واقعي 4

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



كانت Epic Games مهتمة بتحسين محركها باستخدام PVS-Studio ، لذلك اتفقنا على اتفاقية: نقوم بإصلاح كود Unreal Engine بأنفسنا حتى لا يصدر المحلل أي تحذيرات له ، ويقوم الرجال من Epic Games بشراء ترخيصنا بالإضافة إلى ذلك كافئنا على العمل الذي نقوم به.



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



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



قمع الملفات هي وظيفة خاصة لـ PVS-Studio، والذي يسمح لك "بإخفاء" مشغلات المحلل في ملف خاص. في هذه الحالة ، لن تظهر التحذيرات المخفية في السجلات اللاحقة: يمكن عرضها بشكل منفصل.



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



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



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



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



وذهبنا إلى العمل. بعد التحقق من كود المشروع ، وجدنا 1821 تحذيرًا بمستوى واحد من Level_1 و Level_2. يتطلب تحليل هذا الحجم من التحذيرات عملاً جادًا ، ولتسهيل هذه العملية برمتها ، قمنا بإعداد تحليل مستمر للكود على خادم CI الخاص بنا.



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



استغرقت العملية برمتها 17 يوم عمل. الجدول الزمني لتصحيح التحذيرات هو كما يلي:





في الواقع ، لا يعكس هذا المخطط عملنا بالكامل. بعد أن أصلحنا جميع التحذيرات ، انتظرنا يومين آخرين لقبول طلبات السحب الأخيرة. طوال هذا الوقت ، واصلنا التحقق تلقائيًا من أحدث إصدار من Unreal Engine ، والذي استمر بدوره في إعادة ملئه برمز جديد. وما رأيك؟ خلال هذين اليومين ، وجد PVS-Studio أربعة أخطاء أخرى في الكود! كان أحدهم خطيرًا بشكل خاص ويمكن أن يؤدي إلى سلوك غير محدد.



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



يمكنك قراءة المزيد حول كيفية عملنا على كود Unreal Engine على مدونة Unreal Engine الرسمية أو على موقعنا الإلكتروني .

تحليل الألعاب المختلفة

هل ذكرت أننا تحققنا من مشاريع مختلفة مفتوحة المصدر وكتبنا مقالات عنها؟ لذلك ، لدينا عدد كبير من المقالات المتشابهة حول مشاريع الألعاب! لقد كتبنا عن ألعاب مثل VVVVVV و Space Engineers و Command & Conquer و osu! وحتى (مقال قديم جدًا) Doom 3 . لقد قمنا أيضًا بتجميع أفضل 10 أخطاء مثيرة للاهتمام في صناعة ألعاب الفيديو.



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



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



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

خاتمة

هذا يختتم مقالي القصير. أتمنى لك رمزًا نظيفًا ويعمل بشكل صحيح بدون أخطاء وأخطاء!



مهتم بموضوع التحليل الساكن؟ هل تريد التحقق من مشروعك بحثًا عن أخطاء؟ جرب PVS-Studio .

إذا كنت ترغب في مشاركة هذه المقالة مع جمهور يتحدث الإنجليزية ، فيرجى استخدام رابط الترجمة: George Gribkov. كيف يساعد تحليل الكود الثابت في صناعة GameDev .