GlamUp Girls: لعبة تلبيس للهاتف (Flutter + Flame، ثلاث لغات)

GlamUp Girls: لعبة تلبيس للهاتف

GlamUp Girls لعبة تلبيس: تختار اللاعبة عارضتها، تضع لها المكياج، تختار الشعر والملابس، ثم تخرج بها إلى منصة العرض. فيها 11 عارضة و918 قطعة ملابس وأربع حزم حيوانات أليفة ومسابقات أسبوعية وشهرية. تعمل بالتركية والإنجليزية والعربية، ولكل لغة تعليق صوتي خاص بها. أول commit كان في 7 نيسان/أبريل 2026، والإصدار الإنتاجي على Google Play في 20 آب/أغسطس 2026. تصنيفها PEGI 3، ضمن فئة الألعاب العادية، وتخضع لسياسة العائلة في Play.

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

ماذا في اللعبة

• 👗 11 عارضة، لكل واحدة 15 فئة، بمجموع 918 قطعة ملابس
• 🐾 4 حزم حيوانات أليفة (قطة وكلب ومهرة ووحيد قرن)، 193 قطعة
• 🌟 نقاط المنصة: 4 فئات في الوضع الحر و5 فئات في المسابقة، على مقياس من 0 إلى 100
• 🏆 مسابقات أسبوعية وشهرية ومجموعة قطع نادرة
• 🌍 واجهة بالتركية والإنجليزية والعربية، تخطيط من اليمين إلى اليسار للعربية، وتعليق صوتي بكل لغة
• 🛡️ بوابة والدية على مداخل الشراء، ومعاملة الإعلانات كإعلانات موجهة للأطفال بتصنيف محتوى G

العمل المنجز

كتبتُ العميل بـ Flutter وFlame: 398 ملف Dart و155,283 سطراً تحت lib/. منطق العمل موزع على 81 صنف خدمة، وحالة الشاشات في 10 أصناف تحت lib/store. الحفظ محلي أولاً على SharedPreferences مقيدة بمعرّف المستخدم، أما المزامنة السحابية فطبقة منفصلة، حتى لا يتعطل اللعب دون اتصال. الخادم على Firebase Cloud Functions: 15 دالة قابلة للاستدعاء، وملف index.js من 2,770 سطراً، ووحدة مستقلة من 629 سطراً للتحقق من المشتريات.

خط إنتاج المحتوى

خزانة الملابس مصمَّمة على شكل 11 عارضة × 15 فئة. وراء تعريفات القطع الـ918 توجد 23 حزمة أصول و14,081 صورة webp منظَّمة. أكثر ما استهلك وقتي كان تنويعات الألوان. في البداية كنت أكتب الأعداد بيدي. كلما أُضيفت قطعة إلى حزمة، يتقادم الجدول وتعرض اللعبة عدداً خاطئاً. الآن يولّد مسحُ الأصول 1,134 مدخلاً (حزمة، بادئة) ويضعها في الشيفرة مباشرة. لم يعد الجدول يتقادم، لأنه لم يعد هناك جدول يدوي أصلاً.

تقييم الإطلالة

التقييم وحدة مستقلة من 15 ملفاً و1,583 سطراً، ستة منها محللات. الإطلالة الحرة تكسب حتى 25 نقطة في كل فئة من أربع؛ وفي المسابقة تُضاف فئة "ملاءمة الموضوع"، فتصبح خمس فئات بعشرين نقطة لكل منها، على مقياس من 0 إلى 100. فوق ذلك مضاعِف ندرة من خمس درجات، من Common ×1.00 إلى Legendary ×1.25. هذه ثوابت في الشيفرة لا ملاحظات في تعليق، فأي تغيير في التصميم يمس موضعاً واحداً.

ثلاث لغات والكتابة من اليمين إلى اليسار

نص الواجهة موزع على 51 ملف ARB في 17 نطاق أسماء: 6,342 سطر مفتاح بالإنجليزية، و6,333 بالتركية، و6,567 بالعربية. سبعة وعشرون اختبار i18n منفصلاً تراقب التطابق بين الملفات وتلتقط أي إنجليزية تتسرب إلى الشاشات العربية.

الدرس الحقيقي جاء من الجانب العربي. حين يقع نص لاتيني، كاسم مستخدم مثلاً، داخل جملة عربية، تنزلق علامة التعجب والنقطة إلى الجهة الخطأ. قستُ ذلك بـ TextPainter بدل الاعتماد على العين: علامة التعجب من دون عزل ظهرت عند x=0.0، ومع عزل FSI/PDI من يونيكود ظهرت عند x=36.1. حين صار الفرق رقماً، صار الإصلاح صغيراً. ولكي لا يعود الخلل، يعدّ اختبارُ حراسة من 261 سطراً استخدامات EdgeInsets.only وfromLTRB وPositioned وTextAlign التي ترسم بصمت في الجهة الخطأ عند الكتابة من اليمين إلى اليسار، ويستثني المتناظر منها.

التعليق الصوتي 30 جملة لكل لغة: 22 للجولة الإرشادية و8 ردود فعل. التركية والإنجليزية من edge-tts (tr-TR-EmelNeural وen-US-AvaNeural)، والعربية من Azure Speech (ar-EG-SalmaNeural). كل لغة مثبَّتة على صوت واحد، فلا يتبدل صوت الشخصية من شاشة إلى أخرى.

الخادم والمشتريات

التحقق من الشراء يجري على الخادم لا في العميل. على iOS أعتمد توقيع JWS من StoreKit 2، وعلى Android واجهة Play Developer API. العملية الموثَّقة تُكتب تحت verified_purchases/{transactionId} بإنشاء ذرّي، فالإيصال نفسه لا يصلح مرتين ولا في حساب آخر. الأخطاء ثلاثة أصناف: الإيصال غير الصالح فعلاً وخطأ الإعداد يُرفضان، أما خطأ الشبكة العابر أو استجابة 5xx فتمرّ بتساهل. هذا الخيار الأخير قابل للنقاش. فضّلتُ نافذة تساهل قصيرة على حرمان طفلة دفعت بالفعل بسبب تعثر مؤقت في الخادم.

فئة الأطفال والامتثال

مداخل الشراء داخل التطبيق تقف خلف حوار تحقق والدي لا يُغلق بالنقر خارجه: سؤال جمع يُختار حدّاه عشوائياً بين 12 و19 (الجواب بين 24 و38)، وسؤال جديد بعد 600 ميلي ثانية من كل إجابة خاطئة، والتحقق الناجح يبقى في الذاكرة 15 دقيقة.

على جانب الإعلانات لا توجد بوابة كهذه، وأقولها صراحة لأن مسودتي الأولى زعمت العكس، وكذّبتها الشيفرة. الإعلانات مقيدة بالمعاملة الموجهة للأطفال وبتصنيف محتوى G، وقبل تهيئة الحزمة البرمجية يعمل مسار موافقة Google UMP بمهلة 8 ثوانٍ.

سطح الاختبار

3,883 حالة في 424 ملف اختبار، مع 27 ملف اختبار على المحاكي لجانب Firestore وCloud Functions. يُضاف إليها 11 حارس انحدار باسم *_guard_test.dart: ستة تمسح المصدر على القرص وتقفل نمطاً برمجياً في CI، وخمسة تتحقق من السلوك. مصفوفة الفيض تشغّل 43 شاشة على 13 عرضاً، واختبار تغطية منفصل يقارن سجل الشاشات بملفات *_screen.dart على القرص، فأي شاشة جديدة غابت عن السجل تحوّل CI إلى الأحمر.

الصعوبات التقنية

• تقادم أعداد تنويعات الألوان في جدول يدوي؛ حُلّت بتوليد الجدول من مسح الأصول
• انزياح الترقيم عند وقوع نص لاتيني داخل جملة عربية؛ قياس ثم عزل FSI/PDI
• إعادة استخدام إيصال الشراء أو نقله إلى حساب آخر؛ أُغلق بالإنشاء الذرّي
• الإبقاء على بوابة الشراء وموافقة الإعلانات آليتين منفصلتين في فئة الأطفال
• نسيان إضافة شاشة جديدة إلى مصفوفة الفيض؛ اختبار التغطية يلتقطه في CI

لماذا كان مهماً

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

بالأرقام

خلاصة

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