ورود
ثبت نام
صفحه اصلی
اخبار بازی
بررسی بازی
حقایق بازیها
داستان بازی
بررسی سخت افزار
برنامههای ویدیویی
انجمنها
نوشتههای جدید
پرمخاطبها
جستجوی انجمنها
جدیدترینها
ارسالهای جدید
آخرین فعالیتها
کاربران
کاربران آنلاین
جستجو
جستجو فقط عنوان ها
توسط:
جستجو فقط عنوان ها
توسط:
ورود
ثبت نام
جستجو
جستجو فقط عنوان ها
توسط:
جستجو فقط عنوان ها
توسط:
Menu
Install the app
Install
فراخوان عضویت در تحریریه بازیسنتر | برای ثبت درخواست کلیک کنید
صفحه اصلی
انجمنها
گفتگو درباره بازیها و صنعت بازیهای ویدیویی
گفتگوی آزاد پیرامون بازیها
پیش نیازهای لازم برای ساخت یک بازی
ارسال پاسخ
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
متن گفتگو
<blockquote data-quote="VahiD_ST" data-source="post: 1196587" data-attributes="member: 41400"><p><strong>قسمت سوم و آخر</strong></p><p><strong></strong></p><p><strong>راهنمای کلی از موضوعاتی که باید در مستندات طراحی یک بازی وجود داشته باشد</strong></p><p>---------------------------------</p><p>در این بخش به صورت فهرست وار اصول و موضوعات اصلیای که در مستندات طراحی یک بازی باید وجود داشته باشد لیست شده و توضیح خلاصهای در مورد آن داده خواهد شد. مشخص است که برای سبکهای مختلف ممکن است این لیست دارای تغییراتی باشد. از طرفی در انتها یک نمونه لیست کامل و جزئیات و کارهایی که در طراحی یک بازی باید انجام شود به صورت ضمیمه آورده شده است.</p><p>نکته: در بازیهای امروزی طراحی بازی به دو قسمت طراحی بازی(Game Design) و طراحی فنی بازی(Technical Design) تقسیم میشوند. در طراحی بازی تمام بازی به صورت ساده و در قالب کلمات طراحی میشود و در طراحی فنی بازی این جملات و تعاریف به روشهای مهندسی نرمافزار و با زبانهایی مانند Unified Modeling Language و با استفاده از اصول شییگرا و فلوچارتها به صورت دقیق و به زبان کامپیوتر تعریف میشود.</p><p>اما لیست کارهایی که در طراحی یک بازی باید انجام شود:</p><p></p><p></p><p><strong>مستندات چشمانداز پروژه ساخت بازی</strong></p><p>---------------------------------</p><p>این مستندات شامل نگاه کلی و اهداف اصلی ساخت بازی است.</p><p>به این مستندات، مستندات مفهومی بازی نیز میگویند.</p><p>این مستندات به صورت خلاصه مشخصههای اصلی بازی را معین میکند.</p><p>اهداف اصلی از ساخت بازی باید در این اسناد مشخص شود.</p><p>در این مستندات قرار نیست مانند یک طرح پیشنهادی نیروها و زمان انجام پروژه نیز مشخص شود.</p><p>هدف این است که در چند صفحه هرکس بتواند بعد از خواندن این مستندات نگاه و چشمانداز درست و کاملی از بازی و اهداف اصلی آن داشته باشد.</p><p></p><p><strong>جمع آوری و مشخص کردن، نیازهای بازی</strong></p><p>---------------------------------</p><p>یکی دیگر از کارهای اصلی برای شروع طراحی بازی مشخص کردن نیازها و مشخصات یک بازی است.</p><p>منظور از نیازهای بازی همه آن چیزهایی است که بازی نیاز دارد تا انجام شود.</p><p>بهترین راه شناسایی این نیازها قرار دادن خود به جای مخاطب و گیمر است.</p><p>حداقل سختافزار مورد نیاز بازی یک نیاز است. یعنی بازی برای انجام چه سختافزاری میخواهد.</p><p>منوی بازی</p><p>ابزار مورد نیاز کاراکتر اصلی بازی</p><p>تعداد پولی گون برای نمایش کاراکترهای بازی</p><p>موتور مورد نیاز برای ساخت بازی.</p><p>و هر چیزی که بازی برای انجام شدن به آن نیاز دارد باید در این لیست وجود داشته باشد.</p><p>با استفاده از این لیست و جمع آوری هرچه دقیقتر و بیشتر نیازهای یک بازی کار طراحی بازی بسیار سادهتر و راحتتر انجام خواهد شد.</p><p></p><p><strong>طراحی بازی</strong></p><p>---------------------------------</p><p>مفهوم و ایده اصلی بازی</p><p>یک قدم جلوتر از طرح چشمانداز بازی باید بازی به صورت کامل و خلاصه تعریف شود.</p><p>به طور خلاصه هسته اصلی بازی و روند آن تعریف شود.</p><p>نوآوریهای جدید بازی(اگر وجود دارد) معین شود.</p><p>طوفان مغزی</p><p>با کمک همهی اعضای ساخت بازی ایدهای مختلف جمعآوری گردد.</p><p>ایدههای مختلف مانند روند بازی، سبک گرافیکی، داستان و ....</p><p>بخشهای مختلف هنری و فنی نظرات و ایدههای خود در مورد مفهوم اصلی بازی، مشکلات و جزئیات ساخت بازی را بدهند.</p><p>جمع بندی ایدهها و حذف و ویرایش نهایی گیمپلی اصلی بازی</p><p>شروع به مستند کردن طراحی بازی</p><p>از این به بعد تمامی بازی و با جزئیات کامل باید نوشته شود.</p><p>در این بخش میتوان از روشهای مرسوم کنترل ورژن برای ثبت تغییرات استفاده کرد.</p><p>با استفاده از بانکهای اطلاعاتی و نرمافزارهایی مانند اکسل، دیاگرامها و طرحهای ساده باید طراحی بازی به صورت شفاف، مشخص و در ارتباط منطقی با سایر قسمتهای بازی انجام شود.</p><p>60 ثانیه بازی</p><p>در بسیاری از پروژههای خوب بازیسازی، حدود شصت ثانیه از گیمپلی در مستندات طراحی تعریف و طراحی میشود. در این شصت ثانیه همه کارهایی که در کل بازی انجام میشود با جزئیات کامل و با توجه به تعاریف بخشهای قبل شرح داده میشود.</p><p>تمام تعاملاتی که در بخشهای مختلف در بازی روی میدهد در این شصت ثانیه نمونه بازی، مشخص میشود( از اتفاقاتی که در صفحه نمایش برای مخاطب روی میدهد تا الگوریتمهایی که در موتور پایه اجرا میشود و حتی دستوراتی که در سیستم عامل اجرا میشود(مثلا برای وصل شدن به اینترنت برای بازی گروهی))</p><p>هسته اصلی بازی</p><p>شامل توضیح، تشریح و توصیف کامل مکانیزمهای بازی است.</p><p>شصت ثانیه گیم پلی به انجام این کار بسیار کمک میکند.</p><p>توصیف و تشریح کامل تعاملات بازی، رفتارها و کنترلهایی که در گیمپلی بازی وجود دارد در این بخش انجام خواهد شد.</p><p>جمع آوری و مشخص کردن نیازهای بازی در این بخش بسیار به کمک خواهد آمد.</p><p>جواب دادن به همه نیازهای بازی و دسته بندی کردن آنها باعث خواهد شد که چیزی از قلم نیافتد.</p><p>راهنمای قدم به قدم</p><p>یکی از مهمترین بخشهای یک مستند طراحی بازی راهنمای قدم به قدم بازی</p><p>با استفاده از این راهنما و بدون فکر بازیکننده باید بازی را بدون مشکل تا آخر برود(در صورتی که بازی تکمیل شده باشد)</p><p>کلیه کارهایی که بازیکننده در بازی باید انجام دهد در این راهنما وجود دارد.</p><p>از روایت داستان در این راهنما خبری نیست و فقط قرار است که بصورت مکانیکی بازی به آخر برسد.</p><p>با تکمیل این راهنما کلیه مکانیزمها، مراحل، مبارزات، معماها و ... بازی از ابتدا تا انتها مشخص خواهد شد.</p><p>لیست منابع مورد نیاز بازی</p><p>این لیست شامل همه منابع و مواردی است که بازی برای اجرا و نمایش به آن نیاز دارد از لیست کاراکترها و دشمنان گرفته تا انواع بافتها، کاشیها، سلاحها و ....</p><p>رفتار و انواع هوش مصنوعی و ...</p><p>لیست افکتهای صدا</p><p>صدای کاراکترها</p><p>تمهای مختلف موسیقی</p><p>سلاحها</p><p>ابزار</p><p>جادوها</p><p>مدلهای کاراکترها</p><p>مدلهای محیط بازی</p><p>انیمیشنها</p><p>هوش مصنوعی</p><p>ماموریتها</p><p>کات سینها</p><p>اسکریپها</p><p>....</p><p>همه این لیستها باید به صورت کامل و جامع برای کل بازی از ابتدا تا انتهای آن، و در ارتباط با سایر بخشهای مستندات طراحی مشخص شده باشد و تا حد ممکن مشخصههای اصلی آنها در یک بانک اطلاعاتی تعریف شده باشد.</p><p>نمونههایی از دیگر بازیها</p><p>در صورتی که بازی شما از یک یا چند بازی دیگر الهام گرفته است مشخصات آن بازیها و نکاتی که از آنها ایده گرفته شده است آورده شود.</p><p>این کار بهتر است با تکه فیلمی از بازی نمونه همراه باشد که آن بخش یا مکانیزم خاص را نمایش میدهد.</p><p>طراحی منوها</p><p>کلیه منوهای بازی و واسطهای کاربری باید به دقت طراحی شوند.</p><p>هدف طراحی مکانیزم منوها به همراه جزئیات و به صورت کامل است.</p><p>طراحی هنری و بصری ممکن است بارها تغییر کند بنابراین طراحی گرافیکی منوها در حد اولیه و برای ایده دادن به بخش هنری است.</p><p>کلیه آیتمهای منوها، کلید و اتفاقاتی که در این منوها روی میدهد باید مشخص و تعریف شوند.</p><p>جزئیات دقیق مکانیزمهای بازی</p><p>کلیه مکانیزمهای بازی که قبلا تعریف شدهاند باید به صورت کامل و در ارتباط با سایر بخشهای بازی در اینجا تعریف شوند.</p><p>مکانیزمهای بازی از مکانیزم حرکت کاراکتر اصلی میتواند باشد تا مکانیزم باز و بسته شدن یک در.</p><p>نوشتن دفترچه راهنمای بازی</p><p>طراحیهای هنری و مفهومی بازی</p><p>کاراکترها</p><p>آیتمها</p><p>فضاها</p><p>استوری برد انیمیشنهای کاراکترهای بازی</p><p>استوری برد کات سینهای بازی</p><p>طراحی فنی بازی</p><p></p><p></p><p><strong>کلام آخر</strong></p><p>---------------------------------</p><p>کار طراحی بازی و جمعآوری و ساخت یک مستندات طراحی کامل اصلا کوچک، بیاهمیت و ساده نیست. برای یک بازی خوب یا بهتر بگوییم یک بازی بزرگ ایرانی شبیه شمشیرنادر، لطفعلی خان، عصر پهلوانان و ... این مستندات در حد یک کتاب چند صد صفحهای است و انجام آن شاید چندین ماه زمان ببرد.</p><p>دوباره تاکید میکنیم در طراحی یک بازی بزرگ این مستندات لازم و حیاتی است و بدون آن حرکت در تاریکی و بدون نور و شناخت مسیر است. به همین دلیل است که اکثر پروژهها بسیار طولانی، نامعین و در انتها با مشکلات فراوان همراه میشوند و در نهایت با کم و کسریهای فراوان به بازار عرضه میشوند.</p><p>برای طرحی مستندات یک بازی خوب با همکاری مدیر پروژه، مدیر فنی، مدیر هنری با وقت بسیار کم در حد مشاروه و با حضور تمام وقت طراح یا طراحان بازی و با صرف هزینه پایین میتوان به یک طرح جامع دست یافت. </p><p>لازم به توضیح است که مستندات طراحی بازی هرچه دقیقتر و کاملتر باشد هزینههای ساخت و زمان انجام پروژه به واقعیت و آنچه در طرح است نزدیکتر خواهند شد و پس از پایان این طراحی مدیران پروژه با احاطه کامل خواهند توانست برنامه ریزی دقیقی از نظر منابع انسانی، مالی و زمانی برای ساخت بازی داشته باشند. </p><p>مدیران با داشتن مستندات کامل طراحی در صورت لزوم خواهند توانست در همان ابتدای پروژه بخشهایی که به اصل و جذابیت بازی لطمه نزند را از پروژه حذف کنند(برای رسیدن به زمان یا سقف مالی پروژه) یا در همان ابتدا از ساخت یک بازی بیکیفیت و هدر دادن سرمایهها جلوگیری کنند.</p><p>از طرفی مستندات کامل طراحی باعث خواهد شد که تهیه کننده یا سرمایهگذار را به سرمایهگذاری بیشتر و با اطمینان بالاتر برای پروژه ساخت یک بازی جذب کند.</p><p>در پایان نیز باید گفت با اینکه مستندات طراحی یک بازی پس از تصویت به عنوان کتاب قانون و حرف اول و آخر یک پروژه است. اما در حین ساخت بازی و با مشخص شدن مشکلات و کاستیها قابل تغییر است. اما بازهم به مدد یک طراحی قوی و کامل این تغییرات با آگاهی و با ریسک بسیار پایین انجام خواهد شد.</p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p style="text-align: left">ضمیمه های استفاده شده برای این سند:</p> <p style="text-align: left">[SPOILER=]Game Design Document Outline </p> <p style="text-align: left">Version 0.1(draft) October 10, 2005</p> <p style="text-align: left">By Mark Baldwin</p> <p style="text-align: left">Baldwin Consulting</p> <p style="text-align: left"><a href="http://baldwinconsulting.org">http://baldwinconsulting.org</a></p> <p style="text-align: left"></p> <p style="text-align: left">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.</p> <p style="text-align: left"></p> <p style="text-align: left">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.</p> <p style="text-align: left"></p> <p style="text-align: left">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. </p> <p style="text-align: left"></p> <p style="text-align: left">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. </p> <p style="text-align: left"></p> <p style="text-align: left">Title Page </p> <p style="text-align: left">Game Name – Perhaps also add a subtitle or high concept sentence.</p> <p style="text-align: left">Copyright Information</p> <p style="text-align: left">Version Number, author, date</p> <p style="text-align: left">Table of Contents – Make sure this includes all the subsections to make finding material. If practical, hyper linking the document will help here. </p> <p style="text-align: left">Design History – This is a change listing quickly describing each major version and changes.</p> <p style="text-align: left">Section I - Game Overview</p> <p style="text-align: left">Game Concept</p> <p style="text-align: left">Feature Set</p> <p style="text-align: left">Genre</p> <p style="text-align: left">Target Audience</p> <p style="text-align: left">Game Flow Summary – How does the player move through the game. Both through framing interface and the game itself.</p> <p style="text-align: left">Look and Feel – What is the basic look and feel of the game? What is the visual style?</p> <p style="text-align: left">Project Scope – A summary of the scope of the game.</p> <p style="text-align: left">Number of locations</p> <p style="text-align: left">Number of levels</p> <p style="text-align: left">Number of NPC’s</p> <p style="text-align: left">Number of weapons</p> <p style="text-align: left">Etc.</p> <p style="text-align: left">Section II - Gameplay and Mechanics</p> <p style="text-align: left">Gameplay</p> <p style="text-align: left">Game Progression</p> <p style="text-align: left">Mission/challenge Structure</p> <p style="text-align: left">Puzzle Structure</p> <p style="text-align: left">Objectives – What are the objectives of the game?</p> <p style="text-align: left">Play Flow – How does the game flow for the game player</p> <p style="text-align: left">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.</p> <p style="text-align: left">Physics – How does the physical universe work?</p> <p style="text-align: left">Movement</p> <p style="text-align: left">General Movement</p> <p style="text-align: left">Other Movement</p> <p style="text-align: left">Objects</p> <p style="text-align: left">Picking Up Objects</p> <p style="text-align: left">Moving Objects</p> <p style="text-align: left">Actions</p> <p style="text-align: left">Switches and Buttons</p> <p style="text-align: left">Picking Up, Carrying and Dropping</p> <p style="text-align: left">Talking</p> <p style="text-align: left">Reading</p> <p style="text-align: left">Combat – If there is combat or even conflict, how is this specifically modeled?</p> <p style="text-align: left">Economy – What is the economy of the game? How does it work?</p> <p style="text-align: left">Screen Flow</p> <p style="text-align: left">Screen Flow Chart – A graphical description of how each screen is related to every other</p> <p style="text-align: left">Screen Descriptions – What is the purpose of each screen? </p> <p style="text-align: left">Main Menu Screen</p> <p style="text-align: left">Options Screen</p> <p style="text-align: left">Etc.</p> <p style="text-align: left">Game Options – What are the options and how do they affect game play and mechanics?</p> <p style="text-align: left">Replaying and Saving </p> <p style="text-align: left">Cheats and Easter Eggs</p> <p style="text-align: left">Section III – Story, Setting and Character </p> <p style="text-align: left">Story and Narrative - Specific details like scripts and cut scenes may not be in this document but be in the Story Bible. </p> <p style="text-align: left">Back story</p> <p style="text-align: left">Plot Elements</p> <p style="text-align: left">Game Progression</p> <p style="text-align: left">License Considerations</p> <p style="text-align: left">Cut Scenes</p> <p style="text-align: left">Cut scene #1</p> <p style="text-align: left">Actors</p> <p style="text-align: left">Description</p> <p style="text-align: left">Storyboard</p> <p style="text-align: left">Script</p> <p style="text-align: left">Cut scene #2</p> <p style="text-align: left">etc.</p> <p style="text-align: left">Game World</p> <p style="text-align: left">General look and feel of world</p> <p style="text-align: left">Area #1</p> <p style="text-align: left">General Description</p> <p style="text-align: left">Physical Characteristics</p> <p style="text-align: left">Levels that use area</p> <p style="text-align: left">Connections to other areas</p> <p style="text-align: left">Area #2</p> <p style="text-align: left">etc.</p> <p style="text-align: left">Characters</p> <p style="text-align: left">Character #1</p> <p style="text-align: left">Back story</p> <p style="text-align: left">Personality</p> <p style="text-align: left">Look</p> <p style="text-align: left">Physical characteristics</p> <p style="text-align: left">Animations</p> <p style="text-align: left">Special Abilities</p> <p style="text-align: left">Relevance to game story</p> <p style="text-align: left">Relationship to other characters</p> <p style="text-align: left">Statistics</p> <p style="text-align: left">Character #2</p> <p style="text-align: left">etc.</p> <p style="text-align: left">Section IV – Levels</p> <p style="text-align: left">Level #1</p> <p style="text-align: left">Synopsis</p> <p style="text-align: left">Introductory Material (Cut scene? Mission briefing?)</p> <p style="text-align: left">Objectives</p> <p style="text-align: left">Physical Description</p> <p style="text-align: left">Map</p> <p style="text-align: left">Critical Path</p> <p style="text-align: left">Encounters</p> <p style="text-align: left">Level Walkthrough</p> <p style="text-align: left">Closing Material</p> <p style="text-align: left">Level #2</p> <p style="text-align: left">etc.</p> <p style="text-align: left">Training Level</p> <p style="text-align: left">Section V - Interface</p> <p style="text-align: left">Visual System</p> <p style="text-align: left">HUD - What controls </p> <p style="text-align: left">Menus</p> <p style="text-align: left">Rendering System</p> <p style="text-align: left">Camera</p> <p style="text-align: left">Lighting Models</p> <p style="text-align: left">Control System – How does the game player control the game? What are the specific commands?</p> <p style="text-align: left">Audio</p> <p style="text-align: left">Music</p> <p style="text-align: left">Sound Effects</p> <p style="text-align: left">Help System</p> <p style="text-align: left">Section VI - Artificial Intelligence</p> <p style="text-align: left">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?</p> <p style="text-align: left">Enemy AI – Villains and Monsters</p> <p style="text-align: left">Non-combat Characters</p> <p style="text-align: left">Friendly Characters</p> <p style="text-align: left">Support AI</p> <p style="text-align: left">Player and Collision Detection</p> <p style="text-align: left">Pathfinding</p> <p style="text-align: left">Section VII – Technical – This may be abbreviated with most in the Technical Bible.</p> <p style="text-align: left">Target Hardware</p> <p style="text-align: left">Development hardware and software</p> <p style="text-align: left">Development procedures and standards</p> <p style="text-align: left">Game Engine</p> <p style="text-align: left">Network</p> <p style="text-align: left">Scripting Language</p> <p style="text-align: left">etc.</p> <p style="text-align: left">Section VIII – Game Art - This may be abbreviated with most of the content in an Art Bible.</p> <p style="text-align: left">Concept Art</p> <p style="text-align: left">Style Guides</p> <p style="text-align: left">Characters</p> <p style="text-align: left">Environments</p> <p style="text-align: left">Equipment</p> <p style="text-align: left">Cut scenes</p> <p style="text-align: left">Miscellaneous</p> <p style="text-align: left">Section IX - Secondary Software</p> <p style="text-align: left">Editor</p> <p style="text-align: left">Installer</p> <p style="text-align: left">Update software</p> <p style="text-align: left">Section X - Management</p> <p style="text-align: left">Detailed Schedule</p> <p style="text-align: left">Budget</p> <p style="text-align: left">Risk Analysis</p> <p style="text-align: left">Localization Plan </p> <p style="text-align: left">Test Plan</p> <p style="text-align: left">Appendices</p> <p style="text-align: left">Asset List</p> <p style="text-align: left">Art</p> <p style="text-align: left">Model and Texture List</p> <p style="text-align: left">Animation List</p> <p style="text-align: left">Effects List</p> <p style="text-align: left">Interface Art List </p> <p style="text-align: left">Cut scene List</p> <p style="text-align: left">Sound</p> <p style="text-align: left">Environmental Sounds</p> <p style="text-align: left">Weapon Sounds</p> <p style="text-align: left">Interface Sounds</p> <p style="text-align: left">Music</p> <p style="text-align: left">Ambient</p> <p style="text-align: left">“Action”</p> <p style="text-align: left">Victory</p> <p style="text-align: left">Defeat</p> <p style="text-align: left">Voice</p> <p style="text-align: left">Actor #1 lines</p> <p style="text-align: left">Actor #2 lines</p> <p style="text-align: left">Etc.</p> <p style="text-align: left">[/SPOILER]</p> <p style="text-align: left"></p></blockquote><p></p>
[QUOTE="VahiD_ST, post: 1196587, member: 41400"] [B]قسمت سوم و آخر راهنمای کلی از موضوعاتی که باید در مستندات طراحی یک بازی وجود داشته باشد[/B] --------------------------------- در این بخش به صورت فهرست وار اصول و موضوعات اصلیای که در مستندات طراحی یک بازی باید وجود داشته باشد لیست شده و توضیح خلاصهای در مورد آن داده خواهد شد. مشخص است که برای سبکهای مختلف ممکن است این لیست دارای تغییراتی باشد. از طرفی در انتها یک نمونه لیست کامل و جزئیات و کارهایی که در طراحی یک بازی باید انجام شود به صورت ضمیمه آورده شده است. نکته: در بازیهای امروزی طراحی بازی به دو قسمت طراحی بازی(Game Design) و طراحی فنی بازی(Technical Design) تقسیم میشوند. در طراحی بازی تمام بازی به صورت ساده و در قالب کلمات طراحی میشود و در طراحی فنی بازی این جملات و تعاریف به روشهای مهندسی نرمافزار و با زبانهایی مانند Unified Modeling Language و با استفاده از اصول شییگرا و فلوچارتها به صورت دقیق و به زبان کامپیوتر تعریف میشود. اما لیست کارهایی که در طراحی یک بازی باید انجام شود: [B]مستندات چشمانداز پروژه ساخت بازی[/B] --------------------------------- این مستندات شامل نگاه کلی و اهداف اصلی ساخت بازی است. به این مستندات، مستندات مفهومی بازی نیز میگویند. این مستندات به صورت خلاصه مشخصههای اصلی بازی را معین میکند. اهداف اصلی از ساخت بازی باید در این اسناد مشخص شود. در این مستندات قرار نیست مانند یک طرح پیشنهادی نیروها و زمان انجام پروژه نیز مشخص شود. هدف این است که در چند صفحه هرکس بتواند بعد از خواندن این مستندات نگاه و چشمانداز درست و کاملی از بازی و اهداف اصلی آن داشته باشد. [B]جمع آوری و مشخص کردن، نیازهای بازی[/B] --------------------------------- یکی دیگر از کارهای اصلی برای شروع طراحی بازی مشخص کردن نیازها و مشخصات یک بازی است. منظور از نیازهای بازی همه آن چیزهایی است که بازی نیاز دارد تا انجام شود. بهترین راه شناسایی این نیازها قرار دادن خود به جای مخاطب و گیمر است. حداقل سختافزار مورد نیاز بازی یک نیاز است. یعنی بازی برای انجام چه سختافزاری میخواهد. منوی بازی ابزار مورد نیاز کاراکتر اصلی بازی تعداد پولی گون برای نمایش کاراکترهای بازی موتور مورد نیاز برای ساخت بازی. و هر چیزی که بازی برای انجام شدن به آن نیاز دارد باید در این لیست وجود داشته باشد. با استفاده از این لیست و جمع آوری هرچه دقیقتر و بیشتر نیازهای یک بازی کار طراحی بازی بسیار سادهتر و راحتتر انجام خواهد شد. [B]طراحی بازی[/B] --------------------------------- مفهوم و ایده اصلی بازی یک قدم جلوتر از طرح چشمانداز بازی باید بازی به صورت کامل و خلاصه تعریف شود. به طور خلاصه هسته اصلی بازی و روند آن تعریف شود. نوآوریهای جدید بازی(اگر وجود دارد) معین شود. طوفان مغزی با کمک همهی اعضای ساخت بازی ایدهای مختلف جمعآوری گردد. ایدههای مختلف مانند روند بازی، سبک گرافیکی، داستان و .... بخشهای مختلف هنری و فنی نظرات و ایدههای خود در مورد مفهوم اصلی بازی، مشکلات و جزئیات ساخت بازی را بدهند. جمع بندی ایدهها و حذف و ویرایش نهایی گیمپلی اصلی بازی شروع به مستند کردن طراحی بازی از این به بعد تمامی بازی و با جزئیات کامل باید نوشته شود. در این بخش میتوان از روشهای مرسوم کنترل ورژن برای ثبت تغییرات استفاده کرد. با استفاده از بانکهای اطلاعاتی و نرمافزارهایی مانند اکسل، دیاگرامها و طرحهای ساده باید طراحی بازی به صورت شفاف، مشخص و در ارتباط منطقی با سایر قسمتهای بازی انجام شود. 60 ثانیه بازی در بسیاری از پروژههای خوب بازیسازی، حدود شصت ثانیه از گیمپلی در مستندات طراحی تعریف و طراحی میشود. در این شصت ثانیه همه کارهایی که در کل بازی انجام میشود با جزئیات کامل و با توجه به تعاریف بخشهای قبل شرح داده میشود. تمام تعاملاتی که در بخشهای مختلف در بازی روی میدهد در این شصت ثانیه نمونه بازی، مشخص میشود( از اتفاقاتی که در صفحه نمایش برای مخاطب روی میدهد تا الگوریتمهایی که در موتور پایه اجرا میشود و حتی دستوراتی که در سیستم عامل اجرا میشود(مثلا برای وصل شدن به اینترنت برای بازی گروهی)) هسته اصلی بازی شامل توضیح، تشریح و توصیف کامل مکانیزمهای بازی است. شصت ثانیه گیم پلی به انجام این کار بسیار کمک میکند. توصیف و تشریح کامل تعاملات بازی، رفتارها و کنترلهایی که در گیمپلی بازی وجود دارد در این بخش انجام خواهد شد. جمع آوری و مشخص کردن نیازهای بازی در این بخش بسیار به کمک خواهد آمد. جواب دادن به همه نیازهای بازی و دسته بندی کردن آنها باعث خواهد شد که چیزی از قلم نیافتد. راهنمای قدم به قدم یکی از مهمترین بخشهای یک مستند طراحی بازی راهنمای قدم به قدم بازی با استفاده از این راهنما و بدون فکر بازیکننده باید بازی را بدون مشکل تا آخر برود(در صورتی که بازی تکمیل شده باشد) کلیه کارهایی که بازیکننده در بازی باید انجام دهد در این راهنما وجود دارد. از روایت داستان در این راهنما خبری نیست و فقط قرار است که بصورت مکانیکی بازی به آخر برسد. با تکمیل این راهنما کلیه مکانیزمها، مراحل، مبارزات، معماها و ... بازی از ابتدا تا انتها مشخص خواهد شد. لیست منابع مورد نیاز بازی این لیست شامل همه منابع و مواردی است که بازی برای اجرا و نمایش به آن نیاز دارد از لیست کاراکترها و دشمنان گرفته تا انواع بافتها، کاشیها، سلاحها و .... رفتار و انواع هوش مصنوعی و ... لیست افکتهای صدا صدای کاراکترها تمهای مختلف موسیقی سلاحها ابزار جادوها مدلهای کاراکترها مدلهای محیط بازی انیمیشنها هوش مصنوعی ماموریتها کات سینها اسکریپها .... همه این لیستها باید به صورت کامل و جامع برای کل بازی از ابتدا تا انتهای آن، و در ارتباط با سایر بخشهای مستندات طراحی مشخص شده باشد و تا حد ممکن مشخصههای اصلی آنها در یک بانک اطلاعاتی تعریف شده باشد. نمونههایی از دیگر بازیها در صورتی که بازی شما از یک یا چند بازی دیگر الهام گرفته است مشخصات آن بازیها و نکاتی که از آنها ایده گرفته شده است آورده شود. این کار بهتر است با تکه فیلمی از بازی نمونه همراه باشد که آن بخش یا مکانیزم خاص را نمایش میدهد. طراحی منوها کلیه منوهای بازی و واسطهای کاربری باید به دقت طراحی شوند. هدف طراحی مکانیزم منوها به همراه جزئیات و به صورت کامل است. طراحی هنری و بصری ممکن است بارها تغییر کند بنابراین طراحی گرافیکی منوها در حد اولیه و برای ایده دادن به بخش هنری است. کلیه آیتمهای منوها، کلید و اتفاقاتی که در این منوها روی میدهد باید مشخص و تعریف شوند. جزئیات دقیق مکانیزمهای بازی کلیه مکانیزمهای بازی که قبلا تعریف شدهاند باید به صورت کامل و در ارتباط با سایر بخشهای بازی در اینجا تعریف شوند. مکانیزمهای بازی از مکانیزم حرکت کاراکتر اصلی میتواند باشد تا مکانیزم باز و بسته شدن یک در. نوشتن دفترچه راهنمای بازی طراحیهای هنری و مفهومی بازی کاراکترها آیتمها فضاها استوری برد انیمیشنهای کاراکترهای بازی استوری برد کات سینهای بازی طراحی فنی بازی [B]کلام آخر[/B] --------------------------------- کار طراحی بازی و جمعآوری و ساخت یک مستندات طراحی کامل اصلا کوچک، بیاهمیت و ساده نیست. برای یک بازی خوب یا بهتر بگوییم یک بازی بزرگ ایرانی شبیه شمشیرنادر، لطفعلی خان، عصر پهلوانان و ... این مستندات در حد یک کتاب چند صد صفحهای است و انجام آن شاید چندین ماه زمان ببرد. دوباره تاکید میکنیم در طراحی یک بازی بزرگ این مستندات لازم و حیاتی است و بدون آن حرکت در تاریکی و بدون نور و شناخت مسیر است. به همین دلیل است که اکثر پروژهها بسیار طولانی، نامعین و در انتها با مشکلات فراوان همراه میشوند و در نهایت با کم و کسریهای فراوان به بازار عرضه میشوند. برای طرحی مستندات یک بازی خوب با همکاری مدیر پروژه، مدیر فنی، مدیر هنری با وقت بسیار کم در حد مشاروه و با حضور تمام وقت طراح یا طراحان بازی و با صرف هزینه پایین میتوان به یک طرح جامع دست یافت. لازم به توضیح است که مستندات طراحی بازی هرچه دقیقتر و کاملتر باشد هزینههای ساخت و زمان انجام پروژه به واقعیت و آنچه در طرح است نزدیکتر خواهند شد و پس از پایان این طراحی مدیران پروژه با احاطه کامل خواهند توانست برنامه ریزی دقیقی از نظر منابع انسانی، مالی و زمانی برای ساخت بازی داشته باشند. مدیران با داشتن مستندات کامل طراحی در صورت لزوم خواهند توانست در همان ابتدای پروژه بخشهایی که به اصل و جذابیت بازی لطمه نزند را از پروژه حذف کنند(برای رسیدن به زمان یا سقف مالی پروژه) یا در همان ابتدا از ساخت یک بازی بیکیفیت و هدر دادن سرمایهها جلوگیری کنند. از طرفی مستندات کامل طراحی باعث خواهد شد که تهیه کننده یا سرمایهگذار را به سرمایهگذاری بیشتر و با اطمینان بالاتر برای پروژه ساخت یک بازی جذب کند. در پایان نیز باید گفت با اینکه مستندات طراحی یک بازی پس از تصویت به عنوان کتاب قانون و حرف اول و آخر یک پروژه است. اما در حین ساخت بازی و با مشخص شدن مشکلات و کاستیها قابل تغییر است. اما بازهم به مدد یک طراحی قوی و کامل این تغییرات با آگاهی و با ریسک بسیار پایین انجام خواهد شد. [LEFT]ضمیمه های استفاده شده برای این سند: [SPOILER=]Game Design Document Outline Version 0.1(draft) October 10, 2005 By Mark Baldwin Baldwin Consulting [url]http://baldwinconsulting.org[/url] 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. [/SPOILER] [/LEFT] [/QUOTE]
Insert quotes…
Verification
پایتخت ایران
ارسال نوشته
صفحه اصلی
انجمنها
گفتگو درباره بازیها و صنعت بازیهای ویدیویی
گفتگوی آزاد پیرامون بازیها
پیش نیازهای لازم برای ساخت یک بازی
Top
نام کاربری یا ایمیل
رمز عبور
نمایش
رمز عبور خود را فراموش کرده اید؟
مرا به خاطر بسپار
ورود
اگر میخواهی عضوی از بازی سنتر باشی
همین حالا ثبت نام کن
or ثبتنام سریع از طریق سرویسهای زیر
Twitter
Google
Microsoft