نگران نیستیم! در حاشیه انتشار کاریکاتور منتسب به خبرگزاری تسنیم

پوریا احمدی

۱۳۹۶/۱۰/۲۳

CBO
b

مدلسازی با Raymarching و میادین فاصله در یونیتی

سید مرتضی کمالی

۱۳۹۶/۱۱/۲۷

راهنمای ارسال مقالات برای گیمولوژی

علیرضا محمدی

۱۳۹۷/۰۱/۲۷

سردبیر
b

شیدر نویسی در یونیتی (بخش دوم)

سید مرتضی کمالی

۱۳۹۶/۰۸/۱۳

چالش‌های بازگشت بازیکنان به بازی

سمیرا دولت‌آبادی

۱۳۹۶/۰۸/۰۲

عضو تحریریه
b

شیدرنویسی در یونیتی (بخش اول)

سید مرتضی کمالی

۱۳۹۶/۰۷/۲۶

مارکتینگ بازی: طراحی برنامه

سمیرا دولت‌آبادی

۱۳۹۶/۰۷/۲۰

عضو تحریریه
b

باز‌ی سازان بزرگ چطور شما را گول می‌زنند؟

فرناز حقیقت

۱۳۹۶/۰۶/۱۶

روابط عمومی
b

قابلیت‌های آنلاین در بازی‌های تک نفره

رهام سجادی

۱۳۹۶/۰۷/۱۵

عضو تحریریه
b

آشنایی با روند کلی نوشتن سند طراحی بازی

* این مقاله ویژه رویداد "لول‌آپ" و برای ارتقا دانش هر چه بیشتر شرکت کنندگان این رویداد نوشته شده است.

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

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

شروع

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

«بانو گم شده است و مثل همیشه تقصیر شماست. حالا باید راه خود را از بین نامیراها باز کنید و پیش از این که فدای پادشاه زامبی‌ها شود نجاتش دهید. در حالی که حتی صبحانه هم نخورده‌اید! بازی «نبرد برای صبحانه زامبی» یک بازی ترسناک/جنایی دو بعدی ساید اسکرولر و Beat`em up با حضور Isaiah Stakes است!

توضیح شخصیت‌ها

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

داستان بازی

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

توضیحات گیم‌پلی

یک تا دو پاراگراف راجع به هر بخش متمایز گیم‌پلی بنویسید و با هسته اصلی گیم‌پلی شروع کنید. به عنوان مثال هسته اصلی Half-Life 2 راه رفتن به اطراف و تیراندازی است و سپس پیچیدگی‌هایی به آن اضافه می‌شود (مثل Gravity Gun) و پس از آن سکانس‌های ماشین سواری.

نمای کلی طراحی هنری

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

تجزیه سیستماتیک اجزاء

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

تجزیه داده‌های درون بازی

مانند تجزیه سیستم بازی، اما این بار برای داده‌های بصری، متنی و صوتی

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

داده‌های متنی: بخش‌های بزرگ و مهم را مشخص کنید (آموزش، نکات، دیالوگ از پیش نوشته شده، ماموریت‌های از پیش طراحی شده، دیالوگ‌های داینامیک، روایت) و میزان کاری که برای هر بخش نیاز است را اندازه بگیرید.

داده‌های صوتی: مشابه بخش قبل بخش‌های مهم را مشخص کنید (صدای درون بازی، صدای مربوط به HUD و رابط کاربری، موسیقی، صداپیشگی)

نمودار پیشنهادی جریان بازی

هدف و قصد از این بخش این است که متوجه شوید بازیکن از شروع بازی تا انتها قرار است چه تجربه کلی داشته باشد. با این که این بخش می‌تواند یک چیز تکراری باشید (مثلا شروع/ منو/ سکانس میان پرده و …)، شما می‌توانید در این بخش به المان‌های جدیدی فکر کنید که می‌تواند بازی شما را از یک‌نواختی خارج کند.

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

جدول زمانی پیشنهادی پروژه

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

ایده‌ها و احتمالات اضافی

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

همین! نوشتن یک سند این شکلی می تواند از 2 تا 3 صفحه یا به صورت جامع تر از 5 تا 50 صفحه باشد اما این سند بسیار کامل و کاربردی است و می تواند کار شما را خیلی راحت تر کند. در نهایت چند نکته و یا بهتر است بگویم نصیحت را مدنظر داشته باشید:

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

* در اشاره به بازی‌های دیگر تردید نداشته باشید. بعضی اوقات بررسی بازی‌های دیگر می‌تواند به شما و تیم‌تان دیدگاه بهتری بدهد. اما نه به این معنی که یک الهام مستقیم و بی‌معنی از بازی‌های دیگر بگیرید. یعنی بازی بسازید با دیالوگ‌های شبیه Grim Fandango و کیفیت Call of Duty و سیستم طراحی شخصیت Little Big Planet. با این که جالب است، اما توضیح نمی‌دهد که چه کاری می‌کنید و قرار است چگونه آن را انجام دهید.

* سند را قشنگ بنویسید. این که سند مخصوص خودتان و تیم‌تان است، اما دلیل نمی‌شود جوری ننویسید که قابل خواندن توسط دیگران نباشد. حتی برای دل خودتان بعضی اوقات سندهای قدیمی‌تان را نگاه می‌کنید؛ پس کار را برای خودتان سخت نکنید!

امیدوارم این مقاله برای شما مفید باشد.

منبع: Gamasutra

دیدگاه‌ها

پاسخ
٢
٠

امیر   |   ۱۳۹۷/۰۵/۲۱   |   ۱۹:۱۳

خیلی عالی وقعا مفید بود