بتـــــاريخ : 2/26/2011 8:38:27 PM
الفــــــــئة
  • الحـــــــــــاسب
    		•
    التعليقات المشاهدات التقييمات
    0 1444 0
    طباعة أخبر صديق

    موضوعات متعلقة

    تعرف على Virtual Function ... مقالة توضح هذا الموضوع ..

    مختارات من نفس الفئة

    حمل برنامج Google Maps Image Downloader 4.25 مجانا PhotoCard :برنامج لـدمج الصور والكتابة عليها - للموبايل

    معمارية اللعبة الموضوع بشكل كامل

    الناقل : elmasry | العمر :42 | الكاتب الأصلى : Sultan_Althibity | المصدر : www.arabteam2000-forum.com

    كلمات مفتاحية  :
    معمارية اللعبة الموضوع

    معمارية اللعبة
    Game Architectur


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



    +تمهيد
    +التطبيقات الفورية.
    +القسم المنطقي للعبة.
    +قسم العرض للعبة.
    +عـملية البرمجـة.
    +الخلاصـة.

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

    التطبيقات الفوريـة:
    Real-Time Software

    ألعاب الفيديـو هي تطبيقات برمجيـة؛ بشكل أدق هي تصنف على أنها تطبيق فوري real-time software. هذا تصنيف مهـم لأنه سيساعدك على فهـم كيف تتصرف ولماذا بعض القرارات الكـوديـة يتم اتخاذها. لهـؤلاء الذين لا يعرفون مثل هذه المفاهيم فإنني سأتوقف لشرح مثل هذه الخصائص.

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

    لنأخذ مثالاً أعقد من المثال السابق بقليل ؛ برنامج تطبيقي تم تصميمـه للمساعدة في السيطرة على الملاحـة الجويـة أنظر الشكل التالي:
    Posted Image

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

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

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

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

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

    بسبب أن معدل التفاعل يكون سريعاً فإن هـناك حدود حول ما يمكن محاكاته ؛ ولكن برمجـة الألعاب تحاول تحدي مثل هذه الحدود وتحاول صناعـة شيء أقوى مما تقبله البيئـة في كل من التقديم أو العرض presentation والمحاكاة simulation . هذا هـو مفتاح برمجـة الألعاب وموضوع هذا الكتاب.

    الجزء الأول "Gameplay Programming " يتعامل مع تكويد محاكيات العالم الحقيقي التي تعالج عالم اللعبـة، الجزء الثاني "برمجـة المحرك" يغطي طبقة التقديـم أو العرض.

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

    الحلقات الفورية
    Real-Time Loops
    كما هـو مذكور في وقت سابق ، جميع التطبيقات الفورية التفاعلية تشمل ثلاث مهـام تعمل في نفس الوقت؛ أولاً: حالة العالم يجب أن تكون محسوبة بشكل ثابت ( على الرادار أن يشعر بوجود الطائرة في الفضاء ) ، الثانية: يجب أن يسمح للمشغل أو اللاعب بالتفاعل مع العالم ، الثالثة: حالة العالم الناتجـة يجب أن تقدم إلى اللاعب على الشاشـة ، السماعات .. وأي وحدة إخراج متوفرة ؛ في أي لعبة فإن كلتا مهمتي محاكاة العالم وإدخالات المستخدم تعتبران من المهام التي تحدث هذا العالم ؛ في النهـاية فإن اللاعب هـو عبارة عـن مجرد كيـان خاص باللعبـة. للبساطـة ، فإنني سأتبع هذه القاعدة وسأشير إلى الألعاب على أنها تطبيقات تشمل جزأين: التحديث و روتين التصيير render routine .

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

    أولى الطرق هي أن يتم تنفيذ كلا الروتينين في حلقة تكرارية كما هو واضح من الشكل بالأسفل ، أي أن التحديث سيتبعـه استدعاء التصيير وهلم جرا . هذا يضمن بأن كلا الروتينين لهـما أهـمية متساويـة . في هذه الطريقة فإن المنطق (والذي هـو في هذه الحالة التحديث) و التقديم presentation من المفترض اعتبارهـما مرتبطيـن بشكل كامل ؛ ولكن ماذا سيحدث لو كان معدل إطارات\ثانية يتغير عـند أي تغيير غير ملحوظ في مستوى التعقيد؟ (ملاحظة المترجم: يقصد هـنا بمستوى التعقيد تغير معدل إطارات\ثانيـة بين الأجهـزة المختلفـة)، تخيل أن 10% اختلاف في تعقيد المشهد الذي سيسبب بطأً في محرك اللعبـة ، عدد الدورات المنطقيـة يتفاوت طبقاً لذلك ؛ بشكل أسوأ ، مالذي سيحدث في لعبة كمبيوتر شخصي حيث الآلات السريعـة تخرج بيانات بشكل أسرع من الآلات البطيئـة بخمسة أضعاف ؛ هل سيكون الذكاء الصناعي AI أبطأ في هذه الآلات الغير قويـة ... من الواضح أن استعـمال الطريقة المتزاوجـة تنشيء بعض الأسئلة المثيرة حول كيف ستتأثر اللعبـة بسبب اختلافات الأداء....

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

    حل مختلف آخر لمشكلة التزامن سيستخدم طريقـة القناتين التوأمين ،أنظر إلى الشكل بالأسفل، لذا فسيكون بإمكان قناة واحدة أن تنفذ قسم التصيير والأخرى ستحرص على تحديث العالم ؛ بواسطـة التحكم بالتردد في أي من الروتينين سيتم استدعاؤهـما ، سنضمن بذلك بأن قسم التصيير سيتم استدعاؤه عدد من المرات حتى يبقى مستمر ؛ تنفيذ AI بين 10 إلى 25 مرة في الثانية أكبر من كفاية أغلب الألعاب.

    Posted Image
    تخيل وجود لعبة أكشن يتم تنفيذها 60 تردد في الثانيـة مع تنفيذ AI في قناة ثانوية 15 تردد في الثانيـة ؛ من الواضح أن إطاراً واحد من الأربعة إطارات سيتم تحديثها ؛ بالرغـم من أن هذا الفعل جيد لضمـان سرعـة محددة فإن لها بعض الجوانب السلبيـة ؛ على سبيل المثال كيف نضمن بأن الأربعة إطارات التي تتشارك في دورة الـ AI مختلفة عـملياً ، عرض صور متحركـة ورسومات أنعـم .

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

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

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

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

    هذا هـو الكـود بلغـة السي لتطبيق مثل هذه الطريقة:

     

    long timelastcall=timeGetTime();
    while (!end)
       {
       if ((timeGetTime()-timelastcall)>1000/frequency)
              {
              game_logic();
              timelastcall=timeGetTime();
              }
       presentation();
       }

    لاحظ كيف نستدعـي الدالة timeGetTime ، هذه الدالة من دوال الويندوز وتعيد الوقت محسوباً بالميلي ثانيـة منذ آخر مرة تم عـمل فيها booted للويندوز ؛ وهكذا فإن طرح الدالتين يضمن لنا أن نقيس بدقـة الفترة الزمنيـة بين الدالتين.

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

    Posted Image

    هذا هـو السورس كـود:

     
    time0 = getTickCount();
    while (!bGameDone)
       {
       time1 = getTickCount();
       frameTime = 0;
       int numLoops = 0;

       while ((time1 - time0) > TICK_TIME && numLoops < MAX_LOOPS)
              {
              GameTickRun();
              time0 += TICK_TIME;
              frameTime += TICK_TIME;
              numLoops++;
              }
       IndependentTickRun(frameTime);

       // If playing solo and game logic takes way too long, discard
       // pending time.
       if (!bNetworkGame && (time1 - time0) > TICK_TIME)
              time0 = time1 - TICK_TIME;
       if (canRender)
              {
              // Account for numLoops overflow causing percent > 1.
              float percentWithinTick = Min(1.f, float(time1 - time0)/TICK_TIME);
              GameDrawWithInterpolation(percentWithinTick);
              }
       }

    الآن دعـنا نمشي خطوة فخطوة ؛ الحلقة (الدورة) لها مكونين اثنين: الأولى ( الـ while تتحكم في الوصول إلى الدالة GameTickRun ) تعتني جيداً بمنطق اللعبة بينما الأخرى ( if تتحكم في الوصول إلى الدالة GameDrawWithInterpolation) تتحكم بقسم التصيير render .

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

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

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



    القسم المنطقي للعبة:
    The Game Logic Section

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

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

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

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

    تخيل لعبـة مثل The Legend of Zelda الكلاسيكية ؛ الروتينات الثلاث التي ذكرناها في الأعلى سيكون لديها المسؤوليات التالية:

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

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

    3- روتين " تحديث اللاعب" يربط القيود إلى التفاعلات ويولّد ردود العالم الصحيحـة ، إذا كان اللاعب يضغط على اليسار ولم يكن هـناك أي عقبـة في الاتجاه فنحن يجب أن نحرك الرسوميات animation ونجدد موقعـه وهكذا.

    تحديث العالم:
    World Update

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

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

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

    في إطار لعبتنا العام سنفترض أن هـناك عدد ضخماً من هذه العـناصر النشطـة سواءً أكانت منطقيـة أو ذات ذكاء صناعي ؛ لذا فإن عـملية تحديث هذه العـناصر تتضمن أربع خطوات ؛ الخطوة الأولى هو مرشح يختار العـناصر ذات العلاقـة باللعب الحالي فمثلاً عدو على بعد 10 أميال من اللاعب ليس مهـماً أصلاً ولا يجب على هذا المرشح استبعاد أي عـنصر؛ بعض الألعاب (مثل الألعاب الاستراتيجيـة) يظل عليها أن تقوم بحساب سلوكيات جميع الكيـانات ، إلا أنها تستخدم تقنيات اختصارها LOD واصطلاحاً هي level of detail وهي تستخدم للأجسام البعيدة.
    الخطوة الثانيـة حالة العـنصر النشط الذي يجب تحديثـه ، هـنا الفارق بين الكيـانات المنطقيـة والذكيـة ، الأخيرة تتطلب عـملية معقدة أكثر لتحديث حالتها.

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

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

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

    لكي نلخص هذه النظرة التي شرحنـاها فإننا نضع هـنا Psudecode لهذه النظرة:

     
    Player update
       Sense Player input
       Compute restrictions
       Update player state
    World update
       Passive elements
              Pre-select active zone for engine use
       Logic-based elements
              Sort according to relevance
              Execute control mechanism
              Update state
       AI based elements
              Sort according to relevance
              Sense internal state and goals
              Sense restrictions
              Decision engine
              Update world
    End



    قسم العرض\ التقديم
    The Presentation Section

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

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

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

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

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

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

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

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

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

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


    تصيير العالم
    World Rendering

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

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

    لخط معالجـة جرافكس ، روتين الاختيار يطبق عـن طريق القص clipping و الغربلة culling و حساب الانسدادات computing occlusions ؛ لذا فإن التمثيل الناتج سيكون فقط الجزء المرئي من عالم اللعبة للاعب ، بهذه الطريقة فإننا نركز فقط على رسم ما هـو مهـم حقيقـة للاعب ، هذه الروتينات هي من صميم أي خط معالجـة جرافكس معاصر وسنحلل الطريقة بالكامل في الفصول 12 و13 و14 ، بعض المساعدة الاختياريـة من الممكن أن تطبق على البيـانات المرئيـة أحياناً ، وهي تحسب صلة البيانات وتختار مستوى مناسب من التفصيل لتصييرها ، الشجرة التي ترى على بعد 500 متر ليست بحاجـة إلى 10 آلاف مثلث ، لأن كل مثلث سيحتل جزء كسري صغير جداً من البكسل على الشاشـة ، وهكذا ، درجـة وضوح أقل وتمثيل أكثر كفاءة سنستعمله بدلاً من التأثير الضار على الأداء.

    الآن هـندسية العالم تحولت للجزء المرئي وخصصت مستوى مناسب من التفصيل ، لقد حان الوقت لصباغـته على الشاشـة وهذا يتم إنجازه عـملياً في خطوتين ، أولاً: الهـندسية ستخزن في صيغـة كفوءة وهذه الخطوة تدعـى "الحزم الهـندسية geometry Packing " ؛ ثانياً: هذه الهـندسية المحزومـة ترسل إلى الهاردوير حيث تعالج ؛ هاردوير الجرافكس حساس جداً لطرق التحزيم: الأداء يزداد عشرة أضعاف باختيار الآليات المناسبة ، سنتعرف على التحزيـم والتصصير أكثر في الفصل 12 ,

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

    تصيير الشخصيات غير اللاعب
    NPC Rendeing

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

    ثم روتين الصور المتحركـة الرئيسي يجب أن يحسب ، هـناك مجمـوعـة كبيرة من الاختلافات من الإطارات المفتاحيـة keyframed إلى الصور المتحركـة الهيكلية Skeletal animation وهكذا ؛ جميعها ستتم تغطيتها في الفصل 15 ؛ ولكن النتيجـة النهائيـة لهـم جميعاً هي نفسها: بيانات الأشكال الهـندسية الثابتـة والتي تمثل اللقطـة الحالية لكيف تكون الشخصيات لكل إطار.

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

    اللاعب
    The Player

    اللاعب الرئيسي ليس في الحقيقـة سوى حالة خاصـة جداً من الـ NPC ، ولكن خط معالجـة تصييره أسهل بكثير من الشخصيات الأخرى الثانويـة لسببين اثنين بسيطين: الأول: اللاعب بشكل عام مرئي عـموماً ، لذا ليس هـناك حاجـة للمزيد من الوقت في التحقق إن كان مرئياً أم لأ ، لأنه هـو البطل وبالتالي ليس هـناك أي داعي لكي يكون مخفياً؛ الثاني: ليست هـناك أي حاجـة لعـمليات LOD أيضاً ، أغلب الألعاب تجعل للاعبين دوراً مركزياً لذا فهي تستخدم شبكات درجـة الوضوح العالية جداً ( المصطلح الإنجليزي high-resolution meshes ).
    هكذا ، فإن اللاعب الرئيسي سيمر فقط بخطوة الرسوميات والتحزيم ثم خطوة التصيير ، أحياناً فإن الصور المتحركـة للاعب ستكون ذات جودة عالية من رسوميات الأعداء لأن اللاعب هـو المركز الرئيسي للعبـة ولكن بشكل عام ليس هـناك فرق كبير بين اللاعب و NPC .

    إطار العـمل العام للتقديم انتهينا منـه الآن ، وللتلخيص فهاهي Pseducode لما شرحنـاه:

     
    Game logic
       Player update
              Sense Player input      (chapter 5)
              Compute restrictions  (chapter 22)
              Update player state
       World update                    (chapters 6 to 9)
              Passive elements              (chapter 4, spatial index)
                     Pre-select active zone for engine use
              Logic-based elements
                     Sort according to relevance
                     Execute control mechanism
                     Update state
              AI based elements
                     Sort according to relevance
                     Sense internal state and goals
                     Sense restrictions
                     Decision engine
                     Update world
    End

    Presentation
       World presentation           (chapters 11 to 14, 17 to 21)
              Select visible subset  (graphics)
                     Clip
                     Cull
                     Occlude
              Select resolution
              Pack geometry
              Render world geometry
              Select audible sound sources (sound)
              Pack audio data
              Send to audio hardware
       NPC presentation               (chapter 15)
              Select visible subset
              Animate
              Pack
              Render NPC data
       Player presentation (chapter 15)
              Animate
              Pack
              Render
    End



    تحذير: الألعاب الشبكية
    Caveat: Networked Games

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

    قسم تحديث اللاعب يجب أن يتغير لكي يرسل عـند كل تحديث للاعب رسالة تجديد موقع اللاعب عبر الشبكـة إلى بقية اللاعبين ، اللاعبون يستلمون المعلومات هذه من الشبكـة ويستخدمونها لتحديث الـ NPCs والذين هـم في الحقيقـة يمثلون بقيـة لاعبي اللعبـة على الشبكـة ؛ التغيير الثاني يؤثر على نواة نظام الذكاء الصناعي ؛ ألعاب الشبكـة بإمكانها أن تملك ذكاء صناعياً للوحوش الآلية وهكذا ، ولكن نوع خاص من الذكاء الصناعي يجب تمثيله بالنسبة للاعبين الآخريـن ، هذا النموذج الخاص من الذكاء الصناعي يستلم البيانات من قناة الاتصالات communications channel ويعكسها إلى بيئة اللعب المحلية local gaming environment .

    مع هذين التغييرين الطفيفيـن ، فإن ألعاب الشبكـة ليست مختلفـة كثيراً عـن الألعاب الأحاديـة ، كل ما تحتاجـه هـو فهـم أن أي لاعب يرى اللاعبين الآخرين على أنهـم NPCs في شاشة لعبتـه



    عـملية البرمجـة
    The Programming Process

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

    المراحل
    Stages

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

    Posted Image

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

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

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

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

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

    دعـنا الآن نفصل هذه المراحل الثلاث بشكل أعـمق.

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


    قبل الإنتاج: من أين تأتي الأفكار؟
    Preproduction: Where Do Ideas Come From?

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

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

    نوع آخر أكثر خطورة يبدأ بعبارة " دعنا نبدأ كتابة لعبـة جديدة مع هذه التقنيات الجديدة من التصيير" ؛ بالرغـم من أن العديد من الألعاب الرائعـة تم تكويدها بهذه الطريقـة ، فإن عليك تذكر حقيقـة مهـمـة جداً: وهي أن اللاعبين المخلصين جداً يهتمون فقط بالتقنيـة أما الآخرون -الأقل إخلاصاً- فليست التقنيـة هي التي تجعلهـم يمرحـون.

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

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

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

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

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


    مناقشة فئات الميزات
    Discussing Feature Sets

    أول مهـمـة لأي قائد مبرمجيـن هي تعريف قائمـة الميزات التي ستطبق في اللعبـة من ناحيـة أسلوب اللعب gameplay والعرض presentation .. كم عدد الشخصيات المعروضيـن ؟ هل يمكن للمستعـمل أن يضرب الكائنـات ، هذه القائمـة يجب أن تكون ثمرة جهـد بين فريقي التصميم والتشفير وحتى تصبح مهـام كلا الفريقين ذات مغـزى من ناحيـة التطبيق الصميمي والعـملي. الطريقة الجيدة لعرض مجمـوعـة ميزات معقولة على ورقـة هي باستعـمال طريقـة إنكماش-تمدد expansion-contration .

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

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

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

    الطريقة الموضوعيـة الأفضل لاختيار أي من العـناقيد يتم معالجتها هي استخدام طريقـة ميني ماكس minimax الكلاسيكيـة ؛ كما تعلم ، فإن المينيماكس تحاول تقليل الأضرار وزيادة الفوائد ، ومن الممكن أن تراها في الأسفل على شكل مصفوفـة مربعـة وهي تمثل التكلفـة مقابل المنفعـة :

    Posted Image

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

    يجب عليك أن تقلق بشأن العائق الأول إذا كان فريقك صغيراً والثاني إذا كان فريقك مبتدئاً ؛ بعد ذلك يجب عليك اختبار جـودة كل عـنقود من عـناقيد الميزات وفقاً لمعايير مختلفـة وتصنفها على أساس التصنيف التالي:

    + الميني مين Minimin : ليست مهـمـة للاعب ولكنها سهلة التكـويد ، وهي ليست سوى عـناصر تزيينيـة تكـود في آخر المشروع إذا سمح الوقت بذلك ، فمثلاً تطيير الطيور في لعبـة مغامرات ثلاثية الأبعاد لا تضيف الكثير إلى اللعبـة ولكنها سهلة التكـويد.
    + الماكسيميني Maximin : هذه ميزات لا تضيف أي فائدة (أو القليل منها) بشأن تجربـة اللاعب وأيضاً صعبـة التكـويد ؛ من الواضح أنه يجب إسقاطها فوراً ، تخيل لعبـة سباق سيارات حيث بإمكانك أن ترى السائق داخل السيارة ، معالجـة نظام الرسوميات العـظميـة Skeletal animation system إلتزام هام ، ولكن ليس من الواضح أن هذا الجهـد سيضيف أي قيمـة على المدى البعيد.
    +الميني ماكس Minimax: هذه الميزات هي أحلام فريق اللعبـة، فهي سهلة التكـويد وتضيف الكثير إلى تجربة اللاعب ؛ بشكل واضح ،فهذه الميزات يجب أن تضاف إلى اللعبـة بإفتراض أن الوقت يسمح بذلك ؛ على سبيل المثال ، القدرة على تأكيد نظرة الشخصيـة في لعب انتحال الأدوار RPG يمكن تطبيقها بسهـولة وهـو تحسين عـظيم لمحبي هذا النوع من الألعاب ، من الميزات الأخرى أيضاً نظام الاتصال بين الكائنـات الذكيـة ، رؤيـة الكائنـات الذكيـة وهي تتعاون وتزامن مهامها وفق مهام الأخريات تحسن الكثير من تجربة اللاعب ومستوى صعـوبة تكويدها هـو متوسط.
    +الماكسيماكس Maximax: هذه الميزات هي أحجار الزاويـة للعبتك ، وهي في الأساس تعرف أسلوب اللعب gameplay للعبتك مع صعـوبة تكويدها ، التصيير (outdoors renderer) لمحاكي الطيران عبء ضخـم عـند التكـويد ، ولكن هـو الذي عـمود اللعبـة ؛يجب عليك أن تقوم هـنا بتحليلين بسيطين: أولاً هل هـناك تكـويد بسيط يحول هذا النوع من الميزات إلى ميزات minimax ، في بعض الحالات فإن إستراتيجيات تكـويد مختلفـة يمكن أن تبسط من الخوارزميـة كثيراً ؛ ثانياً: هل فريقك قادراً على معالجـة الميزة ؟ (مع اعتبار التعقيد والحجم للميزة) ، وإذا كان الأمر كذلك فكم من الميزات يمكن معالجتها .

    النتيجـة النهائيـة هي عبارة عـن قائمـة ميزات معقولة من وجهة نظر التصميم ومن وجهـة نظر الكفاءة ، هذه الميزات يجب أن تعـمل وأن تكون معقولة لعـمل فريق البرمجـة ، وأيضاً هذه الميزات يجب أن تعرف لعبـة عـظيمـة وأكثر من رائعـة ويمكن أن تبنـى من قبل الموظفين المتوفرين في الفريق.

    الإنتاج: نقاط التوقف هي السيدة
    Production: Milestones Are king

    إذا اكتملت مرحلـة ما قبل الإنتاج بشكل كفوء فإن عليك الآن المخاطرة والبدء بإكمال مرحلة الإنتاج بكل أسلوب اللعب gameplay الجـوهري الذي طبق في الديمـو ؛ أثناء الإنتاج فإنك ستحول هذا الديمو إلى لعبـة كاملة ، هـناك الكثير من القواعد في هذه المرحلة ، ولكن بعض النصائح من الممكن أن تفيدك ، القائمـة التالية هي نصائح أخذت من العالم الحقيقي لبرمجـة الألعاب:

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

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

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

    ++ (ترتيب التنفيذ): ليس جميع ميزات الألعاب بنفس الأهـميـة ، بعضها ضروري للعبـة وبعضها مجرد شكل تزييني ، في ألعاب مثل كويك و Unreal فإن ميزة indoors renderer هي مكون مفتاحي كما هـو الحال لروتين إيجاد المسار في الذكاء الصناعي ، من جهـة أخرى فإن فيزياء الـ rag doll لرسوميات الموت عـظيمـة ولكن من الممكن استبعادها ، حاول دائماً إجراء مثل هذا النوع من التماريـن على فئات ميزاتك، فكر بالميزات التي يجب أن تضمن والأخرى التي لا يجب عليها ذلك ، ولا تنسى أيضاً أن التكـويد يأخذ وقتاً أطول مما وضعتـه في خطتك الأولية ؛ وهكذا فإن وجود مسافة واضحـة بين الميزات الجوهريـة والملحقات هـو ممارسة صحيـة ، بالطريقة نفسها حاول أن تفكر بترتيب التكـويد بالنسبة للميزات ، بعض الميزات يجب أن تكود مبكراً لأنها أعـمدة اللعبـة ولن يحدث أي تقدم آخر للعبـة بدونها ، فمثلاً في لعبـة The age of empires فإن إيجاد المسار ( path finding) أكثر أهـمية من محرك الجرافكس نفسـه ، بدون هذه الميزة فإنه لا وجود للعبـة أصلاً ؛ من المفيد أن تعرض الميزات التي ستكـود ومواعيد تكويدها في شكل بياني ، كل عقدة تمثل مكـوّن ، وكل فرع يمثل عقد تعتمد على عقد أخرى حتى تصبح كاملـة ، أنظر إلى الرسم بالأسفل:

    [url=http://www.arabteam2000.com]Posted Image[/url


    الصيانـة
    Maintenance

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

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

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

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

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

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

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

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

    الخلاصـة:

    في هذا المقال استكشفنا أساسيات برمجـة الألعاب ، قمنا بتحليل هيكلية كـود الألعاب وبذلك عرفناك على تصنيف عام لمعظم تكـويد الألعاب ؛ بفهـم هذا التصنيف فإنك تستطيع رؤيـة قطع الأحجيـة والاستقلاليات التي بينها

    كلمات مفتاحية  :
    معمارية اللعبة الموضوع

    تعليقات الزوار ()

    Copyrights© 2007 Manqol.com