طراحان بازی چگونه این ۱۱ مشکل را در بازی‌های معروف حل کردند | جعبه‌ابزار بازی‌سازان (۱۲۴)

چند سالی می‌شود که کانال یوتیوب جعبه‌ابزار بازی‌سازان (Game Maker’s Toolkit) در ویدئوهایی کوتاه و آموزنده به بررسی و توصیف جنبه‌های مختلف بازی‌های ویدئویی و مفاهیم مربوط به این حوزه می‌پردازد.  من تصمیم گرفتم محتوای این ویدئوها را با کمی تصرف و منطبق کردن آن با مدیوم نوشتار، به فارسی برگردانم. این سری مقالات برای کسانی که آرزوی بازی‌ساز شدن را در سر می‌پرورانند، یا صرفاً می‌خواهند بازی‌های ویدئویی را بهتر و عمیق‌تر درک کنند، بسیار مفید خواهد بود. با مجموعه مقالات «جعبه ابزار بازی‌سازان» همراه باشید.

بدون‌شک باحال‌ترین مکانیزم چرخ‌دنده‌های جنگ (Gears of War) خشاب‌گذاری فعالانه است. اجازه دهید توضیح دهم چگونه کار می‌کند. با هربار خشاب‌گذاری اسلحه‌یتان، باید یک مینی‌گیم کوچک بازی کنید. یک پیکان روی یک نوار شروع به حرکت می‌کند و شما می‌توانید دوباره دکمه‌ی بارگذاری را بزنید تا پاداشی به دست آورید.

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

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

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

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

ولی بازیکنان تازه‌کار به‌طور کلی مکانیزم خشاب‌گذاری فعالانه را نادیده می‌گرفتند، برای همین به گلوله‌های بهتر دست پیدا نمی‌کردند و مجبور می‌شدند دائماً با گلوله‌های ضعیف با دشمنان بجنگند. این سناریو بسیار اعصاب‌خردکن به نظر می‌رسد، نه؟

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

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

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

در ادامه خواهید دید.

تشخیص دادن مشکل

پیش از این‌که به راه‌حل‌ها بپردازیم،‌ باید اطمینان حاصل کنیم که با دقت کامل مشکل را شناسایی کرده‌ایم. در طی پروسه‌ی ساخت دایینگ لایت (Dying Light)، کارگردان بازی به مشکلی برخورده بود: اسلحه‌ها سریع‌تر از حد انتظار خراب می‌شدند. بنابراین او به طراحان بازی گفت مقاومت اسلحه‌ّها را بالاتر ببرند. ولی مت بینکافسکی (Maciej “Matt” Binkowski)‌ تمایل نداشت این بخش از بازی را دستکاری کند، چون ممکن بود سیستم اقتصادی بازی را به هم بریزد.

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

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

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

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

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

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

رویکرد اول: آزمون‌وخطای سریع راه‌حل‌های احتمالی

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

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

این ایده جواب نداد. اگر یک معجون فقط ۲۵ درصد از حالت عادی‌اش کارایی داشت، بازیکنان صرفاً چهارتایشان را می‌نوشیدند.

ایده‌ی دوم این بود که نوار سلامتی بازیکن به‌طور خودکار بازیابی شود، ولی به‌شرط این‌که دشمنان از حضورش باخبر نباشند.

این ایده هم خوب نبود. آگاهی یا عدم آگاهی دشمنان به حضور بازیکن به‌قدر کافی واضح نبود.

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

این ایده هم خوب نبود، چون باعث می‌شد بازیکنان دائماً از مبارزات فرار کنند و به‌شکل خنثی و دفاعی بازی کنند. این دقیقاً برعکس چیزی بود که بلیزارد می‌خواست؛ بلیزارد می‌خواست بازیکنان تهاجمی بازی کنند.

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

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

در چنین رویکردی، بازیساز روش‌ها و ایده‌های مختلف را امتحان می‌کند و از نتایج به‌دست‌آمده استفاده می‌کند تا راه خود را به راه‌حل نهایی پیدا کند. مثلاً به هنگام امتحان کردن روش اول – کاهش دادن تاثیر معجون‌ها در صورت استفاده‌ی پشت‌سرهم – وایات چنگ (Wyatt Cheng) از بلیزارد گفت: «وقتی داشتیم این ایده را امتحان می‌کردیم، چندان نسبت به آن هیجان‌زده نبودیم، ولی با این حال پیاده‌اش کردیم. می‌دانستیم که حتی اگر این قرار نیست راه‌حلی باشد که به نسخه‌ی نهایی راه پیدا کند، به ما درباره‌ی ذات مشکل چیزهای زیادی یاد خواهد داد.»

رویکرد دوم: شناسایی اهرم‌ها

جیم گریزمر (Jaime Griesmer)، یکی از اعضای بانجی، در یکی از سخنرانی‌های جالبش در GDC با موضوع موازنه‌سازی بازی‌ها درباره‌ی این صحبت کرد که چگونه مشکلات مربوط به تفنگ تک‌تیرانداز یا اسنایپر را در هیلو ۳ (Halo 3) رفع کردند.

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

برای حل کردن چنین مشکلی اول باید تشخیص داد کدام اهرم‌ها را می‌توان کشید و کدام‌ها را نمی‌توان کشید. در نظر گریزمر:

• نمی‌شد برد اسلحه‌ی تک‌تیرانداز را کاهش داد
• نمی‌شد دمج آن را کاهش داد
• نمی‌شد دقت آن را پایین آورد
• نمی‌شد کشته شدن بلافاصله‌ی دشمن در صورت هدشات شدن با گلوله‌ی تک‌تیرانداز را کنار گذاشت

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

• تعداد گلوله‌های موجود در هر خشاب
• مدت زمان خشاب‌گذاری
• مدت زمان لازم برای زوم کردن
• نرخ شلیک هر گلوله
• امکان‌پذیر بودن یا نبودن هدشات کردن دشمن خارج از دوربین
• بیشترین میزان مهماتی که می‌توان حمل کرد

در نهایت از بین گزینه‌های بالا راهکار درست تغییر دادن «نرخ شلیک هر گلوله» بود. این راهکار مانع از این شد که بازیکن بتواند به سمت دشمن هدف‌گیری و بلافاصله شلیک کند. همچنین این راهکار باعث شد که کارایی تک‌تیرانداز در درگیری‌های نزدیک پایین بیاید، چون دیگر نمی‌شد اسپم‌وار ماشه را فشار داد. در نهایت برای این‌که راهکار جواب دهد، کافی بود زمان بین هر شلیک را از ۰.۵ ثانیه به ۰.۷ ثانیه افزایش داد.

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

رویکرد سوم: اعمال تغییرات بزرگ

بسیار خب،‌ کمی قبل‌تر، درباره‌ی تغییری صحبت کردم که مقیاس آن ۰.۲ ثانیه بود. این تغییری بسیار کوچک بود که اثری بزرگ روی بازی به جا گذاشت. ولی گاهی لازم است یک گرد و خاک حسابی راه بیندازید. یک ماه پیش از انتشار نخستین بازی مجموعه‌ی تمدن (Civilization)،‌ سید مایر (Sid Meier)، سازنده‌ی  بازی متوجه شد که بازی از مشکل ضرب‌آهنگ رنج می‌برد. بنابراین او تصمیم گرفت با کاهش دادن اندازه‌ی نقشه این مشکل را حل کند. منظور از کاهش اندازه‌ی نقشه در حد چند کاشی یا چند درصد نیست. او عملاً نقشه‌ی بازی را نصف کرد!

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

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

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

مایر در رابطه با نقشه‌ی مذکور در تمدن ۱ گفته است: «اگر نگرانی‌ام این بود که مبادا خیلی از آن چیزی که ساخته بودیم فاصله بگیرم، هیچ‌گاه نمی‌توانستم قبل از انتشار بازی اندازه‌ی درست نقشه را دربیاورم.»

رویکرد چهارم: واژگون کردن بازی

در شوالیه‌ی بیل‌به‌دست (Shovel Knight)، یات کلاب (Yacht Club)، سازنده‌ی بازی، قصد داشت سیستم ذخیره‌سازی را به شکلی نو عرضه کند. آن‌ها می‌خواستند سیستمی بسازند که در آن بازیکن می‌توانست یک چک‌پوینت را رد کند تا در ازایش پاداش دریافت کند. برای همین آن‌ها چک‌پوینی ساختند که برای استفاده از آن باید پول پرداخت می‌کردید. اگر می‌خواستید، می‌توانستید چک‌پوینت را بدون فعال کردن رد کنید و پولش را نزد خود نگه دارید، ولی اگر می‌مردید، بخش بیشتری از پیشرفت‌تان را از دست می‌دادید.

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

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

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

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

رویکرد پنجم: راه‌حل را جای دیگر پیدا کنید

وقتی ناتی‌داگ مشغول کار روی رابط کاربری لست آو آس (The Last of Us) بود، در ابتدا قصدشان این بود به جول (Joel) اجازه دهند هر موقع که می‌خواهد از راه یک زیرمنو در رابط کاربری کوله‌پشتی بازی اسلحه‌اش را آپگرید کند. ولی این تصمیم مشکلاتی ایجاد کرد. مثلاً:

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

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

به همین دلیل به بازی میز آپگرید کردن اضافه شد.

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

یادتان باشد که بازی‌ها متشکل از شبکه‌ی عظیمی از سیستم‌های درهم‌تنیده هستند، برای همین گاهی راه‌حل یک مشکل در بخش خاص، به تغییر عاملی در بخشی دیگر بستگی دارد.

رویکرد ششم: حل کردن چند مشکل در آن واحد

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

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

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

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

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

برای همین گاهی‌اوقات بهتر است منتظر راه‌حلی ماند که برای بازی فواید دیگر هم دارد.

رویکرد هفتم: مطالعه‌ی رفتار بازیکن

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

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

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

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

اجرای راه‌حل‌ها

بسیار خب، حال که به یک راه‌حل رسیده‌ایم، می‌توانیم آن را پیاده کنیم. ولی همچنان یک سری چالش پیش رو قرار دارند.

چالش اول اثرات جانبی (Second-order Effects) است. در جریان توسعه‌ی رینبو سیکس سیج (Rainbow Six Siege)، یوبی‌سافت می‌دانست که باید شاتگان بیش‌ازحد قدرتمند بازی را موازنه‌سازی کند. بنابراین آن‌ها شاتگان را نرف کردند و این نرف اثر موردانتظار را به جا گذاشت. شاتگان دیگر عملکردی به‌مراتب بهتر از اسلحه‌های دیگر  نشان نمی‌داد. ولی این تغییر یک اثر جانبی منفی نیز به جا گذاشت.

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

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

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

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

بنابراین طراح‌های بازی راهکاری خلاقانه پیدا کردند: خلق پولترگایست (The Poltergeist). این دشمن نامرئی است و روش حمله‌ی او پرتاب کردن اشیاء فیزیکی‌ای است که در اطرافش قرار دارند. این دشمن در مقایسه با دشمنان دیگر منابع به‌مراتب کمتری برای طراحی نیاز داشت.

ریکاردو بیر (Ricardo Bare)، طراح پری می‌گوید: «طراحان خوب می‌دانند چگونه با توجه به محدودیت‌هایی که دارند، مشکلات را حل کنند.» از قضا پولترگایست به یکی از دشمنان موردعلاقه‌اش در بازی تبدیل شد.

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

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

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

نتیجه‌گیری

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

منبع: مارک براون – یوتیوب