المقالات العلمية

هذه المقالة محمية ضمن الحقوق الفكرية لشركة In|Framez Technology Corp.، ومرخصة للعرض فقط ضمن الشبكة العربية لمطوري الألعاب مع الموافقة الصريحة من المؤلف وشركة In|Framez Technology Corp.. لا يسمح بإعادة نشر هذه المقالة أو تعديلها دون الرجوع للمؤلف. يمنع النسخ والاقتباس دون ذكر المصدر والموافقة من المؤلف.

الموقع :     Palais des congrès - Montreal – Canada

الزمن  :     السابع والعشرون من نوفمبر 2007

مقدمة الجزء الأول

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

http://www.agdn-online.com/coverage.aspx?view=migs2006

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

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

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

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

ديف، هل لديك مانع في أن نتشارك معاً في الذهاب إلى المؤتمر؟

ديف:

أبداً لا أمانع.

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

ابتعد عنه، لقد حجزته أنا قبلك.

أنا:

هي! انه ليس خبزاً كما تعلم. لِمَ تتعامل معه بهذه الطريقة؟ دعه يقرر بنفسه..

(طبعاً كانت هذه خطتي لوضع روك بموقف سيء)

ديف:

هي شب��ب لا يهمني مع من أذهب، فأنا لا أريد الذهاب أساساً.

أنا:

هذه هي الفكرة.

ديف:

آااهاااا.

(الآن حان دور الدبلوماسية مع قليل من البراءة).
أنا:

حسناً لا مشكلة، إن كنت تريد الذهاب معه فلا مشاكل لدي. كل شيء تمام.

روك (بخجل):

لا لا، حقاً.. إن كنت تريد الذهاب معه فلا بأس، سأجد لنفسي شريكاً آخر...

رددت عليه وقد أدركت أن الخطة قد نجحت:

أعتقد أنني أفضل مشاركة ديف.

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

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

المهم، أين توقفنا؟ آه نعم...

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

أنا:

صباح الخير.

ماري:

آه هاهو واسام (لسبب ما تفضل نطق اسمي بفتح الواو بدلاً من كسرها). أمستعد أنت؟

أليكس (ينظر في جدول بالأسماء بين يديه):

هي! كيف حالك؟ أعتقد أن اسمك هنا، تريد بطاقة الدخول؟ هلا أعطيته واحدة يا ماري؟

قلبت ماري مجموعة من البطاقات بين يديها، وهي تغمغم بأسماء أصحابها بحثاً عن بطاقتي، ثم سحبت واحدة وناولتني إياها.

شكرتُ ماري وأخذت البطاقة... لكن لحظة، اسمي ليس عليها.

أنا:

ماري؟ هذه ليست بطاقتي.

ماري:

أوه آسفة، لكن يبدو أن بطاقتك قد أخذها شخص آخر. أظنك لا تمانع انتحال شخصية صاحب هذه البطاقة.

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

ماري:

ما هو الاسم على بطاقتك؟

أنا:

إنني فامشي!

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

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

دخلت القاعة واتخذت مجلسي و...

الكلمة الافتتاحية للمؤتمر (تصميم ألعاب): يوشياكي كويزومي (Yoshiaki Koizumi):

Super Mario Galaxy: The Journey From Miniature Garden to The Galaxy

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

 يوشياكي كويزومي سان! إن كنت تتساءل من يفكر بتحديد التحكمات في ألعاب سوبر ماريو، فقد وجدت ضالتك!

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

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

انتقل يوشياكي بعد ذلك إلى القفزة النوعية التالية في ماريو والتي حدثت في ماريو 64 عندما انتقلت اللعبة إلى عالم ثلاثي الأبعاد، حيث أن أول الأسئلة التي طرحت في وقتها كان: ما هي الكاميرا التي سنستخدمها لرؤية العالم؟

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

 على الشاشة يظهر يوشياكي ساهراً في مكتبه لإنجاز بعض الأعمال، بعد لحظة سيدخل عليه مياموتو ليشاركه السهرة...

فلنناقش المشكلة الأولى: فقدان الإحساس بالعمق. السبب ببساطة هو أن العالم فعلاً ثلاثي الأبعاد، إلا أنه في النهاية يتم إسقاطه على شاشة تلفزيون مسطحة تزيل قدرة تمييز العمق من المشاهد. هناك عدة حلول لهذه المشكلة. الحل الأول هو الظلال. وهكذا نجد أن ماريو دائماً يملك ظلاً أسفله مباشرة (حتى وإن كان اتجاه أشعة الشمس ليس عمودياً). هذا الظل يعيد للمشاهد القدرة على استنباط مكان ماريو في العالم حتى عندما يقفز أو يطير، إذ أن الظل دائماً يُـظهر مكان ماريو على الأرض التي يمكنه الوقوف عليها.

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

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

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

 يوشياكي يستعرض ماريو جالاكسي مع زميلته. لم ينسَ أن يلف ربطة الأمان حول يده عندما أمسك بعصا التحكم!

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

المحاضرة الأولى (تقنيات برمجية): كريس دوران (Chris Doran):

Painting with Light: The Artistic Possibilities of Real-time Radiosity

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

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

L(x,w) = Le(x,w) + s B(x,w’,w) * Li(x,w’) * V(x,x’) * dw’

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

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

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

كاستطراد جانبي، يذكر كريس أن المصورين منذ القرن التاسع عشر كانوا أشخاصاً متعددي العلوم، فقد كانوا فنانين، وفيزيائيين ورياضيين... تماماً كمبرمجي اليوم (مع تحفظي الشخصي على الجانب الأول).

(اضغط هنا لتحميل تسجيل لعرض التقنية- 37.9 MB)

(اضغط هنا لتحميل تسجيل لمقارنات الإضاءة - 16.3 MB)

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

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

المهم أن المحاضرة انتهت وأنا أسب وألعن في قرارة نفسي هؤلاء الذين يسمحون لمثل هذه المحاضرات الدعائية تماماً بأن تحدث في مؤتمر كهذا.

خرجت من القاعة لألقى زميلي العتيد فريد. سألته:

هه، ما رأيك؟

**** ثور. ليتني لم أُضِع وقتي بالجلوس حتى النهاية...

ما هي وجهتك القادمة؟

سأدخل محاضرة كيفن تيت.

همم، كنت أفكر بفعل ذلك أيضاً، إلا أن بيير يعتقد أنه من الغريب أن يحضر شخص محاضرة لزميل عمله في نفس الشركة. 

لا علاقة لذلك بالموضوع. أعتقد أن محاضرته مثيرة للاهتمام..

وأنا كذلك، هيا بنا...

المحاضرة الثانية (إدارة وإنتاج): كيفن تيت (Kevin Tate):

A Software Project Challenge: Getting Things Done

كيفن يعمل حالياً في EA في قسم التقنيات المركزية كمدير مشروع. نصفه لكم على طريقة الروايات: شاب أشقر، قصير الشعر، نحيل، قاسي الملامح، يبدو ألمانياً، لكنه أمريكي في الحقيقة. كان لكيفن مغامرة طويلة في التنقل عبر الشركات للعمل على مشاريع برمجية، آخر هذه المغامرات (قبل أن تنتهي بـ EA) كانت في أروقة آلياس Alias، حيث عمل في برنامج سكيتش بوك SketchBook المخصص لأجهزة الـ TabletPC. وقد قامت مايكروسوفت بإرفاق هذا البرنامج مع نسخة ويندوز الخاصة بالـ TabletPC. تم تنفيذ المشروع بزمن قصير نسبياً وبنجاح فائق، حيث كان عدد المشاكل البرمجية bugs المكتشفة بالنهاية عشرين مشكلة فقط (وهو بالفعل عدد ضئيل جداً لمشروع برمجي واقعي). بعد ذلك انتقل كيفن للعمل في برنامج مايا Maya، حيث كانت أول مشكلة يواجهها هي غياب الاختبارات المؤتمتة لوظائف البرنامج، مما يتطلب من فريق تحقيق الجودة QA أن يعيد اختبار البرنامج ككل عند كل تغيير في أي جزء من أجزاء البرنامج، وهي عملية تتطلب جهداً روتينياً كبيراً ويسهل النسيان وارتكاب الأخطاء فيه (ذكر لي زميلي فريد أن سوفت إيماج Softimage تملك اختبارات مؤتمتة متقدمة منذ زمن بعيد جداً – يمكننا الحديث عن هذا الموضوع في المنتدى لمن يود ذلك).

 على اليمين، كيفن تيت. على اليسار، كريس دوران الذي قابلناه في المحاضرة السابقة...

كيفن هو أحد المؤمنين بالعقلية اليقظة Agile Mindset لتطوير البرمجيات (إن لم تسمع عن هذه العقلية بعد، فيمكنك القراءة عنها بويكيبيديا، فقط اكتب Agile Development).

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

إلا أن هذا الوضع يعتبر مقامرة ولا يجب الاعتماد عليه البتة. هذا الوضع ككل ناتج عن العقلية القديمة legacy thinking في تطوير البرمجيات، والتي تــُستخدم بشكل واسع لتنظيم العملية ضمن منهجية تــُنظم الجهود الفردية وتركزها ضمن تسلسل عمليات يتم السير عليها الواحدة تلو الأخرى حتى النهاية. هذه المنهجية تضع بيروقراطية مزعجة في جو العمل في أغلب الأحيان. في هذا التفكير لا تـُعطـَى الأخطاء التي تتولد أثناء الإنتاج أهمية كبيرة (ربما بسبب طبيعة المشاريع البرمجية). بينما في عالم الصناعة industrial business يتم بذل الكثير من الجهد لمتابعة أية أخطاء في الإنتاج لأنها تكلف الكثير. إن عدم متابعة الأخطاء في مهنتنا هو جزء من العقلية القديمة.

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

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

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

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

المبدأ الثالث هو مبدأ 20/80. إن 20% من المزايا تعطي 80% من المنتج. إذن من المفيد التركيز على إحكام هذه الـ 20% للحصول على منتج قائم تقريباً، مع بذل بقية الجهد المتوفر للوصول إلى كمال المزايا الأخرى (الـ 20% المتبقية منها).

المبدأ الرابع هو تقليص زمن الرد feedback time reduction. بمعنى آخر أن الزمن بين إتمام ميزة ما والحصول على قائمة بالمشاكل فيها يجب أن يكون أصغرياً كي نستطيع أن نعالج المشاكل كما يجب. يمكن الوصول لهذا الهدف عن طريق الآتي: عمليات بناء سريعة، تجريب على مستوى الوحدات unit testing، عمليات بناء ليلية، اختبار جودة يومي، آراء العملاء، وهكذا.

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

المبدأ السادس هو أن إنهاء ميزة ما لا يتم بتسليم الكود الخاص بها، وإنما برؤيتها تعمل بشكل صحيح وفعال ضمن المنتج نفسه.

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

 كيفن تيت في خضم الحديث عن مبدأ كايزن وشركة تيوتا... نسيت أن أسأله ما نوع سيارته!

بعد أن انتهت فترة الأسئلة، خرجتُ من المحاضرة لألقى فريد مرة أخرى.

ما رأيك؟

محاضرة رائعة. الكثيير من المعلومات المفيدة.

هذا رأيي كذلك. أنا سعيد بأن كيفن هو المسؤول عن مشروعنا لقسم الـ********

(آسف على التشفير لكن هذه معلومات سرية خاصة بالشركة لا يجب أن أبوح بها). سأكون على اتصال مباشر معه خلال فترة المشروع. 
عظيم. كنت أريد معرفة المزيد عن الـ Agile Development، وقد أعطى فكرة جيدة عن الموضوع.

استراحة للغداء (الساعة 12:30 ظهراً)

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

ساعة الغداء تتحول مواضيع النقاش من نوع المحرك المستخدم في اللعبة الفلانية إلى نوع الوجبة القادمة في القاعة العلانية

الطابور الذي يظهر هنا يشكل فقط ثلث الطابور الكامل. جميعهم يعمل في مجال صناعة الألعاب، والأسوأ أنهم جميعاً جياع!

المحاضرة الثالثة (تقنيات برمجية): كريس هيكر (Chris Hecker):

How to Animate a Character You’ve Never Seen Before

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

 كريس هيكر يقوم "بالتسخين" قبل المحاضرة عن طريق الحديث مع بعض الأشخاص، استعداداً لتحطيم الرقم القياسي في سرعة الحديث

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

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

إذن ما هي التحديات في هذه العملية؟

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

النقطة الأخرى هو أنه أثناء تنفيذ حركة ما، فإن عدداً محدوداً من العظام يتم تحريكه فقط. لكن ماذا عن بقية العظام؟ هل نتركها جامدة في محلها؟ هنا يدخل نظام التحريك الثانوي الذي يستلم جميع العظام الغير محركة بشكل مباشر، ويقوم بتحريكها بحسابات النوابض، مما يعطيها إحساساً بالوزن (spring mass system).

في النهاية تحدث كريس عن نظام الـ IK المستخدم في التحريك في اللعبة، وعن التجارب التي أجروها حتى توصلوا للنظام الحالي والذي أعطى نتائج مرضية جداً.

 على اليمين، كريس هيكر. على اليسار، ديفيد بيري. إن كنت لا تعرف هذا الأخير، فهو الرجل وراء إيرث وورم جيم Earth Worm Jim

المحاضرة الرابعة (تصميم ألعاب): راندي سميث (Randy Smith):

How to Help Your Players Stop Saving All the Time

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

همم، غريب. وما الذي يشدك إلى هذه المحاضرة؟ أنت مبرمج رسوميات.

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

هناك محاضرة عن Direct3D10 في نفس الوقت في قاعة أخرى. ربما كان من الأفضل لك أن تذهب هناك. العديد من زملائك ذاهبون هناك بالفعل.

همم لقد حيرتني. حسناً، سأغير رأيي. وماذا عنك؟

أنا سأتواجد هنا لفترة.

ما المحاضرات التي تنوي حضورها؟ هل تنوي الذهاب إلى الـ CTO Panel؟

أجابني بطريقة غريبة:

نعم. يجب أن أكون هناك...

ها. أراك تقولها بطريقة غريبة. ما القصة؟

ضيق عينيه وأومأ برأسه بشكل بطيء بمعنى انتظر-و-سترى.

إذن أراك هناك... إلى اللقاء.

تركته وتوجهت إلى المحاضرة التالية عن Direct3D10. لكن، ما بكم تنظرون إلي؟ أعلم أن عنوان هذا القسم هو محاضرة عن تصميم الألعاب وليس عن Direct3D10، لكن ماذا أفعل؟

إنها الظروف وما باليد حيلة... لكني أنصحكم بعدم التسرع بالحكم... المهم، اتخذت مقعدي بين الحضور وأخرجت عدة التوثيق استعداداً لتلقي المعلومات، إلا أن المُحاضِر لم يظهر بعد. مضت حوالي 10 دقائق، ثم:

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

(اضغط هنا لتحميل تسجيل لرسام من Ubisoft يعمل على إحدى الشخصيات- 7.8 MB)

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

المحاضرة الخامسة (تقنيات برمجية): مناظرة بين الموجهين التقنيين Chief Technology Officers من عدة شركات:

I Make Games not Softwares

إحساسي الداخلي هو أن هذه المناظرة ستكون مهزلة. يشاركني في شعوري هذا أغلب زملائي، لذا تجدونا مجتعمين للرؤية والاستمتاع. مشرف المناظرة هو أنطوان دودينز (Antoine Dodens) وهو معروف بشخصيته الغريبة. أطراف المناظرة هم كريس مكيفوي (Chris Mcevoy) من شركة فيكاريوس فيجنز (Vicarious Visions) أو أكتيفجن (Activision) بعبارة أخرى، ومارتن ووكر (Martin Walker) من شركة A2M، وجوليان ميرسيرون (Julien Merceron) من إيدوس (Eidos)، و... سيرجي سافشينكو (Sergei Savchenko) من EA!

لذلك كان يتصرف بغرابة عندما سألته عن هذه المناظرة، لكنني كالأبله لم أكن أعرف أنه عضو فيها أساساً...

 من اليمين إلى اليسار: أنطوان دودينز، جوليان من إيدوس، مارتن من A2M، فيكاروس من أكتيفجن، وأخيراً، سيرجي من EA!

باعتبار أن هذه المناظرة لها وضع خاص، فقد قررت تسجيلها بشكل كامل (صوت وصورة) ويمكنكم تحميلها من هنا:

(اضغط هنا لتحميل الجزء الأول من التسجيل - 333.4 MB)

(اضغط هنا لتحميل الجزء الثاني من التسجيل - 315.0 MB)

(اضغط هنا لتحميل الجزء الثالث من التسجيل - 247.6 MB)

(اضغط هنا لتحميل الجزء الرابع من التسجيل - 19.14 MB)

الملفات ذات أحجام كبيرة نسبياً لذا وباعتبار أن غالبيتنا من أصحاب الإنترنت المحدودة، فإنني أنصح باستخدام أي برنامج لتسريع التحميل.

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

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

أترككم مع هذه المناظرة الشائقة وأرجو أن تستمتعوا بها كما استمتعت أنا بها...

نهاية اليوم الأول

بعد أن انتهت المناظرة، وقفنا مع سيرجي لفترة نناقش الأمور التي طـُرِحت في المناظرة. بالنسبة لسيرجي فقد عمل مع أنطوان سابقاً، وهذه ليست هي المرة الأولى التي يطرح فيها هذا النقاش معه. خرجتُ عائداً إلى الشركة لألتقط ما تبقى من أنفاسي هناك، وأستمتع قليلاً بلعب نيد فور سبيد (Need For Speed ProStreet) على جهازي ذو المعالج الرباعي.

لا تذهبوا، فسأراكم مرة أخرى في تغطية اليوم الثاني للمؤتمر...