كفريق تطوير ألعاب صغير مكون من 12 شخصًا ، كان أكبر تحدٍ واجهناه في العامين الماضيين ليس صعوبة إطلاق اللعبة ، ولكن مشكلة انخفاض معدل الاحتفاظ بالمستخدمين. بعد انتهاء كل حدث ، تنخفض حماسة اللعبة بسرعة إلى الصفر؛ وغالبًا ما تستغرق المفاوضات مع العلامات التجارية الأخرى نصف شهر ، بينما تؤدي تسوية الحسابات إلى جدل آخر يستمر لنصف شهر؛ وتعتمد خدمة العملاء بشكل كبير على العلاقات العامة ، حيث تظل التقييمات السلبية والعمليات الرمادية دائمًا كظل.
حتى نقرر الانتقال إلى منصة Hemi، كان هذا القرار ناتجًا عن فكرة بسيطة وقوية: جعل النظام منظمًا وتحويل حماس المستخدمين إلى نمو مستدام. فيما يلي إجراءات التشغيل القياسية التي قمنا بتنفيذها خلال 60 يومًا، وقد قمنا بتوثيقها بأكبر قدر ممكن من التفصيل حتى تتمكن الفرق الأخرى من الرجوع إليها ونسخها.
في الأيام من 1 إلى 7، ركزنا على تجزئة المكونات وبناء السلالات. قمنا بتجزئة النصوص، والموسيقى، والشخصيات، والتأثيرات الخاصة، وعناصر الخرائط في اللعبة، وقمنا بتحديد معلومات الترخيص وخطط توزيع الأرباح لكل مكون. في الوقت نفسه، وضعنا قوالب حقوق تتضمن التذاكر، وبطاقات الموسم، والتذاكر، والشارات، التي تغطي القوائم البيضاء، والحدود، وفترات الانتظار، والقواعد الثانوية، ومنحنى الفتح، وشروط الخدمة. الهدف من ذلك هو تضمين النقاط المثيرة للجدل المحتملة في العقد الذكي قبل إطلاق اللعبة، وذلك لتقليل الجدل خلال فترة النشاط.
في الفترة من اليوم الثامن إلى اليوم الرابع عشر، نركز على تحسين تجربة الدخول وآلية التسوية الجماعية. لقد اعتمدنا تقنية تجريد الحساب ونموذج رعاية رسوم الغاز، وعند ظروف الشبكة السيئة أو خلال أوقات الذروة، نقوم بتقليص التفاعلات إلى الحد الأدنى من الوحدات القابلة للتحقق. نحن نسمح للمستخدمين باللعب أولاً ثم التسوية، أو استلام المكافآت أولاً ثم التسوية، وقد نفذنا وظيفة كتابة الإيصالات بعد إدخال البيانات بشكل جماعي على السلسلة. هذه التحسينات مكنتنا من معالجة عشرة أضعاف الطلبات المتزامنة المعتادة خلال 15 دقيقة عند فتح الخدمة لأول مرة، مما ساعد في تجنب الرأي السلبي "توقف الخادم" على وسائل التواصل الاجتماعي.
في الأيام 15 إلى 21، أعدنا تعريف طريقة الربط بين الألعاب، لم نعد مقيدين بدمج العوالم، بل استندنا إلى الشهادات الرقمية. تعاونّا مع استوديوهات الألعاب المجاورة لتحقيق "مهام عبر الخادم": يمكن لحاملي بطاقة الموسم من الطرف الآخر الاستفادة من ميزة عدم الانتظار في لعبتنا، بينما يمكن لـ "شعارات المدينة" الخاصة بنا فتح بيض عيد الفصح الخاص في لعبتهم. هذه الآلية للربط مقيدة للغاية، حيث تتعلق فقط بقراءة دلالات الشهادات، وضبط شروط التفعيل، وتوزيع الأرباح بناءً على السلالات.
هذا النموذج الجديد للتشغيل لا يتيح فقط للإيرادات العودة عبر سلسلة المساهمات، مما يسمح للمطورين الذين يقدمون المكونات الأساسية بالمشاركة أيضًا في الإيرادات الطويلة، بل إنه أثرى أيضًا عرض الألعاب بشكل طبيعي. من خلال هذه الطريقة، نجحنا في تحويل الحماس القصير الأمد للمستخدمين إلى دافع مستمر للنمو، مما فتح طريقًا جديدًا لتطوير ألعاب الويب 3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
كفريق تطوير ألعاب صغير مكون من 12 شخصًا ، كان أكبر تحدٍ واجهناه في العامين الماضيين ليس صعوبة إطلاق اللعبة ، ولكن مشكلة انخفاض معدل الاحتفاظ بالمستخدمين. بعد انتهاء كل حدث ، تنخفض حماسة اللعبة بسرعة إلى الصفر؛ وغالبًا ما تستغرق المفاوضات مع العلامات التجارية الأخرى نصف شهر ، بينما تؤدي تسوية الحسابات إلى جدل آخر يستمر لنصف شهر؛ وتعتمد خدمة العملاء بشكل كبير على العلاقات العامة ، حيث تظل التقييمات السلبية والعمليات الرمادية دائمًا كظل.
حتى نقرر الانتقال إلى منصة Hemi، كان هذا القرار ناتجًا عن فكرة بسيطة وقوية: جعل النظام منظمًا وتحويل حماس المستخدمين إلى نمو مستدام. فيما يلي إجراءات التشغيل القياسية التي قمنا بتنفيذها خلال 60 يومًا، وقد قمنا بتوثيقها بأكبر قدر ممكن من التفصيل حتى تتمكن الفرق الأخرى من الرجوع إليها ونسخها.
في الأيام من 1 إلى 7، ركزنا على تجزئة المكونات وبناء السلالات. قمنا بتجزئة النصوص، والموسيقى، والشخصيات، والتأثيرات الخاصة، وعناصر الخرائط في اللعبة، وقمنا بتحديد معلومات الترخيص وخطط توزيع الأرباح لكل مكون. في الوقت نفسه، وضعنا قوالب حقوق تتضمن التذاكر، وبطاقات الموسم، والتذاكر، والشارات، التي تغطي القوائم البيضاء، والحدود، وفترات الانتظار، والقواعد الثانوية، ومنحنى الفتح، وشروط الخدمة. الهدف من ذلك هو تضمين النقاط المثيرة للجدل المحتملة في العقد الذكي قبل إطلاق اللعبة، وذلك لتقليل الجدل خلال فترة النشاط.
في الفترة من اليوم الثامن إلى اليوم الرابع عشر، نركز على تحسين تجربة الدخول وآلية التسوية الجماعية. لقد اعتمدنا تقنية تجريد الحساب ونموذج رعاية رسوم الغاز، وعند ظروف الشبكة السيئة أو خلال أوقات الذروة، نقوم بتقليص التفاعلات إلى الحد الأدنى من الوحدات القابلة للتحقق. نحن نسمح للمستخدمين باللعب أولاً ثم التسوية، أو استلام المكافآت أولاً ثم التسوية، وقد نفذنا وظيفة كتابة الإيصالات بعد إدخال البيانات بشكل جماعي على السلسلة. هذه التحسينات مكنتنا من معالجة عشرة أضعاف الطلبات المتزامنة المعتادة خلال 15 دقيقة عند فتح الخدمة لأول مرة، مما ساعد في تجنب الرأي السلبي "توقف الخادم" على وسائل التواصل الاجتماعي.
في الأيام 15 إلى 21، أعدنا تعريف طريقة الربط بين الألعاب، لم نعد مقيدين بدمج العوالم، بل استندنا إلى الشهادات الرقمية. تعاونّا مع استوديوهات الألعاب المجاورة لتحقيق "مهام عبر الخادم": يمكن لحاملي بطاقة الموسم من الطرف الآخر الاستفادة من ميزة عدم الانتظار في لعبتنا، بينما يمكن لـ "شعارات المدينة" الخاصة بنا فتح بيض عيد الفصح الخاص في لعبتهم. هذه الآلية للربط مقيدة للغاية، حيث تتعلق فقط بقراءة دلالات الشهادات، وضبط شروط التفعيل، وتوزيع الأرباح بناءً على السلالات.
هذا النموذج الجديد للتشغيل لا يتيح فقط للإيرادات العودة عبر سلسلة المساهمات، مما يسمح للمطورين الذين يقدمون المكونات الأساسية بالمشاركة أيضًا في الإيرادات الطويلة، بل إنه أثرى أيضًا عرض الألعاب بشكل طبيعي. من خلال هذه الطريقة، نجحنا في تحويل الحماس القصير الأمد للمستخدمين إلى دافع مستمر للنمو، مما فتح طريقًا جديدًا لتطوير ألعاب الويب 3.