نحوه ساخت یک سند طراحی بازی کاربردی

شما اینجا هستید زیرا یک ایده بازی درخشان دارید و می خواهید آن را به وجود بیاورید.

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

فرقی نمی کند اولین تایمر باشید یا یک جانباز 25 ساله - این هیجان یک احساس کاملاً آشنا است.

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

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

تو اینو نمیخوای…

پس از کجا شروع میکنی؟

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

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

ابتدا یک یادداشت سریع…

(اگر می خواهید با طراحی بازی امرار معاش کنید)

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

در اینجا دلیل…

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

بنابراین، اگر قبلاً هرگز بازی نساخته‌اید، انجام هر گونه GDD خارج از کمک به سازماندهی بازی‌هایی که واقعاً می‌سازید، اتلاف وقت بزرگی است.

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

با این گفته، ادامه می دهیم…

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

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

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

• امکانات
• محدوده (کار)
• داستان
• گیم پلی
• فن آوری ها

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

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

هدف 1: ایده اصلی خود را به وضوح به سهامداران منتقل کنید. مثلا:

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

هدف 2: ساختار کلی را برنامه ریزی کنید

هدف 3: ویژگی های مورد نیاز برای ساخت بازی خود را به طور کامل کشف کنید

هدف 4: قابل استفاده و قابل تکرار

شما باید تمام اسناد خود را با در نظر گرفتن این اهداف ایجاد کنید.

قالب سند طراحی بازی سنتی منسوخ شده است

اغلب برنامه‌های درجه طراحی بازی اغلب با این موارد مانند پایان‌نامه کارشناسی ارشد برخورد می‌کنند - اوج معنای طراح بازی بودن.

من اغلب می بینم که وب سایت ها قالب های GDD را می فروشند تا این نیاز فرضی به اسناد عظیم را برآورده کنند.

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

خوب، اول از همه، شما به یک سند یکپارچه نیاز ندارید. نه تنها این یک ایده وحشتناک است، ابزارهای مدرن به ما اجازه می‌دهند طرح‌بندی و ارتباط بسیار مؤثرتری نسبت به یک سند واحد داشته باشیم.

...اگر GDD شما به نظر می رسد که چارلز دیکنز آن را نوشته است، آیا واقعاً کسی آن را خواهد خواند؟

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

(این صفحه از این آرشیو عالی از اسناد بسیاری از بازی های استادانه LucasArts است)

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

ماهیت توسعه بازی:

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

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

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

به هر حال، فقط در صورت علاقه…

اکنون، این بدان معنا نیست که من معتقدم مستندسازی ایده بدی است. در واقع، من فکر می کنم مستندات و برنامه ریزی پیشرفته برای برقراری ارتباط با اعضای تیم شما ضروری است.

بنابراین... چگونه GDDهایی را درست کنید که واقعاً مؤثر باشند؟

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

ساختار سند طراحی بازی برای بازی شما باید در 2 جزء اصلی سازماندهی شود:

جزء 1: سند اصلی - این سند معمولاً توسط رهبر و/یا طراح اصلی بازی جمع آوری می شود. این یک سند 10000 فوتی، مختصر و ساده است که شامل موارد زیر است:

• خلاصه اجرایی از تجربه کلی
• چند هنر کلیدی و توضیحات مختصر برای ارتباط با مفهوم بازی
• ارکان ارزش بازی شما
• پیوندهایی به اسناد ویژگی فردی

جزء 2: سند ویژگی - یک سند کوتاه و هدفمند که مستقیماً سایر طراحان، مهندسان و هنرمندان را هدف قرار می دهد. هر سند باید بر روی یک جنبه از بازی تمرکز کند، فقط با جزئیات کافی برای ترسیم اهداف، مکانیزم نحوه کار و تجربه بازیکن مورد نظر.

اسناد ویژگی روی یک جنبه از بازی تمرکز می کنند، با جزئیات کافی برای ترسیم اهداف، مکانیزم بازی در مورد نحوه عملکرد آن و تجربه بازیکن مورد نظر.

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

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

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

نحوه ساخت سند اصلی

اول، شما به ابزارهای مناسب بر اساس فناوری امروزی نیاز دارید.

من به شما پیشنهاد می‌کنم از Google Docs یا یک ویکی (مانند Notion) برای مستندات خود استفاده کنید، هدایت اعضای تیم به اسناد ویژگی‌های دقیق‌تر مرتبط با نقششان را بسیار آسان‌تر می‌کند و همکاری را کارآمدتر می‌کند.

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

الگوی مدرن GDD 1: The Master Doc

فوراً متوجه چه چیزی در مورد آن می شوید؟

... با یک صفحه شروع می شود.

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

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

الگوی بالا هر سرصفحه را به عنوان پیوندی به یک موضوع جداگانه دارد - مکانی عالی برای قرار دادن جزئیات در مورد هر یک. نیازی نیست که سند اصلی خود را با تمام این جزئیات شلوغ کنید. بسیار باهوش!

در مرحله بعد، حلقه های اصلی گیم پلی خود را شرح می دهید.

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

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

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

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

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

اینجا جایی است که می‌خواهید به جای افزودن موارد بیشتر به سند اصلی 10000 فوتی، به بخش‌های تقسیم‌بندی‌شده‌تر اسناد خود پیوند دهید.

حالا، اجازه دهید یک مثال واقعی را که من روی آن کار کردم، مرور کنیم.

نمونه سند طراحی بازی – Master Doc: Dawn of The Phalanx

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

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

چگونه قابلیت های سند را کنار هم قرار دهیم

هدف یک سند ویژگی تمرکز بر یک جنبه واحد از بازی است.

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

به عنوان یک طراح، عملاً هرگز نیازی به ایجاد GDD نخواهید داشت، بنابراین بیایید آنچه را که به طور منظم می سازید مرور کنیم: اسناد ویژگی.

الگوی مدرن GDD 2: The Feature Doc

الگوی دقیق ممکن است از استودیو به استودیو تغییر کند، اما بخش‌های خاصی کاملاً ضروری است:

1. با "چرا" شروع کنید

• چرا این ویژگی ساخته شده است؟
• چگونه تجربه نهایی را برای بازیکن بهتر می کند؟

2. اهداف

• یک لیست سریع از مقادیری که این ویژگی را هدایت می کنند
• اینها را قابل اندازه گیری و مرتبط کنید

3. خلاصه سطح بالا

• ویژگی چیست و چگونه کار خواهد کرد؟
• برای تکمیل این ویژگی چه نوع کاری باید انجام شود؟
• جزئیات کافی برای تحریک کنجکاوی ارائه دهید، بدون اینکه نگران جزئیات باشید

4. تصویر

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

هنر مفهومی باعث می شود که درک این ویژگی سلاح پیچیده در یک نگاه بسیار آسان تر شود.

اکنون، سعی کنید همه اینها را در یک صفحه قرار دهید!

یک خواننده باید بتواند به سند ویژگی شما نگاهی بیندازد و با درک مناسبی از آنچه به دنبال آن هستید دور شود.

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

اسناد ویژگی خود را تا حد امکان کوتاه نگه دارید و در عین حال وضوح کافی برای شروع اولین قدم ها را ارائه دهید.

چه زمانی و چگونه می توان به وضوح با یک ویژگی ارتباط برقرار کرد

پس از تکمیل سند ویژگی یک صفحه‌ای خود، ممکن است هنوز زمان‌هایی وجود داشته باشد که لازم باشد به جزئیات بیشتری وارد شوید:

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

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

در اینجا نمونه‌ای از بخش‌های مختلف است که می‌توانید برای ساختار یک سند مفید مانند این استفاده کنید:

بخش 1: یک مثال مفصل

• تجربه کامل و گام به گام استفاده از این ویژگی را تجربه کنید
• ارتباطات بصری، تعاملات و نتایجی را که باید در هر مرحله رخ دهد را فهرست کنید

بخش 2: ویژگی را به قطعات تقسیم کنید

1. توضیح دهید که هر جزء، تغییرات یا مرحله متوالی ویژگی چگونه کار می کند

2. در صورت امکان، تصاویر یا ویدیوها را اضافه کنید تا به خواننده کمک کند تجربه بازی را تصور کند

3. هر قطعه را به قسمت های مورد نیاز خود تقسیم کنید:

• فناوری - چیزهایی که نیاز به برنامه ریزی دارند
• هنر - دارایی هایی که باید ایجاد شوند
• صدا - نشانه های صوتی برای کمک به پشتیبانی از ویژگی

بخش 3: اتصالات و عوارض جانبی

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

بخش 4: یکپارچه سازی و پس زمینه

• چگونه این ویژگی به بازیکن معرفی می شود؟
• چه نوع قلاب های طرح مربوط به این ویژگی است؟

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

من به شما پیشنهاد می کنم این ساختار را با شرایط خاص خود تطبیق دهید. این یک ساختار ثابت در سنگ نیست. پس لطفا آن را با شرایط خود تطبیق دهید.

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

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

حالا بیایید با هم یک سند ویژگی برای یک بازی که با آن آشنا هستیم بسازیم…

نمونه سند طراحی بازی – مستند ویژه: "Jump" در Super Mario Bros

خلاصه اجرایی:

به منظور ایجاد یک تجربه منحصر به فرد و به یاد ماندنی، ما می خواهیم یک سیستم پرش که غنی تر از بازی قبلی ما، Donkey Kong است، توسعه دهیم. باید یک تجربه عمیق و به یاد ماندنی برای بازیکنان ایجاد کند و از ابتدا تا انتها یک مکانیک اصلی بازی باشد.

اهداف:

پرش باید ابزاری موثر برای مقابله با دشمنان باشد

پرش باید کنترل دقیقی داشته باشد

پرش باید بیان مهارت های ظریف داشته باشد

پرش باید طبیعی و آزاد کننده باشد، حتی اگر به شدت اغراق آمیز باشد

خلاصه سطح بالا:

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

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

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

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

تفکیک ویژگی:

کنترل ها:

فشار دادن A باعث می شود ماریو بپرد

نگه داشتن "A" باعث می شود ماریو همچنان تا سقف 4 آجری بپرد

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

با فشار دادن «<+» یا «+>» روی D-pad به ماریو اجازه می‌دهد تا سرعت افقی خود را تنظیم کند

مکانیک:

فرود آمدن بر روی دشمن باید واکنش منحصر به فردی را در هر دشمن ایجاد کند. در اینجا چند نمونه وجود دارد که ما طوفان فکری کرده ایم:

• گومبا - صاف له می شود، پس از یک لحظه می میرد
• کوپا Koopa - در پوسته خود عقب نشینی می کند، اگر ماریو بعداً به آن برخورد کرد دوباره حرکت می کند
• خاردار - به ماریو صدمه می زند (نباید با این روش برخورد کرد - در عوض توپ آتشین)
• بازی بتل Buzzy Beetle - در پوسته عقب نشینی می کند و در برابر گلوله های آتش مصون است.
• لاکیتو Lakitu - می میرد و ابر خود را پشت سر می گذارد
• لاکیتو کلاد Lakitu Cloud - به شما امکان می دهد ابر را سوار و کنترل کنید. (توجه: به دلیل محدودیت های فنی تا یک بازی آینده به تاخیر افتاد)

تصاویری:

• انیمیشن ماریو باید در طول پرش تغییر کند. در حالت ایده آل یک قاب متفاوت برای بالا و پایین رفتن. (توجه: برای صرفه جویی در حافظه به یک اسپرایت برش دهید)
• در حالت ایده‌آل، باید در جایی که زمین را ترک کرده، کمی گرد و غبار ظاهر شود. (توجه: کاهش به دلیل هزینه و کمبود قدرت پردازش در NES)

جلوه های صوتی:

• هر بار که ماریو می پرد باید صدای شاد و کوتاهی پخش شود
• به همین ترتیب، زمانی که ماریو با موفقیت بر روی دشمن فرود می آید، صدای شادی می آید

چالش ها و ارتباطات:

پرش بخشی ضروری از بازی خواهد بود، بنابراین ما باید ارتفاع تمام لوله ها و موانع را به ارتفاع 3 بلوک استاندارد کنیم.

اثرات جانبی:

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

ما از پویانمایی برای توانایی جدید Fireball استفاده مجدد خواهیم کرد.

پیشینه:

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

اسناد طراحی بازی فقط یک نقطه شروع هستند!

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

اطلاعات کافی را وارد کنید تا همه بدانند چه چیزی کاملاً ضروری است - و شاید چند ایده که ممکن است بخواهید در آینده امتحان کنید.

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

احتمالاً نمی توانید حدس بزنید که این چشم انداز برای گیم پلی دیابلو است

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

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

زمان اقدام است!

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

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

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

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

در آخر ممنونم که همراه بودید ♥ لطفا دیدگاه خودتون رو به اشتراک بگذارید.

در ضمن اگر خواستید می تونید به گروه تلگرام طراحی بازی ملحق شوید
https://t.me/tarahiebazi