سند طراحی بازی چیست و چه کار میکند؟

3
2744
طراحی سند بازی یا GDD
سند طراحی بازی چیست و چه کار میکند؟

وقتی کسی میگوید “نگاهی به سند طراحی بینداز” در واقع منظور همان سند طراحی بازی است،سند طراحی بازی یا GDD در حقیقت یک سند از تمام جزییات کاراکتر ها ،مراحل ،مکانیک های بازی ،منو ها ، اسکرین ها و از این قبیل موارد است. نوشتن سند طراحی بازی برای اکثرا طراحان بازی (چه کسانی بازی میسازند؟ ۸ نقش اصلی یک گروه بازی سازی) بسیار سرگرم کننده است زیرا انها از تمام توانایی های خود برای دادن اسکلت و ماهیچه به بازی استفاده می کنند. البته نوشتن این سند به این سادگی ها هم نیست ، ساخت یک سند طراحی بازی کامل بسیار زمان بر و مشکل است. در طراحی این سند UML نقش حیاتی را ایفا می کنید (۶ نرم افزار مدیریت پروژه که کار شما را در مدیریت پروژه اسان میکند)

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

چه موقع باید سند طراحی بازی بنویسیم؟

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

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

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

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

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

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

همیشه زمانی را برای مطابقت دادن بازی و سند طراحی بازی در نظر بگیرید تا مطمئن شوید تیم تولید با دقت و با یک انعکاس دقیق و به روز ساخت بازی پیش میبرند.

در نظر گرفتن تغییراتی که در اینده ممکن است در سند طراحی بازی اعمال شود یکی از مهم ترین وظایف یک مدیر پروژه است. با در نظر گرفتن این تغییرات میتوان از ایجاد وظایف اضافه بر پروسه تولید جلوگیری و از به خوبی پیاده شدن این تغییرات مطمئن شد.

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

چه چیزی در سند طراحی بازی باید نوشته شود؟
چه چیزی در سند طراحی بازی باید نوشته شود؟

سند های طراحی بازی وابستگی زیاد به برنامه های درامدی دارند، پیاده سازی یک شکل رسمی از بازی در صنعت بازی سازی نیازمند سند طراحی بازی است، در صنعت فیلم سازی مدرک های دانشگاهی زیادی برای دوره های طراحی اسکریپت فیلم طراحی شده است اما با این که صنعت بازی سازی درامد بیشتری نسبت به فیلم های هالیوودی دارد همچنان دانشگاه ها کلاس هایی برای برنامه نویسی بازی و ارت ارائه داده اندT در واقع هیچ کلاسی برای اموزش طراحی بازی وجود ندارد ، علاوه براینها صنعت بازی سازی بسیار جوان است تکنولوژی های وابسته به ان به سرعت در حال تغییر هستند که این امر باعث شده نتوان پیش نیاز های دقیقی را برای یک سند طراحی بازی قرار داد

یک سند طراحی بازی ایده ال سندی است که یک چشم انداز کامل و ثابت و دقیق از روند بازی در ان شرح داده شده باشد، در تئوری بازی سازان باید بتوانند از روی سند طراحی بازیT به صورت دقیق ساخت بازی را دنبال کنند اما در عمل ساخت چنین سند قدرتمند و شفافی بسیار مشکل است.

در ادامه ما به شرح بخش های مختلفی که در یک سند طراحی بازی یا به اختصار GDD وجود دارد می پردازیم:

بخش اول : تعریف بازی

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

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

بازی doom :یک بازی اول شخص شوتر که تحت پلتفرم پی سی است ، در این بازی بازیکن یک تفنگدار را در یک محیط سه بعدی برعلیه غول های عجیب و غریب کنترل می کند ،بازیکن توانایی تنظیم دکمه های کنترلی صفحه کلید ،موس و دسته بازی را دارد ، روند بازی(گیم پلی) برپایه کنش است که در ان هیچ استراتژیک و یا المان های نقش بازی کردن استفاده نخواهد شد، در عوض یک قابلیت خونریزی بالا که اجازه قتل عام تمام دشمنان را میدهد دارا است ، حالت تک نفره شامل سه سری از مراحل برعلیه غول های وحشتناک به همراه موقعیت ها و اهنگ های ترسناک است، حالت چند نفره دارای ویژگی بی نظیر مبارزه بازیکن با بازیکن است.

بخش دوم : هسته بازی

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

زاویه دید اصلی بازی

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

برای شفاف سازی دقیق دید بازی چند طرح یا موکاپ از دید بازی ایجاد کنید.دقت کنید که تعریف دید بازی در ابتدای توضیح هسته بازی باعث می شود تا خواننده سریع تر به نوع بازی پی ببرد.

فعالیت های بازیکن

بازیکن دقیقا در بازی چه کاری انجام میدهد؟ فعل و انفعالات بازیکن با دنیای بازی چیست؟ ایا بازیکن یک خلبان سفینه فضایی است؟یا یک راننده خودروی مسابقه؟یا شاید یک ارتش را مدیریت می کند ؟ میزان مانور بازیکن در فضای سه بعدی چقدر است؟

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

این قسمت یکی از بهترین مکان ها برای استفاده از UML برای تعریف ارتباط بازیکن با بازی است ، میتوانید یک UML برای نشان دادن انواع تعاملات بازیکن و دنیای بازی و عناصر ان ایجاد کنید.

دیاگرام کنترلر

یک نمونه دیاگرام کنترلر
یک نمونه دیاگرام کنترلر

در این قسمت به صورت دقیق استفاده از ورودی های بازی که شامل کلید های صفحه کلید یا یک دسته بازی هستند به صورت تصویری در سند طراحی بازی تعریف می شوند.

رابط کاربری داخل بازی

رابط کاربری داخل بازی
رابط کاربری داخل بازی

این قسمت تمام المان هایی که در صفحه اصلی بازی برای بازیکن قابل نمایش هستند را به تصویر می کشد ، المان هایی شامل نشان دادن زمان ، میزان سلامتی ، نقشه، میزان فاصله تا هدف،رادار و … . باید به صورت دقیق و با جزییات تمام اجزای ui که در این صفحه به نمایش در می ایند توسط UML یا موکاپ طراحی شوند ، در طراحی این UML باید تمام اجزایی که با بازیکن تعامل دارند و یا بازیکن هیچ تعاملی با انها ندارد(مانند ایتم هایی که با دیدن انها از ان استفاده میکند) رسم شود

بخش سوم : محتوای گیم پلی

یک نمونه uml گیم پلی
یک نمونه uml گیم پلی

محتوای این بخش درباره تمام مکانیک ها و سیستم های ریز و درشت بازی با جزییات کامل آن ها است، به عبارتی در این بخش به ان دسته از مکانیک هایی که توضیح انها در بخش قبل سند طراحی بازی کامل نبودند می پردازد.  در ادامه به توضیح سایر مواردی که باید در این بخش به آنها پرداخته شود میپردازیم.

منوی پوسته ها

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

جزییات مکانیک های بازی

در این بخش ما به تعریف دقیق مکانیک ها میپردازیم به عنوان مثال در این بخش می گوییم ان موتور چه مقدار اسب بخار تولید می کند؟،سرعت حرکت شخصیت ها چقدر است؟، هر خشاب یک اسلحه فضایی چند گلوله دارد؟

در این قسمت باید هر چیزی که در مکانیک های بازی مورد استفاده قرار گرفته است با جزییات دقیق شرح داده شود، البته متعادل کردن (بالانس) این جزییات در اینده انجام می شود.

مکانیک راهنمای بازی

تقریبا همه بازی های بزرگ یک راهنمای جامع در بازی دارند، در بعضی از بازی ها نمایش این راهنما در آغاز هر مرحله انجام می پذیرد و در بعضی دیگر در دیالوگ هایی که بین کاراکتر ها رد و بدل می شود، اما هر چه که باشد این قسمت برای زمانی است که بازیکن باید چیزی یاد بگیرد.

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

مکانیک های چند نفره

ایا بازی شما بخش چند نفره(مولتی پلیر) دارد؟ اگر دارد تحت چه نوع سیستم است ایا از شبکه LAN استفاده می کند؟ یا از سیستم های بازی انلاین مانند gamespy ؟

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

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

گاهی این تعویق ها اینقدر بر پروسه بازی فشار می اورند که باعث می شود بخش مولتی پلیر پروژه حذف شود.

بخش چهارم : داستان بازی

در این بخش از سند طراحی بازی ، طراح بازی باید درباره دنیایی که ایجاد کرده است یک پس زمینه داستانی بنویسد، بسیاری از بازی سازان تمایل بیشتری برای کار بر روی این بخش دارند تا بر روی بخش مولتی پلیر!، دلیل این که این بخش را دیرتر معرفی کردیم این است که یک سند طراحی بازی باید بیشتر در خدمت تیم باشد تا طراح بازی. این بخش شامل قسمت های مختلفی است که در ادامه شرح می دهیم

داستان پس زمینه

دنیای بازیتان را بسط دهید، داستان مرتبط با دنیای بازیتان چیست؟، یک نقشه از دنیای بازیتان رسم کنید. اهمیت این قسمت به نوع ژانر بازیتان بستگی دارد بعضی از بازی ها مانند سری  doom and quake هیچ داستان پس زمینه ای ندارند و بعضی دیگر در اولین اجرای بازی داستان بازی شرح داده می شود.

داستان پس زمینه شخصیت ها

پس زمینه شخصیت ها نیز به نوع بازی بستگی دارد، همه بازی ها کاراکتر دارند، اهمیت نقش کاراکتر و وسعت آن به ژانر بازی بستگی دارد،به عنوان مثال در بازی های نقش افرینی، ماجرایی و پلتفرمر یک بخش صرفا برای تعریف شخصیت ها،طرح های انها و توضیح رفتار و خواص انها وجود دارد، که در آن ارتباط تمام مکانیک ها با شخصیت ها که شامل مرجع هایی درباره این که کجا شخصیت ظاهر می شود و نوع آن شخصیت(قابل بازی کردن-غیربازیکن،غول) چیست تعریف می شود

در بازی Gran Turismo این مسئله به این شکل تعریف شده است که هر خودرو یک شخصیت منحصر به فرد به حساب می آید به خصوص خودرو هایی که در سراسر بازی یکتا هستند مانند سوزوکی اسکودو. در این بازی پشت هر خودرو یک داستان تاریخی وجود دارد.

در یک بازی استراتژی ریل تایم ، هر یک از واحد های مبارزه ای داخل بازی (مانند تانک،سرباز،جنگنده) یک کاراکتر جداگانه به حساب می ایند، برای یک بازی تاکتیکی ریل تایم مانند بازی Starfleet Command: the Next Generation ، ما در واقع سه نوع کلاس شخصیت داریم هر کلاس تفاوت های اصلی با کلاس دیگری دارد اما با این حال تک تک کاراکتر های داخل هر کلاس باید با جزییات کامل تعریف شوند.

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

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

پس از این توضیحات زمان تعریف ساختار کمپین ها(campaign) رسیده است ، برای مرتبط کردن محیط ها و اجزا به یک دیگر از UML خطی میتوان استفاده نمود

مرحله،ماموریت و طراحی مناطق

این بخش مورد علاقه بسیاری از طراحان بازی در نوشتن سند طراحی بازی است، در این بخش بازی را به قسمت های کوچک تر مراحل،ماموریت ها و مناطق مختلف تقسیم می کنیم

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

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

توضیح صحنه های بازی

اگر بازی شما شامل قطعات فیلم در حین بازی است، باید این صحنه های فیلم(کات سین) به طور کامل اسکریپت نویسی شوند، با این که در صنعت بازی سازی قالب رسمی برای نوشتن توضیح یک کات سین وجود ندارد اما دو جزء مهم در آن وجود دارد: اول استوری برد و دوم اسکریپت.

استوری برد در واقع یک قاب بصری از صحنه ها است چیزی مانند کامیک ، طراحی استوری برد در برقراری ارتباط بین کسی که مراحل را طراحی می کند و سند طراحی بسیار مهم است .

اسکریپت باید در قالب اسکریپت استاندارد فیلم ها باشد.

با پایان یافتن این بخش هیچ خواننده ای نباید درباره نقش کاراکتر ها و درباره دنیا سوالی داشته باشد.

بخش پنجم: پوشش منابع

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

اسپرایت های دو بعدی و مدل های سه بعدی

یک نمونه مدل سه بعدی
یک نمونه مدل سه بعدی

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

مراحل،ماموریت ها یا مناطق

مناطق بازی
مناطق بازی

لیست مراحل ، ماموریت ها و مناطقی که باید برای بازی ساخته شوند ، ویژگی هر یک از این منابع باید به صورت دقیق نوشته شود به عنوان مثال اندازه طولی و عرضی هر منطقه چقدر است؟

صداها

در اینجا منظور صدای مکالماتی است که باید در بازی استفاده شوند.  در حین نوشتن لیست صداها ، جزییات هر بازیگر صدا را نیز یادداشت کنید.

موشن کپچر

اگر کاراکتر های شما انیمه خاصی دارند باید حتما از قبل هر حرکت کاراکتر را با جزییات ان حرکت لیست کنید تا در مرحله تولید از آن استفاده کنید.

افکت های صوتی

افکت های صوتی یکی از حساس ترین بخش های ایجاد احساس در بازیکن است ، پیشنهاد می شود به صورت ذهنی در مراحل حرکت کنید تا ببینید به چه نوع صدایی و در کجا نیاز دارید.

موسیقی

تقریبا همه بازی ها شامل موسیقی هستند، موسیقی هایی که برای بخش های مختلف نیاز دارید را لیست کنید (به عنوان مثال موسیقی زمان مبارزه با غول مرحله اول )

جلوه های ویژه

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

سخن پایانی

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

برای بهبود مهارت هایتان در نوشتن این سند بهتر است ایده هایی که در ذهن دارید را تبدیل به سند های طراحی بازی کنید، برای ارزیابی کیفیت سندی که نوشته اید آن را به طراحان بازی ارائه دهید تا آن را ارزیابی کنند.

Rating: 5.0/5. From 3 votes.
Please wait...

3 نظر

  1. مطلب، بسیار عالی و گران بود 🙂
    بسی تشکر

    Rating: 4.5/5. From 2 votes.
    Please wait...
  2. لطفا نام کتاب نسخه اصلی رو هم بگید

    Rating: 5.0/5. From 1 vote.
    Please wait...
    • سلام
      لول اپ

      Rating: 5.0/5. From 1 vote.
      Please wait...

پاسخ دهید

لطفا نظر خود را وارد کنید
لطفا نام خود را اینجا وارد کنید