TimTim

سایت خبر خوان

چیزهای که از اولین شکستم در بازیسازی یاد گرفتم

چهارشنبه 20 شهریور 98 | 16:30 - virgool.io - 1
درس‌هایی که در هیچ کتابی به ما یاد ندادند

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

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

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


۱- نداشتن نمونه قابل بازی

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

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

امروزه تیم‌های بازیسازی، بازی اصلی را از این نمونه جدا نمیبینند. ایده بزرگی که در سر دارند بر روی همین نمونه کوچک بنا می‌شود. روش کار بدین شکل است که نمونه اولیه منتشر می‌شود و همه می‌توانند آن‌ را بازی کنند. تیم توسعه دهنده عملکرد بازی، رفتار بازیکنان و KPIها (شاخص‌های کلیدی عملکرد بازی) را در نظر گرفته و از بازیکنان بازخورد می‌گیرند؛ سپس نمونه اولیه را تصحیح می‌کنند و توسعه می‌دهند. این روش توسعه بازی روش توسعه Data driven نام دارد.


۲- کمال‌ گرایی و بلند پروازی بیش از حد

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

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

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

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


۳- مشکل در ارتباط بین تیم فنی و تیم هنری

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

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

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


۴- وجود وابستگی بسیار بین بخش‌های بازی

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

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


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

ویرگول,بازیسازی,توسعه نرم افزار,طراحی بازی,برنامه نویسی,بازی‌های رایانه‌ای,