بنية اللعبة

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

لا يسمح SPIP بتحديد اكثر من بنية هرمية واحدة للاقسام. يجب اذاً اخد القرار حول كيفية انشاء اقسام الموقع.

الامكانات

كما اوضحنا في المقال السابق، يعتمد كل مقال على عدة معايير. يمكننا اذا اختيار احدى البنى التالية للاقسام:
– بنية حسب البيئة: قسم لدريم كاست، قسم لبلاي ستيشن، قسم لويندوز، ...
– بنية حسب اللعبة: قسم للعبة Resident Evil، قسم للعبة Gran Turismo، ...
– بنية حسب نوع المقال: قسم للاختبارات، قسم للأخبار، قسم للحلول، ...
– بنية حسب صنف اللعبة: قسم للالعاب الرياضية، قسم للمغامرات، قسم لالعاب الذكاء، ...

واذا قررنا تعقيد الامور اكثر، يمكن اعتماد احدى البنيتين التاليتين:
– بنية حسب جودة اللعبة (اي قسم لافضل الالعاب وقسم للالعاب المتوسطة ...)
– بنية حسب تاريخ التحرير تفيد في نقل مطبوعة شهرية الى الموقع (قسم لمقالات نيسان 2004 وقسم لايار 2004 وقسم لحزيران 2004 ...).

المستلزمات

تفرض بعض مزايا موقعنا تفضيل بنية على اخرى.

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

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

هكذا يكون اصغر قسم في الموقع هو القسم المخصص لكل ما يتعلق بلعبة واحدة.

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

– اما اصناف الالعاب، فيمكنها توفير بنية هرمية: فسباق الرالي هو سباق سيارات وهذا الاخير هو محاكاة رياضية. ولعبة في مقاومة الرعب تدخل في خانة العاب المغامرات... بالتالي فهذا النوع من البنى يتكيّف تماماً مع SPIP لأننا نستطيع ادخال اقسام فرعية في اقسام اخرى بقدر ما نشاء. فيمكن لقسم اساسي هو «الرياضة» ان يحوي عدة اقسام فرعية (سباق، كرة قدم، كرة مضرب...) ويمكن لكل من هذه الاقسام الفرعية ان يحوي اقساماً فرعية اخرى.

– في المقابل، لا توفر البنى الاخرى هرميات واضحة. فالبيئات لا ترتبط ببعضها: بالطبع يمكننا جمع كل طرفيات الالعاب في قسم اساسي واحد وجمع بيئات الكومبيوتر في قسم اساسي ثان ولكن ليس لهذا التقسيم اية فائدة عملية ولا يوفر عمقاً هرمياً كافياً. وفي المجال نفسه، لا يرتبط نوع مقالات بنوع آخر (فلا تنحدر الاخبار مثلاً من الحلول التي لا تنحدر من الاختبارات...)، وبالتالي لا يسمح التقسيم حسب نوع المقالات ببنية تداخل الاقسام والاقسام الفرعية.

البنية المعتمدة

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

سنعتمد اذاً البنية الاكثر هرمية اي البنية حسب صنف اللعبة. سننشئ اقساماً اساسية حسب الموضوع (مغامرات، معارك، العاب تربوية، رياضة، العاب ذكاء...) وسيحتوي كل من هذه الاقسام اقساماً فرعية.

وفي كل من هذه الاقسام الفرعية سننشئ قسماً فرعياً لكل لعبة يجمع كل انواع المقالات المتعلقة بها في كل البيئات التي تدعمها (فعلى سبيل المثال، سيتم جمع كل المقالات المتعلقة بلعبة Alone in the Dark 4، من اخبار واستعراضات واختبارات وحلول في بيئة ويندوز او دريم كاست او... في قسم فرعي واحد مخصص لهذه اللعبة).

بشكل منطقي، سنجد اختبار لعبة Alone in the Dark بنسخة دريم كاست في قسم Alone in the Dark الذي يوجد هو الآخر في قسم «العاب الرعب» الموجود بدوره في قسم «المغامرات».

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

ماذا يحصل للبيئات وانواع المقالات؟

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

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

(قد لا تتصور عدد المطورين الذين سينطلقون في هذه المرحلة، للعب ببرمجيات SPIP لإضافة القوائم المنسدلة التي يحتاجون اليها.)

والحال ان القوائم المنسدلة موجودة وهي تحديداً المفاتيح.

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

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

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

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

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

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