فكر مرتين قبل استخدام محركات اللعبة

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

دعنا السبب بحكمة

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

مستوى المهارة

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

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

هناك حالة وسيطة بين الافتقار التام للمهارات والمستوى المهني. تقع بشكل أساسي في بلد لغات البرمجة النصية: Scratch و Game Maker و Pygame و Unreal Blueprints و LOVE2D وما إلى ذلك. جميعها مخصصة لأولئك الذين يرغبون في الحصول على مستوى معين من المعرفة التقنية من أجل تحقيق النتائج بسرعة.

إذا كنت مبرمجًا ذو خبرة / محترفًا قادرًا على إتقان برنامج الجهة الخارجية بثقة ، فيمكنك استخدام هذه المهارة وتحديد مدى الحد الأدنى / الحد الأقصى لنهجك (سواء كان هذا الحد الأدنى من SDL أو محرك Unreal مجهز بالكامل).

أهداف التنمية

ما هي أهدافك في هذا المشروع؟ يجب أن تزيد التقنيات من إنجازها:

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

فائدة

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

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

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

ماذا يعطونك حقًا؟

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

نعم ، بالطبع ، تحصل على محرر رائع وأدوات ذات مستوى احترافي ومحرك وصل إلى الآلاف من المطورين ، لكنك تدفع مقابل ذلك من خلال العديد من الجوانب الأخرى:

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

تحتاج إلى طرح السؤال: "ما الذي أحتاجه حقًا؟" تخلص من كل شيء لا لزوم له. كل نظام غير ضروري يضيع الموارد والوقت.

ما هو المطلوب لمشروعك؟

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

هناك ألعاب ناجحة من شأنها أن تخدم سوء خدمة أي من المحركات المتاحة:

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

مستقبل صناعة (ولنا)

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

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

لماذا تشتري المحركات؟

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

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

هل الميزات الجديدة تجعل من الأسهل إكمال اللعبة؟ هل حقا تضيف قيمة إلى المنتج النهائي؟

محاربة المركزية

في كل مرة تنتقل فيها إحدى الاستوديوهات من محركها الخاص إلى Unreal أو Unity ، تكتسب شركات Epic و Unity قوة أكبر في صناعة الألعاب. في البداية ، قد تبدو هذه المركزية مربحة (بعد كل شيء ، لديهم 500 مهندس يعملون على المحرك ، ممتاز!) ، ولكن في غضون عقدين من الزمن سوف يصبح هذا مشكلة حقيقية. تتبادر Google إلى الذهن: لقد استحوذت هذه الشركة على الغالبية العظمى من الوظائف التي يستخدمها الأشخاص على الإنترنت ، وتكلفهم خسارة جزء كبير من الخصوصية.

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

قد يكون المستقبل مفتوح المصدر

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

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

• اتخذت Microsoft خطوات ضخمة في هذا الاتجاه. حتى لو تغيروا ، فأنا متأكد من أن الآخرين يمكنهم ذلك.
• تحتوي اتفاقية الترخيص Unreal على بند يسمح لك بالاعتماد على الكود الخاص بها عند العمل على محركها الخاص (المجاني أو المجاني). أعتقد أن هذا تقدم كبير.
• بفضل الانفتاح الكامل والوصول الحر ، يكتسب Godot شعبية كبيرة ، وآمل أنه إذا أعطى ما يكفي من الوقت والدعم ، فسوف يصبح منافسًا للوحدة (وفي النهاية غير واقعي).
• أصدرت id id (في عهد جون كارماك) شفرة المصدر الكاملة من Doom to Doom 3 . كان لدى كارماك أسباب كثيرة لدفع مثل هذا القرار. الأكثر إقناعا لهذه الشركات هو أنها لا تضر المبيعات. يمكن أن يكون نموذج تجريبي يستخدمه Doom - المطور يعطي المحرك ويبيع البيانات - استراتيجية فعالة اليوم. إذا كان عملك قلقًا من قيام المنافسين "بسرقة" تقنيتك ، فيمكنك نشر الكود الخاص بك بعد إصدار لعبة أحدث بعد ذلك (كما فعلت المعرف). بعد رحيل Carmack ، يبدو أن id قد فقد الاهتمام بنشر الكود.

جودة البرمجيات

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

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

هل سرعة وجودة وأناقة تقنيتك مهمة بالنسبة لك؟ كثير من الناس سعداء بالإجابة السلبية ، لكن البعض يريد إنشاء برامج بطريقة أكثر "نظافة".

ما هي البدائل؟

بدلاً من استخدام المحرك ، فأنت تكتب لعبة فقط.

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

استخدام المكتبات

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

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

• الرسومات: SDL ، SFML ، الغول
• Physics: Bullet، PhysX (التي أصبحت مؤخرًا مفتوحة المصدر - انتصارًا هائلاً!)
• الصوت: SDL ، SFML

هذه ليست سوى جزء صغير جدا من المكتبات الموجودة.

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

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

في الختام

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

في النهاية ، مهمتك الرئيسية هي إكمال المشروع. يجب بذل كل جهد ممكن لإيجاد أقصر طريق لحل هذه المشكلة. قد يكون غير متوقع بالنسبة لك!