به علیرضا پورسهولت تمام نوشته‌های

پلاسکو - گیم جم

تجربه‌ی ساخت سه بازی در گیم‌جم – بخش دوم – بازی پلاسکو

توسط | مقالات فنی | یک نظر

نزدیک به ۴۸ ساعت تجربه کار گروهی فشرده در یک فضای پویا، پرانرژی و چالشی برای من به عنوان اولین حضور در Global Game Jam، تجربه جالبی بود. علاوه بر من،  هادی و نیلوفر نیز در تیم حضور داشتند و در روز دوم رویداد، امیرحسین نیز به ما پیوست. خروجی نهایی تیم ما، بازی Selfish (که به فارسی «پلاسکو» نام گذاری شد) بود. محصول ما، یک بازی موبایل بود که شاید بتوان آن را در دسته Art Game گنجاند.

در گیم جم ۲۰۱۷، تصمیم گرفته شد تا تمام تیم‌ها از لحاظ برنامه‌نویسی از موتور بازی‌سازی کورونا استفاده کنند. از این رو من به دلیل داشتن تجربه بیشتر در کار با کورونا علاوه بر تیم خودمان، به نحوی عضو نیمه‌مشترک بقیه تیم‌ها نیز بودم و فضای کاری دو تیم دیگر را کم و بیش لمس کردم. برای همین دوست دارم علاوه بر تجربه تیم خود، به برخی نکات و اتفاقات در فضای کلی شرکت در حین رویداد نیز اشاره کنم.

آماده سازی

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

ایده‌پردازی و انتخاب موضوع

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

طراحی و مکانیک بازی

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

گرافیک – صدا

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

تجربه نو

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

روحیه تیمی

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

همیشه همه چیز خوب نیست!

اکثر اتفاقاتی که در این رویداد برای ما افتاد اتفاقات مثبتی بود و در روند کار به مشکلات زیادی نخوردیم ولی شاید بد نباشد که به چند مشکلی که با‌ آن مواجه شدیم، اشاره کنم:

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

کلام آخر

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

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

تیم توسعه پلاسکو

 


پیوندهای مرتبط

 

بهینه‌سازی کد لوآ

نکاتی برای بهینه‌سازی عملکرد کد در لوآ

توسط | مقالات فنی | ۶ نظر

لوآ۱ بخش زیادی از محبوبیت و شهرت خود را مدیون عملکرد و کارایی خود است تا جایی که خیلی از زبان‌های اسکریپت‌نویسی دیگر برای معرفی خود از عبارت “سریع و کارا مانند لوآ” استفاده می‌کنند. با این حال، کارایی یکی از المان‌های مهم برنامه‌نویسی است که هنگام کار با زبان لوآ هم باید به آن توجه کرد. « آیا عملکرد برنامه‌ی من نیاز به بهینه‌سازی دارد؟ » اولین سوالی است که ذهن برنامه‌نویس را در خصوص بهینه‌سازی عملکرد به خود مشغول می‌کند. اگر جواب این سوال مثبت باشد سوال بعدی و کلیدی که مطرح می‌شود این است : « کجای برنامه‌ی من نیاز به بهینه‌سازی عملکرد دارد؟ ». برای زبان لوآ، افراد متعددی روی بهبود عملکرد برنامه‌ها و ابزار‌های اندازه‌گیری آن تمرکز داشته‌اند و با توجه به نتایج بدست‌ آمده، نکاتی را برای بهبود عملکرد برنامه‌های نوشته شده با لوآ پیشنهاد می کنند. در این نوشته سعی دارم بخشی از این نکات را با شما به اشتراک بگذارم.

استفاده از متغیر‌های محلی

پیش‌کامپایلر۲ لوآ با توجه به داشتن ثبات‌۳های زیاد می‌تواند تمام متغیر‌های محلی۴ را در ثبات‌های خود نگه دارد. به همین دلیل، دسترسی به متغیر‌های محلی در لوآ بسیار سریع است. برای نمونه فرض کنید متغیر‌های a و b محلی هستند. یک گزاره مانند a = a + b ، دستورالعمل زیر را تولید می‌کند:

حال اگر دو متغیر سراسری۵ باشند، کد برای یک عمل جمع ساده به صورت زیر خواهد بود:

 

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

در کد بالا ،با یک تغییر ساده و استفاده از متغیر محلی برای تابع محاسبه سینوس می توان تا ۳۰ درصد سرعت اجرا را افزایش داد:
 

در هر حال ممکن است شما در کد خود به متغیر‌های سراسری نیاز داشته باشید. در این‌صورت حتماً هر جا که دیگر نیازی به آن‌ها نداشتید آن‌ها را با nil مقدار‌دهی کنید تا به زباله۶ تبدیل شوند زیرا زباله جمع‌کن۷ در زبان لوآ، متغیر‌های سراسری را به عنوان زباله نمی‌شناسد.

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

زبان لوآ برای کار با جداول۸، توابعی را پیش بینی کرده است. یکی از این توابع، تابع insert است که برای اضافه کردن المان جدید به جدول استفاده می‌شود. ابزار‌های اندازه‌گیری مختلف نشان داده‌اند که استفاده دستورات کوتاه درون خطی در تعداد بالا معمولا عملکرد بهتری نسبت به تابع از پیش تعیین شده برای اضافه کردن عضو به جدول دارند زیرا دستورات درون خطی معمولاً عملگرهای زبان لوآ هستند و بار زیادی را ایجاد نمی کنند. در حالی که استفاده از تابع insert در ساده ترین حالت، نیاز به دسترسی به ماژول table و سپس فراخوانی تابع insert از این ماژول و محیط آن دارد. به دو نمونه کد زیر توجه کنید:

 
 

کد دوم، عملکرد بهتر و سریعتری نسبت به کد اول دارد. لازم به ذکر است که کد بالا را می توان با استفاده از یک عملگر ساده‌تر نسبت به #، به حالت بهینه‌تری بازنویسی کرد:

 

ملاحظات در عملگر ها و توابع ریاضی

در لوآ مانند خیلی از زبان‌های دیگر، برخی عملگر‌های ریاضی سریع‌تر از عملگر‌های دیگر رفتار می‌کنند. به عنوان مثال بهتر است که از عملگر ضرب به جای تقسیم استفاده کنیم:

 

عملگر ضرب از عمگر توان هم کارا‌تر است. در توان‌های پایین می توان از ضرب استفاده کرد:

 

سخن آخر

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


۱ – Lua
۲ – Pre-Compiler
۳ – Register
۴ – Local Variables
۵ – Global Variables
۶ – Garbage
۷ – Garbage Collector
۸ – Tables
۹ – Lua Programming Gems, edited by L. H. de Figueiredo, W. Celes, R. Ierusalimschy

 

 

می‌خواهید از آخرین اخبار تاد مطلع باشید؟ ما را در تلگرام دنبال کنید