سرنوشت غم انگیز Mass Effect Andromeda؛ چه بر سر یکی از مورد انتظار ترین بازی های نسل هشتم آمد؟ [قسمت دوم]

فرایند توسعه Mass Effect: Andromeda با مشکلات فراوانی روبرو بود. کارگردان بازی عوض شد، ابعاد پروژه از ابتدا تعریف شد، تیم انیمیشن منابع و نفرات کافی را در اختیار نداشت، فناوری ها و تکنولوژی های مورد نیاز در دسترس نبودند، ارتباطات بین اعضای تیم ضعیف و زمان بندی هم بسیار فشرده بود.

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

• سرنوشت غم انگیز Mass Effect Andromeda؛ چه بر سر یکی از مورد انتظار ترین بازی های نسل هشتم آمد؟ [قسمت اول]
• سرنوشت غم انگیز Mass Effect Andromeda؛ چه بر سر یکی از مورد انتظار ترین بازی های نسل هشتم آمد؟ [قسمت دوم]
• سرنوشت غم انگیز Mass Effect Andromeda؛ چه بر سر یکی از مورد انتظار ترین بازی های نسل هشتم آمد؟ [قسمت سوم]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

آگوست 2014 کیسی هادسون از بایوور رفت. چندی بعد جرارد لهیانی هم این استودیو را ترک کرد و مک والترز، نویسنده سه گانه اصلی مس افکت که در ادمونتون مشغول به کار بود به جای او منصوب شد و سکان هدایت پروژه آندرومدا را به دست کرفت.

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

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

بایوور راهی برای عملی کردن ایده های کنترل سفیه فضایی، مبارزات در فضا و تولید سیاره ها به روش Procedural نمی یافت. گاهی تکنولوژی و منابع لازم برای پیاده کردن این ایده ها وجود نداشت، گاهی هم نتیجه نهایی متقاعد کننده به نظر نمی رسید.

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

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

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

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

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

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

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

در تابستان سال 2015 بایوور مونتریال بالاخره متوجه شد که راه و روشی که اتخاذ کرده به جایی نمی رسد. البته خیلی از مکانیزم ها در نهایت به سختی توسعه یافته بودند، برای مثال در نسخه آزمایشی هدایت و کنترل سفینه امکان پذیر شده بود، اما بایوور راهی پیدا نمی کرد که در نسخه نهایی این مکانیزم ها را به شکلی پیاده کند که برای بازیکن جذاب باشند.

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

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

پس از مدتی باز برنامه تغییر کرد و تعداد سیاره ها از 30 به 7 کاهش یافت. در این مقطع کارمندان بایوور نمی دانستند که باید چه کنند. چه محتویاتی را نگه دارند و کدام ها را حذف کنند. اصلا نمی دانستند که این کاهش ابعاد پروژه چه معنایی برای شان دارد و چه تاثیری روی کاری که قرار است بکنند می گذارد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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