استمع إلى المقال

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

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

لماذا تم اختيار ألعاب الطاولة Board Games؟

ألعاب الطاولة أو ال Board Games هي ألعاب يتم فيها تبادل الأدوار بين اللاعبين، كل منهم يمتلك مجموعة بطاقات أو قطع يتم تحريكها أو وضعها على رقعة خاصة بها.  

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

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

• 

• 

بيئة العمل:

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

لغة البرمجة المعتمدة في تطوير اللعبتين هي لغة Kotlin وتم اعتمادها لأول مرة في جامعتي ضمن هذه الورشة، وذلك نظراً للانتشار الواسع الذي حققته في الفترة الأخيرة. البيئة التي تم تطوير اللعبتين فيها هي IntelliJ IDEA وكان ذلك خياراً متعمداً لمنع أي محاولة لتطوير اللعبة داخل محركات الألعاب. حيث إن محركات الألعاب تمتلك أدوات سهلة تحسن من جودة رسوميات اللعبة وتجعل من صناعة القوائم وتحديد مكانها وشكلها أمراً سهلاً، بينما تطوير اللعبة في بيئة مثل IntelliJ وبتحديد مكتبة وحيدة يمكن الاستعانة بها “bgw” جعل المهمة أصعب وزاد من الفائدة المكتسبة.

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

اقرأ أيضاً: تعلّم البرمجة بلغة كوتلن (1): أساسيات البرمجة عبر كوتلن

العمل على منصات إدارة النسخ “Git” هي بالطبع من أفضل الأدوات التي يجب على أي مطور أن يتقنها قبل الشروع في تطوير إحدى الألعاب، خصوصاً في حال كان يعمل ضمن فريق، فبالتأكيد لن يعمل الجميع على نفس الحاسوب ولن يعمل كل منهم على نسخ منفصلة، بل ستكون هناك نسخة متوفرة على Git والجميع يقومون بتحديثها بشكل متكرر. عملت في تطوير اللعبتين ضمن منصة GitLab، ومن بين التطبيقات المهمة في فهم كيفية التعامل مع Git هي لعبة Oh My Git.

الخطوة الأولى – بناء النماذج:

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

النماذج Models هي مخططات تكون بمثابة مرجع بالنسبة للمبرمج، تُرسم على الأوراق أو على تطبيقات مخصصة للنمذجة مثل Astah، هذه النماذج تظهر نوع وطبيعة العلاقة التي تجمع بين الأصناف “Classes” كما تقدم عدد وسبل ارتباط الكائنات مع بعضها البعض. هذا التقسيم يساهم بشكل كبير في تسريع عملية كتابة الكود، يقلل من نسبة ظهور الأخطاء فيه وتكون بمثابة مرجع لكل أعضاء الفريق لتحثهم جميعاً على سلك نفس الطريق أثناء التطوير.

النموذج الذي صممته برفقة الطلاب الآخرين في كلا المشروعين هو نموذج المجال “Domain Model” وتم تقسيم كل لعبة من اللعبتين وفق هذا المخطط إلى ثلاث طبقات كل طبقة يتم تطويرها على حدى، والنموذج نفسه يشرح سبل ارتباط هذه الطبقات مع بعضها البعض.

– الطبقة الأولى (الكيانات Entities):

ُتقدم في هذه الطبقة جميع الكيانات أو الخلايا التي تبنى عليها اللعبة دون الخوض في تفاصيل الخدمات التي يقدمها كل كيان. كيف؟ على سبيل المثال إن أردتُ بناء كوخ صغير فسأحتاج إلى عامل، أدوات البناء وإلى من يعيش في هذا الكوخ، هذه القائمة من العناصر وإن كانت تغطي كل العناصر التي ستدخل في عملية البناء، إلا أنها لا تشرح طبيعة عمل كل عنصر ولا تشرح الخدمات التي سيقدمها كل عنصر ضمن سياق الكوخ. في لعبة Schwimmen – لعبة أوراق يمتلك فيها كل لاعب 3 أوراق- وضعتُ في الطبقة الأولى الكيانات التالية: اللعبة، اللاعب، شكل ورقة اللعب، قيمة ورقة اللعب، ورقة اللعب ورزمة أوراق اللعب. الطبقة هنا تشرح بأن اللاعب يملك اسماً، وورقة اللعب تمتلك شكلاً (بستون، زهر، كُبة أو ديناري) وتمتلك قيمة (الشاب -< 10 نقاط، الملكة -< 10 نقاط…الخ)، واللعبة تمتلك من 2 إلى 4 لاعبين ورزمة أوراق من 32 ورقة لعب، وكل لاعب يحصل على 3 أوراق من رزمة الأوراق. هذه الطبقة لا تظهر ما يمكن للاعب فعله ولا تظهر متى تنتهي اللعبة ومتى يمكن تبديل أوراق اللعب على الطاولة.

– الطبقة الثانية (الخدمات Services):

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

الطبقة الثالثة (العرض View):

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

الخطوة الثانية – بناء رسم تخيلي لواجهة المستخدم:

جميع الألعاب تمتلك واجهة للمستخدم تتضمن القوام والازرار والعناصر، قمنا في هذه الخطوة برسم شكل تخيلي للعبة: لون الطاولة، لون الأوراق، وشكل القوائم. استخدمنا للتصميم برنامج Photoshop. وتساعد هذه الخطوة في برمجة الطبقة الثالثة “View” وتحديد هوامش العناصر فيها وحجم القوائم.. الخ.

الخطوة الثالثة – كتابة الكود وتجربته:

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

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