هل مشروع Unity الحالي جاهز للنقل إلى Android وiOS؟

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

عند البحث عن game porting services لا يكفي أن تسأل: «هل يمكن إخراج APK أو مشروع Xcode؟». السؤال الذي يحمي قرارك هو: ما الذي سينتقل كما هو، وما الذي يحتاج تعديلًا، وما المعلومة الناقصة التي تمنع تقدير النطاق؟ هذا الدليل يضع فحصًا قصيرًا قبل طلب العرض، ولا يفترض خدمة نقل إلى أجهزة الألعاب المنزلية أو دعم أي محرك غير المشروع الذي تمت مراجعته.

ما المقصود بنقل لعبة Unity موجودة؟

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

تسمح Build Profiles في Unity 6 بحفظ إعدادات بناء متعددة لكل منصة. هذه بداية منظمة، لكنها لا تثبت أن كود اللعبة وأصولها وخدماتها الخارجية تعمل داخل قيود Android وiOS. كما توضح متطلبات تشغيل Unity 6 اختلاف الحد الأدنى لأنظمة الموبايل وواجهات الرسوم وأدوات التطوير؛ لذلك يجب تثبيت إصدار المشروع وبيئة البناء ضمن الفحص.

ابدأ بحزمة يمكن مراجعتها، لا بفيديو للعبة

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

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

مصفوفة فحص قابلية النقل قبل التسعير

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

المسار	قابل للنقل	يحتاج تعديل	يمنع التقدير
المصدر والبناء	يفتح ويبني من نسخة موثقة	تحديث حزم أو إعدادات منصة	سورس ناقص أو نسخة Unity مجهولة
التحكم	طبقة إدخال منفصلة وقابلة لإعادة الربط	إضافة لمس وإيماءات وردود بصرية	منطق اللعب مربوط مباشرة بلوحة المفاتيح أو أجهزة خاصة
الواجهة	Layout مرن ونصوص قابلة للاختبار	ضبط نسب الشاشة والمساحات الآمنة	شاشات ثابتة بلا ملفات أو مرجع قابل للتعديل
الإضافات	دعم موثق للمنصتين ومفاتيح متاحة	ترقية أو استبدال محدود	إضافة مهجورة أو ترخيص/حساب غير متاح
الأداء والذاكرة	العينة ضمن ميزانية الجهاز المستهدف	خفض كلفة الرسوم والأصول والتحميل	لا توجد نسخة Profiling أو أجهزة قبول محددة
الحفظ والخدمات	العقود والبيئات التجريبية موثقة	تكييف دورة الحياة أو تسجيل الدخول	اعتماد على حسابات أو أسرار غير مملوكة للمشروع

افصل بين نجاح البناء وصلاحية تجربة اللعب

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

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

قِس الأداء على الجهاز المستهدف

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

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

اختبر شريحة رأسية قبل تسعير المشروع كله

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

1. ثبّت commit وإصدار المحرك والحزم وبيئة الاختبار.
2. ابنِ نسخة مرجعية قبل أي تعديل وسجّل الأخطاء الحالية.
3. أنشئ إعداد منصة منفصلًا ولا تخلط تعديلات النقل مع إصلاحات غير متفق عليها.
4. نفّذ التحكم والواجهة والإضافة الأكثر خطورة داخل الشريحة.
5. شغّل Profiling على جهاز منخفض وآخر ممثل للجمهور.
6. أخرج قائمة: صالح كما هو، تعديل معروف، سؤال يمنع التقدير.

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

ما الذي يجب أن يخرج من فحص النقل؟

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

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

اعرف قابلية مشروعك للنقل قبل الالتزام بالتنفيذ

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

استعرض خدمة تطوير ألعاب الموبايل — اطلب فحص مشروعك على واتساب