بدأ العام الجديد لمطوري الألعاب بموجة من الانتقادات التي وقعت على لجنة توحيد C ++ بعد نشر شكاوى Aras Prankevichus حول Modern C ++ . نشأ سؤال خطير: هل فقدت لجنة المعايير حقًا التواصل مع الواقع ، أم أنها عكس ذلك ، وهل انفصل مطورو اللعبة عن بقية مجتمع C ++؟
نحن نقدم لك ترجمة للبوابة الشعبية لبن دين ، وهو من قدامى المحاربين في صناعة الألعاب ، والذي عمل لفترة طويلة في Blizzard ، و Electronic Arts and Bullfrog كمطور C ++ وقائد فريق ، حيث يستجيب للنقد من وجهة نظر تجربته الخاصة.TL ؛ DR: ليس لدى لجنة توحيد C ++ هدف خفي لتجاهل احتياجات مطوري اللعبة ، ولن تصبح C ++ "الحديثة" لغة "تم تصحيحها".
طوال الأسبوع الماضي
، كان هناك
نقاش نشط على Twitter ، تحدث خلاله العديد من المبرمجين - وخاصة أولئك الذين يعملون في مجال تطوير اللعبة - عن أن ناقلات التطوير الحالية لـ "C ++ الحديثة"
لا تلبي احتياجاتهم . على وجه الخصوص ، من وجهة نظر أحد مطوري الألعاب العاديين ، يبدو كل شيء وكأن أداء تصحيح الأخطاء في اللغة قد تم تجاهله ، وأصبح تحسين الكود متوقعًا وضروريًا.
نظرًا لأنني تمكنت في عام 2019 من العمل في صناعة الألعاب لأكثر من 23 عامًا ، فإن لدي رأيي الخاص بناءً على الملاحظات حول هذا الموضوع فيما يتعلق بتطوير اللعبة ، والتي أود مشاركتها. هل تصحيح الأخطاء مهم لمطوري الألعاب ولماذا؟ ما هي القضايا المرتبطة به؟
لبداية - القليل من الانغماس في التاريخ.
يعمل العديد من مطوري ألعاب C ++ في Microsoft Visual C ++. تاريخياً ، تشكل سوق ضخم للألعاب حول منصات Microsoft ، مما أثر على التجربة المعتادة لمبرمج الألعاب العادي. في التسعينات والألفينيات من القرن الماضي ، كُتبت معظم الألعاب مع مراعاة هذه الظروف. حتى مع ظهور لوحات المفاتيح من الشركات المصنعة الأخرى والشعبية المتزايدة للألعاب المحمولة ، فإن أصول العديد من استوديوهات AAA والعديد من مبرمجي الألعاب اليوم هي أدوات من صنع Microsoft.
يعتبر Visual Studio أفضل مصحح أخطاء لـ C ++ في العالم. علاوة على ذلك ، فإن برنامج Visual Studio يبرز في الحقيقة أكثر ما يكون من حيث تصحيح البرامج - أكثر من الواجهة الأمامية أو الخلفية أو تطبيق STL أو أي شيء آخر. في السنوات الخمس الماضية ، قطعت Microsoft خطوات كبيرة في تطوير أدوات تطوير C ++ ، ولكن حتى قبل ذلك ، كان مصحح الأخطاء في Visual Studio دائمًا رائعًا للغاية. لذلك عندما تقوم بالتطوير على جهاز كمبيوتر يعمل بنظام Windows ، يكون لديك دائمًا مصحح أخطاء على مستوى عالمي.
بالنظر إلى ما سبق ، دعونا ننظر إلى عملية الحصول على الشفرة التي لن يكون فيها أي أخطاء ؛ فرص لدينا من وجهة نظر مبرمج لا يتعامل مع الألعاب ؛ وكذلك القيود التي يواجهها مطورو اللعبة. إذا قمت بإعادة صياغة الوسيطة الرئيسية لصالح "ناقل تطوير C ++ الحديث" ، فسيتم تقليلها إلى أنواع وأدوات واختبارات. بعد هذا الفكر ، يجب أن يكون مصحح الأخطاء
السطر الأخير من الدفاع . قبل أن نحقق ذلك ، لدينا الخيارات التالية.
فرصة رقم 1: أنواع
يمكننا استخدام الكتابة القوية قدر الإمكان لإزالة فئات كاملة من الأخطاء في وقت الترجمة. الكتابة القوية هي ، بلا شك ، فرصة قدمها لنا التطور الأخير لـ C ++ ؛ على سبيل المثال ، بدءًا من الإصدار C ++ 11 ، تمكنا من الحصول على:
- امتداد كبير
type traits ؛ - الابتكارات مثل
nullptr و scoped enum لمكافحة التراث C - ضعف الكتابة ؛ - GSL والأدوات المساعدة ؛
- المفاهيم في C ++ 20.
البعض منكم قد لا يحب metaprogramming ؛ قد لا يحب الآخرون أسلوب الترميز الذي يستخدم
auto تقريبًا على مستوى العالم. بغض النظر عن هذه التفضيلات ، فإن الدافع الرئيسي لاستخدام الأنماط المدرجة في C ++ يتم تتبعه بوضوح هنا - هذه هي الرغبة في مساعدة المترجم حتى يتمكن ، بدوره ، من مساعدتنا ، باستخدام ما يعرفه بشكل أفضل في نفس الوقت: نظام الكتابة.
إذا كنا نتحدث عن برمجة الألعاب ، فإن الكتابة القوية هنا تعد مجالًا واسعًا للبحث ، ويستخدمها مبرمجو اللعبة على دراية بنشاط ، والذين يرغبون في تحسين مهاراتهم في استخدام C ++ في الممارسة. شيئان مهمان يثيران القلق هنا: التأثير على وقت الترجمة ، والتأثير على إمكانية قراءة التعليمات البرمجية.
بصراحة ، يمكنك بسهولة تجاهل وقت الترجمة - ولكن بشرط أن تكون مبرمجًا في شركة كبيرة جدًا لا تلعب الألعاب ولديها بنية أساسية داخلية ثابتة وقدرة حوسبية لا حصر لها من أجل تجميع أي رمز يمكنك كتابته . تشعر هذه الشركات الكبيرة بالقلق من تكلفة التجميع - وبالتالي تستخدم الوحدات النمطية - ولكن ، كقاعدة عامة ، لا يسبب هذا الألم للمطورين الأفراد. في الوقت نفسه ، بالنسبة لمعظم مبرمجي اللعبة ، هذا ليس هو الحال. لا يملك مطورو Indie مزارعًا للبناء ؛ غالبًا ما يستخدم مطورو ألعاب AAA شيئًا مثل
Incredibuild ، ولكن نظرًا لحقيقة أنه يمكنهم العمل بسهولة مع قاعدة بيانات يبلغ عمرها 10 سنوات أو أكثر ، فإن عملية الإنشاء قد تستغرق 15-20 دقيقة.
يمكننا مناقشة التكلفة النسبية لإضافة أجهزة مقابل تكلفة وقت المبرمج ، وأنا أتفق مع الرأي القائل بأن الأجهزة أرخص ، ومع ذلك:
- تعد الأجهزة نفقات حقيقية لمرة واحدة سيتم تخصيصها لميزانية الربع الحالي ، على عكس النفقات غير الملموسة في الوقت / التوظيف / وما شابه ذلك ، والتي سيتم توزيعها على فترة زمنية أطول. لا يتعامل الناس جيدًا مع القرار الذي يدعم هذا الحل الوسط ، والشركات مصممة خصيصًا بطريقة تحقق الربح على المدى القصير.
- تتطلب البنية التحتية الدعم ، ولا يذهب أي شخص تقريبًا إلى صناعة الألعاب ليصبح مهندس إطلاق. مقارنةً بالمناطق الأخرى حيث يتم استخدام C ++ ، فإن مرتبي مطوري اللعبة ليس مرتفعًا جدًا - ولا يحصل مهندسون من غير اللعبة على أجر أقل هنا.
يمكن للمرء أيضا أن يتكهن بحقيقة أن وقت التجميع لم يكن يجب أن يصل إلى مثل هذه الحالة ؛ ومرة أخرى أنا أتفق معك. سعر هذا هو اليقظة المستمرة - مرة أخرى ، قادمة من مهندس الإصدار - ومن الناحية المثالية ، بعض الأدوات الآلية التي تسمح لك بتتبع التغييرات في الوقت اللازم لإنشاء البناء. لحسن الحظ ، مع ظهور أنظمة CI ، يمكن تحقيق هذا الهدف اليوم بسهولة أكبر.
الفرصة رقم 2: الأدوات
يجب أن نستخدم أقصى عدد من الأدوات المتاحة لنا - التحذيرات ، والتحليل الثابت ، والمطهرات ، وأدوات التحليل الديناميكية ، والمقاطعين وغيرهم.
تجربتي هي أن مطوري اللعبة يستخدمون هذه الأدوات كلما كان ذلك ممكنًا ، لكن الصناعة ككل تواجه العديد من المشكلات:
- تميل هذه الأدوات إلى العمل بشكل أفضل على الأنظمة الأساسية بخلاف Microsoft - وكما ذكر سابقًا ، هذا ليس سيناريو تطوير لعبة نموذجي.
- تهدف معظم هذه الأدوات إلى العمل باستخدام C ++ "قياسي". أنها خارج منطقة الجزاء تدعم
std::vector ، ولكن ليس لي فئة مكتوبة ذاتيا CStaticVector من محرك افتراضي. بالطبع ، إلقاء اللوم على الأدوات لا طائل منه ، ولكن هذا لا يزال أحد العوائق التي تحول دون استخدامها والتي يجب على المطورين التغلب عليها. - يتطلب إنشاء والحفاظ على سلسلة CI التي ستعمل على تشغيل كل هذه الأدوات وجود مهندسي إطلاق - وكما ذكرنا سابقًا ، فإن تعيين أشخاص في وظائف هندسية لا ترتبط مباشرة بالألعاب يمثل مشكلة نظامية لصناعة الألعاب.
لذا ، نظرًا لأن هذه الأدوات تعمل بشكل جيد مع C ++ القياسية ، فلماذا إذن لا يستخدم مطورو الألعاب STL؟
من أين تبدأ الإجابة على هذا السؤال؟ ربما ، من الرحلة القادمة في تاريخ تطوير اللعبة:
- حتى أوائل التسعينيات ، لم نثق في المترجمين C ، لذلك كتبنا الألعاب في المجمع.
- من البداية إلى منتصف التسعينيات ، بدأنا في الوثوق ببرنامج التحويل البرمجي C ، لكننا لم نثق في برنامج التحويل البرمجي لـ C ++. كان كودنا هو C ، والذي استخدم تعليقات نمط C ++ ، ولم نعد بحاجة إلى كتابة typedefs لهياكلنا في كل وقت.
- حوالي عام 2000 ، حدثت ثورة C ++ في عالم تطوير الألعاب. لقد كانت حقبة من أنماط التصميم والتسلسلات الهرمية الكبيرة . في ذلك الوقت ، ترك دعم STL على لوحات المفاتيح الكثير مما هو مرغوب فيه ، وحكمت لوحات المفاتيح العالم في ذلك الوقت. على PS2 ، نحن عالقون إلى الأبد مع GCC 2.95.
- حوالي عام 2010 ، تم إطلاق ثورتين أخريين. حفز الألم من استخدام التسلسلات الهرمية فئة كبيرة تطوير نهج مكون إلى رمز. يستمر هذا التغيير في تطوره اليوم في شكل هياكل نظام الكيانات. جنبا إلى جنب مع هذه كانت الثورة الثانية - محاولة للاستفادة من بنيات متعددة المعالجات.
خلال هذه التحولات في النموذج ، كانت منصات تطوير اللعبة نفسها تتغير باستمرار ، وكانت تتغير بشكل خطير. أعطت الذاكرة المقسمة الطريق إلى مساحة عنوان مسطحة. أصبحت المنصات متعددة المعالجات ، متناظرة وليس غاية. كان على مطوري الألعاب ، الذين اعتادوا على العمل مع بنيات Intel ، التعود على MIPS (Playstation) ، ثم على أجهزة خاصة مزودة بوحدات المعالجة المركزية غير المتجانسة (PS2) ، ثم إلى PowerPC (XBox 360) ، ثم إلى عدم تجانس أكبر (PS3) ... لقد جاء النظام الأساسي الجديد بميزات أداء جديدة للمعالجات والذاكرة ومحركات الأقراص. إذا كنت ترغب في تحقيق الأداء الأمثل ، فاضطررت إلى إعادة كتابة التعليمات البرمجية القديمة الخاصة بك ، والكثير والكثير من الأحيان. لن أذكر مدى تأثر الألعاب بظهور ونمو شعبية الإنترنت ، فضلاً عن القيود التي فرضها أصحاب المنصات على المطورين.
تاريخياً ، كانت تطبيقات STL على منصات الألعاب غير مرضية. ليس سراً أن حاويات STL غير مناسبة للألعاب. إذا دفعت مطور اللعبة إلى الحائط ، فربما يعترف بأن
std::string ما يرام ، وأن
std::vector خيار افتراضي معقول. لكن جميع الحاويات الموجودة في STL تواجه مشكلة في التحكم في التخصيص والتهيئة. يجب أن تقلق العديد من الألعاب من القيود المفروضة على الذاكرة لمختلف المهام - وبالنسبة لتلك الكائنات التي من المرجح أن يتم تخصيص الذاكرة لها ديناميكيًا أثناء اللعب ، وغالبًا ما يتم استخدام أدوات تخصيص
اللوح أو
الساحة . لا يعد
الوقت الثابت المطفأ نتيجة جيدة ، لأن التخصيص يُعد أحد أكثر الأشياء "تكلفة" التي يمكن أن تحدث أثناء تنفيذ البرنامج ، ولا أريد تخطي إطار لمجرد أنه حدث عندما لم أكن أتوقعه . كمطور لعبة ، يجب أن أدير متطلبات ذاكرتي مسبقًا.
يتم الحصول على قصة مماثلة للتبعيات الأخرى بشكل عام. يريد مطورو الألعاب معرفة ما تستغرقه كل دورة من دورات المعالج ، وأين ومتى ولما هي مسؤولية كل بايت من الذاكرة ، وكذلك أين ومتى يتم التحكم في كل مؤشر ترابط للتنفيذ. حتى وقت قريب ، قام برنامج التحويل البرمجي لـ Microsoft بتغيير ABI مع كل تحديث - لذلك إذا كان لديك العديد من التبعيات ، فقد تكون إعادة بناء كل هذه العمليات عملية مؤلمة. يفضل مطورو الألعاب عادةً التبعيات الصغيرة التي يسهل دمجها ، والقيام بشيء واحد فقط والقيام بذلك بشكل جيد - ويفضل أن يكون ذلك مع واجهة برمجة تطبيقات C-style - وتستخدمها العديد من الشركات ، أو تكون في نطاق عام أو لديها ترخيص مجاني لا يتطلب إشارة من المؤلف.
تعتبر SQLite و
zlib أمثلة جيدة لما يفضل مطورو الألعاب استخدامه.
بالإضافة إلى ذلك ، تتمتع صناعة ألعاب C ++ بتاريخ غني من المرضى الذين يعانون من متلازمة "غير اخترع هنا". يجب توقع ذلك من هذه الصناعة ، التي بدأت مع هواة منفردين قاموا بصنع أغراضهم الخاصة بمعدات جديدة تمامًا وليس لديهم خيارات أخرى. صناعة الألعاب ، من بين أشياء أخرى ، هي الوحيدة التي يتم فيها الإشارة إلى المبرمجين في الاعتمادات في أي ترتيب معين.
كتابة مجموعة متنوعة من الأشياء ممتعة ، ويساعد حياتك المهنية! من الأفضل لك بناء شيء خاص بك بدلاً من شراء الملابس الجاهزة! ونظرًا لأننا قلقون جدًا بشأن الأداء ، فيمكننا تكييف حلنا بطريقة تجعله مناسبًا بشكل خاص لمشروعنا - بدلاً من اتخاذ حل معمم يهدر الموارد المتاحة بلا طائل. العداء لـ Boost هو المثال الرئيسي لكيفية ظهور هذا التفكير في تطوير اللعبة. عملت في مشاريع سارت على النحو التالي:
- بادئ ذي بدء ، لحل مشكلة معينة ، نقوم بتوصيل مكتبة من Boost إلى المشروع.
- كل شيء يعمل بشكل جيد للغاية. عندما تحتاج إلى التحديث ، يحدث القليل من الألم ، ولكن ليس أكثر من عند تحديث أي تبعية أخرى.
- هناك لعبة أخرى تريد استخدام الكود الخاص بنا ، لكن العقبة الرئيسية هي أننا نستخدم Boost - على الرغم من أن تجربتنا مع Boost سارت على ما يرام.
- نزيل الشفرة باستخدام Boost ، لكننا نواجه الآن مشكلة جديدة: يجب أن نحل المشكلة التي تم حلها من مكتبة Boost بدلاً من حلها من قبل.
- ننسخ أساسًا أجزاء كود Boost التي نحتاجها في مساحات الأسماء الخاصة بنا.
- في وقت لاحق ، واجهنا حتماً ووقتًا تلو الآخر حقيقة أننا نحتاج إلى وظائف إضافية تكون موجودة بالفعل في الكود الأصلي إذا لم نرميها بعيدًا. لكن الآن نحن أصحاب هذا الرمز ، لذلك يتعين علينا مواصلة دعمه.
نحن لا نحب شيئًا ضخمًا يحاول القيام بأشياء كثيرة في نفس الوقت أو يمكن أن يؤثر على وقت الترجمة - وهذا أمر معقول تمامًا. ما يخطئ الناس مرارًا وتكرارًا هو أنهم يعارضون قبول الألم المفترض اليوم - بينما بسبب هذا القرار سيواجهون ألمًا حقيقيًا وأكبر كثيرًا بدعم من شيء ما على حساب شخص ما - الميزانية التي سيكون لديهم لتجربة على مدى السنوات الثلاث المقبلة. للأسف ، فإن وجود أدلة في شكل ألعاب تستخدم بنجاح طبقًا من STL و Boost ، لا يمكن بأي حال من الأحوال التأثير على علم النفس البشري وإقناع مطوري الألعاب.
لكل هذه الأسباب ، أنشأت العديد من شركات الألعاب مكتبات خاصة بها تغطي ما تفعله STL - بل وأكثر من ذلك - مع دعمها لحالات الاستخدام الخاصة باللعبة. حتى أن بعض شركات الألعاب الكبيرة كانت قادرة على إتقان عملية تطوير
استبدال STL الخاص بها بالكامل ، والمتوافق تمامًا تمامًا مع واجهة برمجة التطبيقات ، مما أدى في وقت لاحق إلى تكاليف باهظة لدعم هذا المشروع.
من الحكمة إيجاد بديل محسّن لـ std::map ، أو تطبيق
تحسين المخزن المؤقت الصغير في
std::vector . من غير المقبول أن يتم دعم تطبيقاتك الخاصة
algorithms أو
type traits ، وهو ما لن يكون مفيدًا. بالنسبة لي ، من المؤسف أنه بالنسبة لمعظم المطورين ، فإن STLs مجرد حاويات. منذ عندما تعلم STL في البداية ، يتم تعليمهم ذلك بالضبط ، عند الحديث عن STL ، يعني معظمهم
std::vector - رغم أنهم في الحقيقة يجب أن يفكروا في
std::find_if .
الفرصة رقم 3: الاختبارات
يقال أنه يجب إجراء اختبار مكثف ، ويجب أن يغطي TDD و / أو BDD جميع الشفرات التي يمكن تغطيتها ، ويجب معالجة الأخطاء عن طريق كتابة اختبارات جديدة.
لذلك ، دعونا نناقش موضوع الاختبار.
انطلاقا من تجربتي ، لا يتم استخدام الاختبارات الآلية عمليا في صناعة الألعاب. لماذا؟
1. لأن الدقة ليست مهمة للغاية ، لكن لا توجد مواصفات حقيقية
باعتباري مبرمجًا شابًا في صناعة الألعاب ، تخلصت سريعًا من فكرة أنني يجب أن أحاول محاكاة شيء ما بشكل واقعي. الألعاب هي
الدخان والمرايا والبحث عن مسارات قصيرة. لا أحد يهتم مدى واقعية المحاكاة الخاصة بك ؛ الشيء الرئيسي هو أن تكون ممتعة. عندما لا يكون لديك مواصفات أخرى غير "اللعبة يجب أن تشعر بالراحة" ، يكون موضوع الاختبار مفقودًا. بفضل الأخطاء ، يمكن أن تتحسن طريقة اللعب. في كثير من الأحيان ، يحدث خطأ في الإصدار ، ويفوز حتى بحب المستخدمين (
تذكر نفس غاندي من الحضارة ). تختلف الألعاب عن المناطق الأخرى التي تستخدم C ++؛ هنا عدم وجود صحة لا يؤدي إلى حقيقة أن شخصا ما في نهاية المطاف يفقد مدخراته.
2. لأنه صعب
بالطبع ، ترغب في إنتاج اختبارات آلية أينما كنت. يمكن القيام بذلك لبعض الأنظمة الفرعية التي توجد لها نتائج نهائية محددة بوضوح. اختبار الوحدة في صناعة الألعاب موجود بالطبع ، لكن كقاعدة عامة ، يقتصر ذلك على الكود المنخفض المستوى - تمثيلي STL المذكور سابقًا ، وإجراءات تحويل السلسلة ، وطرق المحرك الفعلية ، إلخ. عادة ما يتم اختبار الحالات التي يكون فيها القسم القابل للتنفيذ من الشفرة نتائج يمكن التنبؤ بها عن طريق اختبارات الوحدة ، على الرغم من عدم استخدام TDD هنا - لأن مبرمجي اللعبة يفضلون تبسيط حياتهم ، وليس العكس. ولكن كيف يمكنك اختبار رمز اللعب (انظر النقطة الأولى)؟ بمجرد تجاوز اختبار الوحدة ، تصادف على الفور سببًا آخر يجعل اختبار الألعاب صعبًا للغاية.
3. لأن المحتوى متورط
من المحتمل أن يشمل اختبار الأنظمة غير التافهة توفير المحتوى الذي سيتم تنفيذه به. معظم المهندسين لا يجيدون إنتاج هذا المحتوى بمفردهم ، لذلك للحصول على اختبار ذي معنى ، ستحتاج إلى جذب شخص لديه المهارات المناسبة لإنشاء المحتوى. بعد ذلك سوف تواجه مشكلة قياس ما تحصل عليه في المخرجات - بعد كل شيء ، لم يعد هذا خطًا أو رقمًا ، بل صورة على الشاشة أو صوت يتغير بمرور الوقت.
4. لأننا لا نمارسها
اختبار الوحدة هو وظيفة أعرف عنها المدخلات والمخرجات المحتملة. ومع ذلك ، فإن طريقة اللعب لا يمكن التنبؤ بها وتتطور بشكل ديناميكي ، ولا أعرف كيف يمكن اختبار هذه الظاهرة بشكل صحيح. ما الذي يمكنني اختباره - إذا ، بالطبع ، إذا حصلت على إذن من مديري لتكريس وقت كاف لهذا - وهذا ، على سبيل المثال ، الأداء أو القدرات عالية المستوى ، مثل التوفيق ، والتي يمكنني تحليلها. قد يكون هذا العمل في البنية التحتية مثيراً لبعض المبرمجين ، ولكن بالنسبة لمعظمهم ، فإنه ليس مثيرًا للاهتمام ، بالإضافة إلى أنه يتطلب موافقة ودعم من صاحب المحفظة. كمبرمج لعبة ، لم تتح لي الفرصة مطلقًا لممارسة كتابة اختبارات عالية المستوى.
5. بما أن [الشركة] لا ترى الحاجة للاختبار الآلي
هدفنا الرئيسي هو إطلاق اللعبة. نحن نعيش في عصر الصناعة الذي يتحرك إلى الأمام من خلال الزيارات التي تحقق أقصى استفادة من أموالها في الشهر الأول من المبيعات ، عندما يتم تعظيم تكاليف التسويق لهذه الزيارات. علمتنا دورة حياة لوحات المفاتيح أن الكود في أي حال لن يعيش لفترة طويلة. إذا كنا نعمل على لعبة على الإنترنت ، فعلى الأرجح سنحصل على وقت إضافي لاختبار التوفيق أو تحميل الخادم. نظرًا لأن إصدار اللعبة نحتاج إلى أن يكون أدائها جيدًا ، يجب علينا على الأقل إجراء اختبار الأداء ، لكن يجب ألا نتمثل في هذه العملية تلقائيًا. بالنسبة للإدارة في صناعة الألعاب ، فإن الاختبار الآلي ليس أكثر من مضيعة للوقت والمال. لتنفيذه ، من الضروري توظيف المهندسين ذوي الخبرة الذين سينفذون العمل ، وستكون النتيجة غير محسوسة تقريبًا. يمكن أن تقضي الوقت نفسه على تطوير ميزات جديدة. على المدى القصير ، من المربح استخدام موظفي ضمان الجودة لاختبار اللعبة ، وهو ما يقودنا إلى النقطة التالية.
6. لأنه بشكل عام ، يتم تصنيف الاختبارات في الألعاب كنشاط من الدرجة الثانية
أنا أحب المهنيين جيدة ضمان الجودة. بالنسبة لي يستحقون وزنه من الذهب. إنهم يعرفون كيفية جعل لعبتك أفضل عن طريق كسرها بطريقة لم تكن لتخطرك أبدًا. إنهم خبراء متخصصون في لعبتك في هذا الصدد لا تفهمونهم ، ولا يكادون تفهمهم. إنها أفضل من فريق المترجمين ذوي القدرات الفائقة لمساعدتك على القيام بكل شيء بشكل صحيح. أنا سعيد لأنني أتيحت لي الفرصة للعمل مع العديد من المتخصصين في ضمان الجودة على مدار سنوات عملي.
كان عليّ دائمًا القتال لأضمن بقاءهم في فريقي.
AAA-, , QA — , . , . , .
, , , . «» , , QA , , , .
. , . QA-, , API , « ». , , .
. , , , — .
. . , , « .» « Y.». QA- — , , .
, , ; , — , , — QA , , , , QA .
, , , QA-, . . . , , .
— , API , , ( ) — , .
, , C++.
, . , , , , , . , - , , .
, , , , . , , — , . , (
data breakpoints ) , , — , , ? , , , , , , , , , (
soak testing )?
سمة اثنين ، يمكننا الاعتماد على المصحح وحده. في هذه الحالة ، نفعل ما فعلناه دائمًا. نحن نحاول عزل المشكلة ، وجعلها تحدث في كثير من الأحيان. نضيف تسجيل وتنخل برنامجنا من خلال ذلك ؛ نضبط الموقتات وإعدادات التدفق ؛ نحن نستخدم البحث بناء ثنائي. ندرس مقالب الأساسية وسجلات التعطل. نحاول إعادة إنتاج المشكلة عن طريق خفض المحتوى إلى الحد الأدنى ؛ نحن نفكر في ما يمكن أن يسبب المشكلة ومناقشتها.في كثير من الأحيان ، حتى نصل إلى السبب الحقيقي للتحطم ، سيكون لدينا وقت لإصلاح بعض الأشياء الأخرى. بمعنى آخر ، نحن نحل المشكلات ، وفي النهاية ، لا يمثل استخدام المصحح سوى جزءًا صغيرًا من هذه العملية. إذن ، نعم ، سرعة تصحيح الأخطاء هي إضافة لطيفة ، لكن افتقارها لا يمنعنا من أن نكون مهندسين. ما زلنا بحاجة إلى مهاراتنا الأخرى ، مثل القدرة على تحليل المقالب الأساسية وقراءة المجمع الأمثل.« ++» , . ; , ; , . « C++» , — , , STL _ _, STL . , STL « », ; , ,
, .
, , « C++» — , .
— , .
, C++ , . , . , .
copy elision ( ) , . . , , NRVO , , . , C++
.
: ++
, C++, .
1.
, C++, , . , . , , — .
, . C++98, , - , .
, , , . , C++-, «» C++. — , C C++98. , , , – , . ?
2.
, GDC,
CppCon , , . ;
;
. , , — , .
C++ . , SG14, SG7, SG15 — , —
isocpp.org . — , , 200 ? «» «» .
, , , , Twitter Reddit. , — .