بهینه‌سازی و انتشار بازی

چرا بهینه‌سازی قبل از انتشار حیاتی است؟

بازی‌ای که روی سیستم توسعه‌دهنده روان است ممکن است روی موبایل یا PC ضعیف کند شود. بازیکن امروز انتظار نرخ فریم پایدار و زمان بارگذاری کوتاه دارد؛ اگر بازی کند باشد، حتی با گیم‌پلی خوب، حذف می‌شود یا رها می‌ماند. بهینه‌سازی تجمل نیست؛ بخشی از تجربهٔ محصول است.

در Unity، مشکلات عملکرد معمولاً از منابع گرافیکی سنگین، فیزیک بیش از حد، تخصیص حافظه در Update، فراخوانی رسم زیاد و نورپردازی نادرست ناشی می‌شوند. خبر خوب: بیشتر این موارد با ابزارهای داخلی Unity قابل شناسایی و اصلاح هستند — اگر روش درست را از ابتدا بشناسید.

Nova Lab در بخش پایانی دوره unity-game-dev به بهینه‌سازی و خروجی می‌پردازد، زیرا دانشجویی که فقط پیش‌نمونه می‌سازد اما نمی‌داند چطور آن را منتشر کند، نیمی از مسیر را طی کرده. هدف: بازی قابل نصب، قابل بازی و قابل نشان دادن در نمونه‌کار.

تفاوت بین «روی لپ‌تاپ من خوب بود» و «روی گوشی دوستم از کار افتاد» درس کلاسیک انتشار است. تست روی دستگاه‌های متنوع — حتی ارزان — قبل از انتشار از آسیب به اعتبار جلوگیری می‌کند و نشان می‌دهد شما مثل توسعه‌دهنده حرفه‌ای فکر می‌کنید.

فهرست سادهٔ «قبل از انتشار» بسازید: بدون از کار افتادن در اولین اجرا، صدا و کنترل درست، متن خوانا، حجم معقول و یک مسیر مشخص برای بازخورد. Nova Lab این فهرست را به‌عنوان بخش تحویل پروژه پایانی استفاده می‌کند.

Profiler و شناسایی گلوگاه

Unity Profiler ابزار اصلی تحلیل عملکرد است. مصرف پردازنده نشان می‌دهد کدام اسکریپت یا سیستم زمان می‌برد؛ پردازندهٔ گرافیکی نشان می‌دهد رندر کجا سنگین است؛ حافظه به نشتی و تخصیص اشاره می‌کند. قبل از هر بهینه‌سازی تصادفی، Profiler را باز کنید و گلوگاه واقعی را پیدا کنید — اغلب با چیزی که حدس زده‌اید متفاوت است.

برای موبایل، Profiler را روی دستگاه واقعی یا با Unity Remote متصل کنید. شبیه‌سازی در ویرایشگر دقیق نیست. زمان هدف هر فریم برای ۶۰ فریم در ثانیه حدود ۱۶٫۶ میلی‌ثانیه و برای ۳۰ فریم حدود ۳۳ میلی‌ثانیه است. اگر از این بیشتر است، باید بفهمید کدام بخش مقصر است.

در تمرین Nova Lab، دانشجویان یک صحنه با مشکل عملکرد عمدی را با Profiler تحلیل می‌کنند و گزارش کوتاهی می‌دهند: مشکل، علت، راه‌حل. این مهارت در تیم‌های حرفه‌ای روزانه استفاده می‌شود و تفاوت بین «فکر می‌کنم کند است» و «می‌دانم چرا کند است» را مشخص می‌کند.

Frame Debugger برای مشکلات رندر مفید است: هر فراخوانی رسم را می‌بینید و می‌فهمید چرا پردازندهٔ گرافیکی مشغول است. ترکیب Profiler و Frame Debugger معمولاً هشتاد درصد مشکلات عملکرد رایج در پروژه‌های آموزشی را پوشش می‌دهد.

هنگام تحلیل عملکرد، یک سناریوی ثابت را تکرار کنید: همان مسیر حرکت، همان مبارزه. بدون سناریوی ثابت، مقایسه قبل و بعد از بهینه‌سازی گمراه‌کننده می‌شود. در Nova Lab این روش «خط پایه به‌علاوهٔ تغییر» را در گزارش عملکرد تمرین می‌دهیم.

بهینه‌سازی گرافیک و رندر

کاهش فراخوانی رسم با دسته‌بندی، استفاده از اطلس برای تصویر دوبعدی، محدود کردن رسم روی هم و انتخاب شیدر مناسب تأثیر زیادی دارد. برای سه‌بعدی، سطح جزئیات برای مدل‌های دور، حذف اشیاء پنهان و تنظیم فاصلهٔ سایه مهم هستند. Quality Settings در Unity به شما اجازه می‌دهد سطوح مختلف گرافیک برای دستگاه‌های ضعیف و قوی تعریف کنید.

بافت‌ها را با اندازه مناسب وارد کنید — بافت ۴K برای آیکون رابط تلفن اشتباه است. فرمت فشرده‌سازی بسته به پلتفرم (Android، iOS) متفاوت است. پخت نور برای محیط‌های ثابت به‌جای نور لحظه‌ای همه‌جا، در بسیاری از بازی‌های موبایل انتخاب هوشمند است.

قانون عملی: هر دارایی گرافیکی باید «دلیل وجود» داشته باشد. اگر ظاهر تأثیری روی گیم‌پلی ندارد و عملکرد را می‌خورد، ساده‌اش کنید یا حذف کنید. بازی مستقل موفق اغلب با سبک هنری ساده اما یکدست، عملکرد بهتری از بازی شلوغ با دارایی‌های ناهماهنگ دارد.

URP برای بسیاری از پروژه‌های موبایل و مستقل انتخاب پیش‌فرض مدرن Unity است. در Nova Lab با تنظیمات پایهٔ URP آشنا می‌شوید: کیفیت سایه، مقیاس رندر و پس‌پردازش فقط وقتی لازم است فعال شوند.

کد و حافظه: جمع‌آوری زباله و تخصیص

در Unity، تخصیص حافظه در مسیر داغ — مثل Update در هر فریم — می‌تواند جهش جمع‌آوری زباله بسازد و افت ناگهانی فریم ایجاد کند. از ساخت شیء جدید در Update (مثل چسباندن رشته یا لیست تازه) پرهیز کنید. استخر شیء برای گلوله، دشمن و ذره رایج است. struct به‌جای class در موارد مناسب می‌تواند تخصیص را کم کند.

Coroutine و رویداد برای زمان‌بندی بهتر از بررسی بی‌پایان است. Find و GetComponent در Update ممنوع — در Awake یا Start ذخیره کنید. این قوانین ساده‌اند اما اگر از روز اول رعایت شوند، اشکال‌زدایی عملکرد در انتها بسیار کمتر می‌شود.

StringBuilder برای به‌روزرسانی متن رابط مکرر (مثل امتیاز) از چسباندن معمولی رشته بهتر است. برای پیش‌نمونهٔ ساده شاید تفاوت کم باشد، اما در خروجی موبایل با رابط پر از متن زنده، تخصیص کمتر محسوس است.

Memory Profiler برای پیدا کردن نشتی و دارایی‌های بارگذاری‌شده اما استفاده‌نشده مفید است. پس از هر نشست بازی، حافظه باید به سطح پایدار برگردد؛ اگر مدام بالا می‌رود، نشتی دارید. Nova Lab در بازبینی کد پروژه‌های پایانی این موارد را چک می‌کند.

فیزیک هم می‌تواند گلوگاه باشد: برخوردهای پیچیده، جسم صلب زیاد و گام زمانی نامناسب. ساده‌تر کردن مش برخورد و کاهش تعداد جسم پویا اغلب بدون تغییر ظاهر نتیجهٔ محسوس می‌دهد.

تنظیمات خروجی و Player Settings

قبل از خروجی، پلتفرم هدف را در Build Settings انتخاب کنید. Player Settings شامل نام بسته، آیکون، جهت صفحه (برای موبایل)، بستر اسکریپت (IL2CPP برای موبایل و کنسول رایج است) و سطوح API می‌شود. هر پلتفرم فهرست خاص خود را دارد — Android نیاز به keystore، iOS نیاز به حساب Apple Developer دارد.

خروجی توسعه با اتصال خودکار Profiler برای تست نهایی قبل از خروجی انتشار مفید است. خروجی انتشار باید بدون سربار اشکال‌زدایی و با بهینه‌سازی فعال باشد. صحنه‌های داخل خروجی را مدیریت کنید — فقط صحنه‌های لازم را بگذارید تا حجم و زمان بارگذاری کم شود.

در دوره Nova Lab، دانشجویان حداقل یک خروجی PC (Windows) و در صورت امکان فایل Android تحویل می‌دهند. تجربه نصب بازی روی دستگاه دیگر — نه فقط اجرا در ویرایشگر — درس مهمی درباره مسیر واقعی تا بازیکن است.

حجم خروجی را با فشرده‌سازی، حذف دارایی‌های استفاده‌نشده و تقسیم بسته برای Android مدیریت کنید. کاربر موبایل حجم بالا و نصب طولانی را کمتر تحمل می‌کند؛ برای اولین انتشار، سبک‌تر بهتر از پر از قابلیت و سنگین است.

انتشار روی پلتفرم‌های مختلف

برای PC، انتشار مستقیم (وب‌سایت شخصی، itch.io، Steam) مسیرهای رایج هستند. Steam نیاز به فرآیند بررسی و Steamworks دارد؛ itch.io برای بازی مستقل و پیش‌نمونه بسیار در دسترس است. برای موبایل، Google Play و App Store درگاه‌های اصلی هستند — هر کدام سیاست، ردهٔ سنی و اطلاعات فروشگاه خاص می‌خواهند.

قبل از ارسال، صفحهٔ فروشگاه را آماده کنید: توضیح کوتاه، تصویرهای واقعی گیم‌پلی، آیکون با اندازه‌های استاندارد و در صورت نیاز تریلر کوتاه. بازی در اولین اجرا از کار نیفتد — تست روی چند دستگاه یا شبیه‌ساز. رد شدن اولیه در فروشگاه‌ها شایع است؛ بازخورد را بخوانید و اصلاح کنید.

برای بازار ایران، انتشار بین‌المللی ممکن است محدودیت پرداخت و دسترسی داشته باشد؛ اما خروجی و نمونه‌کار محلی هم ارزش دارد. بسیاری از دانشجویان Nova Lab بازی را برای نمایش در کلاس، رویداد یا شبکه‌های اجتماعی منتشر می‌کنند — این هم شروع معتبر انتشار است.

صفحهٔ فرود ساده با لینک دانلود، توضیح کوتاه و تصویر متحرک گیم‌پلی برای انتشار مستقل کافی است. حتی بدون فروشگاه، شما روند «ساخت → خروجی → توزیع» را کامل کرده‌اید — همان چیزی که کارفرما در موقعیت تازه‌کار می‌خواهد ببیند.

برای itch.io یا انتشار مستقیم، فایل راهنمای کوتاه با نیازمندی‌های سیستم و نحوه اجرا به تجربه کاربر کمک می‌کند. این جزئیات کوچک حرفه‌ای‌گری شما را نشان می‌دهد و از سوالات تکراری جلوگیری می‌کند.

نگهداری، آپدیت و مسیر بعد از انتشار

انتشار نقطه پایان توسعه اولیه نیست. گزارش اشکال از بازیکن، آمار استفاده (با رعایت حریم خصوصی) و نظرات به شما می‌گویند کجا وصله یا به‌روزرسانی محتوا لازم است. شماره‌گذاری منظم نسخه (۱.۰.۱ برای رفع اشکال) اعتماد بازیکن را حفظ می‌کند.

برای بازی‌های زنده، بهینه‌سازی مداوم با هر آپدیت محتوا مهم است — دارایی جدید ممکن است عملکرد قبلی را خراب کند. آزمون بازگشت: بعد از هر تغییر بزرگ، Profiler را دوباره اجرا کنید. این عادت در استودیوهای حرفه‌ای جا افتاده است.

فهرست تغییرات عمومی برای بازیکنان کوچک هم مفید است: «نسخه ۱.۰.۱ — رفع از کار افتادن در سطح دوم» اعتماد می‌سازد. برای نمونه‌کار، لینک به خروجی‌های مختلف نشان می‌دهد شما محصول را زنده نگه می‌دارید.

اگر دوره unity-game-dev را در Nova Lab گذرانده‌اید، شما پیش‌نمونه ساخته، بهینه کرده و خروجی گرفته‌اید — یعنی چرخه کامل را یک بار دیده‌اید. قدم بعدی: پروژه شخصی بزرگ‌تر، شرکت در مسابقهٔ فشردهٔ ساخت بازی، یا تخصص در یک حوزه (رابط، شبکه، شیدر). بهینه‌سازی و انتشار مهارت‌هایی هستند که با هر پروژه Unity عمیق‌تر می‌شوند؛ هر بازی منتشرشده خط بعدی رزومه شماست.

گروه دانشجویان Nova Lab منبع خوبی برای گزارش اشکال و ایدهٔ آپدیت بعد از انتشار اول است. نگه داشتن حلقهٔ بازخورد حتی برای بازی کوچک، شما را در ذهنیت محصول زنده نگه می‌دارد — تفاوت بین کسی که یک بار بازی ساخته و کسی که در حال ساخت محصول است.