في نهاية عام 2017 ، أتيحت لي الفرصة لاختبار قوتي وحماسي كمشارك في واحدة من العديد من ألعاب Jam العالمية.
نظرًا لأن هذه كانت تجربتي الأولى في مثل هذا المشروع ، فقد تعلمت بعض الدروس المفيدة وبعض المفاجآت السارة. حسنًا ، لقد حصلت أيضًا على لعبة يمكنني اللعب بها مع زملائي في أيام الجمعة.
تحت القطة ، وصف كيف استمر 30 يومًا من التطور المكثف وبطء 20 يومًا من انتظار النتائج.
ملاحظة: المقالة ذات طبيعة سردية ، مع القليل من التفاصيل التقنية.مقدمة
لطالما أردت أن أجرب نفسي كمطور ألعاب ، وفي العام الماضي أصبحت هذه الرغبة أكثر تدخلاً وتدخلاً. في نهاية العام ، قررت البدء في فعل شيء ما - حضور اللقاءات حول تطوير اللعبة ، وقراءة الكتب ، وحتى عمل نموذج أولي صغير للعبة.
ثم في أحد الأيام ، عرض زميلي سليم المشاركة في واحدة من العديد من Game Jam ، واعتقدت أن هذه هي أفضل فرصة لدراسة مطبخ اللعبة دون أي التزامات طويلة الأجل. هذا ليس نموذجًا أوليًا ، ولكن ليس مشروعه الذي طال أمده حتى الآن. بالإضافة إلى ذلك ، غالبًا ما تكون المواعيد النهائية الضيقة من أفضل المحفزات. والميزة الرئيسية هي أنه على أي حال ، فإن الناتج هو شيء كلي وكامل ، والذي يلهم دائمًا الإنجازات الجديدة.
لذلك قررنا المشاركة. اثنان من مطوري جافا ، بدون خبرة على الإطلاق في صناعة الألعاب. ولكن متى يحتاج المرء أن يبدأ؟
تحضير
كان Game Jam الذي تم اختياره موضوعيًا ، وكان على المنظمين الإعلان عن الموضوع بدقة قبل بدء التطوير. تم منح المتسابقين شهر واحد لإنشاء اللعبة.
سجلنا قبل أسبوع من البداية ، وبسبب عدم وجود موضوع ، قضينا بعض الوقت في الترقب والتراخي. ربما كان من الأفضل قضاء هذا الوقت في اختيار نوع اللعبة وآليات اللعبة. ثم لفها بأسلوب مناسب.
في الساعة X ، أعلن المنظمون عن موضوع المسابقة - الإرتداد (العودة) وبدأ العد التنازلي.
كان لدى سليم الرغبة الوحيدة في اللعبة - وجود خادم اللعبة والوقت الحقيقي بالضرورة. كان مهتمًا بمعرفة المسرات والصعوبات في تطوير جانب الخادم. أيضًا ، كان يجب أن تكون اللعبة بسيطة ، وإلا فقد لا يكون لدينا الوقت لإكمالها.
فيما يتعلق بالموضوع ، كانت الأفكار في البداية إما عن الرجعية ، أو عن عصور ما قبل التاريخ. موضوع الرجعية غير مثير للاهتمام بالنسبة لي ، لذلك حاولت أن أتوصل إلى شيء عن الديناصورات أو الأشخاص القدماء. ومع ذلك ، لم أتمكن من التوصل إلى شيء بسيط ومتعدد المستخدمين حول هذا الموضوع.
ثم توصلت إلى فكرة إنشاء لعبة رمل ، بالمعنى الحرفي - إشارة إلى ترفيه الأطفال على الشاطئ. نحن نبني القلاع ، ونركض ونرمي الرمال على منافسينا (آمل ألا يكون لدى الجميع مثل هذه الطفولة الصعبة) ، لكن الآباء غير الراضين يعاقبون على ذلك. كل هذا في 2D بهدف أعلى.
واعتبر سليم أن الرمال قاسية جدًا في العيون واقترح استبدال الرمال بالثلج والقلاع بقلعة الجليد. على هذا الخيار ، توقفنا. بأفضل ما لدينا من إمكانيات ووقت ، يمكننا إضافة وظائف جديدة ومتنوعة.
التنمية. الأسبوع 1
تم تقسيم أدوارنا في المشروع بأنفسهم. كما قلت ، كان سليم مهتمًا فقط بتطوير الخادم. وقد كنت مهتمًا بتجربة تطوير واجهة المستخدم ، لأنه ، في رأيي ، يختلف كثيرًا عن تطوير تطبيقات الأعمال. تم تخطيط واجهة اللعبة على شبكة الإنترنت.
وصف موجز للتقنيات المستخدمةتم بناء التفاعل بين العميل والخادم بشكل كامل على مآخذ الويب ، لأننا كنا بحاجة إلى إرسال رسائل من الخادم إلى العميل بشكل غير متزامن ومنتظم. تم أيضًا إرسال رسائل من العميل عبر مقبس الويب ، ولكن ببساطة لسبب "لماذا لا". كانت جميع الرسائل بتنسيق Json.
للعمل مع مآخذ الويب على الخادم ، تم استخدام Spark micro-framework. وكما تم استخدام box2d محرك فعلي ، باعتبارها واحدة من الأكثر شعبية. كان مسؤولا عن حساب الفيزياء على الخادم.
تمت كتابة العميل في JS خالص ، دون استخدام أي أطر عمل ، لأنني لست قويًا فيها ، بالإضافة إلى ذلك ، هذا لا معنى له لمشروع صغير. كمحرك للعبة ، تم استخدام Phaser 2 - محرك JS شاب وواعد. على عكس المحرك الفعلي على الخادم ، كان الغرض الرئيسي منه هو الرسومات والحسابات المادية البسيطة. تم استخدام KnockoutJS أيضًا
لربط البيانات .
تم استخدام منتجات JetBrains كـ IDE: Intellij IDEA وإصدار تجريبي من WebStorm (إصدار 30 يومًا فقط ، في وقت Game Jam).
بدأ التطوير باجتماع مشترك في يوم الراحة. في أول ساعتين ، التقطت نقوشًا "مؤقتة" وأدركت صبيًا يجري يعرف كيف يرمي كرات الثلج. كان يمكن أن تكون هناك صورة لـ "لقد كانت / أصبحت" ، لكنها خالية من أي معنى - بصريا ما كان ، ثم يبقى.
وجود واجهة مستخدم عاملة ، بقي
فقط لتشديد تفاعل الخادم. لذلك ، تم تكريس بقية اليوم للتكامل: مناقشة واجهة برمجة التطبيقات ، وإعداد الاتصال ، وتنفيذ التفاعل. بحلول نهاية اليوم ، يمكن لرجلنا الصغير تحريك 1 بكسل إلى الجانب ، بالضغط على مفتاح. لقد كانت متواضعة ، لكنها ما زالت ناجحة.
استمر المزيد من التطوير فقط في وقت الفراغ من العمل ، مع 6 أيام في الأسبوع بشكل منفصل للمنازل ، ويوم واحد معًا. كان هذا كافياً بفضل واجهة برمجة تطبيقات بسيطة وتوزيع صارم للأدوار.
لتكرار نجاح اليوم الأول (الجري ورمي كرات الثلج) ، ولكن بالفعل من خلال الخادم ، استغرقنا أسبوعًا. وقد تأثر ذلك أيضًا بالعديد من العوامل التقنية ، بما في ذلك المشكلات المتعلقة بالأدوات المصممة بشكل سيئ لنموذج التفاعل بين العميل والخادم. أود أن أتطرق إلى هذا النموذج بمزيد من التفصيل.
نموذج التفاعل بين العميل والخادم
في البداية ، تقرر أن الخادم سيكون مسؤولاً عن أي حركة ، ولن يرسل العميل سوى أوامر ، مثل الضغط على مفتاح ، ورسم ما جاء من الخادم. في وقت لاحق ، تم تعديل هذه الفلسفة قليلاً ، لكن الخادم حتى النهاية ظل الرابط المركزي.
في التنفيذ الأول ، أرسل الخادم تحديثات إلى العميل في كل مرة. على سبيل المثال على سبيل المثال ، إذا تم الضغط على مفتاح ما ، فسيتم تغيير موضع اللاعب كل بضع أجزاء من الثانية ويتم إرسال موضع جديد إلى العميل.
باستخدام مثل هذه الخوارزمية البسيطة ، قمنا بتنفيذ حركة اللاعب. ولكن السعي لتحقيق الأفضل دفعنا إلى تغيير الخوارزمية إلى حدث واحد: يتم إرسال الأحداث المهمة فقط الكافية للمزامنة إلى الخادم ، وكذلك إلى العميل.
على سبيل المثال ، لتحريك لاعب إلى أعلى الخريطة ، تحتاج إلى 4 أحداث:
- العميل : ضغط مفتاح up؛
- الخادم : بدأ اللاعب في التحرك من النقطة [x، y1 ] بزاوية α بسرعة ν ؛
- العميل : ضغط مفتاح up؛
- الخادم : انتهى اللاعب من التحرك عند النقطة [x، y2 ].
هذا النهج له إيجابيات وسلبيات.
سلبيات- منطق أكثر بكثير على العميل: يجب على العميل نفسه حساب الحركة ، التصادمات ، إلخ.
- يجب على المنطق على العميل تكرار المنطق على الخادم بدقة شديدة ، وإلا يتم الحصول على قفزات في حركة الكائنات. كذلك في المقالة سيكون هناك العديد من الأمثلة حول هذا الموضوع ؛
- في حالة وجود مشاكل في الشبكة ، يمكن أن يؤدي تلقي الأحداث لاحقًا إلى حالات غير صحيحة (الخروج من الحدود ، المرور عبر الأشياء ، إلخ) ؛
- بشكل عام ، من الأسهل بكثير إخراج الحالة من المزامنة على الخادم والعميل.
الايجابيات- حمل أقل بكثير على I / O ؛
- يمكن تعليق منطق إضافي في الأحداث. على سبيل المثال ، في بداية / نهاية الحركة ، يمكنك بدء / إيقاف الرسوم المتحركة ؛
- مشاكل الشبكة أقل تأثيرًا على نعومة الحركة. أثناء تحلق كرة الثلج ، لن يؤثر التأخير حتى ثانية واحدة على أي شيء ، حيث يجب ألا يرسل الخادم أي شيء ؛
- يصبح API والتفاعل نفسه أكثر شفافية.
من هذه القوائم ، من الواضح أنه إذا كنت تعمل بجد على تنفيذ العميل ، فهناك ما يقرب من الإيجابيات. بالنسبة لمشروعنا ، تمكنا من تحقيق ذلك وعمل تفاعل العميل والخادم بشكل لا تشوبه شائبة. ولكن يجب أن نشيد ، فقد استغرق الأمر الكثير من القوة والأعصاب.
التنمية. الأسابيع 2 و 3
بعد أسبوع ، عندما تمكنا من إتقان التكامل على الأقل وتقديم الدعم للعديد من أنواع الرسائل بين الخادم والعميل ، حان الوقت لإضافة المزيد إلى اللعبة أكثر من مجرد صبي يعمل.
لذلك ، قررنا إضافة فتاة جارية! على طول الطريق ، بالنسبة للفتاة ، كان عليّ عمل نافذة اختيار شخصية. وبما أنه لا يزال يتعين عمل النافذة ، فمن الخطأ عدم إضافة اسم أيضًا. بالإضافة إلى ذلك ، اضطررت إلى توسيع الصور ، على غرار
نهج التصحيح 9 .
بدا وكأنه الإصدار الأول من نافذة تسجيل الدخولبسبب كل هذا ، استغرقت هذه المهمة البسيطة والمهمة لإضافة فتاة أمسيتين ، ولكن من الواضح أنها كانت تستحق ذلك. ثم جاءت الحياة اليومية الرمادية مع نفس المهام: وظائف بسيطة جديدة وإصلاح الأخطاء وتحسينات بصرية بسيطة.
مع تقدم تقدمي من جانب العميل ، ظهرت مشكلة سرعة تطوير الخادم غير المتساوية وواجهة المستخدم. وبما أن الخادم هو جزء مركزي من أي تفاعلات ، بدون الوظيفة النهائية والعملية على الخادم ، فقد توقف تطوير العميل.
لذلك ، قمت بتطبيق خادم وهمية بسيط مباشرة في العميل. تم تنفيذ العديد من الأشياء فيه بطريقة خرقاء للغاية ، بما في ذلك من خلال استخدام الحالة العالمية للعالم اللعبة. كان هذا كافيًا لتطوير واجهة مستخدم مستقلة تمامًا عن الخادم ووفرت لي الكثير من الوقت.
خادم وهمية لديه زائد محدد آخر. كان هناك روبوتات فيه لا تعرف كيف تطلق النار ، لذلك كانت هناك فرصة على الأقل للفوز.
في الوقت نفسه ، كافح سليم مع الخادم. على الخادم ، قام بتوصيل محرك الفيزياء box2d لمحاكاة الفيزياء في اللعبة. يحتوي هذا المحرك على الكثير من الفروق الدقيقة ، واستغرقت دراسته الكثير من الوقت. كانت الصعوبة الأكبر في التطوير عدم وجود تصور لعالم اللعبة. قدم عملائنا فقط ما هو مطلوب. وتم إخفاء بعض عناصر "عالم الخادم" من جانب العميل. بالإضافة إلى ذلك ، لم تكن هناك ضمانات كاملة بأن العميل يقدم كل شيء بشكل صحيح.
كانت إحدى المهام الفرعية الهامة التي كان على سليم حلها التحقق من اصطدامات الأشياء. على العميل ، تم فحص التصادمات للعناصر الثابتة فقط. على الخادم ، كان من الضروري القيام بكل شيء بصدق حتى لا يتم التعدي على حقوق الأجسام المتحركة.
أثناء تطور التصادمات ، تذكرت خطأًا مضحكًا واحدًا يمكن أن يتظاهر بوظيفة خاصة: عندما ألقى لاعب كرة ثلجية ، تم رميها مرة أخرى بـ "ركلة". حدث هذا لأنه في box2d ، بشكل افتراضي ، يمكن لأي شخص أن يتصادم مع الجميع ، ويحدث النفور دائمًا.
تم حل هذه المشكلة عن طريق تقديم أقنعة ، أي عن طريق تحديد فئات الكائنات التي لا يمكن أن تتصادم مع بعضها البعض. على سبيل المثال ، بالنسبة للاعب وكرات الثلج الخاصة به ، تم عمل القناع كما هو.
قرر سليم عدم إضاعة الوقت في التعامل الخاص مع تصادمات كرة الثلج مع بعضهم البعض وعلق على مثل هذا التصادم:
// for the unlikely event that we collide with a sibling snowballكما أظهرت الممارسة ، فإن تكرار هذا الحدث "غير المحتمل" يميل إلى تكرار رمي كرات الثلج ، لأنه عندما تقف مقابل بعضها البعض ، تتزامن مسارات كرات الثلج. وبسبب هذا ، تتغلب كرات الثلج الغريبة باستمرار على نفسها. تباينت آراءنا حول هذا السلوك ، لذلك تركناه كما هو.
بينما كان سليم يستمتع بالاصطدامات ، قمت بتصحيح الحركة المتزامنة للكائنات على الخادم والعميل. كانت هناك أخطاء بسيطة في التنفيذ الخاص بنا ، لكن Phaser قدم أكبر مفاجأة. في محركه الفيزيائي ، يتم تعديل السرعة الحقيقية للأشياء إلى FPS وإيقاف العالم. يتم ذلك لزيادة النعومة. لسوء الحظ ، لم يكن هذا السلوك الذكي متسقًا مع التشغيل المتزامن فيما يتعلق بالخادم ، واضطررت إلى تنفيذ التنفيذ الخاص بي للكائنات المتحركة.
وصف تفاصيل السرعة في Phaser أو "العرق مع الظل"للتحقق من السرعة وتصحيحها ، أضفت كائن لاعب آخر إلى الخريطة ، والتي انتقلت بنفس السرعة ، ولكن في مكان قريب. استخدم مشغل الظل هذا والمشغل العادي خوارزميات متحركة مختلفة. وهكذا نظمت مسابقات وقارنت بين ثبات السرعة.
في البداية حاولت حل مشكلة السرعة المتفاوتة باستخدام إعدادات المحرك والفيزياء التي نستخدمها. ولكن ، كما أفهمها ، لا يمكن تغيير هذا السلوك بأي شكل من الأشكال. كان من الممكن التحول إلى تطبيق أكثر تعقيدًا للفيزياء ، لكنني لم أرغب في القيام بذلك من أجل السرعة وحدها. بالإضافة إلى ذلك ، لم يعط هذا التطبيق سرعة ثابتة تمامًا.
الخطوة التالية حاولت تنفيذ حركة الأجسام بنفسي ، ولكن من المحرك كنت أتحكم ودلتا الوقت بين كل دورة في العالم. هناك عدة نماذج زمنية في Phaser ويستند تنفيذ السرعة القياسية على أحدها. ولكن ، لسبب غير معروف ، ليس لدى أي من هذه الأوقات استقرار ولا يمكنهم توفير سرعة ثابتة. هذه مشكلة معروفة ولا يُخطط لإصلاحها في الإصدار 2:
github.com/photonstorm/phaser/issues/798 .
أمضيت يومين على "منافسة" اللاعب والظل ولم أجد خيار عمل. لذا ، في النهاية ، قمت بكل سرعة معالجتي استنادًا إلى الوقت القياسي في JS. من المثير للدهشة أن مثل هذه الوظيفة الهامة تلقت مثل هذا الدعم الغريب في المحرك واضطرت إلى تنفيذ دراجتها الخاصة.
مع هذه النكات والنكات ، مررنا بهدوء الأسبوعين الثاني والثالث. علاوة على ذلك ، بدأ كل أسبوع بعبارة "حسنًا ، بحلول الأسبوع القادم نحن ملزمون بإعداد نسخة قابلة للتشغيل" - في كل مرة بدا لنا أننا على وشك الاستعداد. إن الافتقار التام للخبرة ووجود تفاؤل هائل هو أسوأ طريقة لتقييم الإطار الزمني.
قبل أسبوع من التسليم ، في اجتماع المطورين ، لم نتمكن حتى من عرض الإصدار العادي وكان علينا إظهار الخادم الوهمي.
بالطبع ، مع سرعة التطوير هذه ، لم يكن هناك شيء يحلم به في قائمة الوظائف التي تم تصورها في البداية ، بل وأكثر من ذلك عن اللطيف الحصول على الأشياء. لذلك ، كان علينا أن ننسى "sandbox" ونتوقف عند أبسط مطلق النار ثنائي الأبعاد.
التنمية. الأسبوع 4 ، الماضي
في الأسبوع الأخير من التطوير ، ركزنا على إصلاح الأخطاء. من الأفضل أن يكون لديك شيء متواضع ويعمل من متعدد الوظائف ، ولكن ينهار. كانت هناك مشاكل كثيرة ، وكان معظمها يتعلق بالاندماج السيئ. هنا وهناك ، ظهرت عيوب طفيفة ، مما زاد من انطباع اللعبة سوءًا.
بالإضافة إلى إصلاح الأخطاء ، جلبت أيضًا اللمعان النهائي إلى واجهة المستخدم: إضافة الموسيقى والأصوات ، واللعب باستخدام الخطوط وتحسين التفاصيل الصغيرة.
من بين جميع الوظائف ، تمت إضافة نظام النقاط هذا الأسبوع فقط ، بالإضافة إلى الحد من مخزون كرات الثلج وترميمها.
في اليوم الأخير من Game Jam ، تمكنا من اللعب قليلاً مع الزملاء. على الرغم من المراجعات الإيجابية العامة ، لم تنجح جلسة اللعبة هذه بسبب خطأ حرج - طارت كرات الثلج على الخادم وعلى العميل بسرعات مختلفة. وبسبب هذا ، فإن دخول لاعبين آخرين كان على الأرجح حادثًا.
وصف سبب وتصحيح الخطألقد صنعنا هذا الخطأ في اللحظة الأخيرة ، مما قلل عدد FPS على الخادم من 1000 إلى 100 التجريبي.
وتجدر الإشارة إلى أنه حتى هذه اللحظة ، لم نتمكن من تحقيق حركة متزامنة تمامًا على العميل والخادم - في بعض الأحيان كانت هناك قفزات في الحركة. من خلال تغيير FPS ، حاولنا زيادة استجابة الخادم.
عندما بدأت البحث في هذا الخطأ ، اكتشفت نمطين:
- عملت حركة اللاعب بشكل صحيح ومستقر ؛
- كانت حركة كرة الثلج على العميل دائمًا أسرع من الخادم.
تأتي قيمة سرعة الأشياء للعميل من الخادم ، أي أنه لا يمكن أن يكون عدم تطابق غير عادي للقيم. أيضًا ، أدت الزيادة العكسية في FPS إلى 1000 إلى تحسين الوضع.
قضيت الكثير من الوقت في محاولة إصلاح هذا الخطأ. لكن لا شيء ساعد. وفي النهاية ، تم العثور على السبب باستخدام googling - box2d يحد بشكل غير مباشر من السرعة القصوى عن طريق تحريك الكائن بما لا يزيد عن 2 بكسل في خطوة واحدة من العالم. على سبيل المثال في 100 FPS ، السرعة القصوى هي 200 بكسل / ثانية (p / s) ، وفي 1000 FPS - 2000 بكسل / ثانية. يتم تحديد هذه القيمة بشكل ثابت ولا يمكن تغييرها ديناميكيًا. وهذا يفسر تمامًا سبب تباطؤ كرات الثلج لدينا ، لأن سرعتها يجب أن تكون 700 p / s ، الأمر الذي يتطلب FPS ثابتًا فوق 350.
لإصلاح هذه المشكلة ، قمت بزيادة FPS إلى 500 ، ولكن لسبب ما. في box2d ، تحتاج إلى تمرير وظيفة الخطوة في العالم كم من الوقت مضى منذ الخطوة السابقة. قبل التغيير ، قمنا دائمًا بحساب هذا الاختلاف قبل استدعاء الوظيفة. ولكن الآن ، عند معرفة التردد المطلوب ، كان من الممكن دائمًا الإشارة إلى دلتا ثابتة تبلغ 2 مللي ثانية. مع تأخر العالم عن العالم الحقيقي ، كان لا بد من تكرار الخطوات واحدة تلو الأخرى ، حتى يدرك وقت العالم التأخر. ثم القليل من النوم وكل شيء جديد.
هذا الإصلاح ، كما هو متوقع ، حل مشكلة سرعة كرة الثلج. بالإضافة إلى ذلك ، اختفت مشكلة الحركة غير المتزامنة على الخادم والعميل أخيرًا. في ذلك الوقت ، كان هذا الشفاء المعجزة مفاجأة كاملة بالنسبة لنا ، ولكن الآن فهمت السبب: على الرغم من الحد الأقصى 1000 FPS ، لم يقم أحد بإلغاء التشغيل البطيء للخادم ، وخاصة مجموعة القمامة. على سبيل المثال في بعض النقاط في الوقت المناسب ، يمكن أن تقع FPS بحرية دون 350 FPS المطلوبة ، مما أدى إلى قفزات عشوائية في السرعة.
لذا ، سعداء من خلل مغلق ولعبة عمل ، قبل ساعتين من الموعد النهائي ، كنا على استعداد للاستسلام. بقي فقط لإرسال اللعبة إلى موقع المشروع.
كنت أتوقع أن تسير الأمور خارج الملعب بسلاسة ، ومن دون جدوى. كان من الضروري إنشاء صفحة مشروع ، ووصف ، وتحميل لقطات شاشة وأكثر من ذلك بكثير. التقينا ، كما هو متوقع ، من النهاية إلى النهاية. على الرغم من أن المنظمين في وقت لاحق لا يزالون يقبلون المشاريع المتأخرة بشكل فردي.
لقطة شاشة للنسخة النهائية من اللعبةالتصويت
وفقًا لشروط المسابقة ، فور الانتهاء من التطوير ، تم فتح تصويت لمدة 20 يومًا. خلال هذه الفترة ، كان بوسع أي شخص رؤية المشاريع المنجزة ، والتي تراكمت منها أكثر من 200. ولم يُسمح إلا للمشاركين بالتصويت لصالح المشاريع. يمكن تصنيف كل لعبة في الفئات التالية: عامة ، ورسومات ، وصوت ، وطريقة لعب ، وابتكار ، وملاءمة للموضوع.
لقد أعدت لنا مرحلة التصويت مفاجأة سيئة تتعلق بطبيعة اللاعبين المتعددين. كان هناك عدد قليل نسبيًا من الأشخاص يشاهدون الألعاب وكانت فرصة لقاء العدو تميل إلى الصفر. على سبيل المثال ذهب الناس إلى بطاقة فارغة ، وألقوا بضع كرات الثلج ، وركضوا بضعة أمتار وغادروا بخيبة أمل.
حاولنا تنظيم جلسات اللعب من خلال منتدى المشروع. أيضًا ، دخلت أنا وسليم بشكل دوري في اللعبة ، على أمل أن نستمتع بالتجول بالملل وحيدا. كل هذا لم يسفر عن أي نتائج.
كنت مهتمًا بمشاهدة بعض الأشخاص وهم يختبرون اللعبة. أتذكر بشكل خاص الحالة عندما دخل لاعب عدة شخصيات في نفس الوقت وبنى خماسية للأولاد. لا أعرف ماذا أراد المؤلف أن يقول ، ولكن لا يزال لدي لقطة شاشة من عملية إنشائه.
لاعب آخر "اخترق" لعبتنا. لدينا فحص طول الاسم ، ولكن فقط من جانب العميل. وبناءً عليه ، تحايل على هذا الدفاع وبدأ في مراسلتي بهذه الطريقة ، في كل مرة يدخل شخصية جديدة ، ويدخل عبارته باسم رجل.
إلى جانب التصويت ، لعبت أنا وزملائي مرة أخرى ، ننتقم من اللعبة الفاشلة في يوم اكتمال المشروع. هذه المرة كان كل شيء يسير بسلاسة وحصلنا على عدد من الأفكار للوظائف الجديدة ، ومع ذلك ، فات الأوان للإضافة.
في رأيي ، فإن جودة اللعبة ، خاصة فيما يتعلق بالتفاعل مع الخادم ، قد تحولت إلى مستوى جيد جدًا. كم مرة لعبنا فيها ، لم نلاحظ أي مشاكل ، ولم نسمعها من لاعبين آخرين. بالنسبة لي شخصياً ، كانت هذه مفاجأة ، بالنظر إلى جودة وعدد الأخطاء قبل التسليم بأيام قليلة.
استمرت 20 يومًا لتقييم الألعاب فترة طويلة جدًا ، لكنها انتهت في النهاية وجاء وقت النتائج الذي طال انتظاره.
وهكذا ، احتلنا المركز 36 من بين أكثر من 200 مشارك بقليل. وهو ، من ناحية أخرى ، ليس سيئًا للمشروع الأول ، ولكن من ناحية أخرى ، فهو مزعج إلى حد ما للفخر. خاصة بالنظر إلى أن العشرة الأوائل حصلوا على ألعاب جيدة ، لكن ليس كلهم يستحقون بعض الاهتمام الخاص.
الدروس المستفادة
من أجل الحصول على دروس في ظروف شبه دفيئة ، بدأ كل هذا. حاولنا اختراع العديد من الأشياء بأنفسنا وقصرنا أنفسنا على مجموعة صغيرة من الأدوات من أجل الشعور بالمشاكل وتجربة الطرق السيئة في بشرتنا. ولكن بعد معرفة كيفية القيام بذلك ولماذا ، ستكون دراسة النظرية أسهل.
الحاجة لفنان . كما أظهرت الممارسة (ليس لدينا فقط) ، يمكنك إنشاء لعبة جيدة بدون رسومات جيدة. ومع ذلك ، يستغرق تحديد الصور والخطوط وعناصر واجهة المستخدم الصحيحة معظم الوقت. والشيء الأسوأ أنهم في النهاية لا يتطابقون. من هذا ، يتم فقدان جو الأنبوب الدافئ ولا تبدو اللعبة شاملة.
اختبارات اللعبة مهمة جدا . بسبب مشاكل في سرعة التطوير ، لم نتمكن من اختبار قابلية تشغيل تطبيقنا معظم الوقت. عندما تمكنا من اللعب بشكل طبيعي ، كان هناك القليل من الوقت لإصلاح مناطق المشكلة. وكنا محظوظين جدًا لعدم وجود الكثير من هذه المشاكل.
في رأيي ، بالنسبة للألعاب ، تعتبر هذه الاختبارات على المستخدمين الحقيقيين أكثر أهمية من تطبيقات الأعمال ، لأنه بالإضافة إلى الراحة وحل مشاكل المستخدم ، لا يزال من الضروري الحفاظ على مستوى معين من العواطف والمشاركة.
ليست كل المكتبات مفيدة بنفس القدر . تقريبا لا أحد يطور الألعاب على محركه الخاص وهناك محركات في السوق لجميع المناسبات. في الفناء كان عام 2017 ، ويتوقع المرء جودتها العالية. اخترت Phaser كواحد من أكثر محركات JS الموصى بها وأصغرها. بعد كل المشاكل التي واجهتنا معه ، أخشى أن أتخيل كيف تبدو المحركات أسوأ. لا ، بشكل عام ، انطباعات العمل مع Phaser إيجابية إلى حد ما ، خاصة بالنظر إلى التوثيق والأمثلة الجيدة. لكن العمل معه دون معرفة عدد كبير من الفروق الدقيقة أمر صعب للغاية. في الربيع تظهر نسخة جديدة وآمل في تحسن كبير. وأيضا في خططي هو مشروع صغير على محرك آخر للمقارنة.
وسأذكر تلك المشكلة بأقصى سرعة في box2d لفترة طويلة.
من الممكن تعلم عملية Game Jam . في بداية هذا المشروع ، لم نكن نعرف شيئًا تقريبًا عن تطوير الألعاب ، ولا عن المكتبات التي استخدمناها. وقضى معظم الوقت في دراسة هذه الأشياء. على الرغم من ذلك ، ما زلنا قادرين على جعل اللعبة في حالة كاملة.
ليس هناك الكثير من الوظائف المطلوبة . أنا متفاجئ قليلاً لأن الكثير من الناس أحبوا لعبتنا. نعم ، لا يجلسون فيه كل مساء ، لكنهم يستمتعون بجلسة أو جلستين صغيرتين. لكن في لعبتنا لا توجد فكرة أصلية ، ولا كمية كبيرة من الوظائف ، ولا أي تاريخ. يمكن قول الشيء نفسه عن معظم الألعاب في Game Jam التي حصلت على تقييمات إيجابية.
(Game) Jam هو سبب رائع للمحاولة . لا يهم ما: فكرة ، مكتبة جديدة ، نقاط القوة الخاصة بك. عندما يكون هناك هدف واضح ويجب أن يرى الآخرون نتيجتك ، فمن الحافز الشديد ألا تصبح يعرجًا وتعطي كل الخير. وحتى إذا كانت النتيجة أسوأ من المتوقع ، فلن يكون من المؤسف أن تتخلص منها ، وتعلم الدروس لنفسك والمضي قدمًا!
روابط إلى الموارد:
شكرا لكم جميعا على وقتكم ومزاج جيد!