بازی را سریع منتشر کنید

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

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

با توجه به این موضوع یک سری اهداف در نظر گرفتیم: این که بفهمیم آیا می‌توانیم یک بازی نسبتا پولیش شده را در طول ۲ ماه عرضه کنیم. بفهمیم انجام این کار با توجه به این مقیاس و برای عرضه در پلت فرم iOS در سال ۲۰۱۸ چقدر سخت خواهد بود. هم چنین با اصول بازاریابی، پرداخت درون برنامه‌ای، استراتژی های مختلف شناخته شدن شرکت و دیگر مسائل عرضه روی پلت های مختلف آشنا بشیم.

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

شرایط

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

مصالحه

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

مکانیک های خاص را به دور بریزید

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

یک گرافیک هنری ساده را انتخاب کنید و به آن بچسبید

با این که اوایل دوست داشتیم یک گرافیک فولکلور سنتی به نسبت عروسک های روسی بسازیم اما متوجه شدیم چنین کاری در ۲ ماه امکان پذیر نیست. در عوض تصمیم گرفتیم همه چیز را ساده کنیم تا بتوانیم asset های گرافیکی را هر چه زودتر تولید کنیم. البته این بدین معنی نبود که در کل زیبایی فولکلور را کنار بگذاریم اما رویکرد را تغییر دادیم. برای محدود کردن وسعت گرافیکی کار های زیر را انجام دادیم:

• یک قالب کلی برای عروسک ها در فتوشاپ طراحی کردیم و برای هر عروسک از آن استفاده کردیم.
• یک prefab کلی از عروسک ها با انیمیشن های آماده باز و بسته شدن و پرتاب شدن ساختیم. بدین صورت برای اجرای هر عروسک فقط کافی بود تصاویر ( sprite) های جدید را جایگزین کنیم.
• حالت های صورت عروسک ها را به سه مدل خنثی، خوشحال و عصبانی محدود کردیم. مگر این که یک عروسک خاص انیمیشن مجزایی نیاز داشته باشد.
• برای تغییر بین انیمیشن ها اگر نیاز نبود حالت گذار (transition) طراحی نکردیم.
• ازیک فونت مجانی متناسب با گرافیک بازی استفاده کردیم. هم‌چنین دارایی‌های رابط کاربری (asset) را تا جای ممکن دوباره استفاده کردیم.
• یک پالت رنگی محدود را انتخاب کردیم و سعی کردیم جزییات گرافیکی را تا جای ممکن محدود نگه داریم.

تمایلات کمال گرا بودن خودتان را کنار بگذارید

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

محتوا را به حداقل میزان ممکن برسانید

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

در سریع‌ترین زمان ممکن یک سیستم کارا بسازید

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

مقابل غرایز اولیه‌تان در طراحی بایستید

از تمام مصالحه‌هایی که انجام دادیم این مورد سخت ترین بود. ما تقریبا مطمئن بودیم که نیاز به یک مکانیک اشتباه کوچک ( near miss) داریم. به این معنی که بازیکن بتواند با یک اشتباه کوچک همچنان بازی را ادامه دهد. بازی های صفر و یکی به احتمال زیاد خسته کننده می‌شوند. برای غلبه بر این موضوع راه های مختلفی را امتحان کردیم و سعی کردیم سیستمی بسازیم که برد و باخت قطعی نباشد. اما نزدیک به دو هفته در پیاده سازی چنین مکانیکی گیر کردیم. بعد از آن مشخص شد که طراحی و پیاده سازی چنین سیستمی زمان زیادی می‌برد. هم‌چنین افزودن آن ارزش زیادی به اهداف مارکتینگ بازی ما اضافه نخواهد کرد. در نتیجه تصمیم گرفتیم « اشتباه کوچک» را حذف کنیم.

اشتباهات و درس هایی که آموختیم

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

چه کار هایی را درست انجام دادیم؟

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

برداشت‌های اصلی

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

• ما می‌توانیم یک بازی نسبتا خوب و پولیش شده را در عرض ۲ ماه روی iOS منتشر کنیم.
• راهکار فعلی ما برای رسیدن به مخاطبان بیشتر کافی نیست.
• کاور و تبلیغات رسانه‌ای جزو ملزومات اصلی بازاریابی است. مگر این که بازی شما یک ویژگی خیلی خاص ( از لحاظ گیم‌پلی یا گرافیک) داشته باشد. یا این که بسیار خوش شانس باشید.
• در بازه ۲ ماه محتوای کمی برای مارکتینگ دارید مگر این که از قبل برنامه ریزی خوبی کرده باشید و آمادگی لازم را داشته باشید. ( دفعه بعد حتما سعی می‌کنیم این کار را انجام دهیم)
• تبلیغات ویدیویی درون بازی فقط با داشتن بازیکنان زیاد امکان پذیر است. ( حداقل ۱۰۰ هزار نفر)

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

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

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