1.5 تفاوت موتورهای بازی بین ژانرهای مختلف (Engine Differences Across Game Genres)

با اینکه اکثر موتورهای بازی مدرن از اجزای مشابهی تشکیل شدن (مثل سیستم رندر، فیزیک، صدا و غیره)،
اما نیازهای خاص هر ژانر بازی باعث می‌شه ساختار موتور بازی متفاوت بشه.

 چند مثال از تفاوت‌ها:

•  بازی‌های شوتر اول شخص (FPS)
  نیاز به دقت بالا در برخوردها (collision) و فیزیک دقیق تیراندازی
  پشتیبانی از سلاح‌های متنوع، ذرات (particles)، و نورهای دینامیک
  اغلب نیازمند نت‌کد قوی برای بازی‌های آنلاین چندنفره

• بازی‌های مسابقه‌ای (Racing)
  شبیه‌سازی دقیق فیزیک وسایل نقلیه
  پشتیبانی از مسیرهای طولانی و open-world
  افکت‌های تصویری خاص مثل motion blur، depth of field

•  بازی‌های نقش‌آفرینی (RPG)
  سیستم دیالوگ و کوئست‌های شاخه‌دار
  نیاز به ذخیره‌سازی گسترده دیتا (inventory، level، world state)
  هوش مصنوعی پیچیده برای NPCها

• بازی‌های مبارزه‌ای (Fighting)
  زمان‌بندی خیلی دقیق (فریم دقیق)
  انیمیشن‌های سینک‌شده بین دو کاراکتر
  مدیریت دقیق comboها، hitboxها، و stateهای پیچیده
   

به طور خلاصه تر:

میتونیم به این نتیجه برسیم که:

هر ژانر، اولویت‌های خودش رو دارهو مهندسان موتور معمولاً موتور رو برای اون ژانر بهینه‌سازی می‌کنن. مثلاً Unreal Engine برای شوتر عالیه، اما برای بازی استراتژیک real-time (RTS) شاید نیاز داره که تغییراتی داشته باشه.

نکته طلایی:در شرکت‌های حرفه‌ای، حتی با اینکه موتور پایه ثابته (مثل Unreal)، معمولاً زیرسیستم‌هایی به‌صورت سفارشی‌سازی‌شده برای ژانر خاص اضافه می‌شن یا تغییر داده می‌شن.

پس در طراحی موتور باید توجه کرد که آیا موتور قراره چند ژانر رو ساپورت کنه یا فقط برای یه سبک خاص می‌ساخته میشه.

1.6 مرور موتورهای بازی (Game Engine Survey)

هدف این بخش، آشنایی با چند موتور بازی معروف که در صنعت استفاده می‌شن، تا بفهمیم هر کدوم چه ویژگی‌هایی دارن، برای چه سبک‌هایی مناسبن و چرا اهمیت دارن.

موتورهای بررسی‌شده در این بخش:

•  Unreal Engine (Epic Games):
  یکی از قدرتمندترین موتورهای بازی دنیا
  مخصوص بازی‌های تیراندازی، اکشن، سینمایی
  پشتیبانی قوی از گرافیک سه‌بعدی پیشرفته
  دارای ابزارهای داخلی زیاد (مثل Blueprint، Material Editor)
  قابل استفاده برای بازی‌های موبایل تا AAA

به‌دلیل ساختار ماژولار، برای ژانرهای مختلف قابل گسترشه و کدنویسی با ++C و scripting با Blueprints

• Unity:
  بسیار محبوب برای توسعه مستقل (indie)، موبایل، دوبعدی، و حتی واقعیت مجازی (VR/AR)
  سبک‌تر از Unreal و یادگیری راحت‌تر
  پشتیبانی از زبان C#
  امکانات خوب برای 2D و 3D
  قابل استفاده برای پلتفرم‌های زیاد (PC، موبایل، کنسول، وب)

 موتور پیش‌فرض فیزیک و رندر ضعیف‌تر از Unreal برای پروژه‌های AAA اما بسیار قابل شخصی‌سازی هست

•  CryEngine (Crytek):
  معروف به موتور با گرافیک خارق‌العاده
  مناسب برای بازی‌های open-world و شبیه‌سازی‌های سنگین
  پیاده‌سازی فیزیک پیچیده، نورپردازی واقع‌گرایانه، و پوشش محیطی گسترده
  یادگیریش سخت‌تر از Unity و Unreal

---------------------------------------------------------------------------------------------------------------------------------------------------------

•  Source Engine (Valve):
  موتور پشت بازی‌هایی مثل Half-Life، Counter-Strike، Portal
  مناسب برای first-person games
  ابزارهای خوبی برای مدسازی و ساخت محتوا داره
  موتور قدیمی‌تر ولی هنوز هم برای بازی‌های خاص استفاده می‌شه

---------------------------------------------------------------------------------------------------------------------------------------------------------

• Custom In-House Engines:
  بعضی استودیوها موتورهای اختصاصی خودشون رو دارن:
   

این موتورها خیلی به سبک خاص بازی‌های اون استودیو بهینه‌سازی شدن و معمولاً قابل دسترس عمومی نیستن، ولی قدرت فوق‌العاده ای دارن

نکته مهم: انتخاب موتور بستگی به نیازهای بازی داره:

• تیم کوچک، سبک ساده، چندپلتفرمی؟ → Unity
• گرافیک سینمایی، پروژه AAA؟ → Unreal
• آزادی مطلق و قدرت سخت؟ → موتور اختصاصی یا CryEngine

جمع‌بندی بخش 1.6:

1.7 معماری موتور در زمان اجرا (Runtime Engine Architecture)

هدف این بخش: درک ساختار کلی یک موتور بازی هنگام اجرا، یعنی بدون درگیر شدن با جزییات کد، بفهمیم موتور در هر فریم چه کاری انجام می‌ده؟

 موتور بازی در زمان اجرا چه کار می‌کنه؟

در قلب هر موتور بازی یه حلقه‌ی تکرارشونده وجود داره به نام:

Game Loop (حلقه‌ی بازی)

• تو هر فریم (مثلاً 60 بار در ثانیه)، این کارها انجام می‌شن:
• پردازش ورودی (کیبورد، موس، کنترلر)
• به‌روزرسانی وضعیت بازی (موقعیت کاراکتر، فیزیک، انیمیشن، AI و...)
• تولید و پخش صدا
• رسم صحنه (Render) روی صفحه
• رفتن به فریم بعد

اجزای اصلی معماری موتور در زمان اجرا:

Jason Gregory این معماری رو به‌صورت ماژولار در نظر می‌گیره:

فلو (جریان کاری در هر فریم) میتونیم به صورت زیر در نظر بگیریم:

+-------------------+
| Handle Input      |
+-------------------+
| Update Game State |
+-------------------+
| Run Physics       |
+-------------------+
| Process AI        |
+-------------------+
| Update Animations |
+-------------------+
| Play Audio        |
+-------------------+
| Render Scene      |
+-------------------+

نکته مهم:اجرای این مراحل باید خیلی سریع و بهینه انجام بشه(مثلاً در 16 میلی‌ثانیه برای 60fps)، وگرنه بازی لگ می‌زنه یا input delay ایجاد می‌شه.

نکات فنی جالب:

• معماری موتور معمولاً ماژولار و قابل گسترش طراحی می‌شه (هر بخش می‌تونه مستقل توسعه داده بشه)
• گاهی برخی سیستم‌ها به‌صورت parallel اجرا می‌شن (مثلاً AI جدا از Physics)
• موتورهای مدرن گاهی از multi-threading استفاده می‌کنن تا عملکرد بهتر داشته باشن

جمع‌بندی 1.7:

معماری زمان اجرای موتور بازی یعنی: ترکیبی از سیستم‌های ماژولار (input، فیزیک، انیمیشن، AI، رندر...) که در یک حلقه‌ی تکرارشونده (Game Loop) اجرا می‌شن، تا دنیای بازی در زمان واقعی به بازیکن نمایش داده بشه.

1.8 ابزارها و مسیر دارایی‌ها (Tools and the Asset Pipeline)

هدف این بخش: در کنار کدنویسی موتور، تیم‌های بازی‌سازی به ابزارها و یک سیستم مدیریت دارایی (Asset Pipeline) نیاز دارن، تا بتونن محتوای بازی رو (مثل مدل‌ها، صداها، انیمیشن‌ها و...) وارد موتور کنن و ازش استفاده کنن.

بد نیست اول بدونیم: "دارایی (Asset)" اصن چی هست؟

هر چیزی که محتوای بازی رو تشکیل می‌ده:

• مدل سه‌بعدی (Character, Props, Environment)
• تکسچر (Textures, Normal maps)
• صدا (Voice, Music, SFX)
• انیمیشن
• اسکریپت‌ها
• داده‌های مرحله (Level Design)
• حتی داده‌های AI یا گراف گفت‌وگو

ابزارها (Tools)

در تیم‌های حرفه‌ای، معمولاً ابزارهایی خاص ساخته می‌شن تا آرتیست‌ها و دیزاینرها بتونن بدون درگیر شدن با کدنویسی، کار کنن:

Asset Pipeline (مسیر پردازش دارایی‌ها)

یه زنجیره‌ی خودکار از کارهایی هست که از لحظه‌ای که یه فایل ساخته می‌شه تا وقتی تو بازی اجرا بشه، اتفاق می‌افته:

مراحل معمول:

• آرتیست مدل یا صدا رو می‌سازه (مثلاً در Blender یا Pro Tools)
• خروجی رو به فرمت مناسب ذخیره می‌کنه (مثلاً .fbx, .wav, .png)
• ابزار Importer فایل رو می‌گیره و پردازش می‌کنه:
• مثلاً تبدیل به فرمت بهینه برای موتور بازی
• فشرده‌سازی، baking نور یا انیمیشن
• سیستم Asset Database فایل رو ذخیره می‌کنه
• بازی موقع اجرا از این فایل‌ها استفاده می‌کنه (یا در زمان ساخت build می‌شه)

Asset Formats (فرمت‌های خاص درون‌موتوری)

بعضی استودیوها فایل‌ها رو به فرمت اختصاصی خودشون تبدیل می‌کنن (مثلاً .pak, .asset, .uasset تو Unreal) تا: حجم کم‌تر بشه، لود شدن سریع‌تر بشه، از کپی غیرمجاز جلوگیری بشه و … 

Build Tools

موتور معمولاً ابزارهایی داره که هنگام "ساخت نهایی بازی (build)":

• همه دارایی‌ها رو جمع می‌کنه
• اون‌ها رو تبدیل می‌کنه به فایل‌های فشرده و قابل انتشار
• نسخه‌ی نهایی بازی رو می‌سازه برای توزیع روی پلتفرم‌ها

نکات حرفه‌ای:

• بعضی تیم‌ها سیستم version control (مثل Perforce یا Git + LFS) دارن برای دارایی‌ها
• تست خودکار دارایی‌ها ممکنه انجام بشه (مثلاً اگه تکسچر خیلی بزرگ باشه یا ناقص باشه، خطا بده)

جمع‌بندی 1.8:

این بخش بیشتر از بُعد توسعه تیمی مهمه، و پایه‌ی سیستم‌های بعدی مثل Level Streaming، Asset Streaming و Memory Management رو تشکیل می‌ده.