2.1 زبان‌های برنامه‌نویسی (Programming Languages)

یکی از اولین تصمیم‌هایی که توسعه‌دهندگان موتور بازی باهاش روبه‌رو می‌شن اینه که:

 با چه زبانی موتور رو بسازیم؟

اکثر موتورهای بازی صنعتی، مخصوصاً AAA با زبان ++C نوشته شدن. دلیلش واضحه:

چرا ++C؟

• قدرت بسیار بالا در کنترل حافظه و عملکرد پایین‌سطحی
• پرفرمنس عالی برای رندر، فیزیک، محاسبات گرافیکی
• قابلیت پیاده‌سازی سیستم‌های پیچیده real-time
• پشتیبانی از برنامه‌نویسی شی‌گرا (OOP)، چندریسمانی (Multithreading)، templateها
•  …

با اینکه C++ یادگیری سخت‌تری نسبت به زبان‌های مثل Python یا C# داره، ولی برای ساخت موتورهایی که باید در حد نانوثانیه سریع و بهینه باشن، تنها انتخاب واقعیه.
موتورهایی که با ++C نوشته شدن:

بقیه زبان‌ها چی؟ (مثلاً C#, Python, Lua)

•  #C:
  معمولاً برای اسکریپت‌نویسی گیم‌پلی (مثل Unity)
  راحت‌تر از ++C ولی برای موتور core استفاده نمی‌شه
  سریع هست، ولی نه در سطح موردنیاز موتور AAA

•  Lua / Python:
  برای اسکریپت‌نویسی سبک
  معمولاً در کنار موتور استفاده می‌شن (برای منطق بازی، UI، یا هوش مصنوعی سبک)
  موتور اصلی نه، ولی رابط با کاربر یا طراح بازی بله

جمع‌بندی مفهومی این بخش:

IDE 2.2، کامپایلر و ابزارهای توسعه حرفه‌ای (Compilers, Linkers and IDEs)

هدف این بخش، معرفی ابزارهایی که برنامه‌نویس‌های موتور بازی برای نوشتن، ساختن، اشکال‌زدایی و مدیریت پروژه ازشون استفاده می‌کنن.

2.2.1 IDE – محیط توسعه (Integrated Development Environment)

پرکاربردترین IDE برای موتورهای ++C:

 Visual Studio (ویندوز)

قدرتمندترین ابزار برای توسعه موتورهای ++C در پلتفرم ویندوز

ابزارهایی مثل:

• Auto-complete (IntelliSense)
• Visual Debugger
• Memory Watch
• Profiler
• Call Stack

 بیشتر موتورهای AAA (مثل Unreal، Lumix، CryEngine) از Visual Studio استفاده می‌کنن.

مواردی که بعنوان جایگزین توی پلتفرم های دیگه میتونیم در نظر بگیریم:

2.2.2 کامپایلرها (Compilers)

2.2.3 دیباگر (Debugger)

موقعی که برنامه کرش می‌کنه یا رفتار اشتباه داره، دیباگرها کمک می‌کنن ببینی:

• چه خطی اجرا شده؟
• مقدار متغیرها چی بوده؟
• چرا این اتفاق افتاده؟

ابزارهای دیباگ معروف:

• Visual Studio Debugger
• GDB (در لینوکس)
• LLDB (در Mac/Clang)

تو موتورهای پیچیده مثل Lumix یا Unreal، دیباگ‌کردن بدون ابزار = کابوس!

2.2.4 Profiler (ابزار تحلیل عملکرد)

برای اندازه‌گیری اینکه: 1- چه تابع‌هایی زمان‌بر ترین هستن؟ 2- bottleneck (گلوگاه عملکردی) کجاست؟

ابزارهایی مثل:

• Visual Studio Profiler
• Intel VTune
• NVIDIA Nsight (برای GPU)
• RenderDoc (برای رندرینگ)

نکته جالب: بازی‌هایی که با ۳۰fps کار می‌کنن به‌خاطر نبود پروفایلینگ درست ممکنه به ۱۵fps برسن

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

2.3 Build Systems (سیستم‌های ساخت)

Premake، CMake، Make و نقششون در پروژه‌های واقعی

هدف این بخش:پروژه‌های موتور بازی صدها فایل ++C دارن. نوشتن دستی دستورات کامپایل برای همه غیرممکنه. برای همین از ابزارهایی استفاده می‌کنن که کل فرایند build رو خودکار کنن.

سیستم‌های ساخت (Build System) یعنی چی؟

یه ابزار یا اسکریپت که به طور خودکار:

• فایل‌هایی که تغییر کردن رو تشخیص می‌ده
• اونا رو کامپایل می‌کنه
• فایل اجرایی (یا DLL و Lib) تولید می‌کنه
• وابستگی‌ها رو بررسی می‌کنه

سه دسته رایج:

• Premake:
  یه ابزار سبک و مینیمال برای ساخت فایل پروژه (مثل Visual Studio Solution)
  فایل کانفیگش به زبان Lua نوشته می‌شه → ساده‌تر از CMake
  پروژه‌هایی مثل Hazel Engine ازش استفاده می‌کنن

با یه دستور مثل:

premake5 vs2022

می شه فایل sln ویژوال استودیو تولید کرد.

برای پروژه‌های شخصی، خیلی سریع‌تر و قابل کنترل‌تره

• CMake
  ابزار پیشرفته‌تر، پیچیده‌تر
  پشتیبانی رسمی توسط موتورهایی مثل Godot و حتی Unity (برای بخش‌هایی)
  می‌تونه برای هر IDE و پلتفرمی فایل بسازه (VS، Unix Makefiles، Ninja و...)
  مثال:

cmake -S . -B build
cmake --build build

• Make / Makefile
  ابزار قدیمی ولی هنوز رایج در لینوکس/یونیکس
  دستی‌تر و نیاز به نوشتن قواعد داره
  مناسب برای درک پایه ولی نه توصیه‌شده برای پروژه‌های مدرن مثل Hazel

چه موفع باید از Build System استفاده کرد؟

• همیشه! وقتی حتی ۳ فایل ++C داشتی، بهتره از یکی از این ابزارها استفاده کنی
• توی موتورهای واقعی، وابستگی‌ها خیلی پیچیده‌ان (مثل فایل‌های Renderer.cpp که نیاز به Math.h دارن)
• Build system اطمینان می‌ده که همه چیز با نظم و سرعت درست ساخته می‌شه

جمع‌بندی مفهومی این بخش:

انتخاب بین Premake و CMake بیشتر بر اساس سلیقه و نیاز تیمه

2.4 Build Systems Version Control (سیستم‌های کنترل نسخه)

Git، Perforce و نقش حیاتی‌شون در توسعه موتور بازی

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

سیستم کنترل نسخه (VCS) چیه؟

سیستمی برای ردگیری، ذخیره و مدیریت تغییرات فایل‌ها (سورس‌کد، اسکریپت، دارایی‌ها، تنظیمات...) به‌صورت نسخه به نسخه

محبوب‌ترین سیستم‌ها:

 Git:

• رایگان، سبک، فوق‌العاده سریع
• قابل استفاده در پروژه‌های شخصی، دانشگاهی و تیم‌های حرفه‌ای
• سرویس‌های معروف: GitHub، GitLab، Bitbucket
• ابزار گرافیکی: GitKraken، GitHub Desktop، SourceTree
•  بازی‌سازهای indie (تک‌نفره یا تیم کوچک) ۹۰٪ از Git استفاده می‌کنن

 Perforce (برای پروژه‌های AAA):

طراحی شده برای کار با فایل‌های حجیم مثل:

• assetهای گرافیکی
• انیمیشن‌ها
• فایل‌های binary (تکسچر، صدا، FBX،... )
• مخصوص استودیوهای بزرگ مثل: Ubisoft، Naughty Dog، Rockstar
• قابلیت‌های قفل‌گذاری فایل، شاخه‌بندی پیشرفته و performance بهتر توی تیم‌های بزرگ

چرا استفاده از VCS ضروریه؟

یه مقایسه سریع بخوایم داشته باشیم:

2.5 Profiling Tools (ابزارهای بررسی عملکرد موتور بازی)

هدف این بخش: موتور بازی باید با سرعت بالا در زمان واقعی (Real-time) اجرا بشه. اما کجاها کند شده؟ چه تابعی بیشترین زمان رو می‌گیره؟ برای پیدا کردن این bottleneckها از ابزارهای Profiler استفاده می‌شه.

Profiler اصلا چی هست؟

یک ابزار نرم‌افزاری که در زمان اجرای برنامه:

• مدت زمان اجرای توابع رو اندازه‌گیری می‌کنه
• مصرف CPU و GPU رو تحلیل می‌کنه
• نشون می‌ده هر فریم بازی چقدر طول کشیده و کجا وقت تلف شده
• کمک می‌کنه کدهای کند یا ناکارآمد رو شناسایی و اصلاح کنیم

چرا توی موتور بازی حیاتیه؟

• بازی‌ها باید توی 60FPS یا بالاتر اجرا بشن ← هر فریم ← 16ms وقت داری
• اگه یه تابعی حتی 5 میلی‌ثانیه طول بکشه، ممکنه کل فریم رو خراب کنه
• بدون Profiler، نمی‌فهمی مشکل از فیزیکه، رندر، یا اسکریپت!

ابزارهای معروف Profiler:

انواع Profilerها:

چرا باید با Profiler کار کرد؟

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

 2.6 Memory Leak and Corruption Detection (تشخیص نشت و خرابی حافظه در موتور بازی)

هدف این بخش:

وقتی با زبان‌های low-level مثل ++C کار می‌کنی، مدیریت حافظه کاملاً دست خودته. اگه حتی یه خطا توی آدرس‌دهی یا آزادسازی حافظه انجام بدی، ممکنه بازی: کند بشه، کرش کنه، یا بدتر: باگ‌هایی بده که به‌سختی پیدا می‌شن

دو نوع مشکل شایع حافظه:

1. Memory Leak (نشت حافظه)

یعنی:

حافظه‌ای رزرو کردی (new یا malloc) ولی هیچ‌وقت آزادش نکردی (delete یا free)

 اتفاقی که زیاد می‌افته تو موتورهایی که asset، scene، یا entity زیاد دارن

مثال ساده:

 void LoadTexture() {
   Texture* tex = new Texture("sky.png");
}

در این مثال ابجکت ساخته شده مفداری از حافظه رو اشغال می کنه اما بعد از انجام عملیات ها اون رو آزاد نکردیم

 delete tex

2. Memory Corruption (خرابی حافظه)

یعنی:

یه بخش از حافظه رو خارج از محدوده‌اش نوشتن یا خوندن

مثال:

int myArray[10];
myArray[12] = 21;

این باعث می‌شه بخش دیگه‌ای از RAM برنامه تغییر کنه → باگی که ممکنه دیر ظاهر بشه و سخت دیباگ بشه!

ابزارهای تشخیص این مشکلات:

چطور کار می‌کنن؟

مثلاً AddressSanitizer با اضافه کردن کدهایی مخفی توی باینری:

• قبل و بعد از هر تخصیص حافظه، memory guard می‌ذاره
• اگه دست‌کاری غیرمجاز انجام بشه، در لحظه متوقف می‌شه و پیام دقیق می‌ده

نحوه فعال کردن در GCC یا Clang:

 g++ -fsanitize=address -g main.cpp -o myprogram
./myprogram

در visual studio با دنبال کردن مسیر زیر به اون دسترسی داریم:

Debug --> Performance Profiler --> Memory Usage

چرا در موتور بازی حیاتیـه؟

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

بخش 2.7 Other Tools (ابزارهای مکمل در توسعه موتور بازی)

هدف این بخش: توسعه موتور بازی فقط کدنویسی نیست. برای اینکه تیم بتونه خوب کار کنه، ابزارهای مکملی هم لازمه مثل: مستندسازی، ساخت خودکار (CI)، ابزارهای هنری، ارتباط بین تیم‌ها و …

در این بخش ابزار های مهمی بررسی میشن که در ادامه به اون ها می پردازیم.

2.7.1 Continuous Integration (CI) Tools

ابزارهایی که کمک می‌کنن هر بار که کد تغییر می‌کنه، build و تست خودکار انجام بشه.

کاربرد:

• اتومات کردن build و تست هر بار که commit انجام می‌دی
• ساخت build شبانه برای تست و عملکرد
• اجرای تست‌های واحد (unit tests)

2. Documentation Tools (مستندسازی کد)

پروژه‌های بزرگ مثل موتور بازی، باید مستند باشن تا:، اعضای جدید تیم بفهمن بحش مربوط به توسعه ای که بهشون سپرده شده در اصل ساز و ساختش و پایه و کد های قبلی اون چی هست، رفتار کلاس‌ها و API مشخص باشه

3. Art Tools (برای تولید Asset توسط تیم هنری)

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

موتور بازی باید بتونه با خروجی این ابزارها تعامل داشته باشه، مثلاً: پشتیبانی از .FBX, .OBJ, .PNG, .WAV, .MP3, .PSD و…

4. Communication & Planning Tools (برای تیم‌های بزرگ)

نکات جالب:

• در موتورهای واقعی، ابزارهایی مثل Level Editor، Animation Graph Editor یا Shader Editor هم طراحی می‌شن (در فصل‌های بعدی توضیح داده می‌شن)
• داشتن ابزار خوب = کاهش باگ، سرعت بیشتر، تیم راضی‌تر

جمع‌بندی نهایی فصل ۲: Tools of the Trade