ألعاب المتصفح الأصلية تصبح أكثر جدية: ما الذي تكشفه مشاريع القتال مفتوحة المصدر

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

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

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

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

أقوى المشاريع التي وجدتها

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

لماذا فاجأتني النتائج

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

وهذا يخلق تمييزًا مفيدًا:

• توقيت التحريك ليس توقيت القتال؛
• معدل إطارات العرض ليس معدل المحاكاة؛
• التصادم لا يعني تلقائيًا ضربة صالحة؛
• التحريك ليس بالضرورة صاحب السلطة على الحركة؛
• التلامس المرئي ليس هو نفسه الإحساس بالضربة.

ظهرت هذه الفروق مرارًا في أقوى المشاريع، وهي أهم من شعار محرّك العرض في ملف README.

Voxel Musou: قتال المتصفح يمكن أن يمتلك نحوًا حقيقيًا للحركات

Voxel Musou كان من أوضح الأمثلة على أن قتال المتصفح لم يعد مضطرًا لأن يعني حركة هجوم واحدة مرتبطة بزر واحد. مصدره متاح في mike007jd/voxel-musou.

يستخدم المشروع سلاسل طويلة من الهجمات العادية وفروعًا تعتمد على الشحن بدل كومبو خطي بحت. وهذا مهم معماريًا لأن النظام يمكن نمذجته هكذا:

current move + buffered input + combat state -> next move

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

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

Long Wind: الأقرب إلى لعبة حركة حديثة في المتصفح

Long Wind كان من أقوى المراجع الشاملة لأنه يجمع حركة من منظور الشخص الثالث مع هجمات خفيفة وثقيلة، وتثبيت الهدف، والحراسة، والصد المثالي، والمناعة أثناء المراوغة، والضغط على الوضعية، وحركات الإنهاء، وردود فعل الإطلاق في الهواء والإسقاط، والمقذوفات، والزعماء، وأنماط متعددة من الأعداء. المصدر متاح في jbang2004/long-wind.

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

مواءمة الحركة تحل مشكلة تتجاهلها عروض الويب التجريبية كثيرًا

Samurai Third-Person Template ThreeJS مثير للاهتمام خصوصًا لأنه يعالج مشكلة كلاسيكية في قتال الاشتباك القريب من منظور الشخص الثالث. مصدره متاح في achrefelouafi/SamuraiThirdPersonTemplateThreeJS.

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

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

التمييز المهم هو:

animation intent != movement authority

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

اكتشاف التصادم والتحقق من الضربة مشكلتان مختلفتان

Stick & Steel يستكشف نموذج قتال مختلفًا جدًا. مصدره متاح في Rabneba/stick-steel.

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

الدرس الأكثر قابلية للنقل ليس أن كل لعبة حركة ينبغي أن تستخدم أسلحة مادية بالكامل. بل هو التالي:

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

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

حسم القتال مركزيًا يجعل الدفاع المعقد أسهل في الفهم

Hollowmere، ومصدره في euuuuuuan/hollowmere-public، برز أقل بسبب الاستعراض البصري وأكثر بسبب بنية البرمجيات.

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

تصور ذهني أنظف هو:

incoming attack -> evade | parry | hit

ينبغي لمحرّك العرض أن يعرض النتيجة، لا أن يخترع نسخة ثانية من حقيقة القتال.

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

إحساس اللعب نظام هندسي، لا مجرد زينة

Fabled Revolutions، ومصدره في ericrius1/FabledRevolutions، مفيد تحديدًا لأنه يعزل المؤثرات التي تجعل الضربات تبدو ذات وزن.

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

غالبًا ما يأتي الإحساس بالضربة من مجموعة من المؤثرات قصيرة العمر:

• التوقّف اللحظي عند الإصابة؛
• اهتزاز الكاميرا أو دفعتها؛
• آثار حركة السلاح؛
• جسيمات الاصطدام؛
• وميض الإصابة؛
• الارتداد؛
• رد فعل التحريك؛
• صوت مضبوط التوقيت.

وهذا يقترح تمييزًا مفيدًا آخر: صحة منطق القتال ليست هي إحساس القتال. لعبة المتصفح تحتاج إلى الاثنين معًا.

محرّك العرض لم يكن المؤشر الرئيسي على جودة القتال

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

ظهر Three.js مرارًا. استخدمت بعض المشاريع تقنيات عرض مرتبطة بـ WebGPU، بينما استخدمت أخرى حزمًا تقليدية قائمة على WebGL. وظهرت عبر البحث محركات فيزياء وTypeScript وJavaScript وVite وWebAssembly ومقاربات عرض مختلفة.

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

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

لماذا يغيّر توزيع الألعاب عبر المتصفح المعادلة

للمتصفح ميزة لا ترتبط كثيرًا بالرسوم: احتكاك توزيع منخفض للغاية.

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

يمكن للعبة المتصفح أن تختصر هذا المسار إلى رابط.

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

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

أين لا يزال المتصفح يخسر

لم يقنعني البحث بأن المتصفحات قد استبدلت منصات الألعاب الأصلية. لم يحدث ذلك.

لا تزال عدة قيود مهمة:

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

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

الذكاء الاصطناعي يجعل الحلقة من النموذج الأولي إلى URL أقصر بكثير

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

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

يمكن للذكاء الاصطناعي تقصير كثير من هذه الحلقات. ومع توزيعه عبر الويب، يصبح سير العمل مباشرًا على نحو غير معتاد:

idea -> prototype -> deploy -> open URL -> test -> iterate

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

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

ماذا يعني ذلك لمطوري الويب

أصبحت الحدود بين تطوير الويب وتطوير الألعاب أقل صلابة.

يمكن للعبة متصفح جادة الآن أن تستخدم أدوات ويب مألوفة، وفي الوقت نفسه تتطلب مفاهيم كلاسيكية من هندسة الألعاب:

• خطوات محاكاة ثابتة؛
• آلات حالات؛
• تخزين الإدخال مؤقتًا؛
• مخططات تحريك؛
• استعلامات مكانية؛
• فيزياء؛
• ميزانيات الإطارات؛
• إدارة موارد GPU؛
• توقيت الصوت؛
• أنظمة حتمية.

وفي الوقت نفسه، يحصل مطورو الألعاب المستهدفون للمتصفح على أشياء يتفوق فيها الويب أصلًا: عناوين URL، والنشر الفوري، والتسليم عبر CDN، والتحديثات السريعة، والقياسات عن بعد، وأنظمة الحسابات، والواجهات المتجاوبة، والمشاركة بلا احتكاك.

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

الويب لا يصبح أفضل فحسب في عرض ألعاب بُنيت في أماكن أخرى. بل يتحول بصورة متزايدة إلى مكان يمكن فيه لأنظمة ألعاب جادة أن تُصمَّم وتُنفَّذ وتُختبر وتُوزَّع وتُلعَب مباشرة.