لماذا Windows هو المنصة المهيمنة على اللاعبين والألعاب اليوم؟ وكيف وصلنا إلى هنا؟

مع زيادة إقبال المستخدمين على الألعاب الإلكترونية ووجود ثلاثة خيارات رئيسية فيما يخص نظامَ التشغيل على أجهزة الحاسب الشخصي (MacOS، Windows، Linux)، لربما لاحظتَ أنّ معظم الألعاب توجد على نظام Windows فقط، ولكن لماذا؟!

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

في البداية، ننظر إلى حجم السوق الكلي لكل من الأنظمة الكبرى الثلاثة على ساحة الاستخدام الشخصي Linux وMac وWindows؛ إذ تشير إحصائياتٌ غير رسمية إلى أنّ حصص الأنظمة الحالية من السوق هي كالآتي (1):

مما يعني أنّ استثمار شركات الألعاب في نظام Windows وحده يغطي قرابة 88% من السوق دون عناء التغيير والتعديل والفحص على عدة أنظمة تشغيل، لكننا هنا نتحدث عن المعلوماتية، وسنترك السوق للمختصين.

تاريخ

بالنظر إلى نظام MacOS بدايةً، وبالعودة إلى منتصف التسعينيات؛ كان نظام MacOS نظامًا داعمًا للألعاب على نحو كبير، ومن أمثلة هذا الدعم إنشاء Apple لمجموعة برمجية تسمّى "Game Sprockets"، وهي تساعد المطوّرين -على نحو كبير- على إنشاء محركات الألعاب؛ أي البرامج التي تُصنّع من خلالها الألعاب. 

لكنّ Apple قررت تغيير الطريقة كليًّا باعتمادها مكتبات Apple Cocoa؛ مما يعني أنه يجب على مطوّري المحركات اعتماد الأدوات الجديدة، وهذا يستهلك وقتًا كبيرًا، خاصة مع وجود عدة مشكلات تعارضت وإمكانية إطلاق ألعاب مهمة على النظام مثل Doom 3. ولكن مع قرار Apple فتح أدوات OpenGL Multithread؛ أصبح بالإمكان صناعة ألعاب مقبولة، وقد ظهر هذا على نحو واضح عندما تضاعف عدد الإطارات في الثانية (Frames Per Second (FPS في لعبة World of Warcraft 2.0.1؛ مما ساهم في تجربة لعب أفضل (1)، لكنّه لم يؤدِّ المطلوب على نحو كبير.

وفي عام 1992، أُصدِر OpenGL من قبل khronos لتقديم خدمات الرسم الثلاثي الأبعاد للأنظمة الرئيسة جميعها (ومن ضمنها Microsoft Windows)، وقد اعتُمِد في Apple وLinux وWindows؛ ليبقى جزءًا مهمًّا من تجربة العمل مع البرمجيات الثلاثية الأبعاد إلى يومنا هذا (2).

في هذه الحقبة نفسها، أطلقت Windows البرمجية التي ستغير سوق الألعاب جذريًّا؛ Direct3D ومكتباتها الضخمة DirectX، وهي مجموعة الأدوات التي ستصبح تقريبًا الأدوات الافتراضية التي يستخدمها المبرمجون لإنتاج الألعاب، وتعتمد هذه الأدوات على ما يُسمّى "Hardware-accelerated API" بحيث تسرّع عمليات الوصول إلى البطاقة الرسومية، ومن ثم تقدّم تجربةَ لعب أفضل.

تسريع الرسومات

في الحقيقة تُدعَم الألعاب -التي هي تطبيقات في النهاية- عن طريق السماح للمبرمجين بالاستفادة من التطور في تقنيات الحوسبة الرسومية بآخر إصداراتها، مع نمذجة طرائق التعامل مع هذه التقنيات. وبمعنى آخر؛ لا يستخدم المبرمج هنا طريقةَ التواصل المباشر (Direct Access Method) مع بطاقة الرسوميات، بل يتعامل مع عدة أدوات مَهمتها تحويل طلب الرسم التي ترسله اللعبة (رسم كائن في اللعبة) إلى طلب خاص يناسب البطاقة الرسومية، وبعد ذلك تُحوَّل هذه الطرائق إلى نماذج معيارية (Standarized Requests)، وبتلك الطريقة تُربَط الألعاب بآخر التقنيات في عالم البطاقات الرسومية دون أي تعديل نسبيًّا من جهة المطور، فعلى سبيل المثال؛ تعمل اللعبة ذاتها على جهاز الحاسوب المنزلي وجهاز الحاسوب في المكتب دون أي تغيير على الرغم من أنّ البطاقة الرسومية مختلفة في كل من الجهازين (2).

ومثال هذا الأدواتُ التي تكلمنا عنها: Apple لـ MacOS، وDirectX لـ Windows، وأخيرًا OpenGL المُستخدَم في نظامي Linux وMacOS.

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

إنّ هذا يأخذ هذا كثيرًا من الوقت، ومن ثم ينتج عددًا من النماذج القديمة التي تؤخر عملية التطوير على نحو كبير (2)، ويُعدّ هذا سببًا مهمًّا لكون آخر إصدارات هذه النماذج كان في OpenGL 4.1 عام 2010.

في Linux يعتمد المستخدمون على Wine، وهي طبقة ترجمة تشغّل تطبيقات Windows على Linux (وهي الفكرة ذاتها مع WSL 1 على Windows 10)، وقد طُوِّرت واجهاتٌ رسومية لها -مثل PlayOnLinux- ولاقت رواجًا جيدًا، لكنها صعبة التثبيت وغير مضمونة النتائج*.

اعتُمِد OpenGL للتطبيقات الرسومية الـ native مضمّنين بذلك المشكلات ذاتها التي يعانيها مستخدمو Mac من OpenGL.

وفي عام 2013، أصدرت Valve منتجًا مهمًّا هو المكتبة الشهيرة Steam for Linux؛ لتفتح بذلك الطريق لنشر الألعاب على النظام على نحو كبير.

اليوم

نتجه إلى الرسومات الثلاثية الأبعاد على نحو أكبر يومًا بعد يوم، ولذلك؛ تزداد أهمية حل هذه المشكلات. ولحلها؛ تخلّت Apple عن OpenGL عام 2017، لتعتمد Metal وهو مقابل DirectX لأنظمة Mac.(4) 

كذلك أصدرت khronos أدوات Vulkan، وهي نظير DirectX؛ لتحدث نقلة نوعية في مجال الألعاب على Linux لكونها Cross-Platform؛ أي إنها تعمل على الأنظمة الثلاثة؛ مما ساهم في تغيير ساحة الألعاب على نحو كبير. وقد اعتُمِدت مع OpenGL في جل أنظمة Linux المخصصة للألعاب مثل SteamOS وUbuntu 20 مؤخرًا؛ إذ أصبح من السهل اعتماد Vulkan لدى مصنّعي الألعاب لتساهم في إنتاج أداء مشابه على الأنظمة جميعها المقصودة باللعبة، أو يمكنهم استخدام Valve ProtonDB بوصفها طبقةَ ترجمة بديلًا عن WineHQ، لكنّ حصة السوق لا زالت عاملًا مهمًّا في زيادة عدد الألعاب التي تعمل على كل الأنظمة الشهيرة.

ولمّا كان المصنعون الكبار يتجهون إلى توفير الألعاب كاشتراك مثل Stadia Geforce Now (هي خدمات تعتمد Linux منصةً)؛ فإن الأمور تتجه للأفضل حتمًا (3).

اليوم يمكنك اللعب على معظم ما تصل إليه يداك من Android، iOS، MacOS، Linux و Windows؛ مما يثبت أنّ قسم الألعاب مهم جدًّا في السوق، كذلك وصل الحال إلى قفزة نوعية في تجربة الألعاب بفضل هذه التقنيات الرائعة من Volkan إلى Metal وإلى DirectX (أكثر التقنيات شهرة واستخدامًا).

هوامش:

*راجع Wine Application Database لتلقيَ نظرة إلى الألعاب المدعومة والمجرّبة هنا

المصادر: