لقد عملنا مع Unity لفترة طويلة ولم نتمكن من المساعدة إلا بدعوة رفاقهم إلى محادثات Pixonic DevGAMM ، التي كانت في سبتمبر. أخبر المهندس الميداني فالنتين سيمونوف كيفية تخطيط بنية الألعاب مع مراعاة مزايا التقنيات الجديدة. تعمل الوحدة عليها منذ عدة سنوات لتحقيق مستوى أداء لم يكن ممكنًا تحقيقه سابقًا. يمكنك الاستماع إلى العرض التقديمي على YouTube ، وقراءة النص مع الشرائح مباشرة أسفل المقطع.
ماذا لو قلت أنه يمكنك زيادة إنتاجية لعبتك 10 مرات؟ في الواقع ، هذا ليس صحيحًا تمامًا ، ولكن هناك بعض الحقيقة في كل نكتة. أريد أن أتحدث عن ما نعمل عليه الآن ، وما سيكون مستقبل الوحدة وما يمكنك استخدامه الآن.
Unity يجعل ألعاب مختلفة تماما. فيما يلي بعض الأمثلة التي ألعبها بنفسي. يستخدمون ميزات مختلفة ويحتاجون إلى أداء مختلف ، ونهج مختلف للتطوير.
ونحن نعمل على مشروع نسميه الأداء بشكل افتراضي. هذه بعض الميزات الخاصة التي ، إذا تم استخدامها بشكل صحيح ، ستحقق تعزيزًا كبيرًا في الأداء. في بعض المهام ، قمنا بقياس 10x وحتى x11. خاصة في مشاكل محاكاة عدد كبير من الأشياء التي تتفاعل مع بعضها البعض.
ولكن عندما نتحدث عن Perfomance بشكل افتراضي ، فإننا نعني أنه سيتعين عليك تغيير نهج التنمية ، وتغيير نهج هندسة الألعاب بشكل كبير. وفي الواقع ، لا يحتاج الجميع إلى ذلك.
سؤال شائع: "ماذا تفعل في ECS؟ هل تقوم بإزالة كل GameObject ، وإزالة جميع التحويلات ، والتسلسل الهرمي والمكونات؟ " لا ، نتركها جميعًا. يمكنك العمل مع Unity تمامًا كما هو الآن ، ولكن إذا كنت تريد المزيد من الأداء ، فأنت بحاجة إلى معرفة التقنيات التي أريد التحدث عنها باختصار.
وأريد أن أشير إلى تقنية أخرى تسمى Scriptable Render Pipelines (SRP) - تتيح لك كتابة خط أنابيب للعبة بشكل أكثر كفاءة. ربما رأيت العرض التوضيحي الذي عرضناه في أحد مواقع Unite. هنا على جهاز الكمبيوتر في الوقت الحقيقي ، يتم محاكاة عدد كبير من الوحدات ، وهو ما يقرب من 60 ألف (يصل إلى 100 ألف ويبدأ في التباطؤ قليلاً):
والميزات الجديدة التي أريد التحدث عنها هي: نظام مكونات الكيان (ECS) ، ونظام الوظائف C # ، والمكبّر الفائق الجديد Burst supercompiler وخطوط أنابيب التقديم القابلة للبرمجة (SRP).
أكرر: الأمر متروك لك لاختيار ما إذا كنت تريد المضي قدمًا معنا ، أو تعلم تقنيات جديدة ، أو أنك على استعداد لتطوير ألعاب تحقق أرباحًا جيدة ويتم صنعها ببساطة.
من أجل فهم ما نحاول حله ، من المهم فهم حالة الحديد في 2018.
لاحظ كيف ينمو أداء وعدد نوى وحدة المعالجة المركزية. من نقطة واحدة ، انخفض أداء مؤشر ترابط واحد. أي أن لدينا الآن العديد من النوى ، لكن إنتاجيتها لا تنمو بسرعة كبيرة. لذلك ، نود استخدام قوة جميع النوى.
يوجد في هاتفي 8 نوى: 4 قوي و 4 ضعيف. ويمكن للهاتف الحديث أن يعمل بنفس سرعة الكمبيوتر الحديث (ولكن ليس لفترة طويلة جدًا بسبب ارتفاع درجة الحرارة). تحتاج أيضًا إلى فهم أن زيادة الأداء لا تستخدم فقط جميع النوى ، ولكن أيضًا تحسين الأداء أحادي النواة.
والصورة الأخيرة ، التي نعطيها دائمًا كمثال على كيفية رفع أداء العملية وعدم زيادة سرعة الوصول إلى الذاكرة كثيرًا:
يمكن ملاحظة أن الوصول إلى الذاكرة الآن بطيء للغاية. يفعل مصنعو المعالجات الكثير لتسوية هذا الاختلاف - إضافة ذاكرة التخزين المؤقت ، تشارك وحدات المعالجة المركزية في حساب المضاربة ، في محاولة للتنبؤ بأي كود سيتم تنفيذه بعد ذلك. وإذا كنت لا تفكر في ذلك عندما تصنع لعبتك (أو عندما نصنع محركًا لك) ، فلا يمكننا الاستفادة الكاملة من المعالجات الحديثة.
من المحتمل أن يقضي الكثير منكم ساعات في النظر إلى صورة مماثلة في Unity:
هنا يمكنك أن ترى أن هناك مؤشرات متعددة ، لكن النوى والخيوط المتبقية ليست في الغالب مشغولة. شيء ما يجري ، ولكن أود أن أشغلهم بالكامل.
الآن لدينا تقديم ، هذا مربع أسود. أمامك خيار: للأمام أو المؤجل ، بالإضافة إلى إعدادات متنوعة للمواد والتظليل ومخازن الأوامر المؤقتة وما إلى ذلك. يمكنك إنشاء صورة جميلة ، ولكن من الصعب للغاية تنفيذ العديد من الخوارزميات.
وكلنا نعرف عن العمارة في الوحدة: المكونات ، GameObjects ، التسلسل الهرمي للتحويلات ، كل التعليمات البرمجية ، جميع البيانات في MonoBehaviour وكل مكون يعالج بياناته.
ولكن هناك مشاكل مع الوضع الحالي للأشياء. عاجلاً أم آجلاً ، تصادف هذا وتفهم كيف تحتاج ولا تحتاج إلى القيام بذلك. يحتوي التسلسل الهرمي للكائنات نفسها على حمل عام معين ، ولا يجب أن تكون بعض الكيانات GameObjects على الإطلاق. وإذا كان لديك عدد كبير من المكونات والتحديثات منها ، فسيصبح كل شيء أبطأ بكثير. لقد كتبت
هذه المقالة ذات مرة ، والتي لا تزال ذات صلة إذا كنت تريد معرفة كيفية عدم القيام بذلك.
والشيء الأكثر أهمية في سياق المعالجات هو أن جميع المكونات وجميع البيانات متناثرة في الذاكرة ، مما يكسر استخدام ذاكرة التخزين المؤقت للمعالج.
الآن أريد أن أتصفح الميزات الجديدة بسرعة.
لن أركز كثيرًا على ماهية ECS وكيف تعمل. النقطة هي أن لدينا Entity ، وهو مجرد معرف كيانات معينة في اللعبة - فهم يخزنون البيانات في شكل مكونات ، أي البيانات فقط ، لا يوجد رمز. وأنظمة معالجة الكيان بمكونات معينة وتغيير هذه البيانات بطريقة أو بأخرى.
لماذا نقوم بعمل ECS وكيف سيكون أفضل من المنافسين؟ هناك بضع نقاط. أولاً ، ليس بشكل رسمي تمامًا ، لكننا نعتقد أننا سنقوم بتشغيل المحرك الآن. من الواضح أننا لا نريد التخلص من GameObjects ، المكونات الحالية للوحدة ، ورمي كل شيء تمامًا وتثبيت ECS. لكننا نريد التحرك نحو محرك أفضل.
نحن نعتمد على الأداء العالي. منذ وقت ليس ببعيد ، انضم إلينا مايك أكتون (إذا كنت في تطوير C ++ ، فأنت تعلم أنه واحد من المبشرين في البرمجة الموجهة للبيانات). ونريد أن نجعل النظام بأكمله يعمل بأسرع وقت ممكن - أسرع من C ++.
نفكر أيضًا في كيفية دمج الأشياء المختلفة أصلاً في ECS. منذ بعض الوقت ، أعلنا أننا كنا ننشئ شبكة جديدة وتستند أيضًا إلى ECS - سيكون من الممكن إنشاء لعبة متعددة اللاعبين على ECS ومشاركة الرمز بين العميل والخادم.
العمل على أدوات التصحيح في الوحدة. على سبيل المثال بينما توجد ECS ، كما كانت ، بشكل منفصل عن GameObjects والمكونات ، وهذا غير مريح للغاية. نريد تبسيط الأشياء.
الآن هناك DebugView يشبه هذا:
هنا يمكنك معرفة نوع الكيان لديك ، والأنظمة التي تستغرق وقتًا طويلاً في المعالجة ، والأنظمة التي تعمل مع المكونات ولكل مكون يمكنك رؤيته في المفتش ، وما هي البيانات الموجودة في كل كيان في المكونات (ألاحظ أن واجهة برمجة التطبيقات غالبًا ما تتغير والعديد من قد تكون البرامج التعليمية قديمة بالفعل).
أيضًا ، إذا سمعت عن تطويرنا الجديد Unity for Small Things (هذا وقت تشغيل صغير جدًا يسمح لك بإنشاء ألعاب للرسائل الفورية) - كل شيء مبني أيضًا على ECS هناك.
في الآونة الأخيرة ، تعد طفرة التطوير والانتقال إلى ECS تقنية شائعة جدًا ويحتاج الجميع إلى معرفتها.
لدينا مؤتمر للمبرمجين ، لذلك من الصعب الاستغناء عن شريحة التعليمات البرمجية. هناك الكثير من التعليمات البرمجية هناك ، لذلك من الصعب سحب نوع ما من القطعة الواضحة لتوضيح شيء ما.
في الواقع ، لقد أخذت نظامًا واحدًا من المثال الذي يعمل مع نظام C # Job System (المزيد عن ذلك لاحقًا) ، ونحن نفعل الكثير لتقليل كمية التعليمات البرمجية ، وإضافة shugar بناء الجملة.
هناك نظام يعمل مع مكونات RotationData ويحتاج أيضًا إلى تحويلات GameObject ، والتي يتم تمثيلها بواسطة TransformAccessArray خاص. وكل تحديث للنظام الذي نقوم بإنشائه Job ، وتشغيل هذه المهمة ، وتحديثه في مكان ما ، يمكن تقسيمه إلى عدة مجموعات وتنفيذه على سلاسل رسائل مختلفة.
كيف تستخدم في المشروع؟ تمامًا كما هو الحال في تطبيقات ECS الأخرى ، يجب أن تفهم أنه يجب عليك التفكير بطريقة مختلفة تمامًا (على عكس GameObjects و Transforms). وتعود على هذه الفكرة. من الواضح أنك بحاجة إلى البدء من بداية المشروع ، لأنني غالبًا ما أتلقى أسئلة مثل "صنعنا اللعبة وأريد التبديل إلى ECS - كيف؟". في اللعبة النهائية ، من الصعب جدًا القيام بذلك.
نحن بحاجة إلى التفكير من خلال التفاعل مع الوحدة ، حيث تعيش ECS بشكل منفصل في عالمها الصغير. نعطي بعض الفرص للتفاعل مع GameObjects و Transforms ، ولكن الفيزياء ، والعرض ، وما إلى ذلك ، هنا يصبح الأمر أكثر تعقيدًا. وبينما تحتاج إلى تحمل حقيقة أن الكثير من الواجهة المألوفة لن تكون متاحة ، ولكننا نعمل أيضًا على ذلك.
وعلى الفور تحتاج إلى التفكير في حقيقة أنك ستكتب أنظمة في نظام العمل ، وهو أكثر كفاءة.
بضع كلمات حول نظام العمل. نريد أن نجعل طريقة بسيطة للغاية لكتابة كود متعدد الخيوط. في الوقت نفسه ، اكتب في C # ، وتحقق من كل شيء من أجلك ، ولا تمنح الفرصة لارتكاب الأخطاء أو إظهار السبب ، وأين وكيف ارتكبت هذه الأخطاء. نحن نقيد ميزات اللغة التي يمكنك استخدامها في الوظائف ونطلق على هذه المجموعة الفرعية C # High Performance C #. ليس لديك أي مراجع في رمز وظيفتك ، ولا توجد خطوط ، ويجب نسخ جميع البيانات - لا يمكنك استخدام عدد كبير من ميزات اللغة ، مما يجعل من الصعب جدًا تصوير خيوط متعددة في ساقك.
نقدم أيضًا مجموعات سريعة جدًا والتكامل مع ECS. يسمح هيكل ECS ونظام الوظائف بتنفيذ التعليمات البرمجية بسرعة كبيرة.
في الوقت نفسه ، لا نعطيك الفرصة لاستخدام هذه التقنيات فحسب - بل نعمل مع هذه الأنظمة بأنفسنا وننشئ واجهات برمجة تطبيقات جديدة حتى يمكن استخدامها في الوظائف.
لقد صنعنا Async Raycasts للفيزياء ، والتي يمكنك من خلالها القول "أريد 600 rakecasts ، افعلها لي يومًا ما ، من فضلك". نحن نعمل على التأكد من أنه باستخدام هذه التقنيات ، من الممكن توسيع الأنظمة الحالية ، على سبيل المثال ، الرسوم المتحركة من خلال Playbles API. ونفكر في إنشاء أنظمة جديدة في Unity لن يتم إغلاقها في C ++ ، والتي سيكون رمزها في C # ومتاحًا لك.
إذا أخذت كود الوظيفة ، فهو بسيط جدًا. الوظيفة هي بنية يوجد فيها أسلوب التنفيذ ، حيث نقوم ببعض العمل عن طريق تشغيل هذه المهمة. وفقًا لذلك ، سوف يفهم برنامج الجدولة الداخلية يومًا ما المكان الأفضل لتشغيله ، وسيحل جميع التبعيات. هنا نحصل على JobHandle ، والتي يمكننا استخدامها كتبعية لبعض الوظائف الأخرى.
كيف تستخدم في المشروع؟ من الجيد أن تستخدم وظائف من البداية ، ولكن هذا ليس ضروريًا هنا. إذا كان لديك نوع من نظام الأداء الحرج ، على سبيل المثال ، المحاكاة ، أو تحديد المسار ، أو الشبكات أو أي شيء آخر - يمكنك معرفة كيفية تحسينه باستخدام هذه الأداة.
ولكن لهذا تحتاج إلى اتخاذ بعض الخطوات الكبيرة ، وفهم كيفية تخزين البيانات بشكل صحيح. في الواقع ، تسمح لنا ECS بتخزين البيانات بشكل صحيح ، لأننا نفصل البيانات عن الكود ويخزن تطبيقنا لـ ECS بيانات المكونات بشكل خطي في الذاكرة ، ومن خلال تشغيل هذه المكونات بواسطة بعض النظام ، فإنك تستخدم جميع إمكانات المعالج ، ويتم تخزين كل شيء في ذاكرة التخزين المؤقت و الخ. نحن نحاول القيام بذلك بسرعة كبيرة.
ثم تقوم بتقسيم هذا العمل إلى مهام متوازية ، وكتابة رمز المهمة وتشغيله. و (على الأرجح) كل شيء يناسبك. بالطبع ، تحتاج إلى الاختبار ، والأهم من ذلك ، الاختبار على النظام الأساسي المستهدف ، اعتمادًا على عدد النوى ، وما إلى ذلك. لكن استخدام نظام العمل و ECS ، كما قلت ، يؤثر أيضًا بشكل كبير على كيفية تخطيط بنية اللعبة الخاصة بك.
ثم كل شيء أبسط بكثير. Burst Compiler هو تقنيتنا الفريدة ، وهو مترجم خاص للشبكة الفرعية C # (عالية الأداء C #) في رمز الجهاز الخاص بالنظام الأساسي الحالي ، والذي ستنشره في مشروعك.
قام الرجال ببعض السحر الذي ربما لا يفهمه أحد غيرهم ، لكن هذا الشيء يسرع رمز الوظيفة 10 مرات ، وهو أمر رائع للغاية. والشيء الأكثر روعة هو أنه لا يتطلب أي إجراء منك - إذا كان لديك رمز الوظيفة ، فأنت ببساطة تضيف سمة [BurstCompile] ، وتقوم Burst بتجميع التعليمات البرمجية الخاصة بك ، وتحصل على أداء "مجاني". هذه هي تقنيتنا الجديدة ويمكنك تجربتها الآن.
وآخر شيء أود أن أذكره بإيجاز هو خط أنابيب العرض النصي (SRP) ، الذي نعمل عليه منذ فترة طويلة جدًا والذي تم تصميمه لمنحك الفرصة لكتابة عرض مخصص جدًا للعبة معينة.
Rip Pipeline هي بعض الخوارزميات التي تقوم بعملية Culling (أي الكائنات التي سيتم رسمها) ، والتقديم والمعالجة اللاحقة. الآن لدينا صندوق أسود ، للأمام أو مؤجل - إنها جيدة بالفعل ، نحصل على رسومات رائعة جدًا على الهواتف المحمولة ، على الكمبيوتر ، على وحدات التحكم. لكن لديهم الكثير من القيود ، لأنه لا يمكن توسيعها. باستخدام هذه الميزة الجديدة ، SRP ، يمكنك كتابة خط الأنابيب الخاص بك ، يمكنك إزالة شيء من هناك ، إضافة ، القيام بأي شيء تريده.
نحن نعمل حاليًا على مثالين لخطوط الأنابيب. واحد LWRP ، الذي نستهدفه على الهواتف المحمولة والأجهزة الضعيفة ، و HDRP ، الذي نستهدفه على أجهزة الكمبيوتر ، ووحدات التحكم ، والتي يعمل عليها أشخاص مشهورون جدًا في الصناعة. قبل ذلك ، صنعوا ألعاب AAA. بالتأكيد ، رأيت كتاب الموتى التجريبي.
استخدمنا هنا HDRP لإظهار القوة الكاملة لهذه التكنولوجيا.
لاستخدام هذا ، ستحتاج أيضًا إلى اتخاذ عدد كبير إلى حد ما من الخطوات البطولية ، لأنه مع خط الأنابيب الجديد ، لا يوجد شيء تقريبًا متوافق مع ما لدينا الآن. على سبيل المثال إذا قمت بالترقية باستخدام Legacy ، فنحن نقدم أداة تساعد على ترقية معظم المواد لك ، ولكنك ستحتاج إلى إعادة كتابة تظليلك ، أي على الأرجح ستبدو القوام مختلفة.
رائع جدًا إذا كان بإمكانك البدء من الصفر وتجربة خط الأنابيب الخاص بك. إذا كنت تريد القيام بشيء ما على خط الأنابيب الخاص بك ، فيرجى الاتصال بنا.
مرة أخرى ، افهم ما تحتاجه ، لأن لديك الآن المزيد من الفرص للقيام بشيء ما ، لكنك ستحتاج إلى أشخاص يمكنهم القيام بذلك أو ستحتاج إلى تعلم كيفية القيام بذلك.
في رأيي ، هذا أمر رائع ، لأن أولئك الذين يمضون معنا بهذه التقنيات الجديدة سيكونون أكثر طلبًا في السوق. هذا كل شيء ، آمل أن يذهب شخص ما وينظر إلى هذه التقنيات ، ويصنع ألعابًا جميلة ورائعة.
أسئلة من الجمهور
- متى يمكنني الحصول على ECS وتطويره؟- يمكنك استخدام ECS ، والمشكلة هي أنه في شكله الحالي هو أكثر استهدافًا للأشخاص الذين يركزون على الأداء ، أي نوع من مشروع AAA. ومهمة الوحدة هي جعل الأداء بشكل افتراضي متاحًا للجميع. لذلك ، نحتاج إلى نظام معين ، إضافة إلى ECS ، والتي ستسمح لنا باستخدام ECS بنفس السهولة التي نستخدم بها MonoBehavior الآن. على الرغم من عدم وجود مثل هذه الوظيفة الإضافية ، إلا أنني لا أعتقد أنه سيتم إصدار ECS في إصدار كامل. واتضح أننا صنعنا ميزة يستخدمها 1٪ من مستخدمينا. وهذه ليست مهمة الوحدة. أنا أعرف الأشخاص الذين يستخدمون ECS بالفعل في الإنتاج ، فقط ضع في اعتبارك أن هذه الميزة لا تزال عميقة في التطوير والآن نقوم بحل مسألة كيفية إنشاء الواجهة الأكثر ملاءمة. والمهمة التالية (لا تقل صعوبة) هي كيفية إنشاء نوع من واجهة برمجة التطبيقات التي تعيش على رأس ECS وتسمح لك باستخدامها بنفس سهولة MonoBehaviour. على سبيل المثال لا توجد إجابة على السؤال "متى بالضبط".
- ECS وبقية العناصر تركز على أخذ بعض GameObject الأساسي وجعل 150 ألف من استنساخها وإدارتها. ولكن ماذا لو كان لدي القليل من الأشياء ، ولكن لديهم كيانات مختلفة؟- يمكنك ، من حيث المبدأ ، ألا تفعل شيئًا ، فهذه التقنية لا تلزمك باستخدامها. إذا استطعت الحصول على تعزيز للأداء باستخدام هذه التقنيات ، فيجب عليك استخدامها. إذا لم يكن هذا مناسبًا لك ، فستستمر في استخدام Unity كما هو. لذلك ، من فضلك لا داعي للذعر.
- لدينا عميل على Unity ، خادم على .NET ، جربنا خادمًا على Unity ، لا شيء يأتي منه. ولكن في الوقت نفسه ، أريد استخدام التقنيات الموجودة في Unity على الخادم أيضًا.
- نحن نعمل على هذا ونفهم أنه لا يمكننا الآن توفير حل خادم فعال. اشترينا شركة Multiplay منذ بعض الوقت من أجل تقديم استضافة عالية الجودة لألعاب Unity. نحن نقوم بالربط الشبكي بشكل منفصل ونلتزم بشكل منفصل بتحسين المحرك بحيث يمكن التخلص من المزيد من الأشياء منه. وفقًا لذلك ، عندما يأتي كل شيء معًا ، سيكون لدينا حل متعدد اللاعبين ممتاز.
المزيد من المحادثات مع محادثات Pixonic DevGAMM