آموزش بازی سازی: با سند طراحی بازی بیشتر آشنا شوید

جمعه ۲۷ مرداد ۱۳۹۶ - ۱۲:۳۱
مطالعه 8 دقیقه
سند طراحی بازی
در این مقاله بخش‌های باقیمانده‌ی سند طراحی بازی را با هم بررسی می‌کنیم و در انتها به چند سوال‌ رایج در این زمینه پاسخ می‌دهیم. با ما همراه شوید.
تبلیغات

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

سند طراحی

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

منوها و رابط کاربری

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

جهان بازی

داستان

شخصیت‌ها

مراحل (اصلی، فرعی و ...)

کنترل بازیکن

سیستم ارتقا

سیستم خرید و فروش

صدا و موسیقی

اتمسفر بازی

هوش مصنوعی

سیستم اهدای جوایز

سیستم مبارزات

سیستم جمع‌آوری منابع

هدایت دوربین

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

طراحی مرحله

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

سند فنی

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

سند طراحی بازی

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

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

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

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

پرسش‌های رایج

- آیا سند طراحی بازی یک سند یکپارچه است؟

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

- آیا برای نوشتن سند طراحی بازی استاندارد مشخصی وجود دارد؟

سند طراحی بازی

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

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

- آیا سند طراحی غیر قابل تغییر است؟ اگر نیست آیا در فرآیند ساخت جلوی خلاقیت تیم‌توسعه را نمی‌گیرد؟

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

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

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

سند طراحی بازی

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

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

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

مقاله رو دوست داشتی؟
نظرت چیه؟
داغ‌ترین مطالب روز
تبلیغات

نظرات