بزرگترین چالشهای بازیسازی؛ مشکلات به نظر سادهای که حلشان غیرممکن است
اوایل سال جاری میلادی، بسیاری از توسعهدهندگان بازی درگیر یک سؤال عجیب بودند: وجود «در ورودی» چه اشکالی در بازیهای ویدیویی دارد؟ بعدها مشخص شد که مشکلات زیادی با افزودن چنین ویژگی کوچکی پدیدار میشود. ویژگی به ظاهر سادهای مانند «در قابل استفاده» میتواند یک مشکل اساسی برای توسعهدهندگانی باشد که به دنبال استفاده از آن برای دلایل مشخصی هستند. از عملکرد تا فیزیک و هوش مصنوعی، هنگام ساخت یک در ساده که بتواند باز شود، دخیل هستند. این در بسیار ساده، نهتنها باید به درستی کار کند، بلکه باید عملکرد آن طوری باشد که بازیکن نباید هیچگاه در مورد عملکرد آن فکر کند و تنها از کنارش رد شود. شاید باور نکنید، اما ساخت چنین در ورودی ساده و فراموششدنی، مسئولیت سنگینی برای یک بازیساز است.
«چه چیزی به نظر شما در بازیسازی بسیار ساده به نظر میآید؛ اما در واقع توسعه و ایجاد آن بسیار دشوار است؟»
واضح است که چشمانداز بزرگتر را درک میکنید و میدانید که این تنها یک مثال ساده است، تا فرایند چالش برانگیز توسعهی یک بازی ویدیویی بهتر نشان داده شود. چند ماه پیش بود که از توسعهدهندگان سراسر دنیا، سؤال جالبی را پرسیدیم: «چه چیزی به نظر شما در بازیسازی بسیار ساده به نظر میآید؛ اما در واقع توسعه و ایجاد آن بسیار دشوار است؟» بیش از ۱۰۰ پاسخ مختلف از افراد باتجربه و توسعهدهندگان مستقل دریافت کردیم که با مشکلات از این قبیل در تیمهای صد نفره دست و پنجه نرم کردهاند.
پاسخها به مشکلات متنوعی اشاره داشتند، اما تعدادی از آنها میان پروژههای گوناگون یکسان بود. افرادی که با آنها صحبت کردیم، جنبههای مختلف توسعه بازی مانند گرافیک، صدا، قصهگویی، تعامل با اشیاء، منوها، سیستم ذخیره بازی و بخش چندنفره را به عنوان چالشهای دشوار عنوان کردند. بسیاری میگفتند که تهدیدهای جدی از سوی بازیکنان در مورد طراحی این بخشها دریافت کردهاند و بسیاری از مخاطبان این سؤال را از آنها پرسیدهاند: «چرا فلان کار را برای درست کردن بازی انجام نمیدهید؟» پاسخ به این سؤال همیشه یکسان است: «به خاطر اینکه انجام چنین کاری بسیار بسیار سخت است»
اگر تا به حال برایتان سؤال بود که چرا بازیساز مورد علاقه شما، به سادگی یک آپدیت برای حل مشکلات بازی منتشر نمیکند، باید این نکته را در نظر داشته باشید که گاهی حل مشکلاتی که از نظر شما ساده هستند، بسیار دشوار است. در ادامه به چالشهای اساسی هنگام توسعه بازی خواهیم پرداخت که فکرش را هم نمیکنید که حل آنها به این اندازه دشوار باشد.
جابهجایی از مکانی به مکانی دیگر
در بخش پیشین به روند توسعهی دشوار درهای موجود در بازیهای ویدیویی پرداختیم، اما بهتر است آن را تحت عنوان کلیتر بررسی کنیم و آنهم، المانهایی است که اجازهی جابهجایی از مکانی به مکان دیگر را میدهند. برای نمونه، آسانسور دقیقاً همین عملکرد را دارد. بسیاری از توسعهدهندگان در مورد نحوهی توسعهی آسانسورها صحبت کرده و انواع و اقسام آنها را مانند نمونهای که بازیکننده را از یک طبقه به طبقه بالاتر میبرد و در عین یک حال یک صفحهی بارگذاری را نمایش میدهد، به چالش کشیدهاند. «بیل گاردنر» (Bill Gardner) که وظیفهی خلق و کارگردانی بازی در استودیو The Deep End Games را بر عهده دارد و همچنین طراح مراحل بازی بایوشاک بوده، در مورد مشکلات ایجاد یک آسانسور میگوید:
«ابتدا باید بگویم که لازم است آسانسور را توسط یک دکمه یا هر چیز، فراخوانی کنید. با انجام این کار، فرصتی را برای بازیکن، اشیاء یا هوش مصنوعی پدید میآورید که درگیر ماهیت این فرایند شود و هنگام فعال شدن آن، مشکلات اساسی ایجاد شود. خب به صورت تصادفی باید با این مشکل جدید دست و پنجه نرم کنید. آسانسور یک دعوتنامه برای شماست تا مجبور شوید دشمنان یا شخصیتها را بیمغز و بیمعنی بسازید یا اینکه اشیاء به یکباره به هوا پرواز کنند و آیتمهای موجود در مأموریتها، برای همیشه همانجا گیر بیفتند. بیایید برای حل مشکل، هوش مصنوعی را هنگام استفاده از آسانسور حذف کنیم. آنگاه چه تضمینی وجود دارد که پس از ورود به آسانسور، همهچیز منطقی پیش برود؟ خواهیم دید که اشیاء یا سرجایشان خواهند ایستاد یا اینکه رفتاری عجیب از خود نشان میدهند.
خب حالا فکرش را بکنید که آسانسور شما را به چند طبقه مختلف ببرد و آنگاه باید یک صف مخصوص برای پیادهسازی افراد هم ایجاد کنید. خب بیایید بگوییم که شما تصمیم به خروج در طبقهی دوم میگیرید و آنگاه بیرون میروید و دوباره دکمه را فشار میدهید. آنگاه خواهید دید که آسانسور مشغول است و باید مدتی منتظر باشید. اگر چنین کاری انجام دهید، خواهید دید که بازیکننده به دریافت پاسخ و واکنش آنی علاقه دارد و درنتیجه شانس اینکه مخاطب خسته شود و بازی شما را معیوب بنامد، بسیار زیاد است. تازه مشکلات ساخت در آسانسور و آنچه هنگام باز و بسته شدنش اتفاق میافتد هم بماند!»
تیم توسعهدهندگان استودیو «اسکایدنس اینتراکتیو» (Skydance Interactive) که بازی «مردگان متحرک» را در کارنامهی خود دارند، به مشکلی مشابه آنچه «گاردنر» بیان کرد، برخوردهاند: ایجاد یک در ورودی برای یک اثر واقعیت مجازی؛ خوشبختانه آنها توانستهاند مشکل را با ایجاد یک ویژگی جدید برطرف کنند. «بیل فرر» (Bill Ferrer) مهندس هوش مصنوعی استودیو در این مورد میگوید: «یکی از باگها زمانی پیش آمد که فردی میخواست از در عبور کند و در عین حال، بازیکن دیگری میخواست در را باز کند، این وضعیتی مشابه آن است که دو نیروی مخالف جلوی هم قرار بگیرند: یک شیء متحرک در مقابل یک نیروی بیوقفه. راهحل ما این بود که در را بشکنیم و در نتیجه یک لحظهی شکهکننده را ایجاد کنیم. نتیجه در واقع یک اشتباه خوشحالکننده بود.»
خب اگر در و آسانسور آنقدر مکانیسم پیچیدهای دارند، چرا بازیکننده را مجاب به استفاده از پله نکنیم؟ «جاش دیویس» (Josh Davis) از استودیو «درینکباکس» باور دارد که پله هم اشکالات خودش را دارد: «ممکن است پله مانند درهای ورودی پیچیده نباشند، اما گاهی اوقات باعث از دست رفتن پویایی و حس غوطهوری هنگام حرکت در محیط میشوند. با خودم میگفتم که آنها تنها یک رمپ ساده هستند؛ اما میتوانند باعث ایجاد مشکل برای پرش و جابهجایی شوند، زیرا که زاویهی حرکت در این حالت متفاوت است. سروکله زدن با پلهها برای ما که توسعهدهنده بازیهای دوبعدی هستیم، دشوار است؛ زیرا که باگهای بسیار زیادی ناشی از پلهها داشتهایم.»
تابهحال به این نتیجه رسیدهاید که ابزارهای انتقال بازیکن داخل بازی، میتواند یک کابوس وحشتناک باشد، اما یک نوع دیگر هم وجود دارد که باعث عذاب توسعهدهنده میشود: سکوهای متحرک. «کایل دانلی» برنامهنویس بازی Doki Doki Literature Club در این مورد میگوید:
«حرکت دادن بازیکن با دسته سخت نیست، همچنین حرکت دادن او روی یک سکو نیز ساده است؛ اما وقتی این دو را با یکدیگر ترکیب میکنید، خواهید دید که حال با دو کار کاملاً متفاوت سر و کله دارید. برای نمونه چهکار میکنید اگر سکو، بازیکن را به سوی سقف ببرد یا اینکه اصلاً او را بکشد؟ یا حتی باعث ازکارافتادن بازی شود؟ یا اینکه قسمت بعدی پلتفرم که بازیکننده را به سوی پایین میبرد، باید همان عملکرد سابق را داشته باشد؟ میتوانید سکوهای متعدد را هم به این معادله اضافه کنید، برای نمونه اگر بازیکننده روی دو پلتفرم که برعکس هم حرکت میکنند، ایستاده باشد، آنگاه باید فرد از وسط نصف شود؟ هنگامی که در مورد حرکت این سکوها تصمیم میگیرید، آنگاه خواهید دید که مشکلات دیگر مانند فیزیک و نحوهی کاربرد از راه میرسند.»
خب اصلاً بیخیال سکوها و پلتفرمها شویم، بیایید ببینیم آیا راه رفتن عادی هم میتواند کار دشواری برای یک توسعهدهنده بازی باشد؟ خب قطعاً حرکت داخل یک محیط که کار سختی نیست، هست؟ برنامهنویس بازی Unknowns Worlds باور دارد که راه رفتن عادی هم میتواند بسیار پیچیده باشد و باعث مشکلات جدی هنگام توسعه شود: «سخت نیست که یک کد بنویسید تا شخصیت حرکت کند؛ اما باید حواستان به تمامی ورودیها باشد تا نتیجهای رضایتبخش به دست آید. زمان زیادی طول کشید تا میزان شتاب و سرعت حرکت شخصیت را پیدا کردیم. همین چند هفته پیش یک باگ جالب در این مورد پیدا کردم، گاهی اوقات بازیکننده هنگام پریدن و وسط هوا فریز میشود. مشخص شد که مشکل از کد نوشته شده برای حرکت بود که هفت سال است از آن استفاده میکنیم و دارای یک باگ عجیب بود که اگر سختافزار سریع عمل میکرد، عملکرد تغییر میکرد. همهچیز خوب بود تا اینکه شما به ۲۰۰ فریم در ثانیه میرسیدید.»
تعامل با اشیاء
دیگر مشکلی که بسیاری از توسعهدهندگان در میان گذاشتند، تعامل با یک شیء یا تعامل اشیاء با یکدیگر بود. این بدین معنی است که کار سادهای مانند برداشتن یک شیء توسط شخصیت یا ارتباط میان دو شخصیت میتواند به طرز غیر قابل باوری پیچیده باشد. «بن وندر» (Ben Wander) از طراحان بازی Airborne Kingdom در مورد مشکل موجود میگوید: «اشیاء بهنوبهی خود واقعی نیستند، آنها نه چگالی دارند و نه مرزهای فیزیکی، اگر یک شخصیت مجبور به برداشتن یک سیب شود، آنگاه باید طراح برود و کاری کند تا انگشتان دست پیرامون سیب قرار بگیرند. خب حالا فکر کنید بخواهیم یک کیوی داخل دستش قرار دهیم، آنگاه باید یک انیمیشن متفاوت ایجاد شود. برای همین است که بسیاری اوقات اشیاء داخل دوربین نمایش داده نمیشوند یا اینکه دستان یک شخصیت داخل دروازه یا دریچهای قرار میگیرد»
«آدری لپرینس» (Audrey LePrince) مؤسس شرکت «گیم بیکرز» که روی بازی Haven کار کرده، کاملاً با مشکل بیان شده آشناست. این بازی در مورد یک زوج رمانتیک است که احساسات نزدیکی به هم دارند و ارتباط فیزیکی میان آنها تا آخر بازی ادامه دارد. وی میگوید: «ایجاد لحظات لمس کردن، گرفتن دست همدیگر و بغل کردن در صحنههای سینمایی نیز دشوار است، اگر بخواهید داخل بازی هم این کار را بکنید، آنگاه کابوس خواهد بود. بازی Haven نمونهی مناسبی است و این در حالی است که بسیاری فکر میکنند، انجام چنین کاری ساده است و باید بیشتر از این حرکات داخل بازی ویدیویی داشته باشیم.»
انیماتور استودیو گیرباکس (Gearbox) به دیگر مشکل موجود اشاره میکند: «نوازش کردن حیوانات». در طی چند سال اخیر، بسیاری درخواست نوازش کردن سگها یا حیوانات دیگر را داخل بازیهای ویدیوی کردهاند؛ اما در واقع انجام آن کار بسیار پیچیدهای است و ممکن است حین ارتباط، مشکلات جدی برای هوش مصنوعی و رابط کاربری ایجاد شود. تعامل اشیاء و شخصیتها میتواند مشکلساز باشد، به خصوص اگر بخواهید واقعیتگرایی را به بازی وارد کنید. یکی از این چالشها، حضور دو شخصیت در یک زمان و انجام دو کار متفاوت است. ارتباط میان دو شخصیت نیازمند انیمیشنهای پیچیده است و باید فریم به فریم انیمیشینها طراحی شوند تا مشکل جاگیری شخصیتها برطرف شود. مشکل زمانی پیدا میشود که چنین حرکتی باید طراحی شود.
هر دو شخصیت در این حالت حرکت مخصوص خود را دارند و البته باید تمامی اجزاء آنها بچرخد تا توهم ضربهی چکش ایجاد شود. بیش از ۱۴۲ انیمیشن، ۹۴۱ فریم مخصوص در ۹۷ لایه، تنها برای شخصیت اصلی یک بازی دوبعدی طراحی شده است. در ادامه باید بگوییم که تنها اشیاء باعث مشکل نمیشوند، بلکه آب و حرکت آن نیز مشکل دیگری است. خالق بازی Unknowns Worlds میگوید که ایجاد دریاچه یا آب قابل تعامل برای بازیکننده بسیار مهم است، اما آنچه اهمیت دارد این است که چطور آب را از مکانهایی که نمیخواهید، دور نگهدارید. مکس میگوید:
«آب در دنیای واقعی حجم خاصی دارد و ما آن را در بازیهای ویدیویی با اشکال سادهای نشان میدهیم. برای نمونه یک اقیانوس، ممکن است یک صفحهی نامتناهی روی یک مکعب مستطیل باشد. تمامی بخشهای داخل این جعبه باید با آب پر شوند تا غوطهوری شبیهسازی شود. استفاده از چنین اشیاء سادهای برای توصیف آب، باعث واقعی شدن آن در دامنهی محدود یک بازی ویدیویی میشود. مشکل زمانی پیدا میشود که شما کشتی، زیردریایی یا حتی یک غار زیرآبی را به بازی اضافه میکنید. فضای اشغال شده توسط آنها نباید از آب پر شود و در نتیجه باید از حجم آب بکاهید. معمولاً روشهای متفاوتی برای شبیهساز تعامل با آب استفاده میشود. برای کدنویسی گیم پلی، باید کنترلهای متعددی قرار داد تا وضعیت بازیکننده و نحوهی نفس کشیدنش مشخص شود. آنگاه باید مشخص کنید آیا بازیکننده داخل حجم اقیانوس قرار دارد؟ آیا داخل کشتی است؟ آیا کشتی ممکن است غرق شود؟ جواب به این سؤال که «آیا بازیکننده داخل آب است؟» در بازی Subnautica به یک چالش اساسی تبدیل شد.»
روایت یک داستان منسجم
یکی دیگر از المانهای بازیسازی که دستکم گرفته میشود، قصهگویی است. اینکه نویسندهها و طراحان داستان بازی از چه شیوههایی برای روایت داستان استفاده کردهاند، خود یک مقاله دیگر است؛ اما ساده بگوییم که نوشتن داستان یک بازی، تنها به نگارش چند دیالوگ خلاصه نمیشود.«آرونه بری» (Arone Bray) از طراحهای داستان در استودیو بایوور (BioWare)، در مورد چالشهای جالبی هنگام ساخت بازی مانند مس افکت صحبت کرده و اینکه چطور انتخابها، روی داستان کلی تأثیر میگذارند. او باور دارد که گنجاندن قابلیت انتخاب در داستان، باعث میشود تا طراح به تمامی عواقب متمرکز شود و نتیجهی انتخاب گزینهها را طراحی کند. این روند چندان پیچیدهای نیست؛ اما همین گاهی اوقات به چالش دشواری برای یک توسعهدهنده تبدیل میشود.
او برای روشن شدن مسئله، مثالی از ساخت اولین شماره از بازی مس افکت مطرح کرده که چطور تصمیمهای گرفته شده در قسمت اول مجموعه، میتواند روی بازی مس افکت ۳ تأثیر بگذارد. اگر مس افکت را بازی کرده باشید، میدانید که با شخصیتهایی مانند «تالی»، «سیتادل» و «گاروس» مواجه میشوید و «تالی» نیز بعدها به تیم اضافه میشود. در صورتی که یکی از شخصیتها به تیم اضافه نشود، بعدها یک گزینه پیدا میشود که با فعال کردن آن، کل تیم گرد هم میآید؛ اما تعداد قلیلی از بازیکنان از اضافه شدن فرد سوم به تیم خودداری کردهاند و دست به چنین انتخاب عجیبی زدهاند. افرادی که این گزینه را انتخاب کردهاند، قطعاً با باگی روبهرو میشوند که کل بازی را به هم میریزد، خوشبختانه توسعهدهندگان قبل از آنکه اتفاق جدی بیفتد، باگ را پیدا میکنند؛ اما یکی از باگها از دستشان در میرود.
اگر یادتان باشد، گزینهای وجود داشت که «تالی» را از تیم کنار میگذاشت و دقیقاً قبل از مرحلهی آخر، تالی به یکباره ظاهر میشود و انگار که مانند زامبیها از مرگ بازگشته باشد! احتمال رخداد چنین اتفاقی بسیار پایین است و فرد باید در مس افکت ۲ با تالی ارتباط برقرار کند و سپس رابطه را تا شمارهی سوم ادامه دهد و در آخر شاهد مرگش باشد. جالب است که توسعهدهندگان این رخنه را در داستان پیدا کردهاند، اما نسخهی نهایی با همان باگ عجیب منتشر شده است.
یکی دیگر از مشکلات، مربوط به بازی الدر اسکرولز آنلاین میشود. مأموریتهای بازی به نحوی طراحی شدهاند که امکان تغییر دنیای بازی وجود دارد. برای نمونه در صورتی که روستایی آتش گرفته باشد، بازیکننده میتواند به کمک روستاییها برود و آنها را نجات دهد. در این حالت نیاز است که دو روستا توسط توسعهدهندگان ساخته شود، نسخهای که کاملاً آتش گرفته و از بین رفته و نسخهای که آتش چندان تأثیری روی آن نداشته است. بتسدا بازی را تست میکند و همهچیز به خوبی پیش میرود؛ اما انتشار بازی نشان داد که طراحی بازی از آنچه توسعهدهندگان فکر میکردند، سختتر است.
هنگامی که بازیکنان به سمت روستا حرکت میکردند، مشکلات مانند مور و ملخ پیدا شدند و جالب است که هیچ توسعهدهندهای فکر آنها را نکرده بود. برای نمونه ممکن بود یکی از اعضای گروه، این مأموریت را انجام داده باشد و دیگری هنوز به آن سطح نرسیده باشد، خواهید دید که تعدادی از بازیکنان به یکباره وسط بازی غیب میشوند، زیرا که آنها باید به صورت فیزیکی در مکان دیگری باشند و قادر به شرکت در مأموریت جدید نیستند. مشکل جایی خود را نشان داد که تمامی مأموریتها به صورت مشابه طراحی شده بودند و در نتیجه ذهنیت بازیکنان از اینکه میتوانند دنیای بازی را تغییر دهند به این مشکل متمرکز شد که «دوستان من کجا هستند؟»
تیم توسعهدهندگان مجبور شدهاند تا تمامی مراحلی که با این تکنیک طراحی شده بود را اصلاح کنند و ساختار آن را دوباره بچینند. جالب است که هنوز چند عدد از آنها در بازی باقی مانده و بیشتر مربوط به مکانهایی هستند که هنوز بازیکن توانایی ایجاد گروه را ندارد. حل چنین مشکل به ظاهر سادهای، بیش از یک سال برای بتسدا طول کشید و این نشان میدهد که ساخت بازی به هیچ وجه ساده نیست.
این تنها «انتخاب» روند داستان نیست که باعث ایجاد مشکل میشوند، تولیدکننده استودیو Harebrained Schemes به نام «جیسی لاو» باور دارد که تبدیل متن داستان به بازی با وجود بخشهای مختلف مانند رابط کاربری، دسترسیپذیری و بومیسازی، کار دشواری است. او در ادامه، ایجاد ارتباط میان تیم داستان و طراحی بازی را مشکلی اساسی خوانده و باید همکاری بسیار نزدیکی میان اعضای دو تیم انجام شود تا مبادا داستان از روند اصلی خارج شود یا طراحی بازی به داستان صدمه بزند. وی میگوید:
«هنگامی که روی بازی بتلتک کار میکردم، فونت استفاده شده برای زبان روسی دارای کاراکترهایی بزرگتر از لاتین بود و همین کافی بود تا جعبهی های متن را به هم بریزد و در آخر هم دیدیم که متن روسی، قابلیت نمایش در رابط کاربری را نداشت و فهمیدیم که فونت استفاده شده، نسبت به فونت انگلیسی به دلایل عجیبی، دارای کاراکترهای کشیدهتر بود. هنگامی که روی بومیسازی بازیها در شرکت ایکسباکس کار میکردم، یک گزینه برای کنسول وجود داشت که کاربران را دعوت به بازی با دوستانشان میکرد و به این شکل بود: «با دوستانتان ارتباط برقرار کنید» این جمله در لهستانی اینطور ترجمه شد: «همراه دوستانتان از سوسیالیسم حمایت کنید» که خوشبختانه سریع متوجه قضیه شدیم.»
افرادی زیادی با بومیسازی بازیها و ترجمهی داستان به زبانهای مختلف مشکل داشتهاند و ترجمهی یک بازی را بسیار پیچیده خواندهاند. «جو میرابلو» از کارگردانهای استودیو Terrible Posture Games باور دارد که زبان آلمانی، بزرگترین چالش برای یک توسعه دهنده است و واژههایی در این زبان وجود دارند که متشکل از ۱۰ تا ۲۰ حرف هستند. جالب است که آنها یک توسعهدهنده اهل آلمان در تیمشان داشتهاند و حتی وی نیز از ترجمه بازی به زبان آلمانی خودداری کرده است. گنجاندن تمام حروف در یک خط کار به ظاهر سادهای است؛ اما در واقع پیچیده و دشوار است. البته استراتژیهایی برای ترجمه بازی و فیلم سینمایی توسط افراد مشهوری مانند آنتونیونی ارائه شده و صحیح نیست که تمامی متن، به صورت واژه به واژه به زمان مقصد ترجمه شود. خواهید دید که کار سادهای مانند ترجمه، میتواند کل داستان را به هم بریزد و حس و حال آن را تغییر دهد.
مجاب کردن بازیکن به انجام کار
یکی از کابوسهای توسعهدهندگان زمانی پیدا میشود که روایت داستان با طراحی بازی گره میخورد و توسعهدهنده مجبور است، بازیکن را مجاب کند تا کار به خصوصی را برای پیشرفت در بازی انجام دهد. برای این کار لازم است سرنخهایی در محیط قرار داده شود و یک سیستم پیچیده برای آن طراحی شوند. «کوین زون» نویسنده و کارگردان استودیوی Young Horses در این مورد میگوید: «گنجاندن درست سرنخها بسیار دشوار است. نمیتوانید به بازیکننده بگویید که این کار را انجام بده، بلکه باید افکار آنها را به نقطهای منعطف کنید. به این منظور لازم است تا شیوههای مختلفی را امتحان کنید و آنچه در تابلوها و روی صفحهنمایش میدهید نیز باید بسیار دقیق باشد. دیدهایم که تعدادی از واژههای اشتباه استفاده کردهاند و باعث منحرف شدن بازیکننده شدهاند و فرد را مجبور کردهاند تا دو برابر بیشتر برای پیشرفت در بازی تلاش کند»
الکساندر هورن، طراح داستان در استودیو Impulse که قبلاً روی بازی Kingdoms of Amalur کار کرده، طراحی نکات و آموزشهای حین بازی را کار دشواری میداند: «دو مرحله اول بازی Kingdoms of Amalur حالت آموزشی دارد و بازیکننده باید یک شمشیر را از فرد مردهای به سرقت میبرد تا مکانیسم غارت (Loot) را یاد بگیرد. دوستم که بازی را تست میکرد، برای ده دقیقه در آن اتاق گیر افتاد و نمیتوانست شمشیر را پیدا کند. تماشای آن صحنه واقعاً اعصاب خردکن بود، زیرا که میخواستم داد بزنم که شمشیر همانجا جلوی چشمت است. بعدها مجبور شدیم شمشیر را داخل در بگذاریم تا وقتی بازیکن، شمشیر را غارت میکرد، بتواند از اتاق خارج شود.»
آزادی عمل
آزادی عمل یکی از ویژگیهای مثبت هنگام بررسی و طراحی بازی به حساب میآید؛ اما اینکه بگذارید بازیکن هر کاری که دلش میخواهد را انجام دهد، آنگاه انواع و اقسام مشکلات نمایان میشوند. کارگردان بازی ماینکرافت دانجنز از پیچیدگی انجام چنین کاری میگوید و اینکه کدنویسی کار سادهای مانند حمله به حریف، به یک کابوس وحشتناک تبدیل شده است: «ایدهآل آن است که با کلیک کردن به دشمن حمله کنید. در پشت صحنه، انجام چنین کاری ساده نیست و باید تمامی احتمالات موجود را در نظر گرفت و در آخر محاسبات بسیار زیادی انجام داد. خب شما روی دشمن کلیک کردهاید، ممکن است یک آیتم دقیقاً همانجا باشد و آیا کلیک شما به معنی برداشتن آیتم بوده یا حمله به حریف؟ اصلاً در فاصلهای هستید که به دشمن حمله کنید؟ اصلاً منظور شما چه بوده؟»
تیم توسعهدهندگان برای کشف دلیل اصلی کلیک، لایههای مختلفی را استفاده کرده تا تمامی احتمالات پیشبینی شوند و این کار بسیار زمانبری است. «سرگی موهوف» طراح گیم پلی بازی کنترل در مورد سیستم تیراندازی و کار با تفنگ میگوید: «آیا اجازه داریم تا فواصل دور را مورد هدف قرار دهیم و در عین حال هدفی در دو قدمی را هم از پا درآوریم؟ اگر هر دو را میخواهیم، آنگاه باید بینیم چطور باید دوربین را حرکت دهیم، آیا تغییر عمق میدان، باعث جابهجایی میان دشمنان دور و نزدیک میشود؟ این روند برای تفنگهای دیگر چگونه است؟ انیمیشن باید چگونه باشد؟ در حالت سوم شخص، گلوله از تفنگ بیرون میآید یا از وسط صفحه؟ اگر از تفنگ بیرون میآید که باید محیط را از نمای دیگری نشان دهیم در این حالی است که در کنترل، شما همیشه از وسط تصویر شلیک میکنید و تازه تغییر تفنگ از دست چپ به دست راست و بلعکس را هم در نظر بگیرید، اینجا بود که ما یک باگ اساسی پیدا کردیم»
در این حالت بازیکننده با خودش میگوید که حل چنین مشکلی بسیار ساده است؛ اما واقعیت آن است که برای حل مشکل، باید یک بازی جدید ساخته شود! تازه فکرش را بکنید که هنوز هیچ گلولهای هم شلیک نشده و ما مراحل قبل از شلیک را بررسی میکنیم. اینجاست که میبینید باگ و مشکلات اساسی پیدا میشوند. کارگردان بازی Sifu از آثار مورد انتظار کنسول پلیاستیشن ۵ که قبلاً روی Absolver کار کرده است، در مورد قابلیت پریدن صحبت کرده و اینکه بسیاری از طرفداران، درخواست افزودن آن را به بازی داشتند. این باعث شده تا تیم توسعهدهندگان حسابی به درخواست طرفداران بخندند: «چنین درخواستهایی میتوانند تمام سیستم مبارزه را به هم بریزند و عملاً ساختار دنیای خلق شده را تخریب کنند. بازیکن انتظار دارد که ویژگی در آپدیت بعدی اضافه شود، این در حالی است که توسعهدهنده برای افزودن چنین ویژگی، نیاز به ساخت یک بازی کاملا جدید دارد.»
ذخیره بازی
تعداد دیگر از توسعهدهندگان در مورد یکی از مشکلات کلاسیک به نام ذخیره بازی، چکپوینت و بارگذاری بازی صحبت کردهاند. از نظر طراحی بازی، باید به مسائل مخفی فکر شود که بعدها مشکلزا میشوند، برای نمونه: امکان استفاده از چند فایل ذخیره وجود دارد؟ آیا بازیکن اجازه دارد تا فایل ذخیره را تغییر دهد؟ چه رابط کاربری برای آن باید طراحی شود؟ سیستم ذخیره دستی استفاده یا خودکار؟ از نظر برنامه نویس، سؤالات دیگری باید پاسخ داده شود. برای مثال: کدام اطلاعات از بازی باید ذخیره شوند؟ آیا مکان اشیاء موجود هم باید ذخیره شوند؟ چه کارهایی هنگام اجرای فایل ذخیره باید انجام شود؟
خواهید دید که باگهای بسیار عجیبی میتواند از همین فایل ذخیره ناشی شود و حتی یکی از توسعهدهندگان از تجربهی عجیب خود میگوید که ذخیرهی بازی هنگام باسفایت، باعث شده تا در پشتی قفل شود و بازیکننده دوباره در همان اتاق قبلی زنده شود. یکی از توسعهدهندگان شرکت Octosoft در این مورد میگوید: «هیچکس باور نمیکند که زنده کردن یک شخصیت مرده و بازگردانی آن به جای قبلی، چقدر کار سختی است. باید کارهای زیادی را انجام دهید تا همهچیز به حالت اول خود بازگردد. همین یکی از دلایلی است که بازیهای اولیه و کلاسیک قابلیت ذخیره را نداشتند. برای نمونه اجرای دوباره یک بازی، به معنی پاک شدن تمامی امتیازهای شما بود و پس از آن بود که سر و کله بازی زلدا پیدا شد و قابلیت ذخیره بازی را ارائه داد.»
مدیر کنترل کیفیت شرکت رمدی به نام «آرتو سومین» در مورد مشکل ذخیره بازی اظهار نظر کرده و خاطرهای از زمان توسعه بازی کنترل تعریف کرده است. او میگوید که پیچیدگی سیستم ذخیره بازی به حدی بوده که حتی توسعهدهندگان نیز نمیتوانستند آن را برای وی شرح دهند و به جای آن، به وی گفتهاند که چطور ممکن است سیستم ذخیره بازی تخریب شود: «پس از تکمیل مرحله Astral Maze و بازگشت به طبقهی پژوهشی ساختمان، دیدیم که دیوارها بدون هیچ دلیلی حرکت میکنند. ما مجبور شدیم تمامی بخشهای بازی را از طراحی مراحل تا برنامهنویسی موتور بازی را بررسی کنیم. حتی سعی کردیم تا باگ را به مدلهای دیگر بازسازی کنیم و جالب بود که تمام تیمها میگفتند تقصیر ما نیست! ما آنقدر کد اصلی بازی را بررسی کردیم تا اینکه در آخر باگ را پیدا کردیم. مشکل از آنجا بود که تمامی فایلهای ذخیره به طور خودکار به کدهای بخش «پژوهش» در نقشه انتقال پیدا میکرد و از آنجایی که بازی به بزرگی و کوچکی حروف حساس بود، نتوانسته بود محیط اطراف بازیکن را تشخیص دهد. حال میبینید که ذخیره یک بازی چقدر پیچیده است.»
بازی گروهی
طراحی بخش چند نفره چه به صورت آنلاین و چه به صورت آفلاین و با شبکه، یکی از سختترین بخشهای طراحی بازی است. مدیرعامل استودیوی Nine Dots باور دارد که قابلیت «تقسیم صفحه نمایش» برای بازی کردن چند نفره باعث ایجاد مشکلات پیچیدهای شود: «اگر اجازه دهید بازیکنان به صورت تقسیم صفحه بازی کنند، خب با منوهای اصلی چه کار میکنید؟ آیا یکی میتواند بازی را نگه دارد و دیگری به روند قبلی ادامه دهد؟ اصلاً روند پیشرفت داستان و جوایز را چطور طراحی میکنید؟ آیا بازیکن را مجبور میکنید تا همیشه با دیگری بازی کند یا اینکه فرد دیگری به طور آنی وارد و خارج شود؟ هنگامی که کار روی بازی Outward را شروع کردیم، هیچ مثالی برای یک بازی جهان باز نقشآفرینی با قابلیت نصف کردن صفحه نداشتیم و مجبور شدیم تا راهحلهای تازهای را پیدا کنیم و مشخص بود که تمامی بازیکنان از راهحل ما راضی نخواهند بود. در آخر داستانها و خاطراتی را از دوستان و خواهر و برادرهایی شنیدیم که خستگی طراحی این سیستم را از تنمان بیرون کرد.»
در سوی دیگر، مشکل اتصال به سرور نیز بسیار جدی است. بسیاری فکر میکنند که یک سرور میتواند X نفر را پشتیبانی کند و Y نفر هم میخواهند بازی کنند، اگر بیاییم این دو رقم را ضرب در هم کنیم، تعداد سرورها به دست میآید و مشکل حل میشود، درست است؟ جواب این است که: خیر! «کریس چوپوسکی» از برنامهنویسهای استودیو Phoenix Labs، به بررسی مشکل اتصال به سرور پرداخته و اینکه چرا همه فکر میکنند که با فشردن یک دکمه، تمامی مشکلات حل میشوند: «تمامی بازیهای آنلاین، روز اول با مشکل مواجه میشوند، همه فریاد میزنند که سرور اضافه کنید و جالب است که تعداد سرورها هیچگاه مشکل نیست. حدود چهار لایه دیگر، علاوه بر تعداد سرور وجود دارند که روی نتیجهی نهایی دخیل هستند.»
وی در ادامه این لایهها را تشریح کرده و توضیحات بیشتری را ارائه کرده است. برای نمونه میزان اطلاعاتی که هر سرور میتواند نگه دارد، مشکلات ارتباطی میان سرورها و همچنین مشکلات ایجاد شده توسط بازیکنان نیز بماند. برای نمونه سرویس ورود به بازی، میتواند هر دقیقه به ۱۰۰ هزار درخواست پاسخ دهد، اما اگر اطلاعات افرادی که وارد بازی میشوند، همگی روی یک سرور قرار داشته باشد چه؟ آنگاه اگر دیتابیس بخواهد اطلاعاتش را بکاپ بگیرد چه اتفاقی میافتد؟
برای نمونه بازیای وجود دارد که هنگام خروج از نبرد به منو برمیگردد، اما هر بار اطلاعات روی منو باید از یک سرویس جداگانه دریافت شود که خب آن هم دارای یک دیتابیس متفاوت است و حال فکرش را بکنید که بازیکنان به صورت عمدی، این دکمه را فشار میدهند تا به منو بازگردند و در این حالت، ۳۰ برابر فشار ایجاد میشود و تمام این فشار روی شبکه وارد میشود. «اولی فریمن» از مهندسان استودیو ۱۰۴۷ Game در مورد صفبندی برای ورود به بازی میگوید: «عملکرد خاصی برای متوازن کردن زمان معطل ماندن در صف بر اساس پینگ وجود دارد. بهتر نیست ۱۰ دقیقه منتظر بمانید تا یک بازی کاملاً متعادل روی سروری نزدیک به منطقهی شما تجربه کنید، یا اینکه یک دقیقه منتظر باشید و تجربهای بد داشته باشید؟ بهتر نیست که یک بازی متعادل با پینگ ۱۰۰ را تجربه کنید تا اینکه یک بازی نامتعادل با پینگ ۵۰؟ مشکل اینجاست که جواب درستی برای این سؤال وجود ندارد؛ اما جوابهای اشتباه زیادی وجود دارند و این چیزی است که ما به صورت مداوم در حال تغییر و بهبود آن هستیم.»
منوها و رابط کاربری
در ایستگاه بعدی به چالشهای طراحی منو و رابط کاربری بازیها میرسیم. کارگردان سابق استودیوی Q-Games به نام «لیام ادواردز»، طراحی منوها را یک کابوس توصیف کرده و میگوید: «هنگام طراحی منو باید فاکتورهای بسیار زیادی را در نظر داشته باشید. این چیزی است که بازیکن اولین بار میبیند و بنابراین اولین برداشت از نظر هنری و لحن اهمیت دارد. همچنین این اولین بار است که فرد واژههای بازی شما را میخواند و بخشهای مختلف آن را جستجو میکند. در صورتی که از واژههایی مانند «شروع بازی» و «تنظیمات» استفاده نکنید، بازیکنان نمیداند که چطور آن را شروع کنند. اگر کنترلهای را تغییر دهید هم این اتفاق میافتد، همین تغییرات کوچک است که باعث میشود بازیکننده مجاب به ادامه بازی شود.»
Tanya Short از توسعهدهندگان شرکت Kitfox Games، مشکل طراحی منوها را بهتر توضیح میدهد. او باور دارد که ساخت منو تنظیمات، حتی در اولین نسخههای بازی نیز کار سختی است و افزودن المانهایی مانند قابلیت دسترسیپذیری یا تنظیمات گرافیکی، کار بسیار دشواری است. توسعهدهندگان دیگری از طراحی رابط کاربری به عنوان کار بسیار دشواری نامبردهاند که در ظاهر بسیار ساده است. برای نمونه به دکمهها فکر کنید، خواهید دید که باید پشت زمینهی آنها، آیکون، رنگ و سایه مشخص شود. فردی باید تمامی این طرحها را انجام دهد و سپس تغییرات به موتور بازی منتقل شود و رابط کاربری نهایی شود.
یکی از منوهای پیچیده که در بسیار از بازیها یافت میشود، فهرست دارایی و آیتمهاست و تعامل با این منو روی روند بازی تأثیر بسیار زیادی دارد. «فورد هورگان» از طراحان ارشد استودیو Firesprite در مورد چالشهای ایجاد یک فهرست دارایی کارا میگوید: «انداختن یک آیتم در دنیای بازی میتواند بسیار پیچیده باشد. ممکن است اصلاً بازی امکان ذخیره در بیرون از محیط مشخص را نداشته باشد و خب نمیتوانید به سادگی آیتمها را دور بیندازید و سپس انتظار داشته باشید که آنها در مکان ذخیره میشوند. اگر آن آیتم برای انجام یک مرحله ضروری باشد چه؟ آیا آیتمهایی که دور ریخته میشوند، دارای فیزیک به خصوصی هستند؟ آیا میتوان از آنها استفاده کرد تا یک پلکان یا ساختمان ساخت؟ اگر این رفتاری نیست که از بازی انتظار داریم، تا چه اندازه باید بازیکننده را محدود کنیم تا به بازی ضربهای وارد نشود؟ حال ظاهر اصلی این آیتمها را در نظر بگیرید، آیا ظاهر آنها همانند روز اولشان است؟ آنگاه باید تمامی بافتهای طراحی شده بارگذاری شوند و خب میتوانیم به سادگی تمام آیتمها را مانند هم طراحی کنیم، در این حالت نیز چطور آنها را از همدیگر تشخیص دهیم؟»
جمعبندی
توسعهدهندگان زیادی در مورد چالشهای ساخت یک بازی و اینکه توسعهی یک اثر چه اندازه میتواند دشوار باشد، صحبت کردند و تمام گفتهها را شنیدیم. مطمئنم بسیاری از شما باورتان نمیشد که طراحی چنین اشیاء و ویژگیهای سادهای به این اندازه دشوار باشد. در ادامه به سه مشکل دیگر خواهیم پرداخت که به نظرم حسن ختامی برای این مطلب خواهد بود و بالاخره شما را متقاعد خواهد کرد که توسعه یک بازی، کار بسیار دشوار و طاقتفرسایی است.
اولین مشکل از سوی «جانمن نوردهاگن» از استودیو Dim Bulb Games بیان شده و آن هم این سؤال ساده بود: پس از آنکه بازیکننده یک دکمه را فشار میدهد، چه اتفاقی رخ میدهد؟ وی در جواب میگوید:
«مسئلهای که ساعتها مرا به چالش کشید، ورودی بود که بازیکن به بازی میدهد. ساده به نظر میرسد نه؟ برای نمونه شما دکمه اسپیس را فشار میدهید و شخصیت میپرد، اما پس از آن است که حالتهای خاص از راه میرسند. خب اگر بازیکن سینهخیز راه برود چه، اگر دکمه اسپیس برای فعال شدن آیتمهای اطراف استفاده شود چه؟ اگر بازیکن از دسته به جای کیبورد استفاده کند، چه اتفاقی میافتد؟ هنگامی که بازی متوقف میشود، چه اتفاقی میافتد؟ خدا به دادتان برسد که اگر بازی شما آنلاین است و نیاز به ارسال اطلاعات به یک سرور وجود دارد! مشخص است که برای هر حرکت سادهای داخل بازی، یک سیستم وجود دارد که باید تمامی احتمالات را بررسی کند»
دومین چالش از سوی «میچل دایر» نویسنده بازیهای شوالیههای گاتهام و Star Wars: Squadrons مطرح شده که عملاً دشوار بودن بازیسازی را به بهترین وجه نشان میدهد:
«تصور کنید که یک صحنه را برای اثری تراز اول مینویسید و دو شخصیت با همدیگر ملاقات میکنند و اطلاعاتی را رد و بدل میکنند. نسخهی خستهکننده این خواهد بود که دو شخصیت آنجا بایستند و با یکدیگر صحبت کند، تازه ساخت چنین چیزی هم گران و بسیار دشوار است، زیرا که باید تمامی انیمیشنهای صورت طراحی شوند تا شخصیتها مانند ربات به نظر نرسند. حال بیایید این صحنه را اندکی جذاب کنیم و شخصیتها را داخل یک کافه قرار دهیم. آنها با یکدیگر ملاقات میکنند و در حین صحبت، قهوه مینوشند. به عنوان یک نویسنده، باید بدانید که میزانسن کاملاً جدیدی با صندلی و میز و کافهچی پیش رو دارید. حال بافتهای تازهای برای دیوارها و دستگاههای قهوه ساز و… باید طراحی شوند. اینجاست که تیم طراحی به شما میگوید: خدای من آنها واقعاً میخواهند قهوه بنوشند؟ ما که شبیهساز مایعات در این بازی نداریم! خب اگر فکر میکردید که قهوهچی برای شما قهوه میریزد و بعد فنجان را بر میدارید و آن را مینوشید، باید بگوییم که بیخیال اینها شوید. نهایتش بتوانید رد قهوه روی میز یا کوسنهای پاره کافیشاپ را نشان دهد.»
دیدید که چنین تصمیمگیری سادهای که دو شخصیت داخل کافه بنشیند و قهوه بنوشند، چطور به یک کابوس برای طراح بازی تبدیل میشود. گاهی اوقات هزینهی خرید یک کافه از بازسازی آن داخل بازی بیشتر میشوند و تازه اگر بتوانید یک انیماتور حرفهای هم پیدا کنید که چنین صحنههایی را واقعی از آب درآورد. خواهید دید که توسعه بازی در واقعیت بسیار سخت است و نمیتوان آن را با هیچ صنعت دیگری مانند سینما مقایسه کرد. تمام تصمیماتی که بازیکن هنگام تجربهی بازی میگیرد، باید پیشبینی شود و تازه شما هنوز کاری انجام ندادهاید و هنگامی که شروع به کار میکنید، چالشهای بعدی از راه میرسند و خواهید دید که کار سادهای مانند نوشیدن قهوه، به زحمت طراحیاش نمیارزد.
آخرین چالش نیز توسط «گابریلا سالواتوره» از موسسان شرکت Beans بیان شده که تجربهی زیادی از توسعه بازی به دست آورده و به خوبی میداند، ساخت یک اثر هنری چه اندازه کار دشواری است. چالشهای بزرگی هنگام بازیسازی وجود دارد، اما اینکه در ظاهر ساده باشد و در واقعیت بسیار دشوار، گزینههای کمتری بهجا میمانند که تقریباً تمامی آنها را در این مطلب بررسی کردیم. به نظر گابریلا، حفظ سرگرمکننده بودن بازی، دشوارترین چالش یک بازیساز است: «سخت است بازیای بسازید که عملکرد مناسبی داشته باشد، حال فکر کنید که این بازی باید سرگرمکننده هم باشد! وقتی بازی حس خوبی به شما میدهد، دلیلش آن است که هزاران تصمیم کوچک گرفته شده تا یک تجربهی پویا و یکسان برای مخاطب ایجاد شود. وقتی در این مورد با دوستانم بحث میکنم، میگویم که باید مکانیسمی سرگرمکننده مانند بازی ماریو بسازیم، پریدن در بازی ماریو، بسیار سرگرم کننده است.»
جالب است بدانید که بازی سوپر ماریو حدود ۴۶ کیلوبایت حجم داشت و توسعهدهندگان توانسته بودند یکی از جذابترین بازیهای تاریخ را بسازند که تمامی سیستمهای آن کاملاً سرگرم کننده و بینقص بود. وی در ادامه میگوید:
«سؤال این است که طراحی مراحل چه اندازه روی بعد سرگرمی بازی تأثیر میگذارد؟ یا اینکه ماکسیمم فاصله پرش در بازی ماریو، چه اندازه روی کیفیت پرش تأثیر میگذارد؟ حس و حال بازی چه اندازه روی سرگرم کننده بودن آن تأثیر میگذارد؟ کنترلها باید چطور باشند؟ آیا فشردن دکمه A بهاندازه فشردن دکمه B رضایتبخش است؟ آیا فشردن بیش از چند ثانیه یک دکمه، تأثیر زیادی روی حس و حال مخاطب میگذارد؟ اصلاً شخصیت چقدر باید در هوا بماند؟ هنگام پرش باید چه صدایی پخش شود؟ اگر هنگام پرش در هوا، بازی را متوقف کنید چه اتفاقی میافتد؟ اگر شما یک بازی میسازید و یکی از مکانیسمهای، پرش است؛ این سؤالاتی است که باید به آنها پاسخ دهید. تمامی مکانیسمها دارای فهرست سؤالاتی به این شکل هستند و اگر سیستم به درستی کار کند، آنگاه بازیکن نباید تمام این سؤالات را متوجه شود و تنها باید تجربهای رضایتبخش از یک پرش مناسب دریافت کند.»
با پرداختن به آخرین چالش، به پایان مقاله رسیدیم و دیدیم که المانها، ویژگیها و اشیاء بسیار جزئی میتوانند روی فرایند توسعه بازی تأثیر بگذارند. نمونههایی که بیان شد، تنها بخش از مشکلات اساسی هنگام توسعه بازی است.
بیشتر این مشکلات، ناشی از شبیهسازی و بازسازی محیط واقعی توسط ماشین هستند و این در حالی است که هنگام ساخت یک فیلم سینمایی، شما در واقعیت این کار را انجام میدهید و دیگر لازم نیست نگران آن باشید که مبادا در ورودی منزل، به جای باز شدن، پرواز کند؛ یا اینکه آسانسور هنگام فشردن دکمه، غیب شود. این مشکلاتی است که مدیوم بازی به همراه دارد و در طی سالهای اخیر نیز تلاش زیادی برای سادهسازی ساخت بازیها انجام شده؛ اما بهتر است دیدمان را نسبت به بازیهای تراز اول و حتی مستقل تغییر دهیم و اگر بازی مشکلات اساسی دارد، آن را به حساب کمکاری و بیتوجهی قرار ندید، دیدید که تنها برطرف کردن یک مشکل کوچک، میتواند منجر به تولید یک بازی کاملاً جدید شود. نظر شما چیست؟ کدام المان بازیسازی از نظر شما ساده بود و حال میدانید که توسعه آن اصلاً کار سادهای نیست؟
منبع: IGN
سوالی که از شما داشتم اینه که برای شروع بازی سازی چه نوع سیستمی رو پیشنهاد میدید که هم مقرون به صرفه باشه و هم بتونه تا حدودی قابل قبول باشه
خیلی مقاله جالبی بود، با اینکه تا حالا تجربه مستقیم بازی سازی نداشتم اما تجربه هایی نزدیک به اون رو داشتم و میتونستم تک تک این مشکلات و چالش هارو درک کنم.
ناراحت کننده ترین بخش اینجاست که بازیساز مستقل ایرانی بدون حمایت از هیچ نهادی باید با این چنین مشکلاتی رو به رو بشه تا با زحمت های فراوان بازی رو ارائه بده که متاسفانه توسط برخی بازیکن ها که هیچ چیز از سختی بازیسازی نمیدونن مورد تمسخر قرار بگیره