كيف تُبرمَج ماكينات السلوتس: معمارية HTML5

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

الطبقة 1: النتيجة

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

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

في الحالتين لا يقرر العميل شيئًا. لهذا لا تصمد فكرة “شدّ اللعبة من لوحة الإدارة”: تغيير العائد يعني تغيير تهيئة الرياضيات المعتمدة، وهذا بناء جديد وتحقق جديد.

الطبقة 2: وحدة الرياضيات

هي قلب اللعبة: أشرطة البكرات، وجدول المدفوعات، ومنطق الميزات، وشيفرة التقييم. تُبقي الاستوديوهات الجادة هذه الوحدة مستقلة عن المنصة، تُكتب مرة واحدة (بلغة Python أو C# أو TypeScript) وتُشغَّل في ثلاثة مواضع: في المحاكي الذي ينتج جدول PAR، وفي الخادم (أو خط الحساب المسبق)، وفي العميل لأغراض العرض فقط لأنه يحتاج إلى معرفة المواضع التي يبرزها. وإذا اختلفت الثلاثة سقط الاعتماد؛ ولهذا تُصدَّر الوحدة ببصمة وتُعامل بوصفها مصدر الحقيقة.

الطبقة 3: بروتوكول الجولة

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

الطبقة 4: العميل بوصفه آلة حالات

عميل HTML5 آلة حالات مرسومة على لوحة WebGL. الحالات المعتادة: خمول ← وضع الرهان ← دوران البكرات ← توقف البكرات (مع الترقّب) ← التقييم ← عرض الربح على مراتب ← مقدمة الميزة ← جولات الميزة ← خاتمة الميزة ← خمول. ولكل حالة رسومها المتحركة وأصواتها وما تتيحه من واجهة (لا يمكن تغيير الرهان والبكرات تدور). والمحرك تحتها عادةً PixiJS — المُصيِّر نفسه الذي تُبنى عليه حزمة الواجهة الأمامية لدى Stake — أو طبقة داخلية فوقه. وسؤال مقارنة Phaser وPixiJS يُحسم غالبًا لصالح الثاني متى احتاجت اللعبة تحكمًا دقيقًا في دفعات الرسوم والمظللات.

المكوّنات الأساسية للعميل:

• مُصيِّر البكرات — شريط منزلق من الرموز مع ضبابية وارتداد وقدرة على التوقف عند موضع محدد؛ ويبطئ الترقّب البكرات الأخيرة حين يفصلنا رمز واحد عن الميزة.
• عارض الأرباح — يبرز الخطوط أو التجمعات، ويحرّك الرموز حسب المرتبة، ويعدّ المبلغ تصاعديًا، ويرتقي إلى شاشات Big / Mega / Epic عند عتبات مضبوطة.
• مُحمِّل الموارد — أطالس النسيج، وصفحات الرموز، ورِكاب Spine، والصوت، تُحمَّل بترتيب الأولوية ليصبح اللعب ممكنًا قبل اكتمال تنزيل مشهد الفوز الكبير.
• مُتحكِّم الصوت — موسيقى بطبقات حسب الحالة، ومقاطع ترقّب، ومجمع مؤثرات، وقواعد خفض الصوت.
• طبقة الواجهة — ضوابط الرهان والرصيد واللعب التلقائي والوضع السريع وجدول المدفوعات والإعدادات، إضافة إلى رايات الولايات القضائية التي تُخفي بعض الضوابط أو تقيّدها.

الطبقة 5: الأداء

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

الطبقة 6: الاختبارات

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

ماذا يعني ذلك عمليًا

برمجة لعبة سلوتس ليست “كتابة مولّد عشوائي” بقدر ما هي بناء سلسلة قابلة للتدقيق بين رقم ورسم متحرك، يمكن لطرف ثالث التحقق من كل حلقة فيها. ولهذا تبقى الرياضيات خارج العميل، ويكون البروتوكول حتميًا، ويُجمَّد البناء ببصمة.

إن كنتم تقيّمون مورّدًا فاقرؤوا كيف يجري الإنتاج على Stake Engine وكيف تُحتسب كلفة تطوير لعبة سلوتس. في Giro Games تمثّل هذه المعمارية كاملةً — الرياضيات والبروتوكول والأداء وبناءات الاعتماد — خدمة تطوير ألعاب سلوتس بتقنية HTML5، تُسلَّم على Stake Engine أو مقابل نظام RGS خاص بالعميل.