Project Hospital هي لعبة حول إدارة مبنى المستشفى بجميع الجوانب القياسية لهذا النوع: المشاهد الديناميكية التي أنشأها اللاعب ، والعديد من الشخصيات والكائنات النشطة ، التي نشرها نظام واجهة المستخدم. لجعل اللعبة تعمل على أجهزة مختلفة ، اضطررنا إلى بذل الكثير من الجهود ، وكان هذا مثالاً رائعًا على "الموت الناجم عن آلاف الجروح" الشائنة - العديد من الخطوات الصغيرة التي تحل مجموعة من المشاكل المحددة للغاية والكثير من الوقت الذي قضيته في التوصيف.
مستوى الأداء: ما أردنا تحقيقه
في مرحلة مبكرة من التطوير ، قررنا المعايير الرئيسية: الحد الأقصى لحجم المشاهد ، ومستوى الأداء ومتطلبات النظام.
لقد حددنا لأنفسنا مهمة تقديم الدعم لما لا يقل عن مائة حرف نشط وكامل الرسوم المتحركة على شاشة واحدة ، وثلاثمائة حرف نشط في المجموع ، وخرائط تجانبية تبلغ مساحتها حوالي 100 × 100 وما يصل إلى أربعة طوابق في المبنى.
كنا على قناعة راسخة بأن اللعبة يجب أن تعمل بدقة 1080 بكسل بمعدل إطارات مناسب حتى على بطاقات الرسومات المدمجة ، وهذا الهدف في حد ذاته لم يكن من الصعب للغاية تحقيقه: العامل المحدد هو وحدة المعالجة المركزية ، لا سيما مع زيادة حجم المستشفى. تبدأ بطاقات الرسومات المدمجة الحديثة في مواجهة المشكلات فقط بدقة تبلغ حوالي 2560 × 1440.
لتبسيط دعم التعديلات ، تم فتح معظم البيانات ، أي أنه كان علينا التضحية بالأداء الذي تم تحقيقه عن طريق حزم الملفات ، لكن هذا لم يكن له تأثير قوي بشكل خاص ، باستثناء وقت التنزيل الأطول قليلاً.
الرسومات
Project Hospital هي لعبة ثنائية الأبعاد متساوية القياس "كلاسيكية" ، لذلك يمكنك أن تفهم أن كل شيء يتم إرجاعه إلى الأمام - في الوحدة يتم ذلك عن طريق تعيين القيم المناسبة على طول المحور Z (أو المسافة إلى الكاميرا) لكائنات الرسوم الفردية. إذا أمكن ، يتم ترتيب الكائنات التي لا تتفاعل مع بعضها البعض في طبقات ، على سبيل المثال ، تكون الأرضيات مستقلة عن الكائنات والحروف.
يتم إنشاء جميع الأشكال الهندسية في مشهد تم عرضه بطريقة غير متساوية بشكل ديناميكي في C # ، لذلك فإن أحد أهم الجوانب لأداء الرسومات هو تكرار إعادة إنشاء الأشكال الهندسية. الجانب الثاني هو عدد مكالمات السحب.
يوجه المكالمات
عدد الكائنات الفردية المرسومة في إطار واحد ، بغض النظر عن بساطتها ، هو القيد الرئيسي ، خاصة على الأجهزة الرديئة (بالإضافة إلى ذلك ، يضيف محرك الوحدة نفسه استهلاكًا مفرطًا للموارد). يتمثل الحل الواضح في تجميع (مجموعة) أكبر عدد ممكن من الكائنات الرسومية في مكالمة سحب واحدة. بحيث يمكنك الحصول على بعض النتائج المثيرة للاهتمام ، على سبيل المثال ، كائنات المجموعة الموجودة على نفس المسافة من الكاميرا بحيث تظهر بقية الرسومات بشكل صحيح خلفها أو أمامها.
فيما يلي بعض الأرقام: على مربع 96 × 96 ، يمكنك نظريًا وضع 9216 كائنًا ، الأمر الذي يتطلب 9216 مكالمات سحب. بعد الخلط ، ينخفض هذا الرقم إلى 192.
ومع ذلك ، في الحياة الواقعية ، كل شيء أكثر تعقيدًا بعض الشيء ، لأنه لا يمكنك سوى تجميع الكائنات بنفس النسيج ، مما يجعل النتائج أقل قليلاً ، لكن النظام لا يزال يعمل جيدًا.
تتم معظم الدُفعات يدويًا من أجل التحكم في النتائج. بالإضافة إلى ذلك ، في الحالات القصوى ، نستخدم أيضًا التجميع الديناميكي للوحدة ، لكن هذا سيف ذو حدين - إنه يساعد بالفعل في تقليل عدد مكالمات السحب ، ولكنه يؤدي إلى إهدار الموارد بشكل غير ضروري في كل إطار ، وفي بعض الحالات قد لا يمكن التنبؤ بها. على سبيل المثال ، يمكن تقديم عثاريتين متراكبتين على نفس المسافة من الكاميرا في إطارات مختلفة بترتيب مختلف ، مما يتسبب في حدوث وميض لا يظهر عند التجميع يدويًا.
الشاهقة
يمكن للاعبين بناء مبانٍ متعددة الطوابق ، وهذا يزيد من التعقيد ، ولكن من المدهش أن يساعد في الأداء. يجب تقديم الأحرف المتحركة فقط في الطابق النشط وفي الشارع ، ويمكن إخفاء كل شيء في الطوابق الأخرى من المستشفى.
تظليل
يستخدم Project Hospital تظليل مكتوب ذاتيًا بسيطًا نسبيًا مع حيل صغيرة ، مثل تبديل الألوان. افترض أن تظليل الأحرف يمكنه استبدال ما يصل إلى خمسة ألوان (حسب الظروف في رمز التظليل) ، وبالتالي مكلف للغاية ، ولكن هذا لا يبدو أنه يسبب مشاكل ، لأن الشخصيات نادراً ما تشغل مساحة كبيرة من الشاشة. برر التظليل الجهد المبذول فيه ، لأن القدرة على استخدام عدد لا حصر له من ألوان الملابس يمكن أن تزيد بدرجة كبيرة من تباين الشخصيات والبيئة.
بالإضافة إلى ذلك ، تعلمنا بسرعة كافية لتجنب تحديد معلمات تظليل واستخدمنا بدلاً من ذلك ألوان قمة الرأس كلما أمكن ذلك.
جودة الملمس
حقيقة مثيرة للاهتمام - في مشروع المستشفى ، لا نستخدم أي ضغط على الملمس: تتم الرسومات بأسلوب متجه ، ويبدو الضغط في بعض القوام سيئًا للغاية.
لحفظ ذاكرة وحدة المعالجة المركزية (CPU) على الأنظمة التي يقل حجمها عن 1 غيغابايت ، نقوم تلقائيًا بتقليل حجم القوام داخل اللعبة إلى درجة وضوح منخفضة (باستثناء مواد واجهة المستخدم) - يمكن فهم ذلك من خلال رؤية المعلمة "جودة الملمس: منخفضة" في الخيارات. القوام واجهة المستخدم الاحتفاظ القرار الأصلي.
تحسين أداء وحدة المعالجة المركزية - multithreading
على الرغم من أن منطق البرمجة النصية للوحدة هو في الأساس واحد الخيوط ، لدينا دائما القدرة على تشغيل مؤشرات ترابط متعددة مباشرة في C #. ربما لا يكون هذا الأسلوب مناسبًا لمنطق اللعبة ، ولكن غالبًا ما تكون هناك مهام مهمة للوقت يمكن تنفيذها في سلاسل عمليات منفصلة عن طريق تنظيم نظام مهام. في حالتنا ، تم استخدام المواضيع لوظائف اثنين:
1. قد تستغرق مهمة العثور على المسار ، خاصة على الخرائط الكبيرة بترتيب مربك ، ما يصل إلى مئات الميلي ثانية ، لذلك كان هذا هو المرشح الرئيسي للنقل من المسار الرئيسي. تأخذ المهام المتوازية في الاعتبار عدد مؤشرات ترابط الأجهزة الخاصة بالجهاز.
2. يمكن أيضًا تحديث بطاقات الإضاءة في مسار منفصل ، ولكن في طابق واحد فقط في كل مرة - وهذا ليس نظامًا حرجًا ، وتخرج المصابيح الأوتوماتيكية في الغرف بسرعة تجعل التحديث النادر كافيًا.
الرسوم المتحركة
في بداية التطوير تقريبًا ، قررنا استخدام نظام الرسوم المتحركة ثنائي الأبعاد. بعد دراسة العديد من برامج الرسوم المتحركة الحديثة ، قررنا في النهاية تعديل نظام بسيط أنشأته منذ عدة سنوات (بشكل أساسي كمشروع هواية) ، لتلائم احتياجات مستشفى Project - فهو يشبه العمود الفقري المبسط مع الدعم المباشر لإنشاء أشكال شخصية. مثل Spine ، فإنه يستخدم وقت التشغيل C # ، والذي من الواضح أنه أغلى من الكود الأصلي ، لذلك أثناء عملية التطوير أجرينا بضع دورات تحسين. لحسن الحظ ، منصاتنا بسيطة للغاية ، فقط حوالي 20 عظمة للشخص الواحد.
حقيقة غريبة: كان التحسن الأكثر فائدة في تحسين الوصول إلى تحويل العظام الفردية هو الانتقال من بحث الخرائط إلى فهرسة بسيطة للصفائف.
بالإضافة إلى حقيقة أن الشخصيات ليست متحركة خارج الكاميرا ، هناك خدعة أخرى: الأحرف المخفية وراء نوافذ واجهة المستخدم الرئيسية لا تحتاج أيضًا إلى أن تكون متحركة. لسوء الحظ ، في الإصدار الأخير من اللعبة ، تحولنا إلى واجهة مستخدم شفافة ، لذلك لم نتمكن من استخدامها.
التخزين المؤقت
إذا أمكن ، فنحن نحاول إجراء الحسابات الأكثر تكلفة فقط مع التغييرات التي تؤثر على قيمها. أفضل مثال على ذلك هو الغرف والمصاعد: عندما يضع اللاعب المصعد أو يبني الجدران ، فإننا نقوم بتشغيل خوارزمية تعبئة توضح البلاط الذي تتوفر منه المصاعد والغرف. هذا يسرع البحث اللاحق عن المسارات ويمكن استخدامه لإظهار اللاعب الذي الغرف غير متوفرة حتى الآن.
تحديثات مبعثرة ومؤجلة
في بعض الحالات ، يكون من المنطقي إجراء تحديثات معينة جزئيًا فقط. فيما يلي بعض الأمثلة:
يمكن إجراء بعض التحديثات في كل إطار فقط لجزء من الأحرف ، على سبيل المثال ، يتم تحديث البرامج النصية لسلوك نصف المرضى فقط في إطارات فردية ، وللنصف الثاني - في إطارات متساوية (على الرغم من أن الرسوم المتحركة والحركات تتم بسلاسة).
في ظروف معينة ، خاصةً عندما تكون الأحرف في وضع الاستعداد ، ولكن تستدعي أجزاء باهظة من الكود (على سبيل المثال ، الموظفون الذين يبحثون عن ما يجب ملؤه ويبحثون عن معدات غير مشغولة) ، يتم تنفيذ العمليات على فترات زمنية معينة ، على سبيل المثال ، مرة واحدة في الثانية.
أحد أكثر التحديات شيوعًا وفي الوقت نفسه هو التحقق من الاختبارات المتاحة لكل مريض. في الوقت نفسه ، هناك حاجة إلى تقييم العديد من العوامل - على سبيل المثال ، أي من موظفي القسم مشغول حاليًا وما هي المعدات المحجوزة. بالإضافة إلى ذلك ، هذه المعلومات ليست شائعة لجميع المرضى لأنها تتأثر ، على سبيل المثال ، من قبل الطبيب المعين لهم وقدرتهم على الكلام. من الضروري التحقق من عشرات الأنواع المتاحة من التحليلات ، لذلك ، في إطار واحد ، يتم إجراء التحديث فقط للبعض ، ويستمر في الإطار التالي.
استنتاج
ثبت أن تحسين مدير اللعبة مع العديد من الأجزاء التفاعلية عملية طويلة. كان عليّ العمل بانتظام مع مُنشئ Unity وإصلاح المشكلات الأكثر وضوحًا ، فقد أصبح هذا جزءًا لا يتجزأ من عملية التطوير.
بالطبع ، هناك دائمًا مجال للتحسين ، لكننا سعداء جدًا بالنتائج. تتواءم اللعبة مع مهامنا ، ويقوم اللاعبون باستمرار بإنشاء تعديلات لها ، وهو ما يتجاوز الحد الأصلي لعدد الأحرف بشكل ملحوظ.
تجدر الإشارة إلى أنه حتى بالمقارنة مع بعض ألعاب AAA التي عملت عليها ، التقيت في مستشفى المشروع بأكثر منطقية تعقيدًا للعبة في ممارستي ، حيث كانت العديد من المشكلات متعلقة بهذا المشروع. ومع ذلك ، ما زلت أوصي بترك وقت كافٍ في أي مشروع للتحسين وفقًا لتعقيد اللعبة.