سلاح «مخفی» وَلو: ولو چگونه بازی‌هایش را پلی‌تست می‌کند؟ | جعبه‌ابزار بازیسازان (۱۳۰)
چند سالی می‌شود که کانال یوتیوب جعبه‌ابزار بازیسازان (Game Maker’s Toolkit) در ویدئوهایی کوتاه و آموزنده به بررسی و توصیف جنبه‌های مختلف بازی‌های ویدئویی و مفاهیم مربوط به این حوزه می‌پردازد. من تصمیم گرفتم محتوای این ویدئوها را با کمی تصرف و منطبق کردن آن با مدیوم نوشتار، به فارسی برگردانم. این سری مقالات برای کسانی که آرزوی بازی‌ساز شدن را در سر می‌پرورانند، یا صرفاً می‌خواهند بازی‌های ویدئویی را بهتر و عمیق‌تر درک کنند، بسیار مفید خواهد بود. با مجموعه مقالات «جعبه ابزار بازیسازان» همراه باشید.
حدوداً یک سال پس از شروع ساخت پورتال (Portal)، پلی‌تسترها (Playtester) یا کسانی که مسئول تست کردن بازی شده بودند، همه بازخوردی مشابه به ولو دادند: «عجب بخش آموزشی فوق‌العاده‌ای. بی‌صبرانه منتظرم اصل بازی را تجربه کنم.» حالا مشکل چه بود؟ آن بخشی که به پلی‌تسترها داده بودند، اصل بازی بود.
با این‌که بازیکنان حدود ۱۴ پازل متفاوت را پشت سر گذاشتند، ظاهراً جای یک عنصری که به آن‌ها نشان دهد در حال تجربه‌ی یک بازی ویدیویی هستند خالی بود. بنابراین پس از به بحث گذاشتن موضوع، ولو به این نتیجه رسید که بازی نیاز به یک شرور یا آنتاگونیست دارد: شخصیتی که برای بازیکن مانع ایجاد کند، انگیزه‌ای برای پیشروی فراهم کند و برای این پازل‌ها یک بستر داستانی ایجاد کند. این بستر داستانی چه بود؟ این‌که تمام این پازل‌ها تمرینی برای شکست دادن یک غول‌آخر هستند.
احتمالاً نتیجه‌ی نهایی معرف حضورتان است: گلادوس (GLaDOS)، یک هوش مصنوعی پیشرفته و کمی خل‌وچل که دائماً با پرخاشگری منفعل (Passive Aggressive) به بازیکن تیکه می‌پراند.
او شما را اذیت می‌کند، به شما توهین می‌کند، شما را گول می‌زند و در نقطه‌ی نهایی بازی نیز شما با گلادوس در اتاقی که جسم فیزیکی‌اش در آن قرار دارد روبرو می‌شوید.
گلادوس: «خب، بالاخره منو پیدا کردی. آفرین. ارزشش رو داشت؟ چون با وجود رفتار خشونت‌آمیزت، تنها چیزی که تا حالا تونستی بشکنی قلب من بوده.»
به‌لطف نویسندگی سطح‌بالا و صداپیشگی فوق‌العاده، گلادوس به یکی از نمادین‌ترین شرورهای دنیای گیم تبدیل شده است. ولی طبق گفته‌ی رابین واکر (Robin Walker)، یکی از اعضای ولو: «خلق گلادوس حاصل فرآیندی بسیار سرراست بود: تلاش ما برای حل اصلی‌ترین مشکل گیم‌پلی در پورتال.»
پلی‌تست کردن پورتال
اگر به‌خاطر بازخوردی که پلی‌تسترها به ولو دادند نبود، شاید گلادوس هیچ‌گاه به وجود نمی‌آمد. اگر از من بپرسید، این حقیقت ارزش پلی‌تست کردن بازی‌ها را نشان می‌دهد. در اینجا پلی‌تست کردن را نباید با تضمین کیفیت (Quality Assurance) یا تست متمرکز (Focus Testing) اشتباه گرفت، چون تضمین کیفیت صرفاً حول محور رفع کردن باگ‌های بازی می‌چرخد و هدف تست متمرکز نیز تحقیق درباره‌ی بازار است.
هدف پلی‌تست این است که بخشی از بازی را در اختیار یک سری بازیکن قرار دهید تا بازی کنند و بعد با تکیه بر آنچه می‌بینید و می‌شنوید، یک سری تغییرات در گیم‌دیزاین اعمال کنید (گاهی در انتهای پلی‌تست نیز یک پرسش‌نامه یا مصاحبه ترتیب داده می‌شود).
مثلاً اگر ولو ببیند که بازیکنان حین تلاش برای تغییر دادن مسیر گوی‌های انرژی خودشان را به کشتن می‌دهند، به این نتیجه می‌سد که شاید اعمال یک تغییر ضروری باشد؛ مثلاً اتاق‌هایی را که در آن‌ها گوی‌های انرژی وجود دارند طوری طراحی کند که فقط بتوان پورتال‌ها را روی دیوارهایی که بالای سر بازیکن هستند ایجاد کرد تا امکان برخورد گوی‌ها به بازیکن وجود نداشته باشد.
بنابراین در پورتال این رویکرد تقریباً روی همه‌ی جنبه‌های بازی تاثیر گذاشت. ولو از پلی‌تست برای مقاصد زیادی استفاده کرد، مثل:
- اطمینان از این‌که فرآیند تدریجی یادگیری مکانیزم‌های بازی بی‌نقص است
- حذف کردن لحظاتی در بازی که برای همه‌ی تست‌کننده‌ها گیج‌کننده یا اعصاب‌خردکن بود
- اطمینان از این‌که بازیکنان متوجه وجود اشیاء مهم می‌شوند
- بهبود ضرب‌آهنگ بازی
- تنظیم کردن درجه‌سختی بازی
- منسجم نگه داشتن خط داستانی بازی
حتی انتخاب سبک گرافیکی نمادین بازی – که عموماً متشکل از دیوارها و طبقات سفید و بی‌روح و استریل‌شده است – ناشی از پلی‌تست کردن بازی بود. در ابتدا، سبک گرافیکی بازی (که می‌توانید آن را درنسخه‌ی بتای بازی در سال ۲۰۰۵ ببینید) متشکل از محیط‌های شلخته، خاکستری و کثیف بود، ولی برای پلی‌تسترها شناسایی عناصر کلیدی حل پازل در چنین محیطی سخت بود.
در یکی از تست‌ها، یک بازیکن نیم ساعت درگیر هل دادن یک قفسه روی یک دکمه بود، در حالی‌که در همان نزدیکی یک جعبه قرار داشت و او متوجه وجود آن نشده بود.
از کیم سوییفت (Kim Swift) – یکی از بازیسازان اصلی پروژه – نقل است: «از وقتی که به ولو آمدیم، احتمالاً مهم‌ترین چیزی که یاد گرفتیم پلی‌تست کردن بود.»
شاید این را ندانید، ولی منبع الهام اصلی پورتال در ابتدا یک بازی به نام نارباکولار دراپ (Narbacular Drop) بود، یک پروژه‌ی دانشجویی که در دانشگاه دیجیپن در واشنگتون ساخته شده بود.
سازندگان بازی به دفتر مرکزی ولو دعوت شدند تا بازی را نمایش دهند و اواسط پخش دموی بازی بود که گیب نیول (Gabe Newell)، مدیرعامل ولو، ارائه‌ی آن‌ها را متوقف کرد تا به کل اعضای تیم شغلی را در ولو پیشنهاد دهد.
هدف این پیشنهاد کاری این بود که بازی در موتور سورس (Source Engine) و در جهان نیمه‌عمر (Half-Life) بازسازی شود و ولو به این تیم دانشجویی کوچک پروسه‌ی ساخت یک بازی را آموزش دهد.
حال این پروسه از چه قرار است؟ قدم اول تعیین یک هدف است. در این مورد خاص، هدف می‌تواند طراحی یک پازل باشد که فهیمدن آن راحت و حل کردنش لذت‌بخش است.
قدم دوم، طراحی محتواست؛ در این مورد خاص، محتوا یک اتاق آزمایش است.
قدم سوم، ترتیب دادن پلی‌تست است تا پی ببرید آیا طراحی‌تان به هدف موردنظر رسیده است یا خیر.
قدم چهارم این است که اگر دیدید به هدف موردنظر نرسیده‌اید، قدم‌های قبلی را دوباره تکرار کنید تا به هدف برسید.
ولو این پروسه‌ی آزمون‌وخطا محور را آنقدر تکرار می‌کند تا به قول دیوید اسپایرر (David Speyrer)، یکی از بازیسازان ولو: «تماشای جلسات پلی‌تست دیگر دردناک و عذاب‌آور نباشد.»
جای تعجب ندارد که ولو بازیسازی را به چشم یک چالش مهندسی یا پژوهش علمی می‌بیند، چون موضوع بازی‌هایش نیز با این رویکرد تناسب دارد. مایک امبایندر (Mike Ambinder)، روان‌شناس درون‌سازمانی ولو می‌گوید: «ما گیم‌دیزاین را به چشم فرضیه و پلی‌تست را به چشم آزمایش‌هایی برای اثبات این فرضیه می‌بینیم.»
لازم به ذکر است که پلی‌تست کردن منحصر به ولو نیست و همه‌ی بازیسازان در یک مقطع از ساخت بازی به بازخورد بازیکنان رجوع می‌کنند. ولی تفاوت ولو با بازیسازهای دیگر این است که گرایشی دیوانه‌وار به پلی‌تست کردن دارد، طوری‌که انگار مذهبش باشد.
- امبایندر پلی‌تست کردن را «مهم‌ترین بخش پروسه‌ی بازیسازی» خطاب کرده است.
- گیب نیول گفته است: «یکی از سلاح‌های مخفی ما تاکنون پلی‌تست کردن بوده است.»
- شان ونمن (Sean Vanaman)، طراح بازی‌ای که در سال ۲۰۱۸ به شرکت پیوست، گفته: «قبل از این‌که در ولو مشغول به کار شوم، می‌دانستم که این شرکت پلی‌تست زیاد انجام می‌دهد، ولی آماده‌ی حجم پلی‌تستی که شرکت واقعاً انجام می‌دهد نبودم.»
ولو پلی‌تست را در مراحل اولیه انجام می‌دهد. کیم سوییفت و اعضای تیمش صرفاً یک هفته پس از شروع ساخت پورتال اولین پلی‌تست بازی را در ولو انجام دادند، با وجود این‌که در این مقطع فقط یک اتاق نیمه‌کاره را برای نشان دادن به مردم در اختیار داشتند.
ولو پلی‌تست را زیاد انجام می‌دهد. پورتال عملاً هر هفته پلی‌تست می‌شد. معمولاً رسم بر این است که پلی‌تست در روز جمعه انجام شود، نتایج آن در روز دوشنبه به بحث گذاشته شوند، در باقی روزهای هفته نتایج و درس‌های یاد گرفته‌شده اعمال شوند و دوباره در روز جمعه تستی دیگر گرفته شود.
شاید این کار زیاده‌روی به نظر برسد، ولی به‌نظرم اگر از ماجرای پروسه‌ی ساخت فاجعه‌بار نیمه‌عمر ۱ (Half-Life)، اولین بازی ولو باخبر شوید، این پلی‌تست کردن افراطی منطقی‌تر به نظر برسد.
تاریخچه‌ی ولو
حدود دو ماه قبل از تاریخی که نیمه‌عمر قرار بود در آن منتشر شود، ولو متوجه شد که بازی… مزخرف است. کن بردول (Ken Birdwell)، یکی از سازندگان بازی گفت: «نمی‌شد بازی را از اول تا آخر بازی کرد؛ هیچ‌کدام از مراحل با هم تناسب نداشتند و بیشتر بخش‌های بازی مشکلات فنی جدی داشتند. برخی از بخش‌های بازی به‌صورت مستقل عالی بودند، ولی به‌طور کلی بازی کار نمی‌کرد.»
تنها گزینه‌ی پیش‌رو این بود که کلاً بازی را دور بیندازند و ساخت آن را از اول شروع کنند. ولی این بار، رویکردی متفاوت را دنبال کردند که به شکل‌گیری دو فلسفه‌ی گیم‌دیزاین منجر شد که این استودیو تا به امروز دنبال‌شان می‌کند.
فلسفه‌ی اول، ایده‌ی گروه‌بندی فرقه‌ای (Cabals) است: طبق این ایده، اعضای تیم سازنده‌ی بازی باید به تیم‌های کوچک‌تر چندتخصصی تقسیم شوند که هرکدام مالکیت کامل روی بخش کوچکی از بازی دارند.
فلسفه‌ی دوم، پلی‌تست کردن پرتکرار بازی، از ابتدایی‌ترین تا نهایی‌ترین مراحل ساخت، بود.
این بار، آن‌ها می‌خواستند در صورت افتضاح بودن بازی، از همان اول این را بدانند.
بنابراین حدود سه ماه پس از شروع ساخت نسخه‌ی جدید نیمه‌عمر، آن‌ها شروع به پلی‌تست کردن بازی کردند. آن‌ها سراغ گیمرهای رندوم در فروشگاه‌های گیم رفتند و با افرادی که کارت‌های ثبت‌نام داخل جعبه‌های بازی‌های کامپیوتر را پر کرده بودند، تماس گرفتند.
آن‌ها بازی را در اختیار این افراد قرار دادند و صرفاً بازی کردنشان را تماشا کردند. با هر تست، آن‌ها ده‌ها نکته یا اشکال جدید پیدا می‌کردند که لازم بود رفع شود، تغییر پیدا کند، اضافه شود یا به‌کل از بازی حذف شود.
مثلاً در طی یک پلی‌تست، ولو متوجه شد که بعضی از بازیکنان تمام جعبه‌هایی را که در یک مرحله وجود داشتند می‌شکستند. با مشاهده‌ی این صحنه، ولو متوجه شد که بهتر است در بعضی از این جعبه‌ها غنیمت‌هایی چون مهمات یا بسته‌های سلامتی قرار دهد.
این پروسه‌ی جدید طبیعتاً خوب کار کرد: این نسخه از نیمه‌عمر موفقیتی بزرگ بود و اکنون به آن به‌چشم یکی از مهم‌ترین بازی‌های تمام دوران نگاه می‌شود.
به‌خاطر همین، ولو به پلی‌تست کردن پرتکرار برای همه‌ی بازی‌های آتی‌اش ادامه داد.
به‌هنگام ساخت نیمه‌عمر ۲ (Half-Life2)، تصمیم اولیه‌ی ولو این بود که در بخش انتهایی بازی اسلحه‌ی گرانشی (Gravity Gun) را در اختیار بازیکن قرار دهد. ولی پلی‌تسترها آنقدر از استفاده از آن لذت بردند که اعضای تیم سازنده تصمیم گرفتند آن را به‌مراتب زودتر در دسترس بازیکن قرار دهند.
به‌هنگام پلی‌تست کردن لفت فور دد (Left 4 Dead)، برای پلی‌تسترها پیدا کردن هم‌تیمی‌هایی که به دردسر افتاده بودند سخت بود، برای همین سیستمی به بازی اضافه شد که به‌موجب آن، همیشه می‌توانید پیکر برجسته‌ی هم‌تیمی‌هایتان را حتی از پشت دیوار ببینید.
در پورتال ۲، ژلی که به شما اجازه می‌داد روی دیوارها بدوید از بازی حذف شد، چون باعث شد به تعدادی از پلی‌تسترها حالت تهوع دست بدهد.
با انتشار استیم، امکانی برای ولو فراهم شد تا در زمینه‌ی پلی‌تست کردن بازی‌ها پا را فراتر بگذارد و میلیون‌ها بازیکن آنلاین را به پلی‌تسترهای پساانتشار بازی تبدیل کند. وقتی داده‌های استیم نشان دادند که بسیاری از بازیکنان در اپیزود یک گیر کرده بودند، ولو پچی منتتشر کرد که درجه‌سختی نبرد محاصره‌ای بدقلق بازی را کاهش می‌داد.
همچنین در زمینه‌ی اکتشاف تکنولوژی جدید، پلی‌تست کردن نقشی محوری داشت. مثلاً یکی از این تکنولوژی‌های جدید، دوربین واقعیت مجازی بود که در ساختن نیمه‌عمر: الکس (Half-Life Alyx) به کار رفته بود. ولو از راه پلی‌تست فهمید که صبر مردم برای ایستادن و گوش دادن به دیالوگ‌های یک شخصیت غیرقابل‌بازی در محیط مجازی در مقایسه با بازی عادی به‌مراتب کمتر است، برای همین آن‌ها ضرب‌آهنگ بازی را سریع‌تر کردند.
کریستین فیلن (Christine Phelan)، یکی از اعضای ولو گفت: «رفتار بازیکنان به ما در ساخت یک بازی واقعیت مجازی کمک کرد. تقریباً می‌توان به بازیکن به چشم یک گیم‌دیزاینر دیگر نگاه کرد. تقریباً در بازی هیچ لحظه‌ای وجود ندارد که به‌وسیله‌ی آنچه پلی‌تسترها به ما گفتند یا از راه رفتارشان نشان دادند، بهبود پیدا نکرده باشد.»
توصیه‌هایی در زمینه‌ی پلی‌تست
بنابراین از زمان ساختن نیمه‌عمر ۱ تا نیمه‌عمر: الکس، پلی‌تست ابزاری ارزشمند برای ولو بوده است. حال می‌خواهم توصیه‌هایی را از زبان بازیسازان ولو با شما به اشتراک بگذارم تا نشان دهم پلی‌تست موثر چگونه باید انجام شود.
با این حال، باز هم باید تاکید کنم: ولو مثل شرکت‌های دیگر نیست. از سازمان‌بندی غیرمتعارف شرکت گرفته تا منابع بی‌انتهایی که به آن‌ها دسترسی دارد، ولو آنقدر منحصربفرد است که شرکت‌های بسیار کمی روی کره‌ی زمین هستند که بتوانند کاری را که آن‌ها انجام می‌دهند تکرار کنند.
همچنین رویکرد ولو برای بازی‌های بسیار خطی و داستان‌محور که هر لحظه‌یشان به‌صورت دستی طراحی شده، بهینه‌سازی شده است و تکنیک‌های دیگر (مثل طراحی نقشه‌های حرارتی) برای انواع بازی‌های دیگر (مثل بازی‌های دنیاباز) بهتر جواب می‌دهد.
با در نظر گرفتن این نکات، حال بهتر است به تجربه‌ی ولو در این زمینه بپردازیم، چون احتمالاً می‌تواند راهنمای مناسبی باشد.
توصیه‌ی اول: زود شروع به تست کردن کنید. طبق گفته‌ی دیوید اسپایرر: «در مرحله‌ی پلی‌تست است که ما مهم‌ترین و بیشترین تغییرات را روی بازی اعمال می‌کنیم. برای همین سعی می‌کنیم از زودترین زمان ممکن شروع به انجام آن کنیم تا بیشترین سود را از آن استخراج کنیم.»
وقتی یک مشکل را زودهنگام شناسایی کنید، وقت این را دارید تا یک راه‌حل موثر برای آن بیندیشید. ولی اگر مشکل دیر شناسایی شود، گاهی تنها کاری که می‌توان انجام داد، یک راه‌حل دقیقه‌نودی و کم‌اثر است. مثلاً این‌که شخصیت‌های داخل بازی صرفاً راه‌حل پازل‌های بدقلق بازی را در دیالوگ‌هایشان به شما بگویند.
گاهی ممکن است ولو چند روز پس از تولید طرح اولیه‌ی یکی از مکانیزم‌های گیم‌پلی یا مراحل بازی شروع به پلی‌تست کند، حتی اگر محیطی که قرار است تست شود، فوق‌العاده زشت و بدترکیب باشد و آثار کدنویسی برنامه‌نویس‌ها معلوم یا کل محیط بازی نارنجی باشد.
ولی پلی‌تست مکرر – با این‌که وقت می‌گیرد – به آن‌ها اجازه می‌دهد در زمینه‌های دیگر در وقت صرفه‌جویی کنند. اگر قرار باشد یکی از مکانیزم‌های گیم‌پلی بعداً تغییر پیدا کند یا به‌کل از بازی حذف شود، طراحی محتوای هنری و صوتی مربوط به آن منطقی به نظر نمی‌رسد، چون باید آن را هم دور انداخت.
توصیه‌ی دوم: به‌طور مکرر تست کنید. ولو عموماً هر هفته بازی در دست ساختش را تست می‌کند تا اطمینان حاصل کند که همیشه در حال اعمال تغییرات لازم بر اساس بازخورد بازیکنان است. تست کردن مکرر همچنین مقدار بسیار زیادی داده به ارمغان می‌آورد. مثلاً هر فصل از نیمه‌عمر ۲ حدود ۱۰۰ پلی‌تستر داشت و حجم اطلاعات زیادی که از هرکدام به دست می‌آید، بسیار باارزش بود.
وقتی تعداد زیادی گیمر بازی را تست می‌کنند، ولو می‌تواند نقاط مشترک بازخوردشان را پیدا کند و صرفاً بازی را به‌خاطر بازخورد نامتعارف چند نفر که بر اساس عادت‌های خاص خودشان است، تغییر ندهد.
هرچقدر در زمینه‌ی تعامل مردم با بازی‌تان تجربه‌ی بیشتری به دست بیاورید، عملکردتان در پیش‌گیری مشکلات مشابه در آینده بهتر می‌شود. از گیب نیول نقل است: «پس از این‌که چند صد پلی‌تست را تماشا کنید، درک بهتری نسبت به این‌که استراتژی‌های گیم‌دیزاین موفق و ناموفق چه هستند، پیدا می‌کنید.» از بعضی از درس‌های معروفی که در پلی‌تست‌های ولو یاد گرفته شد، می‌توان به موارد زیر اشاره کرد: ۱. «وقتی بازیکنان استرس دارند، چیزی یاد نمی‌گیرند» و ۲. «بازیکنان به بالای سرشان نگاه نمی‌کنند!»
توصیه‌ی سوم: صرفاً دهانتان را ببندید و تماشا کنید. پلی‌تست باید شبیه‌سازی‌ای از تجربه‌ی واقعی بازی کردن باشد. این یعنی ناظران باید در طول تست ساکت بمانند و از راهنمایی کردن یا پاسخ دادن به سوال‌های بازیکنان – هرچقدر هم که ضروری – پرهیز کنند.
از کن بردول نقل است: «هیچ‌چیز به‌اندازه‌ی تماشای تلاش یک پلی‌تستر بیچاره که ۲۰ دقیقه می‌شود که در مرحله‌ی شما سرگردان است و در پیدا کردن جواب «واضح»ی که اکنون فهمیده‌اید کاملاً پرت و غیرقابل‌حل است ناتوان است، آدم را فروتن نمی‌کند.»
البته می‌توان پس از پایان تست پرسش‌نامه پخش کرد یا با شرکت‌کنندگان مصاحبه کرد – به‌هرحال به‌لطف همین بازخورد پس از پایان تست بود که مسئله‌ی گلادوس حل شد – ولی معمولاً با تماشا کردن بازیکن‌ها نکات بیشتری را یاد خواهید گرفت تا حرف زدن با آن‌ها.
از کیم سوییفت نقل است: «شاید شرکت‌کنندگان بعداً به شما بگویند که از بازی‌تان خوششان می‌آید، ولی اگر به زبان بدن‌شان دقت کنید، خودتان می‌توانید پی ببرید که آیا واقعاً از بازی لذت بردند یا نه.»
یکی از کلیشه‌های گیم‌دیزاین هم این است که وقتی افرادی بازی‌تان را تست می‌کنند، برای مشکلاتی که بهشان برخورد کردند راه‌حل ارائه می‌دهند، ولی با توجه به این‌که آن‌ها از چشم‌انداز شما یا محدودیت‌هایی که پیش رویتان است، دانش کافی ندارند، بهتر است این راه‌حل‌ها را نادیده گرفت.
توصیه‌ی چهارم: خود طراحان اصلی باید پلی‌تست را اجرا کنند. ولو تست کردن را به یک دپارتمان خاص یا ناشر بازی برون‌سپاری نمی‌کند. جلسه‌ی پلی‌تست را همان کسانی ترتیب می‌دهند و روی آن نظارت دارند که مسئول طراحی و اجرای همان مکانیزم گیم‌پلی یا مرحله‌ای هستند که قرار است تست شود. به‌عبارت دیگر، همان گروه‌بندی فرقه‌ای که پیش‌تر به آن اشاره شد.
این کار برای سازندگان بازی امکانی فراهم می‌کند تا ببینند دقیقاً چه چیزی نیاز به حل شدن دارد و برای آن‌ها انگیزه فراهم می‌کند تا بازی را بهبود بخشند.
رفتار بازیکن شاید الهام‌بخش طراحی یک پازل یا شکل‌گیری یک ایده‌ی جدید در ذهن طراحانی شود که در حال تماشای پلی‌تست هستند. مثلاً در نیمه‌عمر: الکس، بازیکنان به‌طور غریزی جلوی دهان خودشان را می‌گرفتند تا جلوی سرفه کردن الکس داخل محیط بازی را بگیرند، چون می‌ترسیدند سرفه کردن او توجه یک زامبی غول‌پیکر نابینا به نام جف (Jeff) را جلب کند. برای همین، ولو گرفتن جلوی دهان خود را به مکانیزم گیم‌پلی واقعی تبدیل کرد.
توصیه‌ی پنجم: شرکت‌کنندگان مناسب را پیدا کنید. ولو از قشر بسیار متنوعی از شرکت‌کنندگان بازخورد می‌گیرد: از بازیسازان مشغول به کار در خود شرکت گرفته تا کودکان و گیمرهای حرفه‌ای. ولی باید در نظر داشته باشید که طبق تجربیات ولو، بهتر است پیش از اعمال تغییرات، همیشه مخاطبی خاص را در نظر داشته باشید.
مثلاً وقتی ولو داشت تصمیم می‌گرفت که چگونه یک باس‌فایت هیجان‌انگیز با گلادوس را ترتیب دهد، در ابتدا از بازیکنان هاردکور سبک اکشن اول شخص بازخورد دریافت کرد که گفته بودند مرحله به اکشن بیشتر، درجه‌سختی بالاتر و چالش‌های مهارت‌محور بیشتر نیاز دارد. ولی این ایده با شکست مواجه شد. از اریک ولپاو (Erik Wolpaw)، یکی از اعضای ولو نقل است: «بیشتر پلی‌تسترهایی که به ضرب‌آهنگ کندتر و ذهنی‌تر پورتال عادت کرده بودند، [پس از تجربه‌ی غول‌آخر اکشن‌محوری که بازیکنان حرفه‌ای اکشن اول شخص توصیه کرده بودند] احساس گیج شدن، اعصاب‌خردی و نارضایتی کردند.»
ولو همچنان می‌خواست رضایت بازیکنان حرفه‌ای بازی‌های اکشن اول شخص را جلب کند، ولی این کار را با ساختن محتوای فرعی انجام داد، مثل گنجاندن اتاق‌های پیشرفته و نقشه‌های چالش‌محور در بازی.
توصیه‌ی ششم: پیش‌فرض‌های خود را به چالش بکشید. بسیار خب، شاید مبارزه با گلادوس نباید مبتنی بر مهارت می‌بود؛ شاید لازم بود که پیچیده‌ترین پازل کل بازی باشد. آیا این نقطه‌ی اوجی مناسب به نظر نمی‌رسد؟
ولی مسئله این بود: در نظر پلی‌تسترها، آن قسمت در وسط بازی که شما باید روی دیوار پیش رویتان پورتال ایجاد کنید تا از سقوط در آتش جلوگیری کنید، نقطه‌ی اوجی بسیار رضایت‌بخش بود؛ با این‌که عملاً ساده‌ترین پازل در کل بازی است.
ولی ولو متوجه شد که فشار زمانی، تاثیر سبک‌وسیاق بصری و درام غلیظی که در قلب این لحظه جریان داشت، برای بازیکنان به‌مراتب هیجان‌انگیزتر بود. برای همین شاید داشتند زیادی درباره‌ی این‌که چگونه باس‌فایت نهایی را طراحی کنند، به ذهن خود فشار می‌آوردند.
از کیم سوییفت نقل است: «ما بدجوری درگیر این ایده بودیم که باید در انتهای بازی پازلی پیچیده بگنجانیم، ولی این ایده اصلاً درست نبود.» برای همین یک پازل ساده را در انتهای بازی گنجاندند. احتمال این‌که بازیسازان به پیش‌فرض‌هایی گمراه‌کننده درباره‌ی واکنش بازیکنان برسند بسیار بالاست.
با این حال، شاید مهم‌ترین توصیه این باشد که بازخورد به‌دست‌آمده از پلی‌تست صرفاً داده است و این بستگی به طراحان بازی دارد که چطور این داده را تفسیر، فیلتر یا اعمال کنند. به‌عنوان مثال، در ابتدا نیمه‌عمر ۲ بخش افتتاحیه‌ی کوتاهی داشت؛ یعنی فاصله‌ی بین ثانیه‌ی اول شروع بازی و قسمتی که گوردون فریمن تفنگ به دست می‌گرفت و شروع به تیراندازی می‌کرد، کم بود.
پلی‌تسترها از کوتاه بودن بخش افتتاحیه بسیار خوششان آمد. کیست که از سریع رسیدن به بخش اکشن خوشش نیاید؟ با توجه به این بازخورد خوب، منطق حکم می‌کرد بازی را همین‌گونه نگه داشت.
ولی با وجود بازخورد مثبت، مارک لیدلا (Marc Laidlaw)، نویسنده‌ی بازی گفت که ولو تصمیم گرفت این بخش را طولانی‌تر کند. در نظر آن‌ها بهتر بود که بخش مبارزه‌ی بازی با تاخیر شروع شود. از لیدلا نقل است: «ما می‌خواستیم بازیکنان پلیس‌ها را حین انجام کاری وحشتناک ببینند و احساس کنند تیراندازی‌ای که قرار است انجام دهند، واکنش به کار پلیس‌هاست، نه این‌که صرفاً قرار است نقش ماشین کشت‌وکشتار را بازی کنند.»
همچنین آن‌ها به این نتیجه رسیدند که اگر بازیکن زمان بیشتری منتظر بماند تا دیلم نمادین گوردون به دست او برسد، بار احساسی آن به‌مراتب بیشتر خواهد بود.
بارنی: اوه، قبل از این‌که یادم بره، فکر کنم این رو توی بلک میسا جا گذاشتی.
نتیجه‌گیری
نکته‌ی مهمی که باید در نظر بگیرید این است: میزان مفید بودن پلی‌تست کردن را خودتان تعیین می‌کنید. اگر بازی‌تان را بر اساس تمایلات و حس‌وحال لحظه‌ای هر پلی‌تستری که گذرتان به او می‌افتد تغییر دهید، نتیجه‌ی نهایی یک بازی بی‌مایه و سطحی خواهد بود که انگار هیچ چشم‌انداز نبوغ‌آمیزی پشت آن نیست.
ولی اگر این کار را با هدفی مشخص انجام دهید، اگر قصد داشته باشید یک بازی مشخص را برای مخاطبانی مشخص بسازید و بعد از پلی‌تست استفاده کنید تا ببینید به این هدف رسیده‌اید یا نه، مسلماً بازخوردی که دریافت کنید، به ساخته شدن بازی فوق‌العاده‌ای که می‌خواهید بسازید کمک خواهد کرد.
قبل از این‌که مقاله را به پایان برسانیم، می‌خواهم یک داستان جالب دیگر درباره‌ی پورتال تعریف کنم: خلق شدن شخصیت گلادوس اساسی‌ترین تغییری نبود که ولو در واکنش به بازخورد پلی‌تسترها، در پورتال اعمال کرد.
پس از برگزاری یک گیم‌جم (Game Jam) درون‌سازمانی اندکی پس از انتشار پورتال ۱، ایده‌ی ساختن یک بازی پازل آزمایشی به نام F-Stop به ذهن تعدادی از بازیسازان ولو رسید. در این بازی، شما با استفاده از یک دوربین از اشیاء عکس می‌گیرید. اما بعد می‌توانید با استفاده از این عکس، همان شیء را در قسمت دیگری از دنیای بازی – با اندازه‌ی متفاوت – ظاهر کنید.
گیب نیول بسیار به این ایده علاقه‌مند شد و گفت که بهتر است با اتکا بر ایده دنباله‌ای برای پورتال بسازند؛ یعنی برنامه‌ی اصلی این بود که هر بازی در مجموعه‌ی پورتال، روی یکی از فناوری‌های ساخته‌شده در اپرچر ساینس (Aperture Science) تمرکز کند.
ولی پس از این‌که ولو یک سال را صرف ساخت بازی کرد، پلی‌تسترها واکنشی بسیار محکم نشان دادند: پورتال بدون وجود پورتال‌ها کار نمی‌کند. برای همین ولو تصمیم گرفت این ایده را کنار بگذارد و ساخت پورتال ۲ را از اول شروع کند.
این روزها ما فرصت این را داریم تا ببینم F-Stop ممکن بود چه بازی‌ای از آب دربیاید، چون طرفداران از اَسِت‌ها و کدهای لورفته‌ی بازی استفاده کرده‌اند تا بازی را به شکل‌های مختلف بازسازی کنند. ولی ولو هیچ‌گاه به این ایده رجوع نکرد. اگر دنبال بازی‌ای با ایده‌ی مشابه می‌گردید، سوپرلیمینال (Superliminal) و ویوفایندر (Viewfinder)، بازی پازل عکاسی‌محور که قرار است به‌زودی منتشر شود، توصیه می‌شود.
منبع: مارک براون – یوتیوب
