PixelTread
سير العمل

سير عمل مشروع GMS2: من فتح المجلد إلى اللعب التجريبي

03
السيناريو

مشروع تعاني فيه الكاميرا من الاهتزاز

يكتب الكثيرون GMS2 وهم يقصدون GameMaker الحديثة. لنفترض أن اللاعب يمشي ذهابًا وإيابًا وتتهزّ الكاميرا لأن الموقع يحتوي على قيم كسرية. تفتح مجلد المشروع، تصف العرض في جملة واحدة وتترك PixelTread يجد الكود. يمسح الوكيل المجلد باستخدام list_dir و glob، يقرأ ملفات الحركة والكاميرا بـ read_file، ويقترح تعديلًا صغيرًا كـ diff. لا يتغير شيء حتى تقرّر، لذا تكون الجلسة الأولى طريقة آمنة لتعلم وظيفة كل أداة. نفس الدورة تعمل لمعظم الأخطاء الصغيرة: وصف، قراءة، مراجعة، اختبار. تنتهي كل جولة في المحرر، حيث تضغط تشغيل وترى النتيجة بنفسك. إذا لم يكن الإصلاح الأول كافيًا، تصف ما تغير ويبني البطاقة التالية على سابقتها. اترك المشروع مفتوحًا في المحرر أثناء العمل.

01

فتح المجلد

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

02

وصف المشكلة

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

03

مراجعة diff

اقرأ كل بطاقة، افتح diff وقبل فقط الأسطر التي تفهمها. ارفض الباقي واذر السبب، وسيعيد الوكيل المحاولة. وضع Ask first يوقف قبل كل إجراء يغير ملفًا، لذا لا يتم حفظ شيء خلف ظهرك. افتح البطاقة الموسعة لرؤية diff الكامل، وليس فقط سطر الملخص.

04

البناء والاختبار

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

سكربت حركة صغير

scr_move.gml
// Move an object with the arrow keys
function scr_move(_speed) {
    var _r = keyboard_check(vk_right);
    var _l = keyboard_check(vk_left);
    var _d = keyboard_check(vk_down);
    var _u = keyboard_check(vk_up);
    x += (_r - _l) * _speed;
    y += (_d - _u) * _speed;
    // keep the position on whole pixels
    x = round(x);
    y = round(y);
}

تقرأ الدالة مفاتيح الأسهم بـ keyboard_check، وتحرك x و y بقيمة سرعة، وتقرب كليهما حتى يُرسم السبريت على بكسلات صحيحة. التقريب هو إصلاح الاهتزاز الموصوف أعلاه. سكربت مثل هذا هو بالضبط ما يمكن للوكيل فتحه وتغييره وإظهاره كـ diff، ويمكنك اختباره في غرفة خلال دقيقة. احفظه كأصل سكربت أولاً، وغير سطرًا واحدًا في كل مرة. اطلب من الوكيل إضافة تعليق فوق كل تغيير حتى تتمكن من العثور عليه لاحقًا. أسماء العناوين مثل _speed سهلة إعادة التسمية.

أربع مهام لمشاريع بدأت في game maker studio 2

التعلم عن طريق تغيير سكربتاتك الخاصة

يسأل الكثيرون عن كيفية تعلم برمجة GameMaker حقًا، والإجابة الجيدة هي تغيير سكربتات حقيقية ومراقبة ما يحدث. افتح مشروعًا صغيرًا واطلب من الوكيل شرح سطر سكربت واحد تلو الآخر. يقرأ الملف بـ read_file ويقتبس أسماء الوظائف من الدليل الرسمي باستخدام web_search. ثم اطلب تغييرًا صغيرًا واحدًا، مثل سرعة مشي أسرع. اقرأ diff في وضع Ask first، اقبله، ابنِ واعمل. كرر مع تغيير جديد كل يوم، واترك الوكيل يكتب ملف ملاحظات بـ write_file، حتى تتمكن من العودة إلى ما علمك كل تعديل. التقدم البطيء هو لا يزال تقدمًا.

رسم سبريت بجزء شفاف

قد تريد جعل جزء فقط من السبريت شفافًا، على سبيل المثال النصف السفلي لشخصية تقف في الماء. يقرأ الوكيل سكربت الرسم الخاص بك بـ read_file، يبحث عن استدعاء الرسم الحالي بـ grep ويقترح تغييرات edit_file ترسم السبريت في قطعتين بـ draw_sprite_part_part_ext، إحداهما بقيمة alpha أقل. يمكن لوضع Plan only إظهار القطعتين أولاً. قصير وقابل للاختبار. اقبل diff، شغّل الغرفة، وتحقق من الفاصل بين كلا الجزأين على مستوى البكسل، لأن فجوة بكسل واحدة سهلة الرؤية في الحركة. إذا تحرك مستوى الماء، اطلب من الوكيل ربط الانقسام بمتغير.

إيقاف الحركة قبل الجدار

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

العثور على الخطأ الأول في سجل البناء

يخفي سجل البناء الطويل السطر الذي يهم. احفظ السجل كملف نصي في مجلد المشروع، ثم اطلب من الوكيل فتحه بـ read_file والبحث فيه بـ grep لكلمة error. يبلغ عن الخطأ الأول مع اسم السكبت والسطر، ويمكنه قراءة هذا السكبت لتقديم إصلاح بـ edit_file. إصلاح الخطأ الأول غالبًا ما يزيل الأخطاء التالية. اقبل diff في Ask first، ابنِ مرة أخرى وقارن السجل الجديد بالقديم لمعرفة ما إذا كان عدد الأخطاء قد انخفض. كرر حتى يصبح السجل نظيفًا.

PixelTread لنظام Windows

شغّل سير العمل هذا على مشروعك الخاص

تحميل PixelTread ↗