اگر وارد دنیای طراحی بازی شده باشید، احتمال زیادی وجود دارد که با اصطلاح GDD روبه‌رو شده باشید. GDD مخفف Game Design Document یا «سند طراحی بازی» است؛ سندی که ایده‌ها، قوانین، سیستم‌ها و ساختار کلی یک بازی را به شکلی قابل فهم ثبت می‌کند.

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

برای ساخت اولین بازی خود می توانید مقاله "راهنمای بازیسازی: چطور اولین بازیمون رو بسازیم؟" را مطالعه کنید.



GDD چیست؟

GDD مخفف Game Design Document یا «سند طراحی بازی» است. این سند توضیح می‌دهد که یک بازی دقیقاً قرار است چگونه کار کند؛ از ایده‌ی کلی و ساختار گیم‌پلی گرفته تا سیستم‌های مختلف، قوانین، پیشرفت بازیکن و جزئیاتی که برای ساخت بازی لازم هستند.

در واقع یکی از مهم‌ترین نقش‌های GDD این است که فاصله بین چیزی که طراح بازی در ذهن دارد و چیزی که در نهایت توسط تیم ساخته می‌شود کمتر شود. عباراتی مثل «مبارزات بازی باید سریع و تاکتیکی باشند» می‌توانند جهت کلی طراحی را مشخص کنند، اما هنوز برای ساخت یک سیستم کافی نیستند. سند طراحی باید این ایده را به قوانین مشخص‌تری تبدیل کند؛ برای مثال اینکه بازیکن در هر نوبت چه انتخاب‌هایی دارد، حمله چگونه انجام می‌شود، دشمن چه زمانی واکنش نشان می‌دهد و شرایط برد و باخت چیست.

به همین دلیل GDD را می‌توان نوعی زبان مشترک میان اعضای تیم دانست. Game Designer (طراح بازی) از آن برای ثبت منطق طراحی استفاده می‌کند، Programmer (برنامه‌نویس) باید بتواند از روی آن رفتار سیستم‌ها را درک کند و اعضای بخش Art یا UI نیز از آن برای فهمیدن نیازهای واقعی بازی استفاده می‌کنند. البته این به آن معنا نیست که هر جزئیات فنی یا هنری باید داخل GDD قرار بگیرد؛ هدف اصلی این سند توضیح طراحی بازی است.

برداشت قدیمی از Game Design Document معمولاً یک فایل بسیار بزرگ و ثابت بود که پیش از شروع تولید نوشته می‌شد. در توسعه بازی امروزی، GDD معمولاً ساختار منعطف‌تری دارد. یک بازی کوچک ممکن است تمام طراحی خود را در چند صفحه جمع کند، در حالی که یک پروژه بزرگ می‌تواند برای سیستم‌هایی مثل Combat (مبارزه)، Progression (پیشرفت) یا Game Economy (اقتصاد بازی) سندهای جداگانه داشته باشد.

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

برای ساخت بازی با هوش مصنوعی می توانید مقاله "چطور با هوش مصنوعی بازی بسازیم؟ معرفی بهترین ابزارهای AI برای ساخت بازی" را مطالعه کنید.

یک GDD خوب چه ویژگی‌هایی دارد؟

یک GDD خوب قبل از هر چیز باید قابل استفاده باشد. هدف از Game Design Document این نیست که صرفاً تمام ایده‌های بازی را در یک فایل جمع کنیم؛ سند باید به اعضای تیم کمک کند بدون حدس زدن بفهمند هر سیستم چرا وجود دارد و چگونه کار می‌کند. 

اگر برنامه‌نویس بعد از خواندن توضیح یک مکانیک هنوز مجبور باشد چند بار از طراح بپرسد «دقیقاً باید چه اتفاقی بیفتد؟»، احتمالاً آن بخش از سند هنوز به اندازه کافی شفاف نیست.

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

ویژگی مهم دیگر، ساختار مناسب اطلاعات است. خواننده نباید برای پیدا کردن نحوه کار یک سیستم مجبور شود تمام سند را از ابتدا بخواند. بخش‌هایی مثل Core Gameplay (گیم‌پلی اصلی)، Progression (پیشرفت)، Economy (اقتصاد بازی)، Combat (مبارزه) یا UI (رابط کاربری) باید تا جای ممکن مرز مشخصی داشته باشند. این موضوع مخصوصاً در پروژه‌های بزرگ اهمیت بیشتری پیدا می‌کند، چون GDD به مرور از یک سند ساده به یک مرجع کاری برای چند نفر تبدیل می‌شود.

در عین حال GDD نباید به سندی ثابت تبدیل شود. طراحی بازی در طول Prototype (نمونه اولیه)، Playtest (تست بازی) و Production (تولید) تغییر می‌کند و سند نیز باید همراه با آن تغییر کند. اگر یک مکانیک حذف شده اما هنوز در GDD توضیح داده می‌شود، سند به‌جای کمک کردن می‌تواند باعث اشتباه شود. به همین دلیل یکی از مهم‌ترین ویژگی‌های یک GDD کاربردی این است که نسخه فعلی بازی را توصیف کند، نه تاریخچه تمام تصمیم‌هایی را که قبلاً گرفته شده‌اند.

کیفیت یک GDD بیشتر از حجم آن، به شفافیت، دسترسی سریع به اطلاعات و قابل اجرا بودن طراحی بستگی دارد.

برای تخمین هزینه ی ساخت بازی و بودجه بندی بازی خود می توانید مقاله" هزینه ساخت بازی اندروید چقدر است؟ از ایده تا انتشار و درآمدزایی" را مطالعه کنید.


بخش‌های اصلی یک Game Design Document + قالب

ساختار یک Game Design Document برای همه بازی‌ها یکسان نیست. یک بازی پازلی موبایل، یک Roguelike (بازی با ساختار اجرای تکرارشونده و معمولاً پیشرفت مرحله‌ای) و یک RPG (بازی نقش‌آفرینی) به اطلاعات متفاوتی نیاز دارند. با این حال، بیشتر GDDها چند بخش اصلی دارند که تقریباً در هر پروژه‌ای به شکل مستقیم یا غیرمستقیم دیده می‌شوند.

  • معرفی کلی بازی

ابتدای GDD باید در مدت کوتاهی تصویر روشنی از خود بازی بدهد. ژانر، پلتفرم، مخاطب هدف، زاویه دید، ساختار کلی تجربه و چیزی که بازی را از نمونه‌های مشابه متمایز می‌کند، معمولاً در همین قسمت مشخص می‌شوند. این بخش جای توضیح تمام جزئیات نیست. هدف آن این است که کسی که برای اولین بار سند را باز می‌کند، بدون خواندن ده‌ها صفحه بفهمد چه بازی‌ای قرار است ساخته شود.
نام بازی: نام فعلی یا Working Title (نام موقت پروژه)

Genre: ژانر یا ترکیب ژانرهای بازی

Platform: پلتفرم هدف مانند PC، Mobile یا Console

Game Concept: توضیح کوتاهی از اینکه بازی چیست و بازیکن در آن چه تجربه‌ای خواهد داشت.

Design Pillars: چند اصل اساسی که تصمیم‌های طراحی بازی باید با آن‌ها هماهنگ باشند. برای مثال ممکن است یک بازی روی «تصمیم‌گیری سریع»، «ریسک و پاداش» و «پیشرفت قابل مشاهده» تمرکز داشته باشد.

  • Core Gameplay و Core Loop

بعد از معرفی، معمولاً باید مشخص شود بازیکن در عمل چه کاری انجام می‌دهد. Core Gameplay (گیم‌پلی اصلی) مجموعه تعاملاتی است که بیشترین زمان بازیکن را تشکیل می‌دهد و Core Loop (چرخه اصلی گیم‌پلی) توضیح می‌دهد این فعالیت‌ها چگونه به یک چرخه تکرارشونده تبدیل می‌شوند.  بهتر است این چرخه آن‌قدر واضح باشد که بتوان فعالیت اصلی بازیکن را در چند مرحله دنبال کرد.

برای مثال:

Explore → Collect → Fight → Upgrade → Explore

اگر Core Loop هنوز در GDD مشخص نیست، معمولاً یعنی خود طراحی بازی نیز هنوز به اندازه کافی شفاف نشده است.

  • Mechanics و قوانین بازی

در این بخش Mechanics (مکانیک‌های بازی) با جزئیات بیشتری توضیح داده می‌شوند. حرکت، مبارزه، ساخت‌وساز، کارت‌ها، منابع، مدیریت Inventory (موجودی)، تعامل با محیط یا بطور کلی هر سیستمی که مستقیماً رفتار بازی را شکل می‌دهد، می‌تواند در این قسمت قرار بگیرد. 

مثلاً برای یک Upgrade System (سیستم ارتقا) می‌توان توضیح داد که ارتقاها با چه منبعی خریداری می‌شوند، چه ویژگی‌هایی را تغییر می‌دهند، چند مرحله دارند و چه محدودیت‌هایی برای آن‌ها وجود دارد.

همین ساختار را می‌توان برای Combat، Inventory، Crafting، Dialogue، Building یا هر سیستم دیگری استفاده کرد.

  • Progression و ساختار پیشرفت

بیشتر بازی‌ها نوعی Progression (سیستم پیشرفت) دارند. این پیشرفت ممکن است افزایش Level (سطح)، باز شدن مناطق جدید، دریافت تجهیزات، یادگیری توانایی‌ها یا حتی صرفاً دشوارتر شدن مراحل باشد.

GDD باید توضیح دهد بازیکن چگونه از وضعیت ابتدایی به وضعیت‌های پیشرفته‌تر می‌رسد و چه چیزی انگیزه ادامه بازی را ایجاد می‌کند. در پروژه‌های بزرگ‌تر این بخش معمولاً با سیستم‌هایی مثل Unlock (باز شدن محتوا)، Reward (پاداش)، Difficulty Curve (منحنی سختی) و Economy ارتباط نزدیکی دارد.

  • Game Economy و منابع

اگر بازی دارای Currency (ارز)، انرژی، مواد اولیه یا منابع مشابه است، رابطه میان Source (روش تولید یا دریافت منبع) و Sink (روش مصرف منبع) باید روشن باشد. Game Economy (اقتصاد بازی) فقط مربوط به بازی‌های مدیریتی یا Free-to-Play نیست؛ حتی مهمات در یک بازی اکشن نیز می‌تواند بخشی از اقتصاد منابع بازی باشد. 

در این قسمت معمولاً مشخص می‌شود منابع از چه راه‌هایی وارد بازی می‌شوند و بازیکن آن‌ها را در چه بخش‌هایی مصرف می‌کند. این رابطه در طراحی با مفاهیمی مثل Source (منبع تولید) و Sink (محل مصرف) شناخته می‌شود.

  • Content و ساختار محتوای بازی

بخشی از GDD نیز به چیزهایی اختصاص پیدا می‌کند که درون سیستم‌های اصلی قرار می‌گیرند؛ مثل دشمنان، مراحل، شخصیت‌ها، سلاح‌ها، کارت‌ها، ساختمان‌ها یا دستورهای غذایی.

در اینجا تفاوت بین System (سیستم) و Content (محتوا) اهمیت دارد. برای مثال «سیستم دشمنان» توضیح می‌دهد دشمن چگونه حرکت و حمله می‌کند، در حالی که Goblin، Skeleton و Boss نمونه‌هایی از محتوایی هستند که از آن سیستم استفاده می‌کنند.

  • UI، Controls و Feedback

طراحی بازی فقط شامل قوانین پشت صحنه نیست. بازیکن باید بتواند این قوانین را ببیند و با آن‌ها تعامل کند. به همین دلیل GDD معمولاً توضیحاتی درباره UI یا User Interface (رابط کاربری)، Controls (کنترل‌ها) و Feedback (بازخورد بازی به عمل بازیکن) نیز دارد.

برای مثال اگر بازیکن منابع کافی برای یک ارتقا ندارد، بازی چگونه این موضوع را نشان می‌دهد؟ اگر ضربه‌ای Critical (ضربه بحرانی) باشد، بازیکن از کجا متوجه می‌شود؟ اگر یک تعامل در آن لحظه امکان‌پذیر نیست، چه بازخوردی دریافت می‌کند؟

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

  • Win، Loss و Game States

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

حتی بازی‌هایی که Win Condition (شرط برد) مشخصی ندارند، معمولاً Game State (وضعیت بازی) دارند؛ برای مثال شروع روز، پایان روز، توقف بازی، شکست مأموریت یا بازگشت به Hub.

این بخش کمک می‌کند مرزهای سیستم مشخص باشند و رفتار بازی در شرایط مختلف به تفسیر برنامه‌نویس واگذار نشود.

  • Scope

در پایان بهتر است مشخص شود دقیقاً چه چیزی قرار است در نسخه فعلی بازی ساخته شود.

برای مثال اگر در حال ساخت یک MVP یا Minimum Viable Product (حداقل نسخه قابل ارائه) یا Prototype هستید، باید مشخص باشد کدام سیستم‌ها داخل این نسخه هستند و کدام قابلیت‌ها فعلاً خارج از محدوده پروژه محسوب می‌شوند.

برای انتشار بازی کامپیوتری خود می توانید مقاله "راهنمای کامل انتشار بازی روی Steam؛ چطور Wishlist بگیریم؟" را مطالعه کنید.

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

Game Overview → Core Gameplay → Game Systems → Progression → Economy → Content → UI & Controls → Game States → Scope


نکته مهم این است که یک GDD خوب مجبور نیست تمام این بخش‌ها را دقیقاً با همین نام یا در یک فایل داشته باشد. ساختار سند باید تابع خود پروژه باشد. هدف این نیست که یک قالب ثابت را پر کنیم؛ هدف این است که اطلاعاتی که برای طراحی و ساخت بازی لازم هستند، در جای مناسب و به شکل قابل فهم ثبت شوند.

برای جذب ناشر و ساخت Pitch deck (پیچ دک) میتوانید مقاله " پیچ دک بازی چیست؟ آموزش ساخت Pitch Deck برای جذب ناشر" را مطالعه کنید.

جمع‌بندی

GDD یا Game Design Document (سند طراحی بازی) قرار نیست فقط یک فایل رسمی برای شروع پروژه باشد؛ مهم‌ترین کاربرد آن این است که طراحی بازی را از یک ایده ذهنی به چیزی شفاف، قابل بررسی و قابل اجرا تبدیل کند.

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

همچنین Game Design Document یک سند ثابت نیست. با تغییر طراحی، نتیجه Playtest (تست بازی) و تصمیم‌های جدید تیم، GDD نیز باید به‌روزرسانی شود تا همیشه نسخه فعلی بازی را منعکس کند.

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