الفكرة الرئيسية

تمت كتابة الكثير من الكتب والمقالات والبرامج التعليمية حول تقييم التطبيقات والمحركات وأنظمة البرامج المختلفة.

إليكم ما تقدمه لنا ويكيبيديا القديمة حول هذا الموضوع:

اختبار الأداء ، المعيار (اختبار اللغة الإنجليزية) - مهمة التحكم اللازمة لتحديد خصائص الأداء المقارنة لنظام الكمبيوتر.

ولكن ماذا لو وصلنا إلى مسألة تقييم محركات اللعبة قليلاً من الجانب الآخر؟ جميع محركات اللعبة و SDKs لتطوير اللعبة (وليس فقط) غالبًا ما تعلن عن نفسها كأدوات بديهية للغاية وسهلة الهضم. نحن نبيع البساطة للتعلم ، يتم عرض منحنى رائع للتعلم والدخول ، أمثلة خفيفة ورائعة ، حيث تخلق شاشة واحدة من الكود ، عند إطلاقها ، نوعًا من السحر الرائع. لذلك ، استعدادًا لحدث Ludum Dare المرتقب ، قررت مرة أخرى أن أنظر حولي وأرى ما الذي تقدمه "الأسواق" لإيميلي البسيطة - شخص كان يعمل في تطوير اللعبة لمدة أسبوع دون عام. وهذا هو ، واحدة من مجموعات من الناس من CA التي تبيع هذه الصفات المدهشة للغاية من السهل هضم المحرك.

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

حول المعيار

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

"التكوين" أو عني

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

عن المهمة

تم اختيار مشروع اختبار لاستنساخ لعبة Doodle Jump. أنا متأكد من أن الكثير من الناس يعرفونها أو يلعبونها ، إنها لعبة رائعة جدًا ومتطورة جدًا لأجهزة Android.

ستكون اللائحة على النحو التالي:

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

تحلل اللعبة إلى مكونات

في شكل تجريدي للغاية وأعلى مستوى ، أرى نفسي مكونًا أساسيًا للعبة مثل هذا:

1. المشغل (العفريت ، سلوك القفز ، رد الفعل على الأزرار المضغوطة)
2. كائنات المستوى: المنصات ، الأعداء ، إلخ.
3. الفيزياء: سرعة قفزة اللاعب ، تسارع السقوط الحر ، يجب أن تعالج المنصات الاصطدامات فقط إذا قفزت من أعلى وتسمح للاعب بالمرور عبره إذا عبره من أسفل المنصة.
4. إنشاء المستوى الإجرائي: التهيئة والإضافة إلى المستوى (إلى الأماكن التعسفية ، ولكن مع بعض القواعد والقيود) على ذبابة منصات وأعداء جدد ، مما يخلق حالة لعبة جذابة للاعب
5. "كاميرا" تتبع المشغل وهو يتحرك للأعلى. يجب أن تبقي الكاميرا المشغل في الرؤية للمشغل وأن "ترتد" معه تدريجيًا ، مع عرض منصات جديدة تظهر في منطقة العرض (في رؤية الكاميرا)
6. Game Over آلية الزناد. يخسر اللاعب إذا وصل إلى الحافة السفلى للمنطقة المرئية (بعد أن قفز بالفعل مرة واحدة على الأقل)
7. التهديف لاعب. سنقوم فقط بتحديث عداد ارتفاع اللاعب. سنقوم بتحديث العداد وفقًا لآخر منصة تم الوصول إليها (المنصة التي دفع منها آخر مرة)
8. HUD : تقدم لاعب العرض. عرض الارتفاع.

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

أدناه هي الأصول المستخدمة في العرض. هذه هي أشكال مرسومة بخط اليد (لست فنانًا ، كما ترون) رموزًا للحروف والمنصات بأبعاد 64 × 64 بتنسيق * .png.

وأيضا إعطاء اثنين من المخططات الانسيابية:

1. وبالتالي ، سيتم تنفيذ حساب "النوع الاجتماعي" للاعب (تذكر ، مع قفزة لأعلى ، تحولات الشاشة ، والمغادرة على حافة الشاشة تعني خندق)
   
2. وبالتالي نقوم بحساب وتحديث السرعة العمودية ( y_velocity y والإحداثي y للاعب مع كل إيقاع ، ويتأثر بعاملين اثنين: تسارع GRAVITY ( GRAVITY ) والمنصات ، عند الوصول ، يتم صد المشغل بسرعة مستعادة بالكامل
   
3. تم ترك خوارزمية حساب السرعة الأفقية ، مثل الآليات الأخرى ، خارج نطاق المقالة.

بالمناسبة ، لا يزال لدي أسئلة:

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

سأكون سعيدًا جدًا بأفكارك ومقتطفات حياتك واقتراحاتك في التعليقات و PM حول هاتين المسألتين بلا شك المتعلقة بتصميم اللعبة.

عن المحركات

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

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

لماذا لا الوحدة / محرك غير واقعي / محرك رائع آخر الخ؟

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

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

سألخص حافزي عند اختيار المحرك الذي يحتوي على رابط لهذا الفيديو ، حيث يبدو لي أن المؤلف قد أزال حرفيًا حرفيًا من لغتي ما حاولت صياغته بالكلمات مع نفسي والآخرين طوال هذا الوقت: https://www.youtube.com/watch ؟ v = JH8xwNOQ0TM

Defold

Defold هو محرك عبر منصة من King.
المنصات المدعومة:

• Html5 (WebGl)
• أندرويد 2.3 (API المستوى 9) +
• iOS 8.0+
• ويندوز فيستا +
• OSX 10.7+
• لينكس

الحقيقة الغريبة هي أن King مملوكة لشركة Activision Blizzard .
في المحرك ، انجذبتني لغة التطوير - Lua ، يمكن تثبيت دعم مجموعة من الأنظمة الأساسية لتصميم الألعاب ، بالإضافة إلى توزيع IDE عبر الأنظمة الأساسية الخاصة بهم - على نظام Linux أيضًا. هذا رشوة لي عند الاختيار بين Defold مقابل. Corona SDK .
وفيما يلي سجل ما تم في نقاط التحكم:

أدناه ، في المفسد ، هناك عدد قليل من الرسوم المتحركة التي تظهر التقدم المحرز في الوقت المناسب:

النتيجة ، النقاط المرجعية:

1. المشغل (العفريت ، سلوك القفز ، رد الفعل على الأزرار المضغوطة) (V) Yes
2. كائنات المستوى: المنصات ، الأعداء ، إلخ. (V) Yes
3. الفيزياء: سرعة قفزة اللاعب ، تسارع السقوط الحر ، يجب أن تعالج المنصات الاصطدامات فقط إذا قفزت من أعلى وتسمح للاعب بالمرور عبره إذا عبره من أسفل المنصة. (V) Yes
4. إنشاء المستوى الإجرائي: التهيئة والإضافة إلى المستوى (إلى الأماكن التعسفية ، ولكن مع بعض القواعد والقيود) على أنظمة التشغيل والأعداء الجديدة ، مما يخلق للاعب وضعًا مغريًا في اللعبة (X) No
5. "كاميرا" تتبع المشغل وهو يتحرك للأعلى. يجب أن تحتفظ الكاميرا بالمشغل في مجال رؤية المشغل وأن "ترتد" معه تدريجيًا ، مع عرض منصات جديدة تظهر في منطقة العرض (في مجال رؤية الكاميرا) (X) No
6. لعبة أكثر من آلية الزناد. يخسر اللاعب إذا وصل إلى الحافة السفلى للمنطقة المرئية (بعد أن قفز بالفعل مرة واحدة على الأقل) (X) No
7. التهديف لاعب. سنقوم فقط بتحديث عداد ارتفاع اللاعب. سنقوم بتحديث العداد وفقًا لآخر منصة تم الوصول إليها (المنصة التي دفع منها آخر مرة) (V) Yes
8. هود: تقدم لاعب العرض. عرض الارتفاع. اختياريا ، يبدو أنه لا توجد مؤشرات تقدم في اللعبة الأصلية. (V) Yes

نقاط التقييم: 5/8

Love2d

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

بشكل عام ، بالنسبة لهذا المحرك ، أوصي بسلسلة مناسبة جدًا من الدروس من Habr ، والتي حفزتني وأعطت دفعة قوية لتطوير هذا المحرك ، سأقدم فقط رابطًا للجزء الأول ، ثم يمكنك الانتقال منه إلى الأجزاء المتبقية: إنشاء لعبة على Lua و LÖVE - 1

لذلك ، يوجد أدناه سجل لما تم عند نقاط التفتيش:

احسب "أداء" المحرك:

1. المشغل (العفريت ، سلوك القفز ، رد الفعل على الأزرار المضغوطة) (V) Yes
2. كائنات المستوى: المنصات ، الأعداء ، إلخ. (V) Yes
3. الفيزياء: سرعة قفزة اللاعب ، تسارع السقوط الحر ، يجب أن تعالج المنصات الاصطدامات فقط إذا قفزت من أعلى وتسمح للاعب بالمرور عبره إذا عبره من أسفل المنصة.
   (V) Yes / (X) No // * تم تنفيذه ، ولكن ليس مثاليًا ، به عيوب كبيرة. أود أن أضع هنا 0.5 نقطة لاستكمال هذا البند.
4. توليد المستوى الإجرائي: التهيئة والإضافة إلى المستوى (إلى الأماكن التعسفية ، ولكن مع بعض القواعد والقيود) على ذبابة منصات وأعداء جدد ، مما يخلق للاعب وضع لعبة مغرية (V) Yes
5. "كاميرا" تتبع المشغل وهو يتحرك للأعلى. يجب أن تبقي الكاميرا المشغل في الرؤية للمشغل وأن "ترتد" معه تدريجيًا ، مع عرض منصات جديدة تظهر في منطقة العرض (في رؤية الكاميرا) (V) Yes
6. لعبة أكثر من آلية الزناد. يخسر اللاعب إذا وصل إلى الحافة السفلية للمنطقة المرئية (بعد أن قفز بالفعل مرة واحدة على الأقل) (V) Yes
7. التهديف لاعب. سنقوم فقط بتحديث عداد ارتفاع اللاعب. سنقوم بتحديث العداد وفقًا لآخر منصة تم الوصول إليها (المنصة التي دفع منها آخر مرة) (V) Yes
8. هود: تقدم لاعب العرض. عرض الارتفاع. اختياريا ، يبدو أنه لا توجد مؤشرات تقدم في اللعبة الأصلية. (V) Yes

نقاط التقييم: 7.5 / 8

جافا

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

لكن مع ذلك ، قررت النظر إلى ما هو متاح اليوم ، ونظرت فقط في اتجاه المحركات التي تضمن بشكل جيد 2D فقط ، ولم أهتم بالدعم 3D . واحدة من المحركات ، وخفيفة الوزن Java Game Library 3 ، تحمل اسمها والكلمة التمهيدية Lightweight . ومن المفارقات أن أبسط الأمثلة الأساسية على الصفحة الرئيسية ، عدة شاشات طويلة ، كانت ببساطة خائفة.

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

لحظات مثيرة للاهتمام وشرائح FXGL:

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

  
  

  "بالنسبة لمعظم كائنات واجهة المستخدم ، نستخدم كائنات JavaFX ببساطة ، حيث لا توجد حاجة لإعادة اختراع العجلة."

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

  
  

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

  
  

• أيضا (على ما يبدو مرة أخرى ، مع الإعدادات الأساسية) توفر اللعبة قائمة منبثقة عن طريق الضغط على Esc . أيضا مكافأة لطيفة ، وآمل أن يتم تخصيصها أو على الأقل تعطيل بواسطة رمز أو التكوينات.

  
  

• Debag يعمل أخيرا هنا ! وأخيرا! في Love2D على أقل تقدير ، غير مريح وغير سارة.

  
  

  سجل التنمية

  
  

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

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

, , , ( ). , , Java FXGL , , Lua , . , , .

:

1. FXGL ? . Love2D , Defold , , , , Love2D - , .
2. , . , . (, ), . , - . , , , , . , , , . .
3. gif-, . . , , "" , .

?

, - , ?

لذلك:

1. , . , , , , . - , - ( Love2D ).
2. - , Love2D , . F to pay respect .
3. . , , , - - , , (, , )
4. . 4 , . - Game Jam , .
5. ! , , - Roadmap , , . (!) (?) . 30 . , . , , ! , pet- 44 - Ludum Dare .