سخت‌ترین چالش‌های بازیسازان در ساخت بازی‌ها

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

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

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

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

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

حرکت از جایی به‌جای دیگر

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

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

بیل گاردنر، طراح ارشد مراحل بازی‌های بایوشاک (BioShock) و بایوشاک اینفینیت (BioShock Infinite) که این روزها کارگردان پروژه‌های استودیو The Deep End Games محسوب می‌شود، در مورد سختی‌های طراحی آسانسور می‌گوید: «اولین موضوع در مورد آسانسور این است که وقتی مخاطب با زدن دکمه‌ای باعث پایین آمدن آسانسور می‌شود و قرار است شخصیت اصلی و شخصیت‌های کنترل‌شده توسط هوش مصنوعی یا بعضی اشیا وارد آسانسور شوند، ممکن است در زمان پایین آمدن آسانسور زیر آن رفته و گیر کنند و منهدم شوند. بنابراین در درجه‌ی اول باید فکری به حال این قضیه کنید، وگرنه شاهد اتفاقاتی مثل رفتار احمقانه از طرف همراهان یا دشمنان و همین‌طور به‌هم خوردن فیزیک اشیا و به پرواز درآمدن آن‌ها خواهید بود که جلوه‌ی زشتی به بازی شما می‌دهند.

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

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

آسانسور بازی Half-Life 2 که خیلی از مخاطبان را با باگ‌های خود آزار می‌داد

اعضای استودیو Skydance Interactive هم در زمان تولید بازی واقعیت مجازی The Walking Dead: Saints and Sinners با مشکلات زیادی در ارتباط با درها مواجه شده بودند و بیل فرر، مهندس ارشد هوش مصنوعی استودیو در این مورد می‌گوید: «یکی از باگ‌هایی که هنگام تولید بازی مشاهده می‌کردم، مربوط‌به زمانی بود که بازیکن می‌خواست دری را باز کند و هم‌زمان یک واکر (زامبی) هم قصد عبور از در را داشت. چنین شرایطی باعث می‌شد بازیکن و واکر درون در گیر کنند و کاری از دست مخاطب برنیاید.»

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

شاید این سؤال برای شما پیش آمده باشد که اگر طراحی درها و آسانسورها تا این حد دشوار است، چرا بازی‌سازها راه پله را جایگزین آن‌ها نمی‌کنند. به‌گفته‌ی جاش دیویس، مسئول تضمین کیفیت شرکت Drinkbox Studios سازنده‌ی بازی Guacamelee، راه پله‌ها هم مصیبت‌های خاص خود را دارند: «شاید راه پله‌ها به بدیِ درها نباشند، ولی اکثر اوقات باعث از بین رفتن حس غرق شدن مخاطب درون بازی می‌شوند. همچنین بعضی وقت‌ها مشکلاتی برای نحوه‌ی حرکت و پریدن شخصیت‌ها ایجاد می‌کنند و به خاطر زوایای خاص و فرو رفتن پای شخصیت در آن‌ها، ظاهر زشتی به بازی می‌دهند. این قضیه فقط هم مربوط‌به بازی‌های سه‌بعدی نمی‌شود و بعضی از بازی‌های دوبعدی با سبک‌های بصری خاص هم به شکلی هستند که هنگام بالا و پایین رفتن شخصیت اصلی از راه پله‌ها، با باگ‌های زیادی مواجه می‌شویم.»

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

کایل دانلی که به‌عنوان برنامه‌نویس در شرکت Serenity Forge روی بازی‌های Land of Screens و Doki Doki Literature Club Plus کار کرده، در مورد پلتفرم‌های متحرک می‌گوید: «حرکت دادن معمولی شخصیت درون محیط با کمک کنترلر کار سختی نیست. حرکت دادن شخصیت روی یک پلتفرم ثابت هم کار دشواری محسوب نمی‌شود. ولی اگر این پلتفرم حالت متحرک پیدا کند، اوضاع خیلی سخت می‌شود و باید همه‌چیز را به شکلی ترتیب دهید که بازیکن مشکلی در زمان عبور و مرور نداشته باشد و بتواند به خوبی شخصیت اصلی را طوری هدایت کند که تداخلی با حرکت‌های خود پلتفرم ایجاد نشود.

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

اندی، یکی از برنامه‌نویس‌های استودیوی مستقل Unknown Worlds Entertainment معتقد است که حتی راه رفتن ساده در محیط‌های بازی هم می‌تواند در بعضی شرایط سخت و پیچیده شده و اوضاع را به جاهای باریکی بکشاند: «برنامه‌نویسی اولیه برای حرکت شخصیت درون بازی چیز سختی نیست ولی اینکه حس و حال راه رفتن را به بهترین شکل ممکن شبیه‌سازی کنیم، نیازمند ریزه‌کاری‌های زیادی است و باید به خیلی موارد توجه کرد.

مثلاً ما در زمان ساخت بازی Subnautica، زمان زیادی را صرف رسیدن به بهترین حالت ممکن برای حرکت در محیط‌ها و شتاب شخصیت اصلی در جابه‌جایی از بخشی به بخش دیگر کردیم؛ مخصوصاً با درنظرگرفتن اینکه بازی Subnautica المان‌های مختلفی را با حرکت در محیط ترکیب می‌کند، مثل جریان آب و باد، دویدن و استفاده از Seaglide.

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

تعامل المان‌های مختلف با یکدیگر

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

بن واندر، طراح بازی Airborne Kingdom از ساخته‌های استودیو The Wandering Band چنین نظری دارد: «از آنجایی که آیتم‌ها و اشیایی که برای بازی طراحی می‌کنیم واقعی نیستند، چگالی و محدوده‌ی فیزیکی دقیقی ندارند و اگر قرار باشد شخصیت اصلی مثلاً یک سیب را از روی میز بردارد، هنرمندان استودیو باید حرکات انگشت‌های شخصیت را به شکلی شبیه‌سازی کنند که سیب را به‌طور طبیعی در دست بگیرد. اگر جای سیب با میوه‌های دیگری مثل کیوی یا انگور عوض شود هم باید انیمیشن‌ها و حرکات جدیدی برای انگشت‌های شخصیت در نظر گرفت. به خاطر همین پیچیدگی‌ها است که بازی‌سازها خیلی وقت‌ها ترجیح می‌دهند رد و بدل کردن آیتم‌ها بین دو شخصیت را به‌طور کامل نشان ندهند و مثلاً این اتفاق خارج از محدوده‌ی دوربین رخ بدهد. همچنین بعضی از ایرادات گرافیکی مثل رد شدن دست شخصیت‌ها از درون درها به خاطر همین قضیه اتفاق می‌افتد.»

آدری لوپرینس، یکی از مؤسسان استودیو The Game Bakers با تأیید این قضیه به جدیدترین بازی خود یعنی Haven اشاره می‌کند که دو شخصیت آن روابط نزدیکی با یکدیگر دارند: «لمس کردن، گرفتن دست‌ها و در آغوش کشیدن شخصیت‌ها از جمله مواردی هستند که اجرای آن‌ها حتی در میان‌پرده‌ها هم دشوار است، چه برسد به گیم‌پلی که تبدیل به کابوسی بزرگ می‌شود. بازی Haven نمونه‌ی مناسبی از آثاری با چنین المان‌هایی است که خوشبختانه مخاطبان هم استقبال خوبی از اجرای طبیعی این موارد درون بازی کردند و امیدوارم در آینده شاهد بازی‌های بیشتری با این المان‌ها باشیم.»

مِیب سیول، انیماتور ارشد شرکت Gearbox Software به نمونه‌ی جالب دیگری اشاره می‌کند: «بازی کردن با سگ‌ها در بازی‌های ویدیویی.» این روزها شاهد بازی‌های زیادی هستیم که در آن‌ها می‌توان به بازی کردن و سرگرم شدن با سگ‌ها مشغول شد؛ ویژگی بامزه‌ای که به‌گفته‌ی سیول، طراحی آن واقعاً سخت و پیچیده است و نه‌تنها به انیمیشن‌های دقیقی نیاز دارد، بلکه باید از نظر هوش مصنوعی و رابط کاربری نیز در سطح مناسبی باشد تا جذاب از آب دربیاید.

تمام این صحبت‌هایی که در مورد دشواری‌های طراحی رابطه بین شخصیت‌ها کردیم، نه فقط در مورد بازی‌های واقع‌گرایانه بلکه در مورد آثاری با سبک‌های هنری خاص و متفاوت نیز صدق می‌کند. یکی از نمونه‌ها در این زمینه را می‌توان بازی No Place for Bravery محصول استودیو Glitch Factory دانست؛ اثری که در آینده‌ای نزدیک عرضه خواهد شد و شخصیت اصلی آن Thorn (تورن) در طول داستان، پسرش فید (Phid) را روی پشت خود حمل می‌کند. این دو شخصیت با وجود چسبیدن به یکدیگر، انیمیشن‌های جداگانه‌ی خود را دارند و هرکدام می‌توانند کارهای مخصوصی انجام دهند. مثلاً درحالی‌که تورن با دشمنان می‌جنگد، توجه فید به آیتم ویژه‌ای در محیط جلب می‌شود و واکنش نشان می‌دهد.

ژوآ اِس، هنرمند و انیماتور بازی No Place for Bravery می‌گوید: «رابطه‌ی بین دو شخصیت بازی ما نیازمند انیمیشن‌های خیلی پیچیده‌ای است، مخصوصاً در لحظاتی که فید روی دوش تورن به عقب و جلو حرکت می‌کند. برای دستیابی به انیمیشن‌های مناسب شخصیت‌ها مجبور بودیم تک‌تک فریم‌ها را در نظر بگیریم تا نحوه‌ی ارتباط این دو شخصیت به زیبایی به تصویر کشیده شود.

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

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

اِس صحبت‌های خود را با این آمار و ارقام عجیب به پایان می‌رساند: «ما فقط و فقط برای شخصیت اصلی بازی، حدود ۱۴۲ انیمیشن در نظر گرفته‌ایم که البته اگر بخواهم دقیق‌تر بگویم، شامل ۹۴۱ فریم انیمیشنی مختلف می‌شوند که به ۹۷ لایه تقسیم شده‌اند و در هر بخش، از تعدادی از آن‌ها استفاده می‌کنیم.»

درکنار آیتم‌ها و اشیای مختلف که طراحی و انیمیشن‌سازی پیچیده‌ای دارند، نباید از بحث جریان آب هم غافل شد. مکس، یکی از مؤسسان استودیو Unknown Worlds Entertainment از این می‌گوید که هرچند اکثر بازیکن‌ها کم‌وبیش در جریان سختی‌های طراحی آب در بازی‌های ویدیویی هستند و وقتی کیفیت بالای آب را ببینند به تحسین سازندگان بازی می‌پردازند، ولی کمتر کسی می‌داند که یکی از بخش‌های سخت ماجرا، حفظ کردن آب در محیط موردنظر و جلوگیری از ورود آن به سایر بخش‌های بازی است.

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

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

روایت مناسب داستان

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

آرون لوبری، طراح روایت سابق استودیو BioWare در گفت‌وگو با خبرنگار IGN از چالش‌های داستانی در بازی مس افکت (Mass Effect) گفته و سختی‌هایی که سازندگان بازی در راه ارائه‌ی انتخاب‌های گوناگون به بازیکن‌ها داشته‌اند. در این‌گونه بازی‌ها با انتخاب‌های مختلفی مواجه می‌شویم و وضعیت وقتی برای سازندگان آن‌ها سخت‌تر می‌شود که انتخاب A یا B را باید ساعت‌ها بعد با نتیجه‌ی C یا D پاسخ دهند و این قضیه همین‌طور ادامه پیدا می‌کند و پیچیده‌تر می‌شود. به‌طوری‌که هرچند اکثر اوقات می‌توان از پسِ آن برآمد، ولی در زمان تولید بازی مواردی هم بوده که انتخاب‌ها و نتایج آن‌ها در یک راستا قرار نگرفته‌اند و سازندگان بازی مجبور شده‌اند دست به تغییراتی در این زمینه بزنند.

یکی از این موارد به انتخابی در نسخه‌ی اول مس افکت برمی‌گشته که در مس افکت 3 به نتایج فاجعه‌باری ختم می‌شده است. بازیکن‌ها در نسخه‌ی اول درون سیتادل با گرس (Garrus)، رکس (Wrex) و تالی (Tali) ملاقات می‌کنند و بعد از انتخاب دو نفر از این افراد به‌عنوان اعضای تیم، نفر سوم به‌طور موقت کنار می‌رود تا بعداً در سفینه‌ی نورمندی درخواست عضویت در گروه را بدهد. در اینجا درصد بسیار کمی از بازیکن‌ها هستند که با درخواست این شخصیت مخالفت کرده و او را در گروه خود راه نمی‌دهند.

همین قضیه نزدیک بوده باعث خلق یک باگ نادر در نسخه‌ی سوم شده و آن را غیرقابل بازی کند. به این شکل که رکس از اتفاقات پیش‌آمده در بازی عصبانی می‌شد و شپرد (Shepard) هم امتیاز Paragon یا Renegade کافی نداشت، بنابراین نمی‌توانست رکس را از حمله منع کند و او در آن صحنه کشته می‌شد. از طرف دیگر هم لیارا (Liara) درون گروه نبود و گرس هم در سیتادل به گروه ملحق نشده بود و درنهایت اوضاع به شکلی پیش می‌رفت که تعداد اعضای گروه به اندازه‌ی موردنظر برای پیش‌برد داستان نمی‌رسید و بازیکن نمی‌توانست مس افکت 3 را بیشتر از این پیش ببرد. البته اعضای استودیو درنهایت شانس آوردند که در روزهای پایانی تولید بازی، متوجه این باگ شدند و اوضاع را درست کردند.

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

لوبری در این زمینه می‌گوید: «این باگ وقتی فعال می‌شد که بازیکن در جریان مس افکت 2 با تالی رابطه‌ی عاطفی برقرار می‌کرد و به این رابطه در مس افکت 3 هم ادامه می‌داد، ولی درنهایت دربرابر تالی و نژاد او (Quarianها) قرار می‌گرفت و شاهد مرگ او بود. پس از آن هم با هیچ‌کدام از اعضای گروه رابطه‌ی عاطفی برقرار نمی‌کرد و در این حالت تالی از عالم مرده‌ها برمی‌گشت! البته بعدها این مشکل را ازطریق پچ برطرف کردیم، ولی در نسخه‌ی اولیه‌ی بازی چنین ایرادی به چشم می‌خورد.»

رکس در نسخه‌ی اولیه و پیش‌از عرضه‌ی بازی Mass Effect 3 باعث خلق باگ عجیبی می‌شد

از این نوع مشکلات در بازی الدر اسکرولز آنلاین (The Elder Scrolls Online) هم وجود داشته و مت فایرور، رئیس استودیو ZeniMax Online در این زمینه صحبت‌هایی کرده است. به‌گفته‌ی فایرور، از آنجایی که بازیکن در بازی الدر اسکرولز آنلاین می‌تواند دست به انتخاب‌های مختلف بزند و مثلاً با دیدن دهکده‌ای درگیر جنگ و آتش به کمک اهالی آن رفته یا آن‌جا را رها کند، سازندگان بازی برای چنین موقعیت‌هایی دو کپی مختلف تدارک دیده بودند و یک دهکده‌ی ویران‌شده و یک دهکده‌ی نجات‌یافته را طراحی کرده بودند که نسبت به عکس‌العمل بازیکن، پس از پایان مأموریت مورد استفاده قرار می‌گرفت.

این موضوع در مراحل تست و آزمایش بازی به خوبی پیش رفته بود، ولی در زمان عرضه به مشکلات عجیبی ختم شد: «از همان روزهای اول که بازی منتشر شد و مخاطبان وارد دنیای تمریل شدند، مشکلاتِ این سیستم هم خیلی زود خود را نشان داد. در یک بازی MMORPG خیلی پیش می‌آید که نحوه‌ی پیش‌روی بازیکن و دوستان او با یکدیگر متفاوت باشد و مثلاً احتمال دارد دوستان او مأموریت خاصی را انجام داده باشند که خود او هنوز مأموریت موردنظر را به پایان نرسانده باشد.

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

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

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

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

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

بازی The Elder Scrolls Online در ابتدای کار با مشکلات زیادی همراه بود

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

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

هدایت بازیکن در مسیری که می‌خواهید

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

کوین زان، کارگردان و نویسنده‌ای که در استودیو Young Horses فعالیت می‌کند، از پیچیدگی‌های سیستم راهنما (Hint) در بازی‌های ویدیویی می‌گوید: «تدارک این راهنماها کار واقعاً دشواری است. شما نمی‌توانید همیشه به‌طور مستقیم به بازیکن بگویید چه کاری انجام دهد و به‌جای آن باید بازیکن را در مسیر درست هدایت کنید. این قضیه هم ظرافت‌های خاص خود را دارد و باید در مراحل تست و آزمایش بازی خود متوجه شوید که مخاطبان در چه بخش‌هایی ممکن است مسیر را گم کنند و چگونه باید آن‌ها را به شکل مختصر و مفید هدایت کرد. زیاد دیده‌ام که بازی‌سازها با انتخاب عبارات راهنمای اشتباه باعث سردرگمی بیشتر بازیکن می‌شوند و در این حالت باید دو برابر قبل زحمت بکشند که بازیکن را به مسیر اولیه برگردانند.»

الکساندر هورن، مسئول روایت استودیو Impulse Gear که سابقه‌ی کار روی بازی Kingdoms of Amalur: Reckoning را در کارنامه دارد نیز با اشاره به بخش‌های آموزشی بازی‌ها، از سختی‌های آماده‌سازی آن‌ها می‌گوید: «بخش ابتدایی بازی Kingdoms of Amalur: Reckoning حکم قسمت آموزشی بازی را داشت و اولین آیتم در اولین محیط بازی، شمشیری بود که بازیکن باید از کنار یک جسد برمی‌داشت تا با مکانیزم‌های لوت آشنا شود.

بخش ابتدایی بازی Kingdoms of Amalur که سازندگان مجبور به اعمال تغییراتی در آن شدند

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

اجازه دادن به بازیکن برای انجام کارهایی که دوست دارد

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

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

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

سرگی موهاو، از اعضای استودیو Remedy و طراح ارشد گیم‌پلی بازی کنترل (Control) هم از این می‌گوید که کار روی گان‌پلی این بازی (نحوه‌ی کنترل اسلحه و تیراندازی) سختی‌های خاص خود را داشته است: «ابتدا باید مشخص می‌کردیم که آیا امکان تیراندازی در حالت Aim Down Sights (تیراندازی دقیق با کمک نشان‌گر اسلحه) وجود داشته باشد؟ آیا باید امکان تیراندازی به شکل Hipfire (تیراندازی بدون هدف‌گیری دقیق) را به بازیکن‌ها بدهیم؟ اگر قرار باشد هر دو مورد را در بازی داشته باشیم، چگونه باید بین آن‌ها سوییچ کرد؟ میدان دید در این حالت چه تغییراتی پیدا می‌کند؟ هر اسلحه به چه شکلی و با چه سرعتی امکان هدف‌گیری را به بازیکن می‌دهد؟ انیمیشن‌های مربوط‌به این کار چگونه خواهند بود؟ دقت اسلحه و لگد اسلحه در هر حالت به چه شکل خواهد بود؟ در حالت سوم شخص، گلوله‌ها از درون اسلحه خارج شوند یا از مرکز تصویر؟

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

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

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

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

ذخیره کردن در بازی‌های ویدیویی

تعدادی دیگر از بازی‌سازها هم یکی از بزرگ‌ترین مشکلات به ظاهر ساده‌ی تولید بازی‌ها را ذخیره کردن (Save) و مواردی مثل چک‌پوینت، ریست کردن مأموریت و از نو انجام دادن آن می‌دانند. فرناندو رسکو، مهندس نرم‌افزار ارشد Armature Studio یکی از افرادی است که ذخیره و چک‌پوینت و باگ‌های احتمالی آن‌ها را خیلی اوقات دردساز می‌داند.

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

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

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

به عقیده‌ی اسکوییدلی، به خاطر همین قضیه بوده که بعضی از بازی‌های سال‌های اولیه‌ی این صنعت قابلیت ذخیره کردن به شکل استاندارد را نداشتند: «بازی‌های قدیمی تنها به یک رم مخصوص برای ذخیره‌ی اطلاعات دسترسی داشتند و مثلاً اگر دستگاه آرکید بازی پک-من (Pac-Man) را ریستارت می‌کردید، تمام امتیازهای ذخیره شده توسط بازیکن‌ها از بین می‌رفت. مدت‌ها طول کشید تا بازی‌ای مثل The Legend of Zelda قابلیت ذخیره کردن روی کارتریج را ارائه دهد و به تدریج مفهوم ذخیره کردن جای مواردی مثل یادداشت کُد مراحل را بگیرد، چرا که ذخیره کردن واقعاً عمل سختی بود.»

بازی The Legend of Zelda، اثری پیشرو در زمینه‌ی ذخیره کردن بازی‌های کنسولی

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

سومینن می‌گوید: «بعد از کامل کردن طراحی بخش Ashtray Maze در بازی کنترل، متوجه شدیم که وقتی بازیکن‌ها ازطریق جابه‌جایی سریع (Fast Travel) از آن‌جا به سمت Research Sector می‌روند، دیوارها تغییراتی پیدا می‌کنند که محیط را به هم می‌ریزد. درنهایت هم مجبور شدیم بارها به عقب برگشته و همه‌ی جوانب کار را بررسی کنیم و با کمک اعضای بخش تضمین کیفیت، طراحان مرحله، برنامه‌نویس‌ها و سایر اعضای تیم به راه‌حل مناسبی برسیم.

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

به این صورت که وقتی بازیکن ازطریق قابلیت جابه‌جایی سریع از Ashtray Maze به Research Sector می‌رفت، یک ریستور پوینت به نام Research در کدهای بازی به وجود می‌آمد و از آنجایی که تمام فایل‌های ذخیره‌ی بازی در یک دسته‌بندی به نام research کنار یکدیگر جمع می‌شدند، بزرگ بودن حرف اول ریستور پوینت Research باعث می‌شد توسط سیستم ذخیره‌ی بازی که research با حرف اول کوچک بود شناخته نشود و به خاطر تشخیص ندادن آن، بازی به مشکل خورده و دیوارها تغییر حالت پیدا می‌کردند. حدود یک ماه طول کشید تا علت این ماجرا را بفهمیم و آن را درست کنیم و به خاطر همین اتفاقات است که سیستم ذخیره‌ی بازی‌های ویدیویی را یکی از پیچیده‌ترین بخش‌ها با وجود ظاهر ساده‌ی آن می‌دانم؛ بخشی که تأثیر زیادی روی سایر المان‌های بازی می‌گذارد.»

منطقه Ashtray Maze در بازی Control

بازی‌های چندنفره

سختی‌های تولید بازی‌های چندنفره، چه در حالت محلی (Local) و چه آنلاین از دیگر مواردی است که بازی‌سازهای زیادی با آن درگیر هستند. گیوم بوشه‌ویدال، مدیرعامل Nine Dots Studio از این می‌گوید که اضافه کردن حالت Split-Screen (که تصویر در آن به دو یا چند بخش تقسیم می‌شود)، نیازمند اعمال تغییرات عظیم در طراحی بخش‌های مختلف بازی است.

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

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

کریس پولاک (ملقب به Chhopsky)، برنامه‌نویس ارشد استودیو Phoenix Labs که بازی Dauntless اولین اثر آن‌ها بوده، با اشاره به سختی‌های تولید بازی‌های چندنفره‌ی آنلاین از مشکلات سرور در این بازی‌ها می‌گوید و اینکه برخلاف تصور خیلی از مردم، تنها اضافه کردن سرورهای بیشتر باعث رفع مشکلات نمی‌شود و قضیه پیچیده‌تر از این حرف‌هاست.

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

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

او حرف‌های خود را به این شکل ادامه می‌دهد: «مثلاً ممکن است سرویس من توانایی پاسخ‌دهی به ۱۰۰ هزار درخواست در دقیقه را داشته باشد، ولی داده‌ها باید در دسته‌بندی‌های مختلف درون سرور اجرا شوند و اگر ناگهان تمام بازیکن‌ها به یک بخش وصل شوند، چه اتفاقی برای سرور می‌افتد؟ اگر سرور به مشکل بخورد و بخواهد از حالت پشتیبان استفاده کند، چقدر تأخیر در کار خواهد بود؟

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

آلی فریمن، مدیر تیم تولید استودیو 1047Games، سازنده‌ی بازی Splitgate هم از دشواری‌های Matchmaking (به هم وصل کردن بازیکن‌ها) در آثار رقابتی می‌گوید، مخصوصاً در بازی‌هایی که همیشه شلوغ و پُر مخاطب نیستند: «حفظ تعادل برای متصل کردن بازیکن‌ها به یکدیگر درحالی‌که پینگ مناسبی داشته باشند و بتوانند به خوبی از بازی لذت ببرند، کار بسیار دشواری است. باید به سؤالاتی از این دست جواب داد که آیا بهتر است بازیکن‌ها ۱۰ دقیقه در صف انتظار باشند تا وارد بهترین سرور در منطقه‌ی خود شوند یا در عرض یک دقیقه وارد بازی شوند، ولی با کیفیت پایین؟ آیا یک بازی متعادل با پینگ ۱۰۰ بهتر است یا بازی‌ای بدون تعادل ولی با پینگ ۵۰؟ پاسخ قطعی برای این پرسش‌ها وجود ندارد و باید تمام شرایط را در نظر گرفت و به تدریج وضعیت سرورها را بهبود داد.»

بازی Outward، یک نقش‌آفرینی جهان‌باز با قابلیت Split-Screen

منوها و رابط کاربری

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

اگر از عبارات رایج مثل Settings، Play یا Options استفاده نکنید، خیلی از مخاطبان در چگونگی شروع بازی به مشکل می‌خورند و اگر بخواهید کارهای عجیبی مثل استفاده از دکمه‌های B و Y به‌جای آنالوگ یا D-Pad برای بالا و پایین رفتن در منوها انجام دهید، فقط باعث آشفتگی مخاطبان می‌شوید و همین برخورد اولیه کافی است تا آن‌ها حس خوب یا بدی نسبت به بازی شما پیدا کنند.»

تانیا شورت از استودیو Kitfox Games هم نظر مشابهی دارد و از این می‌گوید که حتی در ناقص‌ترین بازی‌ها و نسخه‌های دسترسی اولیه (Early Access) هم باید به فکر طراحی منوهای مناسبی بود و بخش تنظیمات بازی را به شکلی تدارک دید که باعث گیج شدن بازیکن نشود و امکانات مناسبی را برای لذت بردن هرچه بیشتر از بازی به او بدهد.

در مورد رابط کاربری هم تعدادی از بازی‌سازها مثل دنی واینبام، خالق بازی Eastshade و اتین بولیو، طراح رابط کاربری استودیو Panache Digital Games صحبت‌هایی کرده‌اند و از سختی‌های طراحی رابط کاربری در شرایطی گفته‌اند که باید اطلاعات کافی را در اختیار بازیکن قرار دهد، ولی این کار را بیش از حد پررنگ و غلیظ هم انجام ندهد.

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

فرد هورگن، طراح تکنیکی ارشد استودیو Firesprite هم از دشواری‌های طراحی منوی دارایی (Inventory) می‌گوید و آن را یکی از بخش‌های به ظاهر ساده ولی در حقیقت پیچیده‌ی بازی می‌داند که باید به شکلی طراحی شود که هم مخاطبان به‌راحتی از آن استفاده کنند و هم با سایر المان‌های دنیای بازی هم‌خوانی داشته باشد و مثلاً وقتی کسی می‌خواهد آیتمی را از این منو خارج کند، این اتفاق به شکل مناسبی در دنیای بازی رخ دهد.

به‌گفته‌ی هورگن: «بیرون انداختن آیتم‌ها از داخل منوی دارایی، اتفاقی است که با وجود ظاهر ساده‌ی خود به ظرافت خاصی نیاز دارد و باید بازی را به شکلی طراحی کرد که اگر بازیکن آیتمی را از منو خارج کرد و خواست دوباره آن را استفاده کند، امکان انجام این کار را داشته باشد. همچنین باید آیتم‌های مخصوصی که برای مأموریت‌های بازی الزامی هستند را قفل کرده و امکان بیرون انداختن آن‌ها از منو را به بازیکن نداد. دراین‌میان ممکن است بازی به شکلی باشد که آیتم‌ها پس از خروج از منو، روی زمین حالت فیزیکی داشته باشند و در این صورت باید توجه کرد که آیا بازیکن می‌تواند ازطریق این آیتم‌ها درون محیط کار خاصی انجام دهد و مثلاً تعدادی از آن‌ها را کنار هم قرار داده و یک راه پله برای دستیابی به بخشی غیرقابل دسترسی از بازی بسازد یا حتی دیواری تشکیل داده و جلوی حرکت شخصیت‌های غیرقابل بازی (NPC) را بگیرد و جریان بازی را به هم بزند؟

منوی Inventory بازی The Witcher 3

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

ترکیب تمام بخش‌های بازی با یکدیگر

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

یونمان نوردهاگن از استودیو Dim Bulb Games که بازی Where the Water Tastes Like Wine را از آن‌ها شاهد بوده‌ایم، در پاسخ به این سؤال که تولید کدام بخش از بازی‌های ویدیویی ظاهری ساده دارد ولی در حقیقت پیچیده است، چنین جوابی می‌دهد: «وقتی بازیکن یک دکمه را فشار می‌دهد، چه اتفاقی می‌افتد؟»
او جمله‌ی خود را به این شکل کامل می‌کند: «بخشی از مراحل تولید بازی‌های ویدیویی که من زمان زیادی را صرف آن می‌کنم، ورودی بازی است، یعنی اتفاقاتی که در اثر فشردن دکمه‌ها توسط بازیکن رخ می‌دهد. این بخش در ظاهر خیلی ساده به نظر می‌رسد، ولی پیچیدگی‌های زیادی دارد و باید خیلی چیزها را در آن در نظر گرفت. شاید فشردن دکمه‌ی اسپیس برای پریدن ساده باشد، ولی خم شدن شخصیت در موقعیت‌های خاص چطور؟ اگر بخواهید دکمه‌ی اسپیس را درکنار قابلیت پریدن به قابلیت فعال کردن آیتم‌های نزدیک به کاراکتر هم اختصاص دهید، باید چه کار کنید؟

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

میچ دایر، نویسنده‌ی بازی‌های Gotham Knights و Star Wars: Squadrons هم به شکلی در این زمینه صحبت می‌کند که تمام زوایای تولید بازی را دربرمی‌گیرد: «تصور کنید که در حال نگارش ماجراهای صحنه‌ای از یک بازی AAA (آثار بزرگ و پُر هزینه با کیفیت بالا) هستید که در آن دو شخصیت با یکدیگر ملاقات می‌کنند تا به تبادل اطلاعات بپردازند. در حالت عادی و خسته‌کننده، می‌توان این صحنه را به شکلی تدارک دید که دو نفر تنها به یک گفت‌وگوی ساده با یکدیگر بپردازند و تمام. البته طراحی چنین صحنه‌ای هم هزینه‌های بالایی دارد و باید به فکر انیمیشن‌های چهره‌ی باورپذیر و حرکات طبیعی با استفاده از بازیگرها بود تا شخصیت‌ها شبیه ربات به نظر نرسند.

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

کافه‌ای در بازی Life Is Strange

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

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

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

درنهایت هم گابریلا سالواتوره، یکی از مؤسسان استودیو Beans به این شکل به سؤال خبرنگار IGN جواب می‌دهد: «من این پرسش را با اعضای تیم درمیان گذاشتم و هرکدام پاسخ خود را دادند. تیم هنری، طراحی دندان‌ها را سخت‌ترین بخشِ به ظاهر ساده‌ی بازی می‌داند. تیم تولید هم از این گفته که درخواست از هنرمندان استودیو برای کار با JIRA (نرم‌افزاری برای مدیریت پروژه و رفع ایرادات آن) واقعاً کار سختی است! سایر اعضا نیز هرکدام چیزی گفته‌اند، ولی جواب من این است: تبدیل کردن بازی به یک اثر مفرح و لذت‌بخش.

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

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

پریدن ماریو در بازی Super Mario Bros؛ حرکتی به ظاهر ساده ولی در حقیقت پیچیده

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

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