خبرنگار بخش ایران
مارپو یکی از بازی‌های آنلاین ایرانی است که با الهام از بازی قدیمی مار و پله ساخته شده است. توسعه این بازی را استودیوی «بازی‌بی» بر عهده داشته؛ مجموعه‌ای که پیش از این با انتشار منچ‌باز، تجربه ساخت بازی‌های رومیزی دیجیتال و چندنفره را به دست آورده بود. با این حال روایت این استودیو نشان می‌دهد تبدیل یک سرگرمی آشنا به محصولی آنلاین، چالش‌هایی فراتر از طراحی و پیاده‌سازی قواعد بازی به همراه داشته است.
«سجاد عشقی آزاد»، مدیر ارشد محصول این استودیو، در نشست تجربه بازی‌ساز (GDX) توضیح داد که تیم سازنده در مسیر توسعه مارپو با مشکلاتی از جمله هماهنگی تیم‌های مستقر در سه استان، ناپایداری اینترنت، مدیریت اقتصاد درون‌بازی و مقابله با تقلب روبه‌رو بوده است.
عشقی آزاد در این نشست که روز ۲۰ آبان ۱۴۰۵ در عمارت بلدیه تهران و با میزبانی انستیتو ملی بازی‌سازان برگزار شد، درباره تصمیم‌های طراحی، تجربه‌های تجاری و فنی و مسیری صحبت کرد که مارپو را از یک ایده اولیه به محصولی آنلاین تبدیل کرد. او همچنین توضیح داد که چرا بازی‌بی پس از تجربه «منچ‌باز» سراغ ساخت یک بازی آشنای دیگر رفت و چه درس‌هایی از پروژه‌های قبلی خود گرفت.
چرا بازی‌بی سراغ ساخت مارپو رفت؟
ایده ساخت مارپو از تجربه بازی‌بی در توسعه منچ‌باز شکل گرفت. این استودیو پس از موفقیت منچ‌باز تصمیم گرفت سراغ یک بازی رومیزی آشنا و محبوب دیگر برود؛ محصولی که کاربران ایرانی از دوران کودکی با آن خاطره داشته باشند.
عشقی آزاد درباره منطق این تصمیم گفت:
«منچ، بازی‌ای است که خیلی‌ها می‌شناسندش. تقریباً فکر نمی‌کنم کسی در جمع ما باشد که یک بار در کودکی منچ بازی نکرده باشد. گفتیم چه بازی دیگری می‌توانیم انتخاب کنیم که برای کاربر ایرانی همین ماهیت را داشته باشد و از دوران کودکی با آن آشنا باشد؟ برای ما، مار و پله پاسخ این سوال بود.»
بااین‌حال، انتخاب مار و پله به‌عنوان پروژه بعدی بدون تردید و نگرانی نبود. مدیر محصول بازی‌بی توضیح داد که یکی از پرسش‌های اصلی تیم این بود که چرا تاکنون یک محصول مستقل و موفق از بازی مار و پله، چه در بازار ایران و چه در بازار بین‌المللی، شکل نگرفته است.
او این پرسش را برای خودش به‌عنوان مدیر محصول «ترسناک» توصیف کرد، اما در نهایت تصمیم گرفتند با اتکا به تجربه‌های منچ‌باز وارد این مسیر شوند:
«با مرور همان دستاوردهایی که منچ‌باز داشت و دانشی که کسب کرده بودیم، به این نتیجه رسیدم که پروژه‌ی مارپو هم باید جواب دهد. تصمیم گرفتیم این تجربه را هم کسب کنیم و اگر جوابی که می‌خواستیم نگرفتیم، دست کم چیزهای جدیدی یاد می‌گیریم؛ مثل پروژه‌ی نقطه خط» نقطه خط یکی دیگر از محصولات بازی‌بی است که پس از منچ‌باز تولید و منتشر شده.»
عشقی آزاد در ادامه به رویکردی اشاره کرد که بازی‌بی در انتخاب پروژه‌های جدید دنبال می‌کند: «یک اشتباهی که بعضی از استودیوها می‌کنند این است که یک پروژه می‌سازند و بعد می‌گویند برویم سراغ IP بعدی. هر IP جدید یعنی تجربه‌های جدید و هر IP جدید یعنی چالش‌های جدید که برای به دست آوردن آن‌ها باید هزینه‌شان را هم بپردازید. مادامی که می‌شود از تجربه‌های قبلی استفاده کرد و روی آن ساخت و بالا آمد، چرا باید سراغ یک مسیر کاملاً جدید برویم؟»
تفاوت مارپو با منچ‌باز در چیست؟
یکی از چالش‌های بازی‌بی در توسعه مارپو، ایجاد تفاوت میان این بازی و منچ‌باز بود. تیم سازنده نمی‌خواست کاربران با ورود به محصول جدید، همان تجربه قبلی را با ظاهری متفاوت تکرار کنند.
عشقی آزاد توضیح داد که تیم برای ایجاد این تمایز، از طراحی متفاوتی برای صفحه بازی استفاده کرد و برخی از مکانیک‌های اصلی را تغییر داد. برای مثال، بازیکنان به‌جای یک تاس از دو تاس استفاده می‌کنند. این تاس‌ها قابلیت‌های مشخصی دارند و امکان ارتقای آن‌ها نیز وجود دارد. در نتیجه، بازی مارپو در مقایسه با منچ‌باز عناصر استراتژیک بیشتری دارد.
او همچنین به اهمیت ایجاد تجربه‌ای مستقل برای کاربران مشترک دو بازی اشاره کرد. به گفته او، تیم سازنده نمی‌خواست بازیکنی که پیش‌تر در منچ‌باز برای خرید آواتار یا آیتم‌های ظاهری هزینه کرده، احساس کند باید همان خریدها را دوباره در مارپو انجام دهد.
عشقی آزاد در این‌باره گفت:
«نمی‌خواستیم بازیکنی که از منچ‌باز وارد این بازی می‌شود، بگوید دوباره باید برای همان آواتار یا همان آیتم‌های ظاهری پول بدهم. می‌خواستیم تجربه متفاوتی برایش رقم بزنیم؛ اینکه بگوید من منچ بازی کردم و حالا روزی دو دست هم مار و پله بازی کنم و فضای متفاوتی را تجربه کنم.»
او همچنین به عملکرد «منچ ایکس»، یکی دیگر از پروژه‌های بازی‌بی، اشاره کرد. به گفته عشقی آزاد، توسعه منچ ایکس و مارپو تقریباً هم‌زمان آغاز شده، اما منچ‌ایکس به دلیل گستردگی بیشتر، دیرتر منتشر شده است. او در زمان برگزاری نشست گفت شاخص‌های کلیدی عملکرد منچ‌ایکس حدود ۲۰ تا ۳۰ درصد پایین‌تر از منچ‌باز است؛ اختلافی که با توجه به عمر حدود پنج‌ماهه این محصول، از نظر او طبیعی است.
شکست یک پروژه چگونه به تصمیم‌گیری برای پروژه بعدی کمک می‌کند؟
بخشی از نشست به تجربه بازی‌بی در توسعه پروژه نقطه‌خط و معیارهای تصمیم‌گیری برای ادامه یا توقف یک بازی اختصاص داشت. یکی از حاضران از عشقی آزاد پرسید که استودیو بر چه اساسی به این نتیجه می‌رسد یک پروژه شکست خورده و باید توسعه آن را متوقف کند.
مدیر محصول بازی‌بی توضیح داد که هر پروژه از ابتدای شکل‌گیری، یک سند برنامه تولید (Production Plan) دارد. در این سند، انتظارات تیم از محصول، شاخص‌های کلیدی عملکرد، اهداف مربوط به نرخ بازگشت کاربران و درآمد و همچنین مراحل مختلف توسعه مشخص می‌شوند.
او درباره این فرایند گفت: «هر پروژه‌ای که از روز اول در استودیو شروع می‌شود، یک سری مستندات دارد. در سند برنامه تولید پیش‌بینی می‌کنیم که چه انتظاری از پروژه داریم. شاخص‌های کلیدی عملکرد و هدف‌ها مشخص می‌شوند؛ اینکه از لحاظ تعامل کاربران به چه نرخ بازگشت روز اول و روز هفتمی برسیم و به چه شاخص‌های درآمدی دست پیدا کنیم.»
به گفته او، استودیو پیش از آغاز تولید، هزینه‌های منابع انسانی، هزینه‌های سربار و سایر مخارج را محاسبه می‌کند تا نقطه بازگشت سرمایه پروژه مشخص شود. در کنار این موضوع، عملکرد کمپین‌های تبلیغاتی و میزان درآمدی که هر کاربر جذب‌شده ایجاد می‌کند نیز اهمیت دارد. این شاخص با عنوان بازگشت سرمایه یا ROI شناخته می‌شود.
عشقی آزاد تأکید کرد که صرف رسیدن یک پروژه به نقطه سودآوری، لزوماً به معنای اقتصادی بودن ادامه توسعه آن نیست. او توضیح داد:
«بعضی پروژه‌ها اصلاً بازگشت سرمایه مثبتی ندارند. بعضی پروژه‌ها بعد از شش ماه به نقطه مثبت می‌رسند، اما وقتی از لحاظ اقتصادی بررسی‌شان می‌کنید، می‌بینید ادامه‌دادنشان به‌صرفه نیست.»
دلیل این اتفاق، هزینه حفظ تیم و منابع موردنیاز برای بهبود شاخص‌های محصول است. به گفته او، اگر استودیو برای رشد KPIها همچنان به نگه‌داشتن نیروی انسانی و صرف هزینه نیاز داشته باشد، ممکن است ادامه پروژه توجیه اقتصادی نداشته باشد.
بااین‌حال، بازی‌بی بلافاصله پس از انتشار درباره توقف یک پروژه تصمیم نمی‌گیرد. تیم ابتدا چند فرصت برای بهبود عملکرد محصول در نظر می‌گیرد و معمولاً چهار تا پنج به‌روزرسانی مشخص برای آن تعریف می‌کند. عشقی آزاد درباره این رویکرد گفت:
«این‌جوری نیست که وقتی پروژه منتشر شد، خیلی سریع تصمیم بگیریم. به آن فرصت می‌دهیم و چند آپدیت، معمولاً چهار تا پنج آپدیت مشخص می‌کنیم که قرار است چه چیزی را بهبود بدهند. اگر توانستند این شاخص‌ها را بهتر کنند، پروژه ادامه پیدا می‌کند؛ اگر نه، بهترین تصمیم این است که پروژه متوقف شود.»
توصیه مدیر محصول بازی‌بی به استودیوهای بازی‌سازی
عشقی آزاد یکی از اشتباهات رایج در فرایند توسعه بازی را بزرگ‌شدن بیش از اندازه محدوده پروژه دانست. به گفته او، اضافه‌کردن مداوم قابلیت‌ها، انیمیشن‌ها و جزئیات جدید می‌تواند پروژه‌ای را که قرار بوده در شش ماه آماده شود، به محصولی با بیش از یک سال زمان توسعه تبدیل کند.
او درباره این چالش گفت: «هر پروژه‌ای را می‌توانید آن‌قدر بزرگ کنید که هیچ‌وقت جمع نشود. تصمیم‌گیری درباره محدوده و اسکوپ پروژه یکی از سخت‌ترین تصمیم‌هایی است که باید در روند تولید بگیرید.»
عشقی آزاد در همین زمینه بر اهمیت کوتاه‌کردن زمان ورود محصول به بازار (Time to Market) تأکید کرد و گفت استودیوها باید با استفاده از ابزارهای جدید، از جمله هوش مصنوعی، زمان رسیدن به محصول را کاهش دهند.
او پیشنهاد کرد تیم‌ها به‌جای صرف زمان طولانی برای ساخت محصولی با تمام قابلیت‌های احتمالی، ابتدا یک نسخه حداقل محصول پذیرفتنی (MVP) تولید کنند. البته منظور او ارائه محصولی ناقص نیست؛ بلکه نسخه‌ای است که قابلیت‌های ضروری را داشته باشد و پس از انتشار، بر اساس رفتار واقعی کاربران توسعه پیدا کند.
«یک نسخه MVP تعریف کنید؛ نه اینکه محصول را ناقص ارائه بدهید، بلکه یک محصول کمینه ارائه کنید که هر چیزی را که برای محصول لازم است داشته باشد. بعد از انتشار، خود بازیکن به شما می‌گوید چه می‌خواهد.»
او با اشاره به مثال معروف هنری فورد درباره تولید خودرو توضیح داد که مخاطبان همیشه نمی‌توانند راه‌حل مناسب نیازهای خود را به‌درستی بیان کنند. بنابراین بازی‌سازان باید نیاز واقعی کاربران را بشناسند و پس از عرضه محصول، از رفتار آن‌ها برای تصمیم‌گیری درباره مسیر توسعه استفاده کنند.
توسعه مارپو در سه استان و انتشار هم‌زمان با قطعی اینترنت
یکی از بخش‌های مهم صحبت‌های عشقی آزاد به شرایط خاص توسعه و انتشار مارپو اختصاص داشت. به گفته او، این پروژه با همکاری تیم‌هایی در سه استان پیش رفت. استودیوی بازی‌بی در کرج مستقر بود، بخش فنی پروژه با همکاری یک استودیوی دیگر در مشهد توسعه پیدا کرد و مسئولیت انتشار و پشتیبانی محصول نیز بر عهده استودیوی مدریک در تهران بود.
او هماهنگی میان این تیم‌ها را یکی از چالش‌های شخصی خود در این پروژه دانست و گفت: «این پروژه در سه استان توسعه پیدا کرد. استودیوی ما در کرج بود، با یک استودیوی دیگر در مشهد همکاری داشتیم که بخش فنی پروژه را پیش می‌برد و انتشار و پشتیبانی هم با استودیوی مدریک در تهران بود. هماهنگی بین این سه استان و تیم‌های مختلف برای من یک چالش بود.»
بااین‌حال، مشکلات تیم تنها به هماهنگی میان اعضا محدود نمی‌شد. فرایند طراحی اولیه مارپو هم‌زمان با جنگ ۱۲ روزه آغاز شد؛ دوره‌ای که وضعیت اینترنت و احتمال اختلال در ارتباطات، آینده توسعه یک بازی آنلاین را با ابهام روبه‌رو کرده بود.
عشقی آزاد با یادآوری روزهای ابتدایی توسعه پروژه گفت:
«زمانی که داشتیم نسخه اولیه بازی را روی کاغذ طراحی می‌کردیم و پروتوتایپ را می‌ساختیم، هم‌زمان جنگ ۱۲ روزه شروع شد. شرایط عجیبی بود؛ نمی‌دانستیم اینترنت قرار است قطع شود یا نه و پروژه‌ای که داریم توسعه می‌دهیم، در چنین شرایطی چه وضعیتی پیدا می‌کند.»
در نهایت، مارپو در ۲۲ بهمن سال گذشته و در شرایط قطعی اینترنت منتشر شد. این اتفاق برنامه معمول تیم برای بررسی عملکرد محصول را نیز مختل کرد. عشقی آزاد توضیح داد که در روزهای ابتدایی انتشار، تیم معمولاً با استفاده از داده‌ها عملکرد بازی را بررسی می‌کند؛ اما در آن مقطع دسترسی به ابزارهای تحلیلی و امکان رصد کمپین‌های تبلیغاتی وجود نداشت.
او گفت: «۲۲ بهمن سال گذشته، دقیقاً زمانی که اینترنت قطع بود، بازی منتشر شد. کاری که ما همیشه در روزهای اول بعد از انتشار انجام می‌دهیم، کاملا متکی بر دیتای روزهای اول بازیکنان است؛ اما آن زمان هیچ‌چیزی وجود نداشت. نه به گیم‌آنالیتیکس دسترسی داشتیم و نه می‌توانستیم کمپین‌هایمان را رصد کنیم.»
به گفته او، قطع دسترسی کاربران به برخی سرویس‌های آنلاین باعث شد تعداد زیادی از آن‌ها به فروشگاه‌های داخلی مراجعه کنند و بازی‌های جدید را نصب کنند. در همین دوره، منچ‌باز به رکورد قابل‌توجهی از تعداد مسابقات (مچ) هم‌زمان رسید؛ رکوردی که به گفته عشقی آزاد حتی از تعداد مسابقات هم‌زمان برخی بازی‌های شناخته‌شده رایانه‌ای نیز بیشتر بود.
این افزایش ناگهانی کاربران، مشکلاتی برای زیرساخت سرورها ایجاد کرد. تیم باید محصولی را که تازه منتشر شده بود و هنوز باگ‌ها و مشکلات پایداری داشت، برای حجم بالایی از کاربران آماده نگه می‌داشت.
عشقی آزاد همچنین به چالش دیگری پس از بازگشت اینترنت اشاره کرد. با دسترسی دوباره کاربران به سرویس‌هایی مانند اینستاگرام و تلگرام، بخشی از مخاطبانی که در دوره قطعی اینترنت به بازی‌ها روی آورده بودند، از محصولات خارج شدند. علاوه بر این، بازشدن دسترسی به فروشگاه‌های خارجی مانند گوگل‌پلی، نیاز به بازنگری در برنامه انتشار بازی را ایجاد کرد.
از طراحی مارها تا اقتصاد آرناها؛ جزئیاتی که تجربه کاربر را شکل می‌دهند
مدیر محصول بازی‌بی در ادامه به چالش‌های طراحی بازی اشاره کرد. به گفته او، هدف تیم این بود که هویت ساده و آشنای مار و پله حفظ شود و در عین حال، تجربه‌ای آنلاین و مناسب برای رقابت میان کاربران شکل بگیرد.
عشقی آزاد درباره این رویکرد گفت: «نمی‌خواستیم بازی شناخته‌شده‌ای مثل مار و پله را به یک چیز عجیب‌وغریب تبدیل کنیم. همان سادگی‌ای که بازی رومیزی مار و پله داشت، باید در این پروژه هم حفظ می‌شد؛ فقط می‌خواستیم آن را به یک تجربه آنلاین تبدیل کنیم.»
یکی از چالش‌های طراحی، جانمایی مارها و نردبان‌ها بود. این عناصر به‌صورت تصادفی روی صفحه قرار نگرفته‌اند و تیم سازنده برای هرکدام تصمیم مشخصی گرفته است. برای مثال، سازندگان باید مراقب باشند تعداد نردبان‌ها به شکلی نباشد که بازی بیش از اندازه سریع تمام شود یا جانمایی مارها باعث تکرار بیش از حد یک مسیر و خستگی بازیکن شود.
او در توضیح این بخش گفت:
«شاید به نظر نیاید، اما مار و پله هم لول دیزاین دارد. جانمایی تمام مارها و نردبان‌ها دانه‌به‌دانه طراحی شده است. باید بررسی می‌کردیم چه اتفاقی بیفتد که بازیکن خسته نشود، یک مسیر تکراری شکل نگیرد یا بازیکن با چند بار تاس ریختن به‌راحتی به خانه پایانی نرسد و بازی در دو دقیقه تمام نشود.»
تیم همچنین درباره قوانینی مانند نحوه برخورد مهره‌ها با یکدیگر تصمیم‌گیری کرده است؛ از جمله اینکه اگر بازیکنی مهره حریف را بزند، آن مهره از صفحه خارج شود یا در همان مسیر باقی بماند. به گفته عشقی آزاد، این تغییرات با هدف افزایش تعامل میان بازیکنان انجام شده‌اند؛ بدون اینکه سادگی و هویت اصلی مار و پله از بین برود.
بخش دیگری از طراحی مارپو به ارتباط میان اقتصاد بازی و طراحی هنری مربوط می‌شود. در این بازی، بازیکنان می‌توانند وارد آرناهای مختلفی شوند که هرکدام ورودی متفاوتی دارند. برای مثال، ورود به یک آرنا ممکن است ۱۰۰ سکه و ورود به آرنای دیگری ۱۰ هزار سکه هزینه داشته باشد.
به گفته عشقی آزاد، بازیکنی که برای ورود به آرنای گران‌تر هزینه می‌کند، انتظار تجربه‌ای متفاوت و سطح بالاتر دارد. او توضیح داد: «بازیکنی که ۱۰ هزار سکه ورودی می‌دهد، به‌نوعی بازیکن پریمیوم محسوب می‌شود و انتظار تجربه پریمیوم هم دارد. به همین خاطر، به کسی که ۱۰۰ سکه هزینه کرده یک برد چوبی نشان می‌دهیم، اما برای کسی که هزینه بیشتری می‌کند، فضای متفاوت‌تر و لوکس‌تری با رنگ طلایی می‌سازیم.»
او همچنین تأکید کرد که طراحی هنری مارپو با توجه به جامعه هدف آن انجام شده است. عشقی آزاد گفت طبق داده‌های استودیو، ترکیب کاربران مارپو و منچ‌باز حدود ۵۵ درصد مرد و ۴۵ درصد زن است و میانگین سنی بخش قابل‌توجهی از آن‌ها در محدوده ۳۰ تا ۴۵ سال قرار دارد.
او در این‌باره گفت: «وقتی برای این دسته از بازیکنان بازی توسعه می‌دهید، نمی‌توانید آرت‌استایل پروژه را کودکانه انتخاب کنید. مارها و طراحی صفحه بازی هم حالت کودکانه ندارند و این ظاهر با توجه به مخاطب بازی انتخاب شده است.»
پایداری سرورها و مقابله با تقلب؛ چالش همیشگی بازی‌های آنلاین
عشقی آزاد در بخش فنی نشست، پایداری سرورها و هماهنگی آن‌ها با اتفاقات داخل بازی را از مهم‌ترین چالش‌های توسعه یک محصول آنلاین دانست.
در بازی‌هایی مانند مارپو، هر حرکت بازیکنان باید با سرور هماهنگ باشد. اگر کاربر در میانه یک مسابقه به دلیل تماس تلفنی یا ناپایداری اینترنت از بازی خارج شود، باید بتواند در کوتاه‌ترین زمان ممکن به همان مسابقه بازگردد. این قابلیت با عنوان Rejoin شناخته می‌شود.
او برای توضیح اهمیت این قابلیت، شرایطی را مثال زد که بازیکن در لحظه‌ای حساس از مسابقه به دلیل تماس تلفنی یا قطع اینترنت خارج می‌شود. اگر فرایند بازگشت او بیش از اندازه طول بکشد، ممکن است وضعیت مسابقه تغییر کند و نتیجه‌ای متفاوت از آنچه پیش از خروج در جریان بوده، رقم بخورد.
عشقی آزاد گفت این موضوع در پروژه‌های قبلی بارها تیم را در روزهای پایانی انتشار درگیر کرده است: «انقدر مسئله ری‌جوین در پروژه‌های قبلی اذیتم کرده که در پروژه‌های جدید، بچه‌ها می‌دانند باید در هفته دوم و سوم، ۲۰ بار آن را تست کنیم. بازگشت سریع بازیکن به بازی مسئله خیلی مهمی است.»
موضوع دیگر، مقابله با تقلب و سوءاستفاده از مکانیک‌های بازی است. عشقی آزاد توضیح داد که تیم باید تا جای ممکن اطلاعات حساس، به‌خصوص داده‌های مربوط به اقتصاد درون‌بازی، را در سمت سرور کنترل کند. به این روش Server Authoritative گفته می‌شود.
او برای توضیح اهمیت این موضوع به تجربه یکی از پروژه‌های استودیو اشاره کرد؛ جایی که برخی بازیکنان با استفاده از قابلیت بازی با دوستان، از مکانیک‌های بازی برای انتقال غیرمجاز سکه به یکدیگر استفاده کرده بودند. در این روش، بازیکن با ورود به یک آرنای گران‌قیمت و خروج عمدی از مسابقه، امکان انتقال سکه‌های خود به دوستانش را فراهم می‌کرد. در نتیجه، تعدادی از کاربران به حجم زیادی از سکه دسترسی پیدا کردند و عملاً نیازی به خرید دوباره آن نداشتند.
عشقی آزاد درباره این اتفاق گفت:
«یک بازیکن با قابلیت بازی با دوستان، سه نفر از دوستانش را به یک مسابقه در آرنای آخر می‌برد؛ آرنایی که ورودی آن ۱۰ هزار سکه بود. خودش از بازی خارج می‌شد و سکه‌اش به‌راحتی به دوستانش منتقل می‌شد. در نتیجه، چند صد بازیکن داشتیم که دیگر نیازی به خرید نداشتند و هرکدام چند هزار تا چند صد هزار سکه در اختیار داشتند.»
به گفته او، چنین اتفاقاتی می‌تواند اقتصاد بازی را مختل کند و به همین دلیل، کنترل جابه‌جایی سکه و الماس نباید در اختیار کلاینت یا کاربر باشد. او تأکید کرد که اطلاعات اقتصادی باید از سمت سرور کنترل شوند تا بازیکنان نتوانند با دست‌کاری اطلاعات یا سوءاستفاده از قوانین بازی، تعادل اقتصادی محصول را برهم بزنند.
در پاسخ به سؤال یکی از حاضران درباره اینکه آیا باید از همان مرحله طراحی برای مقابله با تقلب برنامه‌ریزی کرد یا پس از انتشار به سراغ آن رفت، عشقی آزاد توضیح داد که تجربه پروژه‌های قبلی به تیم کمک می‌کند برخی از این مشکلات را پیش‌بینی کند؛ اما رفتار واقعی کاربران تنها پس از عرضه بازی مشخص می‌شود.
او همچنین گفت مقابله با تمام رفتارهای غیرمعمول کاربران همیشه ضروری نیست. به گفته او، برخی رفتارها ممکن است به رقابت و تعامل اجتماعی کمک کنند؛ اما زمانی که تقلب به اقتصاد بازی آسیب بزند و تجربه عمومی کاربران را تحت تأثیر قرار دهد، باید جلوی آن را گرفت.
در پایان، عشقی آزاد به اهمیت آزمایش بازی روی دستگاه‌های مختلف اشاره کرد. به گفته او، بازی‌سازان نباید محصول خود را فقط روی گوشی‌های قدرتمند آزمایش کنند؛ بلکه باید شرایط کاربرانی با گوشی‌های ضعیف‌تر و اینترنت ناپایدار را نیز در نظر بگیرند.
او تأکید کرد: «شما همیشه برای قوی‌ترین گوشی بازی نمی‌سازید. باید توجه کنید که آیا گوشی‌های ضعیف‌تر هم بازی را به‌خوبی اجرا می‌کنند یا نه. خیلی وقت‌ها خودمان گوشی‌های خوبی داریم و وقتی بازی را روی گوشی خودمان تست می‌کنیم، همه‌چیز درست است؛ اما باید شرایط بازیکنانی را هم شبیه‌سازی کنیم که گوشی ضعیف‌تر یا اینترنت ناپایدارتری دارند.»