پیش نیازهای لازم برای ساخت یک بازی

VahiD_ST

کاربر سایت
Nov 10, 2009
8,048
نام
وحید
سلام به بچه های بازی سنتر.

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

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

امیدوارم تاپیک پاک نشه و یا به بیراهه نره.

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

-------------------------------------------------------------------------------
قسمت اول:



----------------------
مقدمه
----------------------

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



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


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

-----------------------------


قسمت دوم:


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

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

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

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


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



----------------------
قسمت سوم و آخر

----------------------
----------------------
راهنمای کلی از موضوعاتی که باید در مستندات طراحی یک بازی وجود داشته باشد
----------------------
در این بخش به صورت فهرست وار اصول و موضوعات اصلی‌ای که در مستندات طراحی یک بازی باید وجود داشته باشد لیست شده و توضیح خلاصه‌ای در مورد آن داده خواهد شد. مشخص است که برای سبک‌های مختلف ممکن است این لیست دارای تغییراتی باشد. از طرفی در انتها یک نمونه لیست کامل و جزئیات و کارهایی که در طراحی یک بازی باید انجام شود به صورت ضمیمه آورده شده است.
نکته: در بازی‌های امروزی طراحی بازی به دو قسمت طراحی بازی(Game Design) و طراحی فنی بازی(Technical Design) تقسیم می‌شوند. در طراحی بازی تمام بازی به صورت ساده و در قالب کلمات طراحی می‌شود و در طراحی فنی بازی این جملات و تعاریف به روش‌های مهندسی نرم‌افزار و با زبان‌هایی مانند Unified Modeling Language و با استفاده از اصول شیی‌گرا و فلوچارت‌ها به صورت دقیق و به زبان کامپیوتر تعریف می‌شود.
اما لیست کارهایی که در طراحی یک بازی باید انجام شود:


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


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

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


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









ضمیمه های استفاده شده برای این سند:
Game Design Document Outline
Version 0.1(draft) October 10, 2005
By Mark Baldwin
Baldwin Consulting
http://baldwinconsulting.org

The Game Design Document (GDD) it the blueprint from which a computer or video game is to be built. As such, every single detail necessary to build the game must be addressed in the document (or support documents). If it’s not in the document, then it probably won’t be in the game.

Below you will find an outline for a generic Game Design Document. The problem is that no generic GDD will be able to address all the various genres for which a game may be created. For example, consider the games PacMan, SimCity and Doom. All three games required detailed design documents, but if you think about it, those documents would be entirely different! As such, when using the outline below you will find sections that will be totally meaningless to your game. But also, there will be sections that your GDD requires to describe the game. Just because it’s not in my outline, it doesn’t mean that it doesn’t belong.

The GDD is a reference document. Members of the development team will constantly be using the document to find specific information for their specific needs. Consider the size such a document may grow to in order to document every piece of the game. We don’t want the GDD to cause information overload and then become a prop under somebody’s wobbly desk. As such it is important that you organize and format the document to make it easy to use. Also note that some of these sections might not appear in the GDD itself but instead would appear in supplemental documents such as an Art Bible or Test Plan. This helps make the overall document more manageable and readable.

One last comment, a game design document is meant to be a living document. Just as when the artist changes the design of his painting every time he takes his brush to the canvas, a computer or video game evolves as code and art are created. The GDD then is the communication tool from which all the members of the team can follow that evolution.

Title Page
Game Name – Perhaps also add a subtitle or high concept sentence.
Copyright Information
Version Number, author, date
Table of Contents – Make sure this includes all the subsections to make finding material. If practical, hyper linking the document will help here.
Design History – This is a change listing quickly describing each major version and changes.
Section I - Game Overview
Game Concept
Feature Set
Genre
Target Audience
Game Flow Summary – How does the player move through the game. Both through framing interface and the game itself.
Look and Feel – What is the basic look and feel of the game? What is the visual style?
Project Scope – A summary of the scope of the game.
Number of locations
Number of levels
Number of NPC’s
Number of weapons
Etc.
Section II - Gameplay and Mechanics
Gameplay
Game Progression
Mission/challenge Structure
Puzzle Structure
Objectives – What are the objectives of the game?
Play Flow – How does the game flow for the game player
Mechanics – What are the rules to the game, both implicit and explicit. This is the model of the universe that the game works under. Think of it as a simulation of a world, how do all the pieces interact? This actually can be a very large section.
Physics – How does the physical universe work?
Movement
General Movement
Other Movement
Objects
Picking Up Objects
Moving Objects
Actions
Switches and Buttons
Picking Up, Carrying and Dropping
Talking
Reading
Combat – If there is combat or even conflict, how is this specifically modeled?
Economy – What is the economy of the game? How does it work?
Screen Flow
Screen Flow Chart – A graphical description of how each screen is related to every other
Screen Descriptions – What is the purpose of each screen?
Main Menu Screen
Options Screen
Etc.
Game Options – What are the options and how do they affect game play and mechanics?
Replaying and Saving
Cheats and Easter Eggs
Section III – Story, Setting and Character
Story and Narrative - Specific details like scripts and cut scenes may not be in this document but be in the Story Bible.
Back story
Plot Elements
Game Progression
License Considerations
Cut Scenes
Cut scene #1
Actors
Description
Storyboard
Script
Cut scene #2
etc.
Game World
General look and feel of world
Area #1
General Description
Physical Characteristics
Levels that use area
Connections to other areas
Area #2
etc.
Characters
Character #1
Back story
Personality
Look
Physical characteristics
Animations
Special Abilities
Relevance to game story
Relationship to other characters
Statistics
Character #2
etc.
Section IV – Levels
Level #1
Synopsis
Introductory Material (Cut scene? Mission briefing?)
Objectives
Physical Description
Map
Critical Path
Encounters
Level Walkthrough
Closing Material
Level #2
etc.
Training Level
Section V - Interface
Visual System
HUD - What controls
Menus
Rendering System
Camera
Lighting Models
Control System – How does the game player control the game? What are the specific commands?
Audio
Music
Sound Effects
Help System
Section VI - Artificial Intelligence
Opponent AI – The active opponent that plays against the game player and therefore requires strategic decision making (example, Civilization or Chess, how is it to be designed?
Enemy AI – Villains and Monsters
Non-combat Characters
Friendly Characters
Support AI
Player and Collision Detection
Pathfinding
Section VII – Technical – This may be abbreviated with most in the Technical Bible.
Target Hardware
Development hardware and software
Development procedures and standards
Game Engine
Network
Scripting Language
etc.
Section VIII – Game Art - This may be abbreviated with most of the content in an Art Bible.
Concept Art
Style Guides
Characters
Environments
Equipment
Cut scenes
Miscellaneous
Section IX - Secondary Software
Editor
Installer
Update software
Section X - Management
Detailed Schedule
Budget
Risk Analysis
Localization Plan
Test Plan
Appendices
Asset List
Art
Model and Texture List
Animation List
Effects List
Interface Art List
Cut scene List
Sound
Environmental Sounds
Weapon Sounds
Interface Sounds
Music
Ambient
“Action”
Victory
Defeat
Voice
Actor #1 lines
Actor #2 lines
Etc.




ویرایش: قسمت سوم و آخر اضافه شد.
 
آخرین ویرایش:

VahiD_ST

کاربر سایت
Nov 10, 2009
8,048
نام
وحید
ظاهرا کسی محل به این مطلب ما نذاشت. مهم نیست. دو قسمت دیگه داره میزارم اگر دیدم کسی استقبال نکرد میگم تاپیک رو پاک کنن.

-------------------------------------------------

قسمت دوم:


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

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

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

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


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

VahiD_ST

کاربر سایت
Nov 10, 2009
8,048
نام
وحید
قسمت سوم و آخر

راهنمای کلی از موضوعاتی که باید در مستندات طراحی یک بازی وجود داشته باشد

---------------------------------
در این بخش به صورت فهرست وار اصول و موضوعات اصلی‌ای که در مستندات طراحی یک بازی باید وجود داشته باشد لیست شده و توضیح خلاصه‌ای در مورد آن داده خواهد شد. مشخص است که برای سبک‌های مختلف ممکن است این لیست دارای تغییراتی باشد. از طرفی در انتها یک نمونه لیست کامل و جزئیات و کارهایی که در طراحی یک بازی باید انجام شود به صورت ضمیمه آورده شده است.
نکته: در بازی‌های امروزی طراحی بازی به دو قسمت طراحی بازی(Game Design) و طراحی فنی بازی(Technical Design) تقسیم می‌شوند. در طراحی بازی تمام بازی به صورت ساده و در قالب کلمات طراحی می‌شود و در طراحی فنی بازی این جملات و تعاریف به روش‌های مهندسی نرم‌افزار و با زبان‌هایی مانند Unified Modeling Language و با استفاده از اصول شیی‌گرا و فلوچارت‌ها به صورت دقیق و به زبان کامپیوتر تعریف می‌شود.
اما لیست کارهایی که در طراحی یک بازی باید انجام شود:


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

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

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


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









ضمیمه های استفاده شده برای این سند:
Game Design Document Outline
Version 0.1(draft) October 10, 2005
By Mark Baldwin
Baldwin Consulting
http://baldwinconsulting.org

The Game Design Document (GDD) it the blueprint from which a computer or video game is to be built. As such, every single detail necessary to build the game must be addressed in the document (or support documents). If it’s not in the document, then it probably won’t be in the game.

Below you will find an outline for a generic Game Design Document. The problem is that no generic GDD will be able to address all the various genres for which a game may be created. For example, consider the games PacMan, SimCity and Doom. All three games required detailed design documents, but if you think about it, those documents would be entirely different! As such, when using the outline below you will find sections that will be totally meaningless to your game. But also, there will be sections that your GDD requires to describe the game. Just because it’s not in my outline, it doesn’t mean that it doesn’t belong.

The GDD is a reference document. Members of the development team will constantly be using the document to find specific information for their specific needs. Consider the size such a document may grow to in order to document every piece of the game. We don’t want the GDD to cause information overload and then become a prop under somebody’s wobbly desk. As such it is important that you organize and format the document to make it easy to use. Also note that some of these sections might not appear in the GDD itself but instead would appear in supplemental documents such as an Art Bible or Test Plan. This helps make the overall document more manageable and readable.

One last comment, a game design document is meant to be a living document. Just as when the artist changes the design of his painting every time he takes his brush to the canvas, a computer or video game evolves as code and art are created. The GDD then is the communication tool from which all the members of the team can follow that evolution.

Title Page
Game Name – Perhaps also add a subtitle or high concept sentence.
Copyright Information
Version Number, author, date
Table of Contents – Make sure this includes all the subsections to make finding material. If practical, hyper linking the document will help here.
Design History – This is a change listing quickly describing each major version and changes.
Section I - Game Overview
Game Concept
Feature Set
Genre
Target Audience
Game Flow Summary – How does the player move through the game. Both through framing interface and the game itself.
Look and Feel – What is the basic look and feel of the game? What is the visual style?
Project Scope – A summary of the scope of the game.
Number of locations
Number of levels
Number of NPC’s
Number of weapons
Etc.
Section II - Gameplay and Mechanics
Gameplay
Game Progression
Mission/challenge Structure
Puzzle Structure
Objectives – What are the objectives of the game?
Play Flow – How does the game flow for the game player
Mechanics – What are the rules to the game, both implicit and explicit. This is the model of the universe that the game works under. Think of it as a simulation of a world, how do all the pieces interact? This actually can be a very large section.
Physics – How does the physical universe work?
Movement
General Movement
Other Movement
Objects
Picking Up Objects
Moving Objects
Actions
Switches and Buttons
Picking Up, Carrying and Dropping
Talking
Reading
Combat – If there is combat or even conflict, how is this specifically modeled?
Economy – What is the economy of the game? How does it work?
Screen Flow
Screen Flow Chart – A graphical description of how each screen is related to every other
Screen Descriptions – What is the purpose of each screen?
Main Menu Screen
Options Screen
Etc.
Game Options – What are the options and how do they affect game play and mechanics?
Replaying and Saving
Cheats and Easter Eggs
Section III – Story, Setting and Character
Story and Narrative - Specific details like scripts and cut scenes may not be in this document but be in the Story Bible.
Back story
Plot Elements
Game Progression
License Considerations
Cut Scenes
Cut scene #1
Actors
Description
Storyboard
Script
Cut scene #2
etc.
Game World
General look and feel of world
Area #1
General Description
Physical Characteristics
Levels that use area
Connections to other areas
Area #2
etc.
Characters
Character #1
Back story
Personality
Look
Physical characteristics
Animations
Special Abilities
Relevance to game story
Relationship to other characters
Statistics
Character #2
etc.
Section IV – Levels
Level #1
Synopsis
Introductory Material (Cut scene? Mission briefing?)
Objectives
Physical Description
Map
Critical Path
Encounters
Level Walkthrough
Closing Material
Level #2
etc.
Training Level
Section V - Interface
Visual System
HUD - What controls
Menus
Rendering System
Camera
Lighting Models
Control System – How does the game player control the game? What are the specific commands?
Audio
Music
Sound Effects
Help System
Section VI - Artificial Intelligence
Opponent AI – The active opponent that plays against the game player and therefore requires strategic decision making (example, Civilization or Chess, how is it to be designed?
Enemy AI – Villains and Monsters
Non-combat Characters
Friendly Characters
Support AI
Player and Collision Detection
Pathfinding
Section VII – Technical – This may be abbreviated with most in the Technical Bible.
Target Hardware
Development hardware and software
Development procedures and standards
Game Engine
Network
Scripting Language
etc.
Section VIII – Game Art - This may be abbreviated with most of the content in an Art Bible.
Concept Art
Style Guides
Characters
Environments
Equipment
Cut scenes
Miscellaneous
Section IX - Secondary Software
Editor
Installer
Update software
Section X - Management
Detailed Schedule
Budget
Risk Analysis
Localization Plan
Test Plan
Appendices
Asset List
Art
Model and Texture List
Animation List
Effects List
Interface Art List
Cut scene List
Sound
Environmental Sounds
Weapon Sounds
Interface Sounds
Music
Ambient
“Action”
Victory
Defeat
Voice
Actor #1 lines
Actor #2 lines
Etc.
 

کاربرانی که این قسمت را مشاهده می‌کنند

Top
رمز عبور خود را فراموش کرده اید؟
or ثبت‌نام سریع از طریق سرویس‌های زیر