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

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

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

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

لم أكتفي بتجاهل هذا المبدأ؛ بل كنت أعتقد أنه قد لا يكون ذو أهمية في برمجة الألعاب وللأسف الكتب التي اطلعت عليها لتعليم برمجة الألعاب بأكشن سكريبت لم تنبه على هذا الخطأ نهائياً؛ لأن هذا المبدأ ستحتاجه في تنظيم المشاريع الكبيرة. أما ألعاب الأركيد البسيطة وما شابه فلن تحتاجه مطلقاً. ومما زاد الطين بلة هو أنني دفعت بقوة باتجاه تحويل أسلوبي البرمجي إلى الأسلوب الذي كنت معتاداً عليه في أكشن سكريبت 2. مما أدى إلى مزيد من الفوضى في سطوري البرمجية الكارثية! عاملاً بالنصيحة التي تقول “في الألعاب طالما أن الكود يعمل فليس مهماً الالتزام بالقواعد”. لكن عندما تصطدم بكل أنواع القواعد فإن الكود لن يعمل!

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

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

السؤال المطروح هنا: إن فشل المطور في مشروعه بسبب أحد هذه المشاكل البرمجية، لماذا لا يعيد بناء المشروع أو يبدأ بمشروع جديد؟ هنا يأتي دور الدوامة أو الحلقة المفرغة التي تحدث عنها مطوّر لعبة سبلنكي (Spelunky) في مدونته. وللأسف من الصعب جداً مقاومة إغراءات هذه الحلقة والبعض يقع بها عشرات المرات وربما سيترك المجال قبل أن يقوم بإنتاج أي شيء يستحق الذكر.

[] لقد تعلمت الكثير! سأبدأ مرة أخرى

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

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

كيف سأكسر هذه الحلقة؟ بكل بساطة؛ سأواصل العمل على نفس المشروع، مهما كان من المؤلم عمل ذلك، أو إن قررت أن أقوم بتغيير المشروع قليلاً، سأقوم بعمل مشروع مصغّر عنه (وليس أكبر منه) بحيث أضمن له النجاح ومن ثم سيكون هذا المشروع المصغّر قابلاً للتوسيع وأتمكن من إكمال المشروع من خلاله فيما بعد. وسأقاوم رغبتي الجامحة بالبدأ بمشروع آخر جديد… وإن كان تبييض صفحة الكود البرمجي أمر اضطراري، فهذا لا يعني أنني لن أستفيد من برنامجي الحالي، ولا يعني أيضاً أنني قمت بالبدأ من جديد.

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

أعجبك المحتوى؟

تفضل بتسجيل بريدك الإلكتروني حتى  تصلك التدوينات القادمة عند نشرها في المجالات التي تهمك:

[wysija_form id=“1”]