الأخطاء العشرة الأكثر شيوعًا التي يرتكبها مطورو الوحدة

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

خطأ الوحدة الشائع رقم 1: التقليل من مرحلة تخطيط المشروع

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

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

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

خطأ الوحدة الشائع رقم 2: العمل مع النماذج غير المحسّنة

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

من المهم ضبط المقياس بشكل صحيح. في بعض الأحيان ، لا يمكن تعيين هذا بشكل صحيح من برنامج النمذجة ثلاثية الأبعاد لديك بسبب الوحدات المختلفة التي تستخدمها هذه التطبيقات. لتصحيح كل شيء ، قم بتعيين عامل المقياس في إعدادات استيراد النماذج (اترك 0.01 لـ 3dsMax و Modo ، قم بتعيين 1.0 لـ Maya) ، ولاحظ أنك ستحتاج أحيانًا إلى إعادة استيراد الكائنات بعد تغيير إعداد المقياس. يجب أن تضمن هذه الإعدادات أنه يمكنك استخدام المقياس الأساسي فقط 1 ، 1 ، 1 في المشاهد الخاصة بك للحصول على سلوك ثابت وعدم وجود مشاكل فيزيائية. من المرجح أيضًا أن تعمل الدُفعات الديناميكية بشكل صحيح. يجب أيضًا تطبيق هذه القاعدة على كل كائن فرعي في النموذج ، وليس الكائن الرئيسي فقط. عندما تحتاج إلى تعديل أبعاد الكائن ، فافعل ذلك فيما يتعلق بالكائنات الأخرى في تطبيق النمذجة ثلاثية الأبعاد بدلاً من الوحدة. ومع ذلك ، يمكنك تجربة المقياس في Unity لاكتشاف القيم المناسبة ، ولكن بالنسبة للتطبيق النهائي وسير العمل المتسق ، من الجيد أن يكون كل شيء جاهزًا جيدًا قبل الاستيراد إلى Unity.

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

يجب أن تحمل جميع الأصول أسماء مناسبة تصف نوعها ووظائفها بسهولة. حافظ على هذا الاتساق في جميع مشاريعك.

خطأ الوحدة الشائع # 3: بناء بنية كود مترابطة

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

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

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

خطأ الوحدة الشائع رقم 4: إضاعة الأداء

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

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

حلقات التحديث

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

التّجسيدات

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

استدعاء

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

رسم المكالمات

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

مشاكل تجاوز الحد

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

شادر

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

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

خطأ الوحدة الشائع # 5: تجاهل مشاكل جمع القمامة

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

• تجنب التخصيصات غير الضرورية في حلقات التحديث.
• استخدم الهياكل لحاويات الخصائص البسيطة ، حيث إنها غير مخصصة في الكومة.
• حاول تخصيص المصفوفات أو القوائم أو مجموعات الكائنات الأخرى مسبقًا ، بدلاً من إنشائها داخل حلقات التحديث.
• تجنب استخدام الأشياء أحادية المشكلة (مثل تعبيرات LINQ أو حلقات foreach ، على سبيل المثال) لأن Unity تستخدم إصدارًا قديمًا غير محسَّن بشكل مثالي من Mono (في وقت كتابته ، تم تعديل الإصدار 2.6 ، مع الترقية على خريطة الطريق).
• سلاسل التخزين المؤقت في Awake() أو في الأحداث.
• إذا كان تحديث خاصية السلسلة في حلقة التحديث ضروريًا ، فاستخدم كائن StringBuilder بدلاً من السلسلة.
• استخدم ملف التعريف لتحديد المشاكل المحتملة.

خطأ الوحدة الشائع رقم 6: تحسين استخدام الذاكرة والمساحة أخيرًا

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

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

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

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

خطأ الوحدة الشائع رقم 7: أخطاء فيزيائية شائعة

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

لتعديل موضع الكائن مع Rigidbody عليه ، قم دائمًا بتعيين Rigidbody.position عندما لا يتبع الموضع الجديد الموضع السابق ، أو Rigidbody.MovePosition عندما تكون حركة مستمرة ، والتي تأخذ أيضًا الاستيفاء في الاعتبار. عند تعديله ، قم بتطبيق العمليات دائمًا في FixedUpdate ، وليس في وظائف Update . سيضمن سلوكيات فيزيائية متسقة.

إذا أمكن ، استخدم المصادمات البدائية على كائنات gameObject ، مثل الكرة أو الصندوق أو الأسطوانة ، وليس مصادمات الشبكة. يمكنك تكوين المصادم النهائي الخاص بك من أكثر من واحد من هذه المصادمات. يمكن أن تكون الفيزياء بمثابة عنق زجاجة في أداء تطبيقك بسبب حمل وحدة المعالجة المركزية (CPU) الخاصة به ، كما أن حساب الاصطدامات بين المصادمات البدائية يكون أسرع بكثير. يمكنك أيضًا ضبط إعداد Fixed Timestep في Time manager لتقليل تكرار تحديثات الفيزياء الثابتة عندما لا تكون دقة التفاعل الفيزيائي ضرورية.

خطأ الوحدة الشائع رقم 8: اختبار جميع الوظائف يدويًا

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

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

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

خطأ الوحدة الشائع رقم 9: التفكير في إضافات متجر أصول الوحدة ستحل جميع مشاكلك

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

من ناحية أخرى ، بالنسبة للوظائف التي قد تستغرق وقتًا طويلاً لتنفيذها ، فمن المفيد دائمًا استخدام المنتجات التي تم اختبارها جيدًا من Unity Asset Store ، والتي يمكن أن توفر لك قدرًا كبيرًا من وقت التطوير. ومع ذلك ، اختر بعناية ، واستخدم تلك التي أثبتت جدواها والتي لن تجلب الكثير من الأخطاء التي لا يمكن السيطرة عليها والغريبة لمنتجك النهائي. تعتبر التقييمات الخمس نجوم مقياسًا جيدًا للبدء.

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

خطأ الوحدة الشائع رقم 10: عدم الحاجة إلى توسيع وظائف الوحدة الأساسية

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

خاتمة

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

مزيد من القراءة على مدونة Toptal Engineering:

• تطوير الذكاء الاصطناعي للوحدة: برنامج تعليمي لآلة الحالة المحدودة