إذا لم يتم أخذ إصدارات Android في الاعتبار وعشرات المشاريع التي تم التخلي عنها مباشرة قبل أن تكون جاهزة ، فعندئذ ، نعم ، إنها أول لعبة مناسبة لأكثر من منصة واحدة. كيف بدأ كل شيء؟ بكل بساطة لقد عملنا في مشروع آخر ، دعنا نسميه "المشروع A" ، وكنا نعمل عليه لفترة طويلة عندما قررنا إنشاء لعبة خلال بضعة أشهر واستخدامها لتدريب مهاراتنا التسويقية ، ثم على الفور أطلق "مشروعنا A" عندما نكون أكثر خبرة في الترويج للألعاب. لكن الخطة فشلت وظل "المشروع أ" على حاله طوال العام. لكن هذه القصة لا تدور حول "المشروع أ" ، بل تدور حول لعبة منطقية تسمى "التكعيب: لغز الشريحة".
كانت المسودة الأولى هي: الحد الأدنى من الرسومات ، والحد الأدنى لواجهة المستخدم وأيضًا الحد الأدنى من كل شيء ممكن ، يجب أن تكون اللعبة في نمط الألعاب غير الرسمية اليوم التي تغمر السوق بالإضافة إلى المباراة 3. نتيجةً لذلك ، بدا هدفنا على هذا النحو: يتم توصيل الرموز المستديرة في الشكل ، ويتم نقلها بضربة رباعية. يعرف أولئك الذين لعبوا Cubicity بالفعل أننا لم نغير المهمة تمامًا ، لكننا قمنا بتحسين الجوانب الأخرى بقوة كوننا فريقًا من شخصين فقط.
إذا توقع بعض القراء أن يجدوا هنا سر تطوير اللعبة الناجحة والسريعة ، فلا يوجد مثل هذا السر. هنا لا نشارك خبرة أو معرفة واسعة ، فنحن فقط نحكي قصة مشروع شركة صغيرة واحدة. ونحن لا نعرف حتى الآن ، سواء كانت ناجحة أم لا. لكن بالنسبة للكثيرين منكم ، قرائنا ، هذه رسالة من الماضي أرسلها المطورون.
دعنا نعود إلى تاريخ كيفية إنشاء التكعيب. بشكل أساسي ، نعمل فقط مع Unity ، وهنا هي المجموعة القياسية لكل مطور Unity لائق: Newtonsoft.json ، Zenject ، Cinemachine ، Dotween ، إلخ. كما يمكن رؤيته في الصورة أعلاه ، فإن النموذج الأولي للعبة تضمن مكعبات ورقائق فقط. بعد أسبوع من الأفكار حول كيفية تحسين اللعبة وجذب اللاعبين ، كانت هناك لحظة يوريكا ... للبحث عن بعض الشخصيات المكعبة أو المستديرة في متجر الأصول. وهكذا تم شراء حزم قليلة من الشخصيات دون تردد. حدث نفس الموقف مع الكتل التي تتحرك عليها الشخصيات الآن. كما تمت كتابة قائمة بعناصر اللعب الجديدة مع ما يقرب من 30 عنصرًا جديدًا اخترنا منه أولاً أشياء محايدة مثل كتل / أسهم إعادة التوجيه والمصعد والنقل الفضائي. قررنا ترك الباقي لمستويات جديدة وتقديمها واحدة تلو الأخرى في 30-35 المستويات.
لكي نكون صادقين ، لا يمكننا حتى أن نتذكر ما الذي ألهمنا لجعل العديد من المستويات في الخطوة الأولى ، ولكن لدينا ما لدينا ، وبالتالي فإن الإصدار الأول تضمن 95 مستوى. إن قول الحقيقة كثيرًا جدًا ، ونحن نأسف لذلك. لماذا نأسف؟ لأن اللعبة لم تكن جاهزة تمامًا وتم تغيير العديد من الأشياء بعد الإصدار. يبدو أننا كنا عالقين في يوم جرذ الأرض ، لأننا كنا بحاجة لإجراء تعديلات في كل مستوى من أصل 95. أمضى شهرين من العمل المستمر على جميع المستويات. ومع ذلك ، لم تكن تلك المستويات جاهزة بنسبة 100٪ ولكننا لم نكن بعيدين عن ذلك. في الأيام الأكثر إنتاجية ، تم نقل 10 مستويات بسهولة من الرأس إلى الورقة وبعد ذلك إلى مكان الحادث. ولكن كان هناك أيضًا أيام تشعر فيها أنك هانك مودي من كاليفورنيا ، الذي يعاني من كتلة الكاتب ، وتعتقد أنك وصلت إلى القاع ، لكن اليوم الجديد يجلب أفكارًا جديدة.
فيما يتعلق بالمكون البصري ، كان الأمر أصعب قليلاً. يتم الرسم كما هو الحال في معظم الألعاب على السطح الخارجي للشاشة بدقة أقل من الشاشة الأصلية ويمزج السطح الأولي ، لكن واجهة المستخدم مرسومة دون أي تغييرات في الدقة لتحسين الوضوح وسهولة القراءة. وبالتالي ، نحصل على أفضل ما في العالمين - وليس واجهة مستخدم ضبابية ، وليس أداءً ثقيلًا في اللعبة. بعد العديد من التجارب ، اخترنا 2x MSAA + FXAA للتظليل ، لأنها تعطي أفضل صورة بأقل قدر من الموارد. لقد توصلنا بشكل معقول إلى أن اللعبة المنطقية لا تحتاج إلى 60 إطارًا في الثانية ، وقررنا عدم إعادة اختراع العجلة وتعيين الحد الأقصى للإطار على 30 إطارًا في الثانية (حتى لوحات المفاتيح عادة ما تفعل ذلك). تعيين حد الإطار له تأثير إيجابي ليس فقط على استهلاك الطاقة ، ولكن أيضًا على تسخين الهاتف ، مما يمنع الهاتف من الاختناق بسبب ارتفاع درجة الحرارة.
بعد ذلك ، كان علينا اتخاذ قرار صعب ، وكان ذلك هو إنهاء النقاط. في كل مرة يتم فيها بدء المستوى ، يتم اختيار الشخصيات بشكل عشوائي من تلك المتاحة للاعب ، ولهذا السبب سيكون من الصعب رسم شخصية مصغرة لبعض الشخصيات. قد لا تصدق ذلك ، لكننا أمضينا وقتًا طويلاً في حل هذه المهمة بعد المماطلة عليها باستمرار. لا تبدو المكعبات في نقاط النهاية فكرة رهيبة ، وقد ساعدت اللوحة الورقية في تجاوز المستوى ووضع الجميع في المكان المناسب. فيما بعد ، تقرر استخدام نفس الأحرف بدلاً من المكعبات ، ولكن بحجم أصغر. أصبح أفضل ، ولكن فقط بالنسبة لنا. بعد بضعة أيام ، تم قلب هذه الشخصيات وتسليط الضوء عليها ، وأصبح من الواضح أكثر من هو ، ولكن لا يزال غير مرض. تم تبني الإصدار النهائي بعد شهر واحد ، عن طريق التجربة والخطأ ، وبعد ذلك قضى أسبوعين في إنشاء أيقونات للتشطيبات. وداعا الصيف ، أراك قريباً مرة أخرى!
في رأينا المتواضع ، تبين أن السحب تبدو لطيفة إلى حد ما. ولكن في الواقع هذا هو أبسط اختراق. عندما قررنا فقط إضافة السحب ، كان الفكر الأول هو إنتاج فيديو بخلفية 360. فشل هذا النهج ، كما هو الحال بالنسبة لمنصات المحمول فمن المستحسن أن تناسب اللعبة في الحد الأقصى للحجم للتنزيل عبر LTE. إذا أردنا ألا يكون الفيديو مضغوطًا بشكل مفرط ، فعلينا إعطاؤه 10-15 ميغابايت. بالاقتران مع وجود مستويات ليلية في اللعبة بسحاباتها ، يكون حجمها أكثر من اللازم (يستغرق إنشاء لعبة Android النهائية بالكامل 61 ميجابايت). كانت الرغبة الثانية في كتابة نظامنا الخاص للسحب. كان من المغري بالنسبة لمطور ما ، ولكن بالنسبة للشخص الذي أراد إنهاء اللعبة في أسرع وقت ممكن ، لم يكن ذلك مناسبًا. جاء الحل في شكل تكوين نسيج للسحابة وإنشاء نظام من الجسيمات مع عمر لانهائي للجسيم ، وكذلك عدد محدود من الجزيئات بشكل عام. بعد ذلك ، أضفنا أحجامًا عشوائية بين ثوابتين مع دوران عشوائي. كانت النتيجة مرضية حقًا ، كانت سماءنا مليئة بالغيوم التي كانت جميلة ولم تجعلنا نبكي عليها.
تتكون الظلال في اللعبة (في إصدار الهاتف المحمول) بالكامل من كواد يتم ترتيبها ببساطة باليد ، لأننا لم نرغب في إضافة ظلال حقيقية إلى إصدار الهاتف المحمول. أحد الأسباب هو غياب الظلال الناعمة على الأنظمة الأساسية المحمولة مع OpenGLES 2.0 ، وبطبيعة الحال ، تدهور الأداء على الأجهزة الضعيفة.
كما ذكرنا سابقًا ، استخدمنا 2x MSAA + FXAA لمكافحة التعرجات ، ولكن هذا ليس كل شيء! لقد أضفنا AmplifyColor أيضًا إلى معالجة المنشورات ، حيث إنها ميزة رائعة مقابل نقود معقولة تتيح لك تطبيق Lut-s مختلفة على معالجة المنشورات. لوت المحدد بشكل صحيح يجعل الصورة تتحسن. خلال عملية التطوير ، جربنا طرقًا مختلفة ، بما في ذلك حزمة معالجة ما بعد الوحدة القياسية ، ولكن في البنية ، استحوذت على خيارات التظليل والخيارات كثيرًا. كانت بعض الحلول جميلة للغاية ، لكنها كانت تعمل بشكل سيء للغاية على الهواتف غير الحديثة جدًا (صدقوني ، إذا كنت تعتقد أن كل شخص لديه الآن هاتف "طبيعي" على الأقل ، فأنت مخطئ. لا يزال عدد كبير من الناس يمتلكون 40 هاتفًا صينيًا ويشكون لك في التعليقات أن DOOM الخاص بك لا تسير على ما يرام في القمامة الخاصة بهم).
ليس من السهل الوصول إلى رصيد اللعبة دائمًا ، وحتى الآن نعتقد في بعض الأحيان أن المستويات قد تكون صعبة للغاية ، وأن تلك المستويات الصعبة قد تظهر كثيرًا وما إلى ذلك. بعد تحقيق التوازن قدر الإمكان ، قررنا تقديم أدوات لجعل الحياة أسهل بالنسبة للاعب (الانتقال إلى الخلف ، والقنبلة ، و Ice Block ، و Teleport) ، ونعم ، أصبح العيش أسهل ، ولكن ليس بالنسبة لنا ، فقط للاعبين في المستقبل. زيادة حجم العمل والبق بالنسبة لنا.
وصلنا إلى قائمة اللعبة ، مع تراجع قوتنا وتراجع الأعصاب. ضرب الإبداع الفرامل. بصراحة ، كان علينا أن نحصل على الإلهام من الألعاب الأخرى ، التي نشكرهم عليها كثيرًا. وأخيراً فعلنا ذلك ، كانت واجهة المستخدم جاهزة للتخطيطات السابقة.
أردنا أن نكون من المألوف كذلك. لذلك قررنا إضافة التوفير على التخزين السحابي ولم نندم عليه. لم تكن هذه المهمة أسهل ، حيث يوجد على منصات مختلفة موفري تخزين سحابي مختلفين. على Steam هناك Steamworks ، للجوال هو GooglePlay و GameRoom. لذلك كان علينا توحيد نظام الادخار بحيث يمكن استبداله بالنظام الأساسي المطلوب. في البداية ، قررنا استخدام EasyMobile لهذه الأغراض ، ولكن سرعان ما تخلينا عن هذه الفكرة. المكوّن الإضافي جيد جدًا ولديه عدد كبير من الاحتمالات ، لكننا لم نحب العمل مع المستودعات السحابية الأصلية. نتيجة لذلك ، اخترنا قاعدة بيانات Firebase Realtime Database ومصادقة Facebook. باختصار ، كان علينا أن نذهب إلى الجحيم لنجعل كل شيء يعمل (وهذا لا يتعلق بالبرمجة ، بل حول 100500 من الإعدادات التي كان يجب إجراؤها في 100500 موقع للتطبيق وفي Facebook ، Firebase إلخ). يوجد أيضًا في قاعدة البيانات حدود لحركة المرور ولحفظها ، في كل مرة نكتب فيها ، نقوم بإنشاء GUID ونكتبه على قاعدة البيانات وعلى الجهاز. وبالتالي ، إذا رأينا أن GUIDs على الجهاز وفي التطابق السحابي ، فيمكننا التأكد من أننا لسنا بحاجة لقراءة جميع البيانات من السحابة ، ولكن يمكننا استخدام نسخة محلية من البيانات. نتيجة لذلك ، تمت إضافة التزامن ، ولكن ... كان أحد أكثر الأخطاء التي نواجهها بالنسبة لنا هو السلوك غير الواضح لقاعدة بيانات Firebase في بعض الحالات. نظرًا لأننا نستخدم Json ، فإننا نقوم بتسلسل الفصول لتخزين الحالة ، لكن Firebase يتصرف أحيانًا بطريقة غريبة بعض الشيء.
إذا مررنا كائن قاموس إلى Firebase ، على سبيل المثال:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() };
عندما نقرأها من قاعدة البيانات ، لن نحصل على كائن Json ، لكننا سنحصل على صفيف Json (ماذا؟)
حسنًا ، حسناً ، سوف نستخدم القوائم في كل مكان ولن تواجهنا مشاكل ، أليس كذلك؟ ولكن يبدو أن هذا غير صحيح.
إذا كتبنا في Firebase:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() };
أو حتى:
var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() };
عندما نقرأها من قاعدة البيانات ، سوف نحصل على كائن Json مع المفاتيح والقيم.
حسنًا ، يمكن فهم منطق المطورين ، ولكنه قد يؤدي إلى الأخطاء التي قد تظهر بعد فترة من الوقت (هل تتذكر المعرفات الفريدة العمومية للحفظ التي ذكرناها أعلاه؟ ونتيجة لذلك ، نادرة القراءة من قاعدة البيانات مع إدخالات متكررة نسبيًا عليها) .
متى يتم الإصدار؟ سمع هذا السؤال في أغلب الأحيان. ولكن كان من الضروري الاستعداد جيدًا لهذا اليوم. كان علينا إعداد قائمة بالأسواق ، واختيار تاريخ الإصدار ، وتجنب المبيعات الكبيرة ، وكان هناك الكثير من الفروق الدقيقة التي أدت إلى تأخير الإصدار لمدة شهرين تقريبًا. بعد نصيحة مقال واحد ، اخترنا الثلاثاء والأربعاء للنشر. قررنا طلب مراجعة على 4pds ، وإخبار اللعبة في العديد من المنتديات والإعلان عنها في الشبكات الاجتماعية ، في Instagram على وجه الخصوص (بالطبع ، مقابل رسوم). ما نجح من كل هذا ، سوف تجد من الجزء الثاني من هذه القصة ، ولكن هذا في وقت لاحق.
ماذا لدينا في النهاية؟ إنشاء لعبة ليست دائمًا عملية سريعة. ومن الممكن أن يتضاعف الوقت المتوقع لتطوير اللعبة بـ 5. احصل على أشخاص يمكنهم مساعدتك بمشورة عملية في الصناعات غير المألوفة. استرخ في كل فرصة ، لأن إنشاء شيء ، وليس مجرد ألعاب ، يستهلك الكثير من الطاقة. ليس من الصواب أن تكون قريبًا من الشعور بالإرهاق وأن تكون أقل فائدة منه في بداية المشروع. والمال ، ابحث عن المال ، ستحتاجه. ومن منا ، شكرا لك على اهتمامك ، حظا سعيدا وأراك في المقال التالي.