آموزش بازی سازی: چالش‌های پیاده‌سازی یک اتمسفر جذاب

شاید بعد از پرداختن به موضوعات مختلفی از قبیل رنگ‌شناسی، نورپردازی، افکت‌های بصری و مدیریت دوربین دیگر وقت آن رسیده باشد که در رابطه با مبحث اتمسفر در بازی‌های ویدیویی صحبت کنیم. با این که معمولا برای دستیابی به چنین چیزی صرفا نمای بصری بازی اهمیت ندارد، اما با این حال باز هم نمی‌توان از نقش پررنگ آن در این مسئله چشم‌پوشی کرد. در بسیاری از موارد برای ما پیش آمده که صرفا با دیدن چندین عکس از محیط یک بازی غرق در اتمسفر آن شده باشیم و همین مسئله نشان‌دهنده‌ی میزان تاثیر نمای بصری در شکل‌گیری اتمسفر یک بازی است.

طراحی سیستمی را در اولویت قرار دهید

اولین چیزی که بهتر است به آن توجه داشته باشید این است که سعی کنید به جای خلق لحظه به لحظه‌ی اتمسفر بازی آن را به صورت یکپارچه و سیستمی طراحی و پیاده‌سازی کنید. به عنوان مثال اگر ویدیو‌های ساخت بازی Alan Wakeرا مشاهده کنید می‌بینید که سازندگان به جای خلق موردی اتسمفر بازی سیستمی را طراحی کرده‌اند که به وسیله‌ی آن می‌توانند در کسری از ثانیه شرایط آب و هوایی را تغییر داده و مدل‌های مختلفی از وزش باد و طوفان را شبیه‌سازی کنند.

شاید چنین چیزی برای بازی‌های مستقل کوچک بیش از حد بزرگ و هزینه‌بر باشد ولی با الهام‌گیری از چنین اقداماتی ما نیز می‌توانیم در مقیاسی کوچک‌تر از آن بهره‌ برده و سرعت ساخت بازی خود را افزایش دهیم. بدون شک یکی از مشکلاتی که در بازی‌سازی مستقل وجود دارد، کوتاه بودن گیم‌پلی بازی‌ها و محیط‌های آنان است و دلیل این مسئله غالبا در پیاده‌سازی مورد به مورد اجزای درون بازی است. اما هنگامی که به صورت سیستمی عمل کنیم شاید در ابتدا وقت بیشتری از ما گرفته شود ولی بعد از آن قادر خواهیم بود در حجم بسیار بیشتری از مراحل عناصر مورد نظر خودمان را قرار دهیم. از نمونه‌های دیگر در این زمینه می‌توانیم به بازی Hellbalde اشاره کنیم که در آن هم سازندگان در مقیاسی کوچک‌تر از بازی Alan Wake سعی کرده‌اند سیستم مخصوص و ویژه‌ی خودشان را برای اتسمفر بازی طراحی و پیاده‌سازی کنند. با این که چندین بار به این موضوع اشاره کرده‌ایم ولی باز هم روی آن تاکید می‌کنیم که هر چقدر که می‌توانید سعی کنید ویدیو‌‌های ساخت بازی‌های مختلف را مشاهده کرده و این گونه روش صحیح انجام کارهای مختلف را از حرفه‌هایی این صنعت یاد بگیرید. شما می‌توانید بخشی از پشت صحنه‌ی بازی Alan Wake را از این لینک و ویدیویی مربوط به Hellblade را از این لینک مشاهده کنید.

هزینه‌های سنگین پردازش باید مدیریت شوند

کافی است کمی به بازی‌هایی از قبیل سری بازی‌های Metro نگاه بیاندازید و به سرعت عاشق اتمسفر غنی آن‌ بشوید. اما پیاده‌سازی چنین اتمسفری بسیار سنگین و از لحاظ فنی هزینه‌بر است. شاید در مقاله‌های قبلی ما به فراوان در مورد راه‌های افزایش کیفیت بصری بازی صحبت کردیم ولی بدون شک یک بازی صرفا از عناصر بصری تشکیل نشده است. از هوش مصنوعی بازی گرفته تا محاسباتی که مثلا برای هر تیر شلیک شده باید صورت بگیرد همه و همه دست به دست هم می‌دهند که فضا برای اعمال افکت‌های بصری محدود شود.

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

نکته‌ی بعد استفاده از الگوریتم‌های بهینه در طراحی سیستم‌های بصری بازی است. شاید در نگاه ساده برای شبیه‌سازی حرکت ویژه‌ای از یک گردباد بتوانید از معادله‌ایی ۳ مجهولی به همراه یکسری توابع سینوسی استفاده کنید ولی هنگامی که صحبت از مدیریت هزاران ذره به صورت همزمان پیش می‌آید تک تک عبارات به کار رفته در این معادله می‌تواند برای شما بسیار هزینه‌بر باشد. البته در الگوریتم‌ها معمولا رشته‌ای از معادلات و محاسبات مورد استفاده قرار می‌گیرد و برای همین اهمیت این مسئله دوچندان می‌شود. معمولا این گونه است که شما باید میان دو مسئله‌ی تخصیص منابع سخت‌افزاری و همچنین دقت محاسباتی که به دنبال آن هستید تعادل برقرار کنید. همواره می‌توان از الگوریتم‌های دقیق‌تر در انجام کارها استفاده کرد ولی اینکه حد و مرز تخصیص منابع تا کجا خواهد بود سوالی است که شما باید به آن پاسخ بدهید.

البته همه چیز صرفا در ساختار الگوریتم‌ها هم نهفته نیست و گاهی مرتبه‌ی اجرای آنان هم حائز اهمیت است. مثلا ممکن است استفاده از یک الگوریتم در حالی که نرخ فریم بازی روی ۶۰ قرار دارد چندان به صرفه نباشد ولی همین الگوریتم در نرخ ۳۰ فریم در ثانیه هیچ مشکلی ایجاد نکرده و نتیجه‌ی مطلوب ما را به همراه خواهد داشت. دقت کنید که برای دستیابی به نرخ فریم ۶۰ بار در ثانیه شما باید هر فریم را حداقل در ۱۶ میلی ثانیه پردازش کنید و این در حالی است که در نرخ فریم ۳۰ این مقدار به حدودا ۳۳ میلی ثانیه افزایش پیدا می‌کند.

نکته‌ی فنی که در این بخش از مطلب قرار دارد این است که ما برای انجام بسیاری از عملیات‌های درون بازی هیچ نیازی به این موضوع نداریم که حتما آن عملیات متناسب با نرخ فریم بازی تکرار شود که از نمونه‌های آن می‌توانیم به اطلاعات نمایش داده شده روی HUD بازی اشاره کنیم. توجه به این مسئله موقعی اهمیت دارد که بسیاری از موتورها به صورت پیش‌فرض اطلاعات را متناسب با نرخ فریم بازی بروز می‌کنند و این گونه منابع سخت‌افزاری سیستم را برای یک کار بیهوده هدر می‌دهند. شما می‌توانید با رعایت چنین نکاتی از بار پردازشی به خصوص پردازنده‌ی مرکزی سیستم کم کرده و آن را در جای دیگری هزینه کنید.

به دلیل محدودیت شدید منابع سخت‌افزاری و همچنین محدودیتی که برای پردازش فریم‌های بازی پیش‌روی ما قرار دارد معمولا برای پیاده‌سازی هر یک از جلوه‌های بصری، حقه‌ای گرافیکی به وجود آمده که یادگیری آنان برای هر بازی‌سازی تقریبا واجب است. مثلا برای شبیه‌سازی یک رودخانه یا آبشار استفاده از سیستم ذرات و شبیه‌سازی واقعی آب صد در صد منتفی است و حتی فکر این که بتوانید این گونه یک جوی کوچک آب را هم شبیه‌سازی کنید باید از سر خود بیرون کنید. در عوض می‌توانید به راحتی با استفاده از کمی شیدر نویسی و حرکت دادن بافت‌ها روی عناصر، حرکت آب را با تقریب مناسبی در حالی شبیه‌سازی کنید که هیچ فشاری از این جهت روی منابع سخت‌افزاری شما نباشد. در انتها هم می‌توانید با استفاده از چند سیستم ذرات بسیار مختصر محل‌های ریزش آب یا برخورد آن با اجسام را جزییات ببخشید که باز هم در انجام همین کار هم حقه‌هایی وجود دارد تا بار نهایی پردازش به کمترین حالت ممکن برسد. با این که تقریبا بیشتر توسعه‌دهندگان از همین روش برای شبیه‌سازی آب استفاده می‌کنند ولی به عنوان یک نمونه‌ی مشهور بد نیست بدانید که بخش بزرگی از کاراکتر پوزایدون در بازی God of Warکه پوشیده از آب بود به این روش تولید شده است.

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

با این که در مقاله‌ای جداگانه به مبحث پروفایلرها و نحوه‌ی کار با آن‌ها خواهیم پرداخت ولی بد نیست بدانید که در این ابزارها صرفا شما نباید به دنبال مثلا حجم رم یا حافظه‌ی گرافیکی مصرف شده باشید و گاهی زمان مثلا ۷ میلی ثانیه‌ای مصرف شده برای پردازش اسکریپت موجود در یک صحنه همان مشکلی است که شما به دنبال آن بوده‌اید. برای همین استخراج اطلاعات از درون پروفایلرها اگر چه بسیار راحت است اما آن قدری دارای جزییات است که هر کسی نمی‌تواند از پس آن برآید و این در حالی است که معمولا پروفایلرها هم فقط مسئول استخراج کردن داده‌ها هستند و این شما هستید که باید با تحلیل این داده‌ها نقطه‌های مشکل آفرین را شناسایی کنید.

جمع‌بندی

صرفا همین دو عنوان اشاره شده خود به میزانی دارای زیرشاخه‌های فنی است که یادگیری حرفه‌ای آنان توسط یک نفر چندان کار معقولانه‌ای نیست. برای همین اگر از لحاظ تعداد نفرات دچار محدودیت هستید بهتر است مثلا همان برنامه‌نویس تیم که باید با انواع الگوریتم‌ها آشنایی داشته باشد مسئولیت کار با پروفایلر را هم برعهده بگیرد چرا که به نسبت دیگر اعضای گروه درک بهتری روی تک تک میلی ثانیه‌های مصرف شده دارد.

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

در انتها باید به این نکته اشاره کنیم خلق یک اتمسفر جذاب و گیرا جدای از مسائل فنی قرار گرفته در پشت آن در وهله‌ی اول یک کار هنری است و نباید این جنبه از کار فراموش شود.