أول حاجة هقولها، ممكن تكون "غير بديهية": لو شفت Pixels كأنها لعبة مزرعة بس، واعتبرت PIXEL كأنها "رمز لعبة واحدة"، هتركز بطبيعة الحال على السعر، الانفتاح، والمشاعر - لكن كل ما شفت أكتر، بحس أن فريق Pixels مش ناويين يخلو لعبة واحدة تبقى أقرب لـ Web3، لكن عايزين يخلو "إدارة الألعاب" تبقى كأنها بزنس ممكن يتقاس، يتكرر، ويتنسخ لألعاب تانية.
الجملة دي بتظهر كأنها فاضية، عشان كده هقولها بطريقة أكثر وضوح: اللي عملوه Stacked، أشبه بـ"محرك LiveOps بنسخة مكافآت"، موش تطبيق جوائز للاعبين عشان يشيلوا الفلوس. الفرق ده بيحدد حاجات كتير: مين اللي بيدفع، الفلوس بتروح فين، إزاي نتجنب الاستوديوهات والروبوتات اللي بتشفط الفلوس، وهل PIXEL فعلاً بتكون مربوطة بلعبة واحدة بس.
كان لدي نفور قليل من عبارة "نظام المكافآت" هذه الأربع كلمات سابقًا، والسبب تعرفه: في تاريخ ألعاب Web3، غالبًا تعني أنظمة المكافآت ثلاثية كاملة—يأتي اللاعبون المتطفلون (刷子/الـfarmers)، وتصبح العملية زراعية (فَرم)، ويتم تفريغ الاقتصاد، ثم يبدأ القائمون على المشروع سد الثغرات بقواعد أكثر تعقيدًا، وفي النهاية تتحول الأمور كلها إلى شبكة رقع. المشكلة أن كلما زادت الرقع، صار اللاعب العادي يُعامل كأنه متغير، وتجربته تتدهور؛ بينما المتطفلون يصبحون كأنهم يلعبون "استغلال ثغرات القواعد"، لكن بكفاءة أعلى. هل طلبت منك أن تصدق تطبيقًا جديدًا للمكافآت؟ بصراحة، صعب.
لكن في سرد Stacked نقطة تجعلني لا أستطيع تجاوزها بسهولة: إنها ليست مجرد فكرة "ما زالت في الدِك/العرض"، بل نظام يعمل فعليًا في بيئة الإنتاج داخل Pixels—والجهة الرسمية أعطت مرساة صلبة وواضحة جدًا: في منظومة Pixels عالجت 200M+ من rewards، وغطّت ملايين اللاعبين، وقدّمت نتائج بمستوى إيرادات 25M++. يمكنك ألا تعجبك طريقة اللعب هذه، لكن على الأقل ليست مجرد "حكي"؛ بل هي "حسابات". وبالنسبة لي، أنا الذي تعرضت لصدمة PTSD بسبب البيانات البيضاء (whitepapers)، هذه الجملة وحدها كافية لأكون حاسمًا: Built in production, not in a deck.
بعد ذلك أريد أن أفكك هذه المسألة بشكل أكثر تحديدًا: إذا كانت Stacked فعلًا—كما يقولون—"محرك LiveOps مدفوع بالمكافآت + خبير اقتصاد ألعاب بالذكاء الاصطناعي"، فجوهرها أنها تحل مشكلتين هما الأغلى والأصعب في نموّ الألعاب التقليدي: أولًا، كيف تُنفق الأموال على "لاعبين حقيقيين" بدلًا من إنفاقها على المنصة وقنوات شراء الإعلانات؛ ثانيًا، كيف نحول التشغيل من "الإحساس" إلى "التجربة"، ومن "مراجعة التقارير" إلى "تعديل الإجراء في نفس اليوم".
أولًا، دعني أتكلم عن السؤال الأول: لطالما شعرت أن مسألة "شراء الإعلانات" هي ثقب أسود في صناعة الألعاب. كثير من الاستوديوهات تصرف ميزانيات من رقمين عشريين، وفي النهاية: كم من اللاعبين يبقى؟ ومن سيتحمّس فعلًا للعب على المدى الطويل؟ وأي نشاط يحقق إعادة شراء؟ كل ذلك غالبًا يكون غامضًا جدًا. إذا نظرت إلى تقارير الإعلانات في الألعاب الجوالة التقليدية ستعرف: يمكن التتبع، لكن يصعب إغلاق الحلقة؛ يمكن إسناد النتائج، لكن غالبًا تأتي متأخرة قليلًا. لذلك الجميع يستبدل ميزانيات أكبر بنموّ يبدو أكثر "تأكيدًا"—والثمن هو أن عائد الاستثمار يصبح أقل جمالًا.
منطق Stacked لـ"redirect ad spend" يقلب الفكرة رأسًا على عقب: بدل أن تُعطى الأموال أولًا للمنصة ثم تقوم المنصة بتوزيع حركة المرور عليك، اجعل ميزانية المكافآت تُضخ مباشرة على اللاعبين، مع اشتراط أن يكون تأثير هذه الأموال قابلًا للقياس—كم يزيد البقاء؟ كم يزيد الدفع؟ كم تتغير قيمة LTV؟ إنها مثل تحويل "ميزانية شراء الإعلانات" إلى "ميزانية تجارب مكافآت قابلة للتحكم". هذا ليس مجرد كلام تسويقي؛ أنا أراه منطقًا ماليًا أكثر صرامة: أنت لا تراهن على جودة حركة المرور القادمة من القنوات، بل تدير مجموعة تجارب مكافآت لاستخراج الفئات التي ستبقى فعلًا، وبشكل لحظي تُعدل ميزانية التسرب.
هنا يأتي السؤال الثاني: كيف يكون الأمر لحظيًا؟ وكيف تُجرى التجارب؟
وهذا هو سبب تأكيد Stacked على قيمة AI game economist—ليس ذلك العمل الخفيف من نوع "AI يكتب لك إعلانًا" أو "AI يصمم لك بوستر"، بل جعل أصعب جزء في التشغيل وأسرعه للاحتباس يتحول إلى حلقة مغلقة من "insight إلى action". كثير من فرق الألعاب لا ينقصها بيانات؛ بل ينقصها شيء واحد: تحويل قراءة البيانات إلى حكم "قابل للتنفيذ"، ثم القدرة على تحويل ذلك فورًا إلى إعدادات معلمات الجولة التالية من النشاط.
سأشرح بمشهد مباشر جدًا: إذا وجدت أن cohort (مثل المستخدمين الجدد) يفقد كثيرًا من البقاء من D3 إلى D7، فغالبًا يكون الأسلوب التقليدي: زميل البيانات يسحب تقريرًا→ اجتماع لمناقشة→ تخمين السبب→ ثم تجربة مرة أخرى في النسخة القادمة أو مع نشاط جديد. لكن عندما تنتهي من التجربة، قد يكون قد مضى أسبوع أو أسبوعان، وفي تلك الفترة يكون قد أُحرق budget الذي كان يمكن إنقاذه، وخسارة اللاعبين لا تعود.
و"طموح" محرك Stacked هو: يمكنك أن تسأل أسئلة مباشرة داخل النظام، مثلما تسأل شخصًا يفهم اقتصاديات الألعاب ويفهم بيانات السلوك—مثل: لماذا تتساقط الـwhales بشكل أسرع من D3 إلى D7؟ ماذا فعل أكثر مستخدمينا ولاءً قبل اليوم 30؟ ما الآليات المرتبطة بقوة بالبقاء طويل الأمد؟ ثم لا يكتفي بأن يعطيك "تفسيرًا"؛ بل الأهم أنه سيخبرك: أين يتسرب ميزان مكافآت؟ وما هي التجربة التالية الأكثر جدوى للتشغيل؟ وكيف تُصمَّم عتبات المكافآت؟ وكيف تُنفذ فلاتر مكافحة الغش؟ وكيف تستخدم ميزانية أصغر لتحقيق زيادة أكبر؟ وفي النهاية يمكنك رفع إعدادات التجارب داخل نفس النظام دون أن تقول: "انتظروا" أو "في النسخة القادمة". Insight to action, no waiting.
تقول إن هذا يبدو مثل "تحايل"؟ نعم، لذا أنا أركز أكثر على سبب نجاحه في العمل. الإجابة ليست غامضة: لأن Pixels لم تبدأ بتصميم هذا النظام من الصفر فقط، بل فرضته عليها بيئة مواجهة حقيقية. إذا مررت على أي نظام مكافآت، ستعرف مدى قوة "الطبيعة العدائية" فيها: روبوتات، سكربتات، استوديوهات، مزارع، متطفلون—كلها ليست أحداثًا عابرة بل حالة ثابتة. إذا لم يكن لديك مكافحة غش، anti-bot، وممرّ قوي من بيانات السلوك لحماية الاقتصاد، فإن نظام مكافآتك سيكون مثل قطعة لحم دسمة، لا بد أن يُنهش في وقت ما.
وهذا هو الدليل الأساسي الذي يجعلني أرى أن Stacked "ليست تطبيق مكافآت generic". ليس خندقها (moat) في تصميم الواجهة أو في حيل الأنشطة، بل في ثلاث قدرات صلبة تتراكب معًا: منظومة مكافحة الغش ومكافحة الروبوتات، وبيانات سلوك قابلة للتوسع على نطاق واسع، وخبرة تصميم مكافآت طويلة الأمد (وأفضل أن أسميها reward design wisdom، أي الحدس والمنهجية الناتجة عن تجارب الفشل والتعلم). يمكن لفرق كثيرة أن تبني سلسلة مهام ولوح نقاط، أو حتى quest board، لكن القليل جدًا يستطيع بناء نظام مكافآت "يبقى حيًا" داخل بيئة مواجهة حقيقية. تقول Stacked إنها أنجزت ذلك بالفعل، وأنها تعمل في بيئة الإنتاج—وهذا بحد ذاته يجعلها أقرب للبنية التحتية لا للوظيفة الواحدة.
حتى هنا قد تسأل: ما علاقة هذا بـ PIXEL؟ هذه بالضبط أكثر نقطة أركز عليها في الفترة الأخيرة.
في الوقت الحالي أميل أكثر إلى اعتبار PIXEL في محرك Stacked بمثابة "وقود/وحدة تسوية" ضمن المحرك، وليس مجرد عملة rewards داخل لعبة واحدة في Pixels. وبشكل أوضح: عندما تجعل نظام المكافآت محرك LiveOps B2B، ستحتاج تلقائيًا إلى عملة مكافآت وولاء عبر الألعاب وتجارب مختلفة، تحمل تدفق القيمة من المستخدمين بين ألعاب متعددة. التفسير الرسمي هو token utility expansion: PIXEL ينتقل من توكن خاص بلعبة واحدة إلى عملة rewards عبر الأنظمة/البيئة. أرى أن هذا الاتجاه مهم جدًا، لكنه يجب أن ننتبه لصياغته أيضًا: ليس وعدًا، ولا شيء سيحدث "فورًا"؛ بل أشبه بـ"ضرورة هيكلية"—عندما يتم توصيل المزيد من الألعاب إلى نفس محرك rewarded LiveOps، لن يمكن أن تبقى المكافآت مقيدة دائمًا بلعبة واحدة فقط.
لذلك قلت إن هناك "ضرورة هيكلية" وراء ذلك، لأن جانب الطلب سيدفعه للأمام: المزيد من الألعاب = المزيد من سيناريوهات المكافآت = مساحة طلب أكبر. فكر في الأمر: إذا كانت Stacked ستجلب أيضًا استوديوهات خارجية إلى الداخل (وهي بالفعل واضحة في نيتها: "now opening to external studios")، عندها لن تصبح ميزانية المكافآت ميزانية تشغيل لعبة واحدة، بل ميزانية نمو متعددة لاستوديوهات مختلفة. كلما كبر هذا "الطبق"، ستحتاج إلى وحدة مكافآت يمكن إعادة استخدامها عبر السيناريوهات، ويمكن إدارتها بدقة، ومربوطة بعمق مع نظام مكافحة الغش. هنا يتغير دور PIXEL من "عملة/Coins يتم إصدارها داخل اللعبة" إلى "تذكرة عامة/عملة ولاء داخل محرك المكافآت". وهذا ما أفهمه من "توسع الدور": من توكنات لعبة واحدة، إلى rewards / loyalty currency / طبقة المكافأة عبر الألعاب.
لكنني أيضًا لن أبدأ بالصراخ بالشراء (喊单) بسبب هذا السرد، والسبب واقعي: أي قصة عن "توسع قابل للتسييل" إذا لم تصل إلى مسارات استخدام حقيقية، ومسار ميزانية، ومسار مكافحة الغش، ستتحول إلى فقاعة جديدة. لذلك أفضل وضع معيار الحكم على ثلاثة نقاط محددة وواضحة وقابلة للتحقق:
أولًا، هل تظهر إشارة حقيقية لدخول "ميزانيات استوديوهات خارجية" إلى هذا النظام؟ لاحظ أنني قلت ميزانيات، لا "ملصقات التعاون". التعاون ليس مرادفًا لتدفق المعاملات، ولا مرادفًا للبقاء طويل الأمد، ولا مرادفًا لزيادة LTV. الإشارة الحقيقية يجب أن تكون مثلًا: بعض الأنشطة/المهام/آليات المكافأة مصممة بوضوح لألعاب خارجية، ويمكن رؤية منطق القياس والإسناد (مثل إطار تجارب يُظهر زيادة البقاء أو زيادة الإيراد)، بدلًا من مجرد نقل نماذج مهام Pixels.
ثانيًا: هل ستظل أنظمة مكافحة الغش وبيانات السلوك بمثابة "قاعدة افتراضية" بدل أن يتم إضعافها بتوسعات خارجية؟ كثير من الأنظمة عندما تتوسع تُضحي بسرعة بالأمان وقوة إدارة المخاطر، خصوصًا عندما لا تتفق استوديوهات مختلفة على فهم جودة اللاعبين وقوة المواجهة. ميزة Stacked الآن تأتي تحديدًا من كونه "مجربًا في المعارك"—من كونه تم صقله عبر لاعبين حقيقيين وبيئات مواجهة داخل Pixels. وإذا تم توصيل المزيد من الألعاب مستقبلًا، فإن قابلية هذا framework لإدارة المخاطر للتوسع وإعادة النسخ ستحدد مباشرة هل هو حقًا بنية تحتية.
ثالثًا: هل يمكن لـ AI game economist أن يُظهر قدرته على "تجارب قابلة للتنفيذ" في المزيد من السيناريوهات، وليس فقط كونه "مولد تقارير"؟ أنا خائف من ذلك النوع من الأدوات: تحليل AI رائع لكنه لا يُطبق على أرض الواقع. الفرق الحقيقي ينبغي أن يكون: تسأل سؤالًا، لا يعطيك فقط نتيجة، بل يعطيك أيضًا خطة التجربة التالية، ويمكن تنفيذها مباشرة داخل نفس النظام. بمعنى آخر، يجب ألا يتوقف الذكاء الاصطناعي عند مستوى الرؤى؛ بل يجب أن يمتد إلى طبقات التصرف:投放 (إعلانات/توزيع)، المكافآت، مكافحة الغش، والتحكم في الميزانية.
انظر، أنا تحدثت كثيرًا—وبشكل مستمر كنت أتجنب نقاش السعر. ليس لأنني غير مهتم، بل لأنني إذا اعتبرت Stacked كـB2B infrastructure play، فإن مصدر قيمتها ليس متغيرًا قصير الأجل مثل "حُمّى الألعاب"؛ بل متغير طويل الأجل مثل "قدرة نمو قابلة للتكرار". المنطق التجاري للبنية التحتية يشبه SaaS: أنت تزود الاستوديوهات بـ ROI قابل للقياس، لذلك الاستوديوهات ستستمر في الدفع؛ إذا استطعت redirect ميزانية شراء الإعلانات إلى اللاعبين، ويمكن تدقيقها وإسنادها، ستثق المؤسسة الاستثمارية أنها ليست صفقة لمرة واحدة.
وهناك أيضًا نقطة يمكن أن تُهمل بسهولة: عندما يتم تعريف Stacked كـ"بنية تحتية" فإن شكل المخاطر يتغير. مخاطر لعبة واحدة غالبًا ترتبط بدورة المحتوى، وبِتَقادم أساليب اللعب، وبأن المنافسين يخطفون المستخدمين؛ أما مخاطر البنية التحتية فترتبط أكثر بسرعة التوسع، وتكاليف المواجهة، والقدرة على الاستمرار في تقديم ROI قابل للقياس. أيّهما أفضل أنظر إليه؟ أفضل الخيار الثاني، لأنه يملك على الأقل احتمال أن تكون "الأرقام قابلة للحساب".
وأخيرًا أريد تلخيص ذلك بجملة واحدة: إذا كانت قصة Pixels مجرد "لعبة Web3 ناجحة" فستُوضع ضمن سرد ألعاب اعتيادي للمقارنة؛ لكن إذا كانت Stacked فعلًا "محرك LiveOps مدفوع بالمكافآت + خبير اقتصاد ألعاب بالذكاء الاصطناعي"، وقد أثبتت نتائج حقيقية في بيئة الإنتاج مثل 200M+ rewards، وملايين اللاعبين، و25M+ إيرادات—فهذا أقرب إلى تحويل نظام المكافآت في Web3، وهو أكثر جزء قابل للانقلاب، إلى مجموعة أدوات نمو يمكن حتى للاستوديوهات التقليدية أن ترغب في استخدامها. توسّع أدوار PIXEL لم يعد مجرد "كلام يُقال للتجميل"، بل صار أقرب إلى مسار تمدد تجاري: المزيد من الألعاب متصلة→ المزيد من الميزانية الداخلة→ المزيد من سيناريوهات المكافآت تظهر→ وتتكون قاعدة طلب أكبر.
لن أعتبرها موضوعًا قصير الأجل ينفجر بين ليلة وضحاها، لكن سأعتبرها اتجاهًا هيكليًا يستحق المتابعة المستمرة لـ"مسار المنتج والميزانية": هل يدخل استوديو جديد؟ هل حلقة التجربة/التجربة المغلقة تعمل فعليًا؟ هل تم إثبات أن "حصن" مكافحة الغش قابل للتوسع وإعادة النسخ؟ طالما يمكن رؤية هذه الأشياء الثلاثة بشكل تدريجي على السلسلة أو من جهة المنتج، ستزداد ثقتي في هذا السرد أكثر فأكثر.