https://virgool.io/feed/@mhalizadeh بازی ساز مستقل و برنامه نویس در TeamLuckyDice. وب سایت شخصی : www.mhalizadeh.com fa 2026-06-07 15:33:23 https://files.virgool.io/upload/users/147429/avatar/Yw4qTB.png?height=120&width=120 https://virgool.io/@mhalizadeh https://virgool.io/@mhalizadeh/five-productivity-tips-for-solo-devs-b5to7uz1b0ce ساخت بازی به صورت مستقل کار بسیار دشواری است. در این مسیر رئیسی نخواهید داشت که به شما بگوید چه کاری باید انجام شود و سعی کند شما را در مسیر درستی هدایت کند. یا اکثر روزها همکاری در اطرافتان نخواهید دید تا برای عصر با هم قرار دیدن فیلم یا فوتبال بگذارید.به عبارت دیگر در اکثر روزها تنها همدمی که دارید کامپیوتر تان خواهد بود که به وسیله آن می خواهید محصولی تولید کنید که شاید ماه ها یا سال ها به طول بیانجامد. در طول این مدت باید سعی کنید در مسیر درست باقی بمانید و هر روز به بهترین شکل کار هایتان را به اتمام برسانید. همواره این احتمال می رود که در این مسیر تمرکز تان را از دست دهید و روزهای متعددی را بدون بهره وری به پایان برسانید یا حتی به طول کامل، پروژه را رها کنید.حدود 8 سال است که به تنهایی مشغول بازی سازی هستم. هرچند در واقع به طور کامل تنها نبوده ام (همیشه با طراحان صدا و موسیقی همکاری کرده ام ) اما اکثر دوران بازی سازیِ مستقل م را در خانه و به تنهایی به برنامه نویسی، طراحی بازی و پیاده سازی بخشِ هنری پرداخته ام.و در این مسیر متوجه شدم که کار کردن به تنهایی چالش های فراوانی دارد.چگونه در این مسیر متمركز باقي بمانم؟ چگونه انگیزه کافی برای ادامه کار را کسب کنم؟ چگونه در حین ساخت این بازی که حداقل دو سال زمان لازم دارد، از مسیر اصلی خارج نشوم؟ چرا باید به خودم زحمت پوشیدن لباس رسمی یا حتی شلوار بدهم ؟ آیا می توانم تمام روز را در رختخواب بمانم؟البته بايد موضوعی را اقرار كنم: قبل از اینکه به صورت مستقل کار کنم، بیش از ده سال به عنوان تهیه کننده (Producer) در صنعت AAAبازی سازی مشغول به کار بوده ام. همیشه علاقه شدیدی به مدیریت پروژه و بهره وری داشتم. من از آن دسته افراد هستم که کتاب های مدیریت پروژه را به عنوان سرگرمی مطالعه میکند. همچنین به صورت فریلنس، مشاوره و آموزشِ مدیریت پروژه انجام میدهم. من در زمینه بهره وری یک نردِ به تمام عیار هستم !این علاقه ی من به بهره وری، در دورانِ بازی سازی مستقل نیز از بین نرفت. من همواره از سایر بازی سازان و دولوپر ها می پرسم که چگونه کار میکنند و فرایندِ کاری خودم را مورد ارزیابی قرار می دهم تا بتوانم هر چه بیشتر در این زمینه پیشرفت کنم. این 5 نکته ای که در ادامه مطرح میکنم، نتیجه ی هشت سال کار، تحقیق و تجربه است:1- همواره بک لاگ (Backlog) داشته باشیدبه طور خلاصه بک لاگ همان لیست کارهایی است که باید انجام دهید. مهمترین کار در بالای این لیست و کم اهمیت ترین در پایین لیست قرار میگیرد و بسیار محتمل است که ترتیب لیست تغییر کند یا آیتمی حذف یا اضافه شود. بک لاگ در واقع نسخه ی بهتری از to-do list است.می توانید بک لاگ تان را با شیت های اکسل طراحی کنید یا از نرم افزار های مخصوص این زمینه استفاده کنید (من از Pivotal Tracker استفاده میکنم که برای یک فرد یا تیم های کوچک رایگان است)، خیلی فرقی نمیکند از چه تکنولوژی و ابزاری استفاده کنید، تنها موضوعی که اهمیت دارد این است که بتوانید کارهایتان را به لیست اضافه کنید و این امکان فراهم باشد که دائما آن را آپدیت کنید.تصویری از بک لاگ م در Pivotal Tracker موضوع مهم دیگر این است که بتوانید تعداد آیتم های بک لاگ تان را درست تخمین بزنید و محاسبه کنید. من ترجیح میدهم که کارها را تا حد ممکن کوچک در نظر بگیرم. وقتی در طول روز چندین کار را تکمیل میکنم و تیک آنها را به عنوان انجام شده میزنم، احساس خیلی خوبی دارم. اگر قرار باشد، بخش بزرگی را انجام دهم، حتما آن را به بخش های کوچکتری که به تنهایی قابل پیاده سازی هستند، تقسیم میکنم.اگر در حال پیاده سازی قسمتی هستید و ناگهان ایده ی جدیدی در مورد بازی به ذهنتان رسید، کاری که در حال انجامِ آن هستید را متوقف نکنید، بلکه آن ایده را به بک لاگ اضافه کنید. پلیر ها در توییتر درخواست بخش جدیدی کرده اند؟ آن را هم به بک لاگ اضافه کنید. باگ جدیدی پیدا کردید؟ آن را هم به بک لاگ اضافه کنید. اگر اولویت انجام کارها تغییر کرد، فقط کافی است که ترتیب آیتم ها را در لیست جا به جا کنید. بک لاگ باید مانند یک موجود زنده، دائم در حال آپدیت و تغییر باشد.اگر با چک کردنِ روزانه بک لاگ در صبح ها مشکل دارید، پیشنهاد من این است که در آخر هر روز این لیست را چک کنید، کارهای روز بعد را بررسی کنید و بگذارید وقتی به خواب میروید ناخودآگاه تان آنها رو مرور و بررسی کند. به این ترتیب وقتی از خواب بیدار می شوید، آماده ی شروع آن کارها خواهید بود.بک لاگ نقشه ی راهتان خواهد بود. به شما میگوید که کجا هستید، پیش از این کجا بوده اید و به کدام سمت می خواهید حرکت کنید. اگر همواره از آن استفاده کنید،گم نخواهید شد.2- ساعاتِ بهره وری تان را بشناسیدآیا شب زنده دارید یا سحر خیز؟ آیا بعد از پایانِ کار روزانه که به خانه برمیگردید کاملا خسته اید و نمی توانید کار دیگری انجام دهید؟ آیا وقتی هم اتاقی یا خانواده تان اطرافتان هستند نمی توانید بر روی کار تمرکز کنید؟ آیا بعد از خوردن ناهار به حالتِ کما می روید ؟!اینکه چه ساعتی بهترین زمان کار کردن تان است بسیار مهم و کلیدی است. پیدا کردن بهترین زمانِ کاری تان نیازمند آزمون و خطا و خود آگاهی بسیار زیاد است. اما هنگامی که از آن مطلع شدید، از آن مراقبت کنید و سعی کنید همواره در آن ساعات مشغول به کار شوید.به شخصه بهترین زمانِ کاری من، صبح ها است و معمولا ساعت دو تمرکزم را از دست میدهم. اما بعد از ظهر ها اگر بلافاصله بعد از خوردن نهار به کار برگردم هم می توانم مفید باشم و ادامه کارم را پیش ببرم. اما عصر یا غروب دیگر کارایی ندارم! به راحتی تمرکز م را از دست میدهم و نمیتوانم مسائل پیچیده را حل کنم. به همین دلیل همیشه سعی میکنم از صبح ها نهایت استفاده را ببرم.پیش از اینکه به صورت مستقل کار کنم، صبح ها ساعت 5 بیدار میشدم و روی پروژه های خودم کار میکردم. به این شکل قبل از شروع کار روزانه ام، حدود دو یا سه ساعت زمان داشتم تا پروژه هایم را پیش ببرم. البته چندین بار سعی کردم که عصر ها نیز روی بازی م کار کنم که همواره با شکست مواجه شد. ولی از زمانی که برنامه کار در صبح ها را انجام میدهم تا حالا یک روز هم برنامه ام را نشکستم.در گذشته که هنوز خانه مستقل ونکوور (Vancouver Indie House) تعطیل نشده بود، اگر به آنجا سری میزدید متوجه میشدید که هر شخص ساعت و روش کاری مخصوص به خود دارد. بعضی ها دور میز صبحانه جمع می شدند و به صورت جمعی کار می کردند، در حالی که بعضی ها دیرتر از خواب بیدار میشدند و تا نیمه های شب در اتاق شان به تنهایی مشغول به کار بودند. در هر ساعتی از شبانه روز که به آنجا می رفتید، افرادی را مشغول به کار می دیدید.نکته ی خوب این موضوع این است که وقتی در بهترین ساعات کاری تان مشغول به کار بوده اید میتوانید با خیال راحت بقیه روز را استراحت کنید و مطمئن باشید که در آن روز به بهترین و موثر ترین شکل روی بازی تان کار کرده اید.3- یک هدف شفاف داشته باشیدیکی از بهترین شیوه ها برای متمرکز ماندن این است که هر روز تنها یک هدف داشته باشید.انتخابِ یک هدفِ شفاف در روز، تفاوتی چشمگیر در بهره وری کارم ایجادکرده است و به نظرم بزرگترین پیشرفتی بوده که طی این چند سال در روش کار کردنم انتخاب کرده ام.داشتن یک هدف، کمک کرده که از به تعویق انداختن کارها جلوگیری کنم، کارها را به شکل صحیحی به پایان برسانم و روی تنها هدفی که تعیین کرده ام متمرکز بمانم. اما بارها پیش می آید که وسوسه شوید چندین هدف انتخاب کنید، اما اصلا این کار را نکنید. نباید دو یا چند هدف برای آن روز در نظر بگیرید. تنها یک هدف داشته باشید و وقتی به اتمام رسید، آنگاه می توانید روی بخش دیگری کار کنید.هدف باید منطقی و شدنی باشد و معمولا مهمترین آیتم یا گروهِ آیتم ها ی بک لاگ خواهد بود. هدف می تواند راه رفتنِ کاراکتر در پروتوتایپ بازی جدیدتان، اضافه کردن تایل ستِ محیط بازی پیکسل آرت تان یا ضبط کردن ویدیو از گیم پلی برای ساخت تریلر باشد. مهمترین نکته این است که شفاف و قابل انجام باشد.اسکرین شات از بازی Bunker Punks: بخاطر داشته باشید که تنها روی یک هدف تمرکز کنید4- اینرسی خلاقیتاینرسی خلاقیت (Creative Inertia) حقیقت دارد و مفهوم آن نیز بسیار ساده است:اگر هر روز کار میکنید، این احتمال بسیار وجود دارد که در آینده نیز به کار کردن ادامه دهید. اگر وقفه ای در کار روی آن پروژه ایجاد کردید، برگشتن و ادامه دادنِ آن پروژه بسیار سخت خواهد بود.تمایل اجسام به حفظ حالت قبلی را اینرسی گویند.من شاهد این موضوع بوده ام که اینرسیِ خلاقیت بیش از هر عاملِ دیگری باعث مرگ پروژه های انفرادی شده است.در تمام رسانه های خلاق رویداد هایی برای بهره بردن از اینرسی خلاقیت وجود دارد: هر روز ترسیم کن (DrawEveryDay)، من مینویسیم (AmWriting)، نقاشی روزانه (DailyPainting). همه ی اینها میخواهند به یک موضوع اشاره کنند: کار کردنِ روزانه روی مهارت تان، کلیدِ بهره وری و پیشرفت در کار است.اگر شغل تمام وقت دارید، درگیر خانواده هستید، شرایط پزشکی خاصی دارید یا به هر شکلی سرتان شلوغ است و به سختی می توانید وقت تان را خالی کنید حتما در نظر داشته باشید که: یک ساعت کار کردن روی بازی تان در طول پنج روز بسیار بهتر از پنج ساعت کار کردن در یک روز است. زیرا شما همواره در حال حرکت کردن خواهید بود و پروژه تان در نهایت تکمیل خواهد شد.به خاطر داشته باشید که اینرسی خلاقیت بسیار قدرتمند است. به آن احترام بگذارید، خودتان را برای آن آماده کنید و هنگامی که پس از هفته ها تعویق می خواهید دوباره سراغ پروژه تان برگردید ولی میترسید که آن را باز کنید، بدانید این اینرسیِ خلاقیت است که دارد شما را اذیت میکند، سپس پروژه تان را باز کنید تا نشان دهید رئیس کیست!5- باگ زدایی کنید!هیچ چیز سریعتر از باگ نمیتواند سرعت پیشرفت پروژه تان را بگیرد و مشکلات فراوانی برایتان ایجاد کند، مشکلاتی مانند اینکه: مانعِ پیاده سازی فیچرهای جدید شوند، با از بین بردن باگ های قبلی، باگ های جدیدی بوجود آیند و نهایتا لطمه وارد کردن به تجربه ی کاربری. پس تعلل نکنید و هر چه زودتر آنها را از بین ببرید. حتی دشوار ترین آنها و بخصوص آنهایی که هیچکس غیر از شما متوجه آن نشده است.اگر در حال پیاده سازی قسمت پیچیده ای از بازی هستید و باگی پیدا میکنید، آن را به بک لاگ اضافه کنید و بعد سراغ آن بروند.تلاش کنید که ساخت بازیِ بدونِ باگ، به عنوانِ یک نوع نگرش در ذهنتان شکل بگیرد و همواره سعی در پیاده سازی آن داشته باشید. این موضوع به شما این امکان را می دهد که بدون ترسِ از وجود باگ و با تمرکز بیشتری کارتان را پیش ببرید زیرا به زیرساخت و کد بیسی که روی آن کار میکنید مطمئن هستید. علاوه بر این هر زمانی که خواستید، می توانید یک دموی قابل بازی را ارائه دهید. در ضمن همواره سعی کنید که پیام های کنسول را جدی بگیرید و آنها را برطرف کنید.خوشبختی یعنی کنسولِ دیباگ خالی از پیام !این پنج نکته ای بود که به نظرم میتواند به بالا بردن راندمانِ اشخاص کمک کند. این نکات کاملا مستقل از همدیگر هستند و پیشنهاد میکنم که آنها را باهم انجام ندهید. اول با یکی از این ها شروع کنید و هر وقت وارد روتین کاری تان شد آنگاه سراغ بعدی بروید. اگر بخواهید تغییرات زیادی را یکباره انجام دهید، به احتمال زیاد نمی توانید هیچ تغییری ایجاد کنید.منبع: Gamasutraترجمه شده در شماره 31 بازینامه محمد علیزاده محمد علیزاده Tue, 22 Sep 2020 10:49:45 +0330 https://virgool.io/@mhalizadeh/unitys-data-oriented-technology-stack-l1rbg8js2xx5 اگر به سیر تکاملی پردازش در کامیپوتر ها و بازی های رایانه ای در دهه ی اخیر نگاهی بیندازیم، متوجه تغییرات اساسی در این ده سال خواهیم شد. اما یکی از بزرگترین تحولات، گذار از دنیایی است که در آن 90 درصد کدها بر روی یک رشته یا یک هسته اجرا می شد به سمت دنیایی که در آن سخت افزار هایی در اختیار همگان قرار دارد که چندین هسته گرافیکی و محاسباتی دارند. در نتیجه در این دنیا ما باید کدهای بهینه ای طراحی کنیم که به شکل موازی اجرا شوند و از پتانسیل سخت افزار، حداکثر استفاده را ببرند. درنتیجه یونیتی این ضرورت را احساس کرد که با این الگوی جدید خود را وفق دهد. سیستم های پایه ای Unity در دوره ای متفاوت طراحی شده اند و اکنون زمان آن فرا رسیده است که با آینده سازگار شوند. پشته ی تکنولوژی داده محور (Data-Oriented Technology Stack) که به اختصار DOTS نامیده می شود، نام سیستمی است که برایندِ تلاش تیم توسعه دهنده ی یونیتی برای باز سازی معماری داخلی ش است به گونه ای که سریع تر، سبک تر و از همه مهم تر به بهینه ترین شکل در تعامل با دنیای عظیمِ چند رشته ای کنونی عمل کند.در این مقاله نگاهی به سه مولفه ی اصلی DOTS خواهیم انداخت و این موضوع را مورد بررسی قرار میدهیم که چگونه به کمک آن می توانیم بازی های نسل آینده را تولید کنیم.پشته ی تکنولوژی داده محور (DOTS)سه عنصر اصلی DOTS :سیستم کامپوننت موجودیت (ECS)سیستم کاری سی شارپ (C# Job System)کامپایلر انفجاری (Burst Compiler)اکنون میخواهیم نگاهی به این بخش ها بیندازیم:1. سیستم کامپوننت موجودیت (ECS)اگر با یونیتی آشنا باشید، میدانید که دو ساختار اساسی که در تمام بخش های بازی وجود دارند عبارت است از: GameObject و MonoBehavior . تمامی GameObject ها شامل یک یا چندین MonoBehavior می باشند که داده ها (آنچه این شیء میداند) و رفتار هایِ هر عنصر (کاری که این شیء انجام میدهد) در یک Scene را توصیف میکنند.پیش از هر چیزی بهتر است بدانید که GameObject یک ساختمان داده بسیار سنگین و چاق است ! در تئوری، GameObject باید فقط محفظه ای برای نگهداری از نمونه یِ MonoBehavior باشد اما در عمل به این شکل پیش نمیرود و مشکلات قابل توجهی وجود دارد، برای مثال:هر GameObject یک اسم و شناسه دارد.هر GameObject یک شیء بسته بندی شده #C دارد که به کد نیتیو ++C اشاره میکند.ساختن و حذف کردن یک GameObject نیازمند قفل کردن و ویرایش یک لیست گلوبال است (و این به این معنا است که این عملیات ها به طور موازی قابل اجرا نیستند).علاوه بر این موارد، GameObject و MonoBehavior آبجکت های پویایی هستند و در هر جایی از حافظه ذخیره می شوند. بهتر می بود اگر میتوانستیم تمامی GameObject ها و MonoBehavior ها را نزدیک به همدیگر نگه داریم که در نتیجه یافتن و اجرای آنها بسیار بهینه تر میشد.برای حل تمامی این مشکلات، یونیتی سیستم کامپوننت موجودیت (ECS) را پیشنهاد و معرفی میکند و آن را به عنوان پارادایمِ جدیدی برای جایگزینی سیستم قدیمیِ GameObject / MonoBehavior مطرح میکند.همانطور که از اسمِ این سیستم مشخص است، از سه بخش تشکیل شده است:کامپوننت ها: که از لحاظ مفهومی شبیه به MonoBehavior هستند، اما با این تفاوت که فقط شامل داده خواهند بود. برای مثال یک کامپوننت پوزیشن فقط شامل یک وکتور 3 بعدی خواهد بود، یا یک کامپوننت LinearVelocity فقط اطلاعاتِ سرعت آن شئ را نگه میدارد و به همین ترتیب. کامپوننت ها فقط داده های ساده هستند.موجودیت ها (Entities): آنها فقط مجموعه ای از کامپوننت ها هستند. برای مثال اگر یک پارتیکل در فضا داشته باشید، میتوانید آن را با لیستی از کامپوننت ها نمایش دهید، برای مثال کامپوننت های Position و LinearVelocity .سیستم: سیستم جایی است که رفتارها رو در آن مدیریت میکنیم. هر سیستم لیستی از کامپوننت ها را دریافت میکند و تابعی را روی تمامی موجودیت هایِ ایجاد شده توسط کامپوننت ها، اجرا میکند.نکته: اگر بخواهیم از لحاظ فنی به شکل صحیحی بیان کنیم، یک موجودیت مجموعه ای از ساختمان های داده نیست. بلکه یک پوینتر است که به مکانی در حافظه اشاره میکند که کامپوننت هایِ موجودیت در آن ذخیره شده اند. با این حال ذخیره سازیِ واقعی توسط یونیتی مدیریت می شود.به کمک این سیستم میتوانیم کامپوننت ها را در آرایه های پیوسته ذخیره کنیم و سپس از موجودیت کمک بگیریم، موجودیتی که فقط یک پوینتر به نمونه اولیه است. همچنین یک تابع برای هر سیستم میتواند رفتار هزاران موجودیتِ مشابه را تعیین کند. این رفتار بسیار بهینه تر از اجرا شدن Update بر روی هر MonoBehavior در هر GameObject است.به همین دلیل در ECS میتوانیم بدون هرگونه کند شدن یا سرباری برای سیستم از موجودیت ها استفاده کنیم که در نمونه های GameObject این موضوع غیرممکن بود. برای مثال میتوان تنها از یک موجودیت برای تمام پارتیکل هایِ پارتیکل سیستم استفاده کرد.2. سیستم کاری سی شارپ (C# Job System)اکنون این موضوع مطرح می شود که ما به ابزاری نیاز داریم که این سیستم ها را به شکل بهینه ای اجرا کند. همانطور که در مقدمه اشاره شد استفاده کردن از تمامی هسته ها به عنوان رویکردِ مدرن در بهینگی مطرح می شود که این روش نیازمند اجرا شدن کدها به شکل موازی با استفاده از سیستم های عظیم چند رشته ای میباشد.متاسفانه توسعه ی بازی به شکل چند رشته ای کار سختی است، بسیار سخت. هر برنامه نویس با تجربه ای می تواند با قطعیت بگوید که گذار از برنامه نویسی تک رشته ای به چند رشته ای مشکلات و باگ های فراوانی را با خود به همراه خواهد داشت، مشکلاتی از قبیل وضعیت های رقابتی (Race Conditions) . علاوه بر این، برای کار به شکل چند هسته ای باید تا حد ممکن به سمت برنامه نویسی سطح پایین حرکت کنید و از تخصیص و آزاد سازی داینامیک و بازیافت حافظه (GC) که در زبان #C وجود دارد اجتناب کنید و بخشی از بازی تان را در زبان ++C توسعه دهید.اما خوشبختانه یونیتی مولفه ای را درون DOTS تعبیه کرده که هدفش ساده سازی برنامه نویسی چند هسته ای در یونیتی از طریق زبان #C است: سیستم کار.میتوانید کار را به عنوان بخشی از کدها تصور کنید که میخواهید به شکل موازی روی تمام هسته های ممکن اجرا شود. سیستم کار #C به شما کمک میکند تا کد هایتان را به شکلی طراحی کنید تا با استفاده از #C از تمام خطاها و تله های رایج در مبحث چند رشته ای در امان بمانید. بالاخره می توانید بدونِ نوشتن یک خط کد ++C، از تمام پتانسیلِ دستگاه تان استفاده کنید.3. کامپایلر انفجاری (Burst Compiler)آیا حرف من را باور میکنید اگر به شما بگویم که این امکان وجود دارد که با نوشتن کد به زبان #C به جای ++C، به راندمان بالاتری دست پیدا کنید؟ آیا فکر میکنید عقلم را از دست داده ام؟ اما هنوز عقلم سر جایش است ! و این موضوع ، هدفِ آخرین کامپوننت DOTS است: کامپایلر انفجاری.کامپایلر انفجاری یک تولید کننده ی تخصصی کد است که یک نوع زیرمجموعه از زبان #C (که High-Performance C# یا به اختصار #HPC نامیده می شود) را به کد های ماشین کامپایل میکند که اغلب اوقات کوچک تر و سریع تر از کدهای معادلش در ++C است.کامپایلر انفجاری در حالت آزمایشی است اما شما میتوانید از طریق Package Manager یونیتی آن را به پروژه تان اضافه کنید و مورد بررسی و استفاده قرار دهید. مطمئنا هنگامی که این کامپایلر را با دو مولفه ی دیگر DOTS ترکیب کنید، به حداکثر راندمان و قدرت این سیستم دست پیدا خواهید کرد.منبع: Packtترجمه شده در شماره 30 بازینامه محمد علیزاده محمد علیزاده Mon, 01 Jun 2020 12:32:59 +0430 https://virgool.io/cafegame/tips-to-optimize-your-unity-2d-mobile-game-ezejbuvscb1e آیفون، آیپد و گجت‌ های اندرویدی به نسبت کنسول و کامپیوتر های شخصی، سخت افزار ضعیف تری دارند، در نتیجه برای ساخت بازی برای آنها باید برنامه نویس قوی تری شوید. هرچند که بهینه سازی نباید در ابتدای توسعه انجام شود، اما در این مقاله شما با رویه هایی آشنا خواهید شد که با پیروی از آنها از تکرارِ مداوم یک اشتباه، جلوگیری خواهید کرد.بهینه سازی بازی نیمی تجربه و نیمی هنر است. شما باید میانبر ها، روش های متفاوت ایمپورت کردن، رفتار موتور یونیتی و خط های کد تان را بشناسید. مطمئنا هنگامی که بازی تان بر روی آیفون قدیمی یا گوشی اندرویدی تان خیلی آهسته اجرا شد، ایده ها و نکته های این مقاله را بیش از پیش کاربردی و با ارزش خواهید یافت.نکته شماره 0: موبایلِ تستِ بازی تان را هوشمندانه انتخاب کنیدهرچه دستگاه کند تر باشد، بهتر است. البته در این کار افراط نکنید زیرا یک گوشی بسیار کند، سرعت شما را خیلی کم خواهد کرد و باعث می شود از ابتدای کار شروع به بهینه سازی کنید، که کاری اضافی و غیر ضروری خواهد بود. به نظر من گوشی های میان رده گزینه ی مناسبی خواهند بود.تا به حال هیچ وقت اینقدر دستگاه های جور وا جور در دنیا وجود نداشته !بهینه سازی در حجم بازیگاهی اوقات بازی شما بدون هیچ دلیلی فضای بسیار زیادی را اشغال می کند .حجم بازی تان از اهمیت بسیار بالایی برخوردار است و باید همواره مراقب آن باشید، زیرا این موضوع روی تعداد افرادی که بازی تان را دانلود میکنند تاثیر مستقیم دارد. علاوه بر این به خاطر داشته باشید که وقتی کاربری نیاز دارد نرم افزاری را حذف کند تا فضای بیشتری برای گوشی خود خالی کند، ابتدا نرم افزار های با حجم بالا هستند که قربانی می شوند!نکته شماره 1: تکسچر ها و فایل های صوتی را فشرده کنیداز بازی تان خروجی بگیرید و سپس درون Editor.log به دنبال فایل هایی بگردید که بیشترین فضا را در بازی تان اشغال کرده است، که اکثر اوقات تکسچرها و فایل های صوتی می باشند. برای اینکه تکسچرها بصورت فشرده و کم حجم در بازی مورد استفاده قرار گیرند باید رزولوشن آنها توان دو باشد، مثلا 1024X2014 گزینه ی مناسبی است. و ترجیحا این ابعاد را بیشتر از 2048 در نظر نگیرید. همچنین فایل های صوتی نیز باید همواره حالت فشرده سازی شان (Compression) فعال باشد مگر اینکه فایل صوتی خیلی خیلی کوتاه باشد و فشرده سازی کیفیتش را مختل کند. (که خیلی بعید است)نکته شماره 2: اسپرایت ها را بسته بندی کنید (Pack)همواره باید اسپرایت های UI و بازی را بسته بندی کنید. از ورژن یونیتی 5 به بعد کاربران امکان استفاده رایگان از Sprite Packerدرون موتور یونیتی را دارند. علاوه بر این ابزار های دیگری مانند NGUI نیز در این زمینه بسیار کارآمد و محبوب هستند. به کمک ابزار sprite packer می توانید به راحتی محدودیتِ اسپرایت ها با رزولوشنِ توان دو و ساخت atlas که گاها از سمت آرتیست ایجاد میشود را از بین ببرید. تنها کافیست که تگِ بسته بندی (packing tag) را مشخص کنید تا یونیتی همه مشکلات را حل کند و به راحتی حجم بازی تان به شکل قابل توجهی کاهش پیدا کند.نکته شماره 3: کتابخانه و dll های بدون استفاده را حذف کنیدشما باید امکان حذفِ (stripping) کتابخانه ها و dll هایِ بدونِ استفاده را فعال کنید، البته به شرط اینکه مشکلی برای پروژه تان و پلاگین های مورد استفاده از آن پیش نیاید. بازی دو بعدی شما احتمالا از بسیاری از امکانات یونیتی از جمله فیزیک استفاده نمی کند که فضای زیادی از بازی تان را اشغال کرده و میتوانید با این تکنیک از شر این فضای اضافی خلاص شوید.نکته شماره 4: مطمئن شوید که asset های غیرضروری را در پروژه اضافه نکرده ایداگر یک گیم آبجکت غیرفعال در بازی دارید، یونیتی در هنگام خروجی گرفتن از بازی تمام رفرنس هایی که آن گیم آبجکت مورد استفاده قرار داده را درون فایل خروجی قرار می دهد، حتی اگر این گیم آبجکت هیچگاه درون بازی فعال نشود و مورد استفاده قرار نگیرد. پنجره hierarchy را از گیم آبجکت های غیر ضروری و رفرنس های آن به assetهایِ بدون کاربرد پاکسازی کنید. همچنین هر فایلی که درون پوشه Resources باشد نیز در خروجی بازی تان اضافه می شود، پس مراقب این موضوع باشید !به خاطر داشته باشید که بهینه سازی مانند هدیه ای است که شما به پلیرهای محبوبتان می دهید.بهینه سازی در استفاده از حافظهسیستم عامل گوشی های هوشمند با آپگرید شدن، نیازمند RAM بیشتری شده اند که در نتیجه این امر، فضایِ حافظهِ کمی برای بازی شما خالی خواهد ماند (بله iOS روی صحبتم با تو هست! ...). با این شرایط بسیار منطقی است که تا حد ممکن تعداد asset های بازی تان که در حافظه لود می شود را کاهش دهید اولین دلیلی که باعث می شود اپلیکیشنی توسط سیستم عامل بسته شود، فشار حافظه (Memory Pressure) است. درست متوجه شدید، کِرَش های رندم بازی تان، اکثرا کِرَش هایی به دلیل مشکلات حافظه هستند.نکته شماره 5: اسپرایت ها را ...هوشمندانه....بسته بندی کنید (Pack)وقتی بازی را اجرا میکنید، فایل ها از حالت فشرده خارج می شوند و دوباره فضای زیادی را اشغال خواهند کرد. اما اگر کارتان را درست انجام داده باشید و اسپرایت ها را به شکل مناسب بسته بندی کرده باشید، فضای زیادی از RAM را حفظ خواهید کرد. قاعده کلی این است که باید تصاویری که قرار است باهم نشان داده شوند را با هم بسته بندی کنید و سعی کنید و سع کنید فضای خالی زیادی در atlasنداشته باشید. برای مثال باید تصاویر مرتبط با رابط کاربری بازی تان را درون یک atlas مجزا قرار دهید. اما در صورتی که بخش بزرگی از آیتم های رابط کاربری تان خیلی مورد استفاده قرار نمیگیرد، باید اسپرایت های آن را درون یک atlasدیگر ذخیره کنید. نکته ی مهم دیگر این که از اسپرایت های 9 قسمتی در رابط کاربری استفاده کنید و به هیچ وجه از تصاویر بکگراند خیلی بزرگ استفاده نکنید، به هیچ وجه.(در عوض سعی کنید تصویر بکگراند را از تایل ها یا اسپرایت های ساده تر بسازید). و نکته ی پایانی اینکه Mipmaps را غیر فعال کنید.نکته شماره 6: کیفیت تصاویر و فایل های صوتی را کم کنیدآیا مطمئنید که در بازی تان به کاراکتری با طول یا عرض 1024 پیکسل نیاز دارید؟به نظرم نیازی به این کیفیت نداشته باشید چون رزولوشن رایج در بین گوشی ها 1024x768 است. (مگر اینکه می خواهید کاراکتر تان، هم اندازه نمایشگر گوشی باشد). آیا موزیک بازی تان یک لوپ 3 دقیقه ای است؟ شاید بتوانید آن را به 30 ثانیه کاهش دهید.این موضوع خیلی رایج است که بازی ساخته شده از حداکثر کیفیت گوشی ها بیشتر باشد. اگر کیفیت تصاویر و فایل های صوتی را کاهش دهید اکثر افراد متوجه این تفاوت در گوشی هایشان نخواهند شد.نکته شماره 7: مراقب رفرنس ها در صحنه بازی (scene) باشیدبگذارید اتفاقی که برای خودم رخ داد را برایتان تعریف کنم. در گذشته در حال توسعه و ساخت یک بازی بودم که در آن تصاویر زیادی وجود داشت. بر اساس انتخاب پلیر ، پریفبی از لیست انتخاب و instantiateمیشد و تصویری ظاهر میشد. این لیست بسیار طولانی بود. در کمال تعجبم این لیستِ رفرنس باعث این میشد تا تمام پریفب ها و تصاویر، درون حافظه RAM لود شوند که اصلا خوب نبود. نکته ی اخلاقی این داستان؟ پروفایلر هیچگاه به شما دروغ نمی گوید، پس همیشه از آن استفاده کنید.نکته شماره 8: اگر نیاز شد از پوشه منابع (Resource Folder) استفاده کنیدراهکار برای مشکل قبلی این است که تمام پریفب ها و asset ها را درون پوشه resourceببرید و هر زمان که نیاز داشتید، همان آیتم را به شکل پویا و داینامیک لود کنید. این روش مثل استفاده از رفرنس خیلی راحت و بی دردسر نیست زیرا شما باید همواره آدرس asset ها را معین کنید و اگر ناخواسته فایلی را به آدرس دیگر منتقل کردید، با خطا روبرو خواهید شد. اما میتوانید به کمک اسکریپت نویسی، ادیتوری برای این منظور بسازید تا این مشکل را برطرف کند.وقتی بازی تان از حجم زیادی از RAM استفاده می کند سیستم عامل با عصبانیت بازی را می بندد :)بهینه سازی در استفاده از CPUیک بازی کند، یک بازی مرده به حساب می آید. پلیر ها در خیلی از موارد با شما کنار می آیند و سطح معمولی بازی تان را نادیده می گیرند. اگر بازی تان رابط کاربری بد، داستان معمولی، گرافیک ضعیف و … داشته باشد احتمالا پلیرها شما را خواهند بخشید، اما در مورد پرفورمنس ضعیف، جای هیچ گونه بخششی نخواهد بود. باید محدودیت هایتان را بشناسید و در مواقعی که مجبور هستید خیلی از چیزها را به بهای فریم ریت قابل قبول قربانی کنید. بله، این یک واقعیت تلخ است!نکته شماره 9: مراقب ساختار های آبنباتی (candy syntax ) باشید، مانند حلقه foreachاین نکته یکی از تکراری ترین راهکارها برای بهینه سازی CPU در یونیتی است. زیرا یونیتی از ورژن های قدیمی دات نت فریمورک استفاده میکند که به اندازه کافی بهینه نیستند. پس بهتر است به جای foreach از حلقه ی for استفاده کنید و به جای لیست از آرایه استفاده کنید.(البته این موضوع مربوط به ورژن های قدیمی یونیتی است که در زمان نوشتن مقاله مورد استفاده قرار میگرفته و در نسخه های جدید یونیتی این مشکل برطرف شده. اکنون یونیتی از NET 4.x. پشتیبانی می شود )نکته شماره 10: لاگ های کنسول را حذف کنیددر یونیتی متغیرهایی از نوع رشته (strings) باعث کند شدن بازی تان می شوند و تا می توانید از تغییر دادن رشته ها بپرهیزید. به همین دلیل حتما در انتهای توسعه بازی، تمامی Debug.Logهایی که برای لاگ گرفتن و دیباگ کردن بازی نوشته اید را حذف کنید، مخصوصا آنهایی که در update یا حلقه ها هستند. از اینکه تغییری به این کوچکی چقدر میتواند روی کارایی بازی تاثیر بگذارد شگفت زده خواهید شد.نکته شماره 11: بهینه سازی را از پایین به بالا شروع کنیدوقتی در حال بهینه سازی بازی تان هستید و پروفایلر را چک میکنید، کلاس هایی که باعث کند شدن بازی شده اند را شناسایی کنید و سپس شروع به بهینه سازی کلاسی کنید که در انتهای و پایین ترین نقطه قرار دارد. اینها کلاس هایی هستند که کلاس های دیگر هم از آنها استفاده میکنند، برای مثال کلاس های هوش مصنوعی (AI) یا مسیریابی (Pathfinding). اگر شانس بیاورید احتمالا با بهینه سازی کلاس های پایین، نیازی به تغییر در کلاس های بالا نداشته باشید.نکته شماره 12: ابتدا به دنبال گلوگاه های (bottlenecks) کلاسیک بگردید، مثل حلقه های تو در تو یا اسکریپت هایی که آیتم های زیادی تولید (instantiate) میکنندتصور کنید که اسکریپتی به اسم PlayerController و اسکریپت دیگری به نام EnemyControllerدارید. اگر قرار است در بازی تان 100 دشمن به صورت همزمان وجود داشته باشند و کنترل شوند، پس این احتمال وجود دارد که اسکریپت EnemyController صد مرتبه بیشتر باعث کند شدن بازی تان شود. درنتیجه شروع به بهینه سازی این اسکریپت کنید و ابتدا سراغ راهکارهای کلاسیکی مانند این موارد بروید: فراخوانی های کندی مانند تابع FindObjectOfType را حذف کنید، استفاده از این توابع در Updateممنوع است. از کَش کردن به کمک متغیر ها استفاده کنید. همچنین کلاس های Singleton نیز می تواند در زمینه بهینه سازی به شما کمک کند.پروفایل عمیق (deep profile) به شما اجازه می دهد تا توابع کند را پیدا کنید. هر چند خود این نوع پروفایل کردن، پرفورمنس را کاهش میدهد.بهینه سازی خوبی را برایتان آرزومندم ! و به خاطر داشته باشید که بازی ای بسازید که پلیرهای تان مستحق آن باشند، پس بازیِ عالی بسازید.منبع: unitydojoترجمه شده در شماره 29 بازینامه محمد علیزاده محمد علیزاده Tue, 26 May 2020 12:52:23 +0430 https://virgool.io/@mhalizadeh/solid-principles-for-game-developers-o3bjqpdahdel اصول SOLID به مجموعه ی 5 قاعده ی توسعه ی نرم افزار گفته می شود که توسط عمو باب (Robert C. Martin) ابداع شد. این اصول، مجموعه ای از دستورالعمل ها برای طراحی شئ گرا (OOD) هستند که در طراحی کلاس ها بسیار پرکاربرد و مفید هستند. برنامه نویسان وب، اپلیکیشن یا هر نوع بیزنسی که بر پایه توسعه ی نرم افزاری اجایل کار میکنند، به طور گسترده ای از این شیوه بهره می برند، اما این اصول در بین توسعه دهندگان بازی خیلی شناخته شده نیست. در این مقاله قصد داریم به تشریح و توضیح این قواعد، در چارچوب توسعه ی بازی بپردازیم.1- اصل تک وظیفه ای (Single responsibility principle)"یک کلاس باید تنها یک دلیل برای تغییر داشته باشد و نه بیشتر"این قاعده، سنگ بنای این مجموعه است و اگر آن را به درستی رعایت کنید، به نتیجه ی مطلوب خواهید رسید. طبق این اصل، هر کلاس باید فقط یک وظیفه به عهده داشته باشد و در نتیجه، تنها یک دلیل وجود خواهد داشت که کلاس را تغییر دهید. اگر کلاس ها کوچک باشند و فقط روی یک هدف تمرکز داشته باشند، به راحتی می توانید تشخیص دهید برای پیدا کردن یا اضافه کردن یک ویژگی در بازی به کدام قسمت باید مراجعه کنید.چرا داشتن چند وظیفه برای یک کلاس، بد است؟ وظایف متعدد در یک کلاس باعث بروز وابستگی (Coupling) بین کد ها می شود و ایجاد تغییر در یک وظیفه، ممکن است باعث اختلال در مسئولیت های دیگر شود. این نوع طراحی بسیار شکننده است و سبب می شود در قسمت هایی که انتظار ندارید، برنامه تان دچار مشکل شود و گاها با این نوع سوالات روبرو شوید: "چرا بعد از تغییر سیستم رندرینگ، پرش و راه رفتن از کار افتاد؟ "اگر کدهای بازی تان این قانون را نقض می کنند، باید فورا هر ویژگی و مسئولیتی را در کلاسِ مخصوصِ خودش قرار دهید. به عنوان اولین قدم می توانید برای هر مسئولیتی یک اینترفیس در نظر بگیرید. کلاس های دیگر می توانند به جای خودِ کلاس، به اینترفیسِ آنها وابسته باشند. سپس بدون هیچ مشکلی میتوانید کلاس را به چندین کلاس تقسیم کنید که هرکدام یک مسئولیت را به عهده دارند و هر کدام یک اینترفیس را پیاده سازی میکنند.چه زمانی این مشکل را دارید ؟ معمولا متهم اصلی در نقضِ این اصل، کلاس یا کلاس هایی هستند که شامل صدها یا هزاران خط کد می باشند. می دانید درباره ی چه حرف میزنم، معمولا یک کلاس Manager یا به همین مفهوم دارید که تمام افراد تیم توسعه، کدهایشان را در آن قرار میدهند. این کلاس معمولا 500 دلیل برای تغییر دارد و 500 وظیفه متفاوت را به عهده دارد. بی رحم ترین باگ ها که ساعت ها یا روزها شما را درگیر میکند از دل این کلاس ها بیرون می آید.2- اصل باز - بسته (Open/closed principle)"اجزای نرم‌افزار (کلاس، ماژول ها، توابع و غیره) باید نسبت به توسعه باز و نسبت به اصلاح بسته باشند."هدف این اصل این است که ایجادِ تغییرات در هر کلاس را به حداقل برساند و در عین حال، این امکان را فراهم کند تا بتوان در سناریو های متفاوت از همان کلاس استفاده کرد. شاید چنین به نظر برسد که این دو مورد با هم تناقض دارند اما خواهید دید که چگونه همدیگر را کامل میکنند و یک طراحی قوی و یکپارچه شکل میدهند. اینکه یک کلاس برای توسعه باز باشد به این معنی است که با توجه به نیازمندی های جدید، بتوان رفتار یک کلاس را به شکل متفاوتی تغییر داد. اگر برای به وقوع پیوستنِ این تغییرات، نیاز به اصلاح هیچ کدی نباشد به این مفهوم است که کلاس باید نسبت به اصلاح بسته باشد.این قانون را به راحتی میتوان با طراحی داده محور (data driven design) اجرا کرد. با ارسال اطلاعات پیکربندی مورد نیاز به یک کلاس، به راحتی می توان آن را توسعه داد و نیاز به اصلاح کد را کاهش داد. هر نوع متغیری (در معنای ریاضی) باید به کلاس ارسال شود، در نتیجه مفهوم کلاس (کد ها)، به تنهایی و به خودی خود عملکرد آن کلاس را مشخص نمی کند. برای درک بهتر این قاعده، بهتر است این موضوع را در قالبِ قاعده ی داده ها و عملیات در طراحی شی گرا (OOD) مورد تحلیل قرار دهید. کلاس، عملیاتی را که قرار است انجام دهد (همان توابع اش) و داده هایی که روی آنها عملیات انجام میدهد را تعریف میکند. تا جایی که امکان دارد، این داده ها باید به کلاس یا تابع ارسال شوند. به این ترتیب پیکربندی داده ها در خارج از کلاس و توسط کدی که آن را فراخوانی می کند، صورت می پذیرد و در نتیجه، امکان ایجاد تغییرات در آن افزایش می یابد.چه زمانی این مشکل را دارید ؟ این همان فایلی است که می ترسید آن را باز کنید و مورد بررسی قرار دهید، چون همه ی تیم در حال کار کردن روی آن کد هستند و مدام آن را تغییر میدهند. مهم نیست با چه سیستمی کار می کنید، این فایل ها همیشه باعث بروز پیچیدگی می شوند و شما را گرفتار خواهند کرد.3- اصل جانشینی لیسکو (Liskov substitution principle)"توابعی که از اشاره گرها(pointer) یا مراجع (reference) برای کلاس پایه (base) استفاده می کنند، باید بدون اینکه از وجودِ آنها آگاهی داشته باشند، بتوانند از اشیاءِ کلاس های مشتق شده استفاده کنند."ارث بری و چندریختی (polymorphism) به عنوان مکانیزم های قدرتمندی برای حل مشکلات پیچیده بوسیله ی راه حل های ساده، تلقی می شوند. این دو همچنین مکانیزم های قدرتمندی برای ایجاد باگ و کد های مشکل ساز می باشند. هدف این اصل این است که اطمینان حاصل کند که سلسله مراتب وراثت به خوبی کار کنند و توسط کدها بطور ناصحیح مورد استفاده قرار نگیرند. در غیر این صورت باگ هایی ایجاد می شود که به سختی قابل شناسایی و ردیابی خواهند بود. شاید این اصل در ظاهر ساده به نظر برسد اما حل مشکلات بوسیله ی آن، تا حدی پیچیده است.اولین قدم برای حل این مشکل پیدا کردن مواردی است از چک کردنِ نوع آبجکت - چه نوع همان آبجکت و چه آبجکت هایی که روی آنها کار میکند. پس از این مرحله ی ساده، اصلی به اسم "طراحی بر اساس قرارداد" (Design By Contract) باید اعمال شود. هر تابعی یک سری شرط دارد که باید پیش از فراخوانی برقرار باشند (پیش شرایط) و یک سری شرط دارند که تضمین می کنند پس از اتمام، برآورده شوند (پس شرایط). این ها معمولا شرایط ضمنی هستند که در ذهن برنامه نویسی که روی آن کار میکند وجود دارد.گام اول، ساختار بندی کردن این شرایط به شکل کد می باشد. هنگامی که این گام به سرانجام رسید، قانون بعدی میتواند به تحقق بپیوندد: "کلاس های مشتق شده، تنها می توانند پیش شرایط را ضعیف کنند و پس شرایط را تقویت کنند". به عبارتی دیگر، توابع یک کلاس مشتق شده نباید انتظاری بیش از کلاس پایه شان داشته باشند و همچنین نباید وعده ی کمتر از آن را نیز بدهند. این قانون بسیار پر اهمیت است و علت آن، این موضوع است که یک مدل که به تنهایی مورد بررسی قرار میگیرد را نمیتوان به شکل معنی داری مورد تایید قرار داد. مطمئنا نمیدانید که آیا کلاس جدیدتان با نام Tankاعتبار دارد یا نه، مگر زمانی که آن را در کنار والدش، خواهر و برادرش (sibiling) و سایر سیستم های بازی قرار دهید.چه زمانی این مشکل را دارید ؟ کلاس هایی که این قانون را نقض میکنند به راحتی قابل شناسایی هستند. کافی است به دنبال کلاس پایه ای باشید که از اطلاعات نوع ران تایم (RTTI) (یا نوع آبجکتی که بر روی آن کار می کند) برای بررسی و شناسایی نوع خودش استفاده میکند. اگر در برنامه تان، كلاس GameEntity برای اجرای یک سری کد و عملیات، چک میکند که آیا خودش از نوع Tank است یا نه، به این مفهوم است که این قانون نقض شده است. کلاس باید بتواند به صورت چند ریختی و بدون اینکه اهمیت دهد که نوع اصلی این آبجکت چیست، توابعِ آن را فراخوانی کند.4- اصل تجزیه ی اینترفیس (Interface segregation principle)"نباید اجباری باشد تا کلاینت ها به اینترفیس هایی که ازشان استفاده نمی کنند، وابسته باشند. "اینترفیس ها باید برای برقراری ارتباط بین آبجکت های مختلف مورد استفاده قرار بگیرند تا کدهایی تمیز با ساختار ماژولار را شکل دهند. اما اصلِ "تجزیه ی اینترفیس" این مفهوم را به این شکل بسط می دهد که اینترفیس ها نیز باید خودشان تمیز و یکپارچه باشند. هر چه اینترفیس بزرگتر باشد، احتمالِ بیشتری خواهد بود که کلاینت، به عملکردِ آبجکت دیگری نیز وابسته شود. اما به کمک اینترفیس های کوچک و تجزیه شده، هر آبجکت فقط به کوچکترین واحدِ عملکردی که نیاز دارد وابسته خواهد بود. این امر منجر به کاهش پیچیدگی ارتباطات بین آبجکت ها می شود و از آن مهمتر اینکه اگر کسی کدهای شما را بررسی کند، به راحتی متوجه میشود که هر کلاسی به چه چیزی وابسته است. به جای داشتن یک اینترفیس "غول پیکر"، بهتر است که آن را به چندین اینترفیس کوچکتر با وظایف مشخص تقسیم کنید تا هر کدام برای یک کلاینتِ بخصوص، مناسب باشند.این قاعده با اصلِ "تک وظیفه ای" بسیار مرتبط است. در این قاعده هر اینترفیس باید تنها یک وظیفه داشته باشد که به شما این امکان را میدهد که به سادگی عملکردِ هر آبجکتی را بر اساس اینترفیس هایی که استفاده می کند، بیان کنید.چه زمانی این مشکل را دارید ؟ تمام اینترفیس ها (کلاس های ابسترکت) را بررسی کنید و مطمئن شوید که تمامی توابع شان همگن و حول یک موضوع هستند. یک راه ساده برای تشخیص اینکه این قاعده را شکستید، زمانی است که چند گروه از توابع، درون یک اینترفیس دارید. معمولا راه تشخیص آن هم دیدن فضای خالی در کدها است، هرچه بین بخش هایی از کدهای یک اینترفیس فاصله ی بیشتری وجود داشته باشد به این مفهوم است که احتمالا این گروه ها کارایی متفاوتی نسبت به هم دارند و اینترفیس یکپارچه نیست.5- اصل وارونگی وابستگی (Dependency inversion principle)"ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند. هر دو باید به انتزاع ها (abstractions) وابسته باشند.""انتزاع نباید به جزئیات بستگی داشته باشد. جزئیات باید بر اساس انتزاع باشد."این یک نکته ی کلیدی است که اخیرا در زمینه ی بازی سازی نیز به شدت پرکاربرد شده است. معمولا اگر یک کلاس به کلاس دیگری وابسته باشد، کلاینت ابتدا آبجکتی از آن کلاس را نمونه سازی(instantiate)میکند و سپس روی آن کار میکند. وارونگی وابستگی (یا وارونگی کنترل) این موضوع را برعکس میکند. به جای اینکه کلاینت مسئول ساخت آبجکت باشد، آبجکتی که به آن نیاز دارد، در اختیارش قرار میگیرد که در نتیجه ی آن، کنترل از کلاینت گرفته می شود و به مالکِ کلاینت که معمولا موتور بازی سازی است داده می شود.مثال خوبی برای این موضوع، سیستم رندرینگ است. به جای نمونه سازی از آبجکت رندرینگ یا فراخوانی مستقیمِ کلاس های API رندرینگ، سیستم رندرینگ باید یک اینترفیس برای عملکردِ سطح پایین رندرینگ دریافت کند. با وابسته شدن به اینترفیسی که به سیستم رندرینگ داده شده، میتوان بدون ایجاد مشکلی برای کلاینت هایِ این سیستم ،API سطح پایین رندرینگ را تغییر داد.چه زمانی این مشکل را دارید ؟ هنگامی که دو سیستم در حال ارتباط و صحبت با یکدیگر هستند، به چه شکلی این کار را انجام می دهند؟ اگر از کلاس های واقعی استفاده میکنند، بهتر است دنبال راهی باشید تا آنها را به اینترفیس وابسته کنید. بهترین راه این است که کلاسِ مورد نظر، رفرنسِ اینترفیسی که نیاز دارد را به عنوان پارامتر متد سازنده اش دریافت کند.منبع: Gamasutraترجمه شده در شماره 27 بازینامه محمد علیزاده محمد علیزاده Mon, 18 May 2020 16:36:27 +0430 https://virgool.io/@mhalizadeh/%D9%87%D9%85%D9%87-%DA%86%DB%8C%D8%B2-%D8%AF%D8%B1%D9%85%D9%88%D8%B1%D8%AF-%D9%BE%D9%84%DB%8C-%D8%AA%D8%B3%D8%AA-%DB%8C%DA%A9-%D8%A8%D8%A7%D8%B2%DB%8C-%D9%85%D8%B3%D8%AA%D9%82%D9%84-csgkhdiq5sow استودیوی مستقل Motion Twin سازنده بازی موفق Dead Cell، پیش از ساخت این بازی، طی یک هفته و توسط 30 تستر، دو پروتوتایپ را مورد پلی تست قرار داد. این مقاله قرار است تجربه این استدیو از فرایند و نکات مهمی که در پلی تستینگ مطرح می شود را برای شما بازگو کند.آیا نیازی است که بازی ام را تست کنم ؟تصور کنید که بازی ای ساختید و به آن افتخار میکنید و تصمیم میگیرید این شاهکار را به همگان نشان دهید. اما پاسخی که دریافت می کنید این است: "آشغاله"، "این چیه دیگه؟"، " چرا این کارو نکردی؟" و …پلی تستینگ، قسمتی کلیدی از فرایند تولید یک بازی است، مخصوصا اگر هدفتان این است که کاربران تان را راضی نگه دارید و بعلاوه از بازی تان درآمد خوبی کسب کنید. اگر میخواهید مطمئن باشید زمانی که به مرحله (سافت) لانچ میرسید، بهترین نسخه از بازی را ارائه می دهید همواره به این نکته توجه کنید که:«خیلی زود شروع به تست کنید و این کار را بارها و بارها انجام دهید»چه چیزی را باید تست کنم ؟برای پاسخ به این سوال که چی چیزی را باید تست کنید ابتدا باید مشخص کنید که اکنون در چه مرحله ای از توسعه و تولید بازی تان هستید. باید به دقت به این موضوع فکر کنید که در هر مرحله، چه چیزی را میخواهید تست کنید.آیا میخواهید:پروتوتایپ تان را تست کنید تا مطمئن شوید، ایده ی اصلی به اندازه ی کافی جذاب است؟اولین نسخه تان را تست کنید تا ببینید آیا افراد از جهانِ بازی خوششان می آید؟نسخه ی پیش از عرضه را تست کنید تا نسبت به نبودِ باگ و قابل فهم بودن بازی مطمئن شوید؟تمام فرایند تست، بعد از این قدم مشخص می شود. اینکه می خواهید چه چیز را تست کنید، تعیین می کند که چه تستر هایی انتخاب کنید و چه سوالاتی بپرسید. برای تست دیباگ کردن مراحل، مطمئنا سراغ مادربزرگتان نخواهید رفت، اما اگر بخواهید تست کنید آیا بازیِ حدسِ کلمه تان روی گوشی های همراه خوانا است، از او کمک خواهید گرفت.به چه شکل این تست را انجام دهم ؟بخش عملی پلی تست نیز نیازمند برنامه ریزی و هماهنگی دقیق است و باید در موردِ تدارکات آن برنامه ریزی کنید. در این مرحله باید:اجازه دهید که تستر ها خودشان و به شیوه ی خودشان بازی کنند و نباید حس کنند که در حال نظارت و بررسی هستند. (سعی کنید شرایط مشابه تجربه ی واقعی کاربران تان را شبیه سازی کنید)جلسه تست را ضبط کنید. برای انجام این کار می توانید از نرم افزار BB Flashback استفاده کردند تا هر اتفاقی که در مانیتور رخ میدهد، بعلاوه واکنش و چهره ی پلیر را به صورت همزمان ضبط کنید.برداشت شخصی هر تستر از بازی را، بدون تاثیر افراد دیگر، یادداشت کنید. میتوانید به محض پایانِ تست، از کاربران بخواهید تا پرسشنامه را پر کنند. همچنین در حین تست هم کاربران میتوانند یادداشت برداری کنند و نظرشان را ثبت کنند.با افراد صحبت کنید. تیم Motion Twin پس از اتمام تست، یک گروه 5 نفره تشکیل دادند که متشکل از دو دولوپر در هر گروه بود و با تستر هایشان گفتگویی شفاف و صریح ترتیب دادند.شما نیز اجازه دهید تسترها صحبت کنند و از اینکه چه اطلاعات سودمندی به شما خواهند داد، شگفت زده خواهید شد.بعد از تست با کاربران گپی خودمانی بزنید، یا حتی با آنها نوشیدنی و پیتزا بخورید! این امر باعث می شود درموردتان با بقیه نیز صحبت کنند و در آینده نیز سراغتان را بگیرند و به نزد تان بازگردند.به چه شکل پرسشنامه طراحی کنم ؟اینکه می خواهید چه بخشی را تست کنید، تعیین کننده ی سوالات پرسشنامه تان خواهد بود. پس بهتر است حتما مطمئن باشید که چه قسمتی از بازی را می خواهید تست کنید و سپس سوالات پرسشنامه تان را بر اساس آن طرح کنید. برای مثال اگر می خواهید قسمت راهنمایِ اولیه بازی را مورد پلی تست قرار دهید، میتوانید این سوالات را بپرسید:آیا به طور کل بخش آموزشی بازی، مفید بود؟آیا خیلی طولانی بود؟آیا قسمتی بود که به نظرتان باید بهتر شود؟بعد از این باید در نظر داشته باشید که چگونه می خواهید پاسخ ها را جمع اوری کنید. تیم Motion Twin برای ساخت پرسشنامه از Google Forms استفاده کردند که پاسخ ها را در Google Sheet ذخیره کردند.پرسشنامه شما باید تا حد امکان چند گزینه ای باشد و اطلاعات قابل تجزیه ای را برگرداند. اما سوالاتی که نیازمند پاسخ های تشریحی هستند را به تعداد کلمات محدود کنید، در غیر اینصورت ممکن است تسترها برایتان رمان بنویسند!چگونه تسترها را انتخاب کنم ؟برنامه ریزی در مورد اینکه چه کسی بازی را تست کند بسیار مهم و حیاتی است زیرا شما را مجبور میکند تا به این قضیه فکر کنید که بازار هدفتان چه کسانی هستند. به این فکر کنید که این بازی را برای چه کسانی می سازید و با پلی تست، مطمئن شوید که آنها از این بازی لذت خواهند برد.اگر هنوز نمی دانید مخاطبانتان چه کسانی هستند، یک جامعه ی گسترده از تسترها انتخاب کنید.حتما تستر های مرد و زن را بطور برابر انتخاب کنید.مطمئن شوید که تسترها در سطح متناسبی نسبت به بازی تان باشند. برای مثال اگر تستری که در بازی های پازل محور بسیار با تجربه و حرفه ای است را برای بررسی پازل های بازی تان انتخاب کنید، احتمالا بر اساس فیدبک های دریافتی بازی تان در زمان عرضه، پازل های بسیار سختی خواهد داشت.چگونه این افراد را پیدا کنم ؟برای این کار از دوستانتان درخواست کنید. با خانواده تان صحبت کنید، در تابلو اعلانات دانشگاه اطلاعیه بزنید، در اینترنت و هر جایی که ممکن است اطلاع رسانی کنید. اگر به دنبال گروه خاصی از تسترها می گردید در جاهایی اطلاع رسانی کنید که احتمال می دهید آنها را آنجا بیابید. پلی تست از راه دور و از طریق اینترنت هم عالی است اما ارزش و دقت تست حضوری بسیار بالاتر است.سازماندهی و چیدمان تستشما به این موارد نیاز خواهید داشت:فضایی کافی برای انجام تست: تیم Motion Twin تست شان را در دفتری با فضای مناسب و کافی انجام دادند. اما شما می توانید این کار را در گاراژ، اتاق شخصی تان، خانه پدری تان یا هر فضای دیگری انجام دهید. فقط مطمئن باشید که در آنجا می توانید تستر ها را از یکدیگر جدا کنید.وقفه زمانی: مطمئن شوید که میتوانید آن تعداد تستری که می آیند را مدیریت کنید. به گفته تیم Motion Twin، آنها از گروه های 5 نفره از تستر ها با وقفه های زمانی 30 دقیقه ای تقاضا کرده بودند تا به آنجا بروند و با این زمان بندی اطمینان داشتند که جلسه تست شان را می توانند کنترل کنند.دستگاه ها: حتما در نظر داشته باشید که به تعداد کافی کامپیوتر/تبلت/ موبایل یا هر وسیله ای که قرار است تست روی آن انجام شود موجود داشته باشید. اگر میخواهید روی گوشیِ تسترها بازی را اجرا کنید یا نیازی به برقراری دسترسی به اینترنت دارید، مطمئن شوید که زمان کافی برای این آماده سازی ها در اختیار خواهید داشت.دوربین و نرم افزار ضبط تصویر: ضبط کردن تست ها به شما اطلاعاتی ارزشمند خواهد داد که اکثرا پرسشنامه ها و گفت و گو های بعد از تست نمی تواند در اختیارتان قرار دهد.حتما برای این کار از تستر ها اجازه بگیرید.همه چیز را تست کنید: قبل از شروی پلی تست، از کارکردن نرم افزار ضبط، اینکه به چه شکل ضبط کردن را فعال یا غیر فعال کنید، صدا و سایر موارد اطمینان حاصل کنید. همچنین در مورد ساختار پوشه ها برای نگهداری فایل های ذخیره شده نیز فکر کنید و آن را در نظر داشته باشید.یک مانور فرضی اجرا کنید: از یکی از دوستان یا همکاران تان دعوت کنید به دفترتان بیاید و در مورد کلیت تست او را راهنمایی کنید و تمام فرایند را برایش شرح دهید. سپس از او (آنها) بخواهید تست را انجام دهند و زمان به پایان رساندن تست و اتمام پرسشنامه را محاسبه کنید. به وسیله ی این کار هم متوجه چالش های پیش بینی نشده خواهید شد و هم خواهید دانست برای انجام تست برای هر فرد به چه میزان زمان نیاز خواهید داشت.تست را شروع کنید:شروع کنید. تسترها را وارد صحنه کنید و پلی تست را آغاز کنید.از انجام این موارد اطمینان حاصل کنید:آب نوشیدنی و مواد خوراکی و … را تدارک دیده باشید. باید تستر ها در حین تست کاملا هوشیار باشند و با این تجربهِ خوب، آنها را تشویق کنید تا دوباره و برای تست های بعدی نیز به شما کمک کنند.به حرفهایشان گوش دهید و آنها را یادداشت کنید.همگی را تشویق کنید تا صحبت کنند و نظر بدهند و اگر فرصتی پیش آمد با آنها تک به تک به گفتگو بپردازید.اجازه دهید کاملا آزادانه بازی را تست کنند.و مراقب باشید این اشتباهات را انجام ندهید:هنگامی که بازی را تست میکنند، مدام اطرافشان پرسه نزنید.در هنگام تست، به آنها کمک نکنید (مگر اینکه در بخشی کاملا گیر کرده اند و نمی توانند ادامه بازی را انجام دهند)وقتی در مورد بازی نظرشان یا موضوعی را به شما می گویند، نگویید که در اشتباه هستند.به آنها پیشنهاد پرداخت پول در قبال تست ندهید (مگر اینکه شرکت خیلی بزرگی هستید و توان پرداخت پول برای تستر را هم دارید)خیلی از این موارد ممکن است بسیار واضح و بدیهی به نظر برسد (یا حتی احمقانه) اما بهتر است این را بدانید که اکثر دولوپرها وقتی می بینند تستری درحال کلنجار رفتن برای حل یک پازل یا قسمت سختی از بازی هست، نمی توانند جلوی خود را بگیرند و او را راهنمایی نکنند. در نتیجه با این کارشان فرایند پلی تست و احتمالا بازی شان را خراب می کنند.تحلیل کردن داده هاهنگامی که تسترها کارشان تمام شد و محل را ترک کردند، باید داده ها را مورد بررسی قرار دهید. ساده ترین کار این است که یادداشت هایی که برداشتید را بررسی کنید و با توجه به بازخوردها و نکاتی که بسیار تکرار شده، لیستی از کارهایی که باید انجام دهید بنویسید. این موضوع، کارِ شما را چند ماه جلو می اندازد و احتمالا وسوسه شوید به همین قسمت اکتفا کنید. اما اکتفا نکنید.معمولا جالب ترین دیدگاه ها و بازخورد ها نسبت به بازی تان را از طریق مشاهده ی ویدیو ها به دست خواهید آورد. برایتان خیلی جالب خواهد بود ببینید تستر ها وقتی فکر میکنند کسی آنها را تماشا نمی کند، چه کارهای انجام میدهند.Motion Twin از تجربه اش چنین می گوید که : "در ویدیو ها، تستر ها همه جور اطلاعاتی به ما دادند. بعضی هر کاری که هنگام تست انجام میدادند را با گزارش روی ویدیو ثبت کردند، بعضی حین بازی آواز میخواندند و بالا پایین میپریدند و بعضی در حالی که زیرلب ناسزا میگفتند با عصبانیت از بازی خارج شدند."مرحله بعدی پرسشنامه است. اگر شما هم از Google Form استفاده کنید، مشکل خاصی در تحلیل داده ها و استنباط نتیجه نخواهید داشت. Motion Twin نیز با کمک این ابزار بعد از تست به این نتیجه رسیده بودند که بازی شان از نظر زیبایی شناسی برای خانم ها بسیار جذاب بوده، اما گیم پلی بیشتر مورد علاقه مردان جوان (و گیمرهای حرفه ای) قرار گرفته.جمع بندیبه طور خلاصه، انجام پلی تست برای بازخوردهایی که در اختیارتان قرار میدهد، بسیار مفید و ضروری است. اما مهمتر از این اطلاعات، فرایندِ کلی انجام پلی تست است. بازی سازان مستقل اکثرا جنبه ی بازاریابی بازی شان را فراموش میکنند. انجام یک پلی تست در مقیاس کوچک به بهترین شکل به شما کمک میکند تا روی ساخت محصولی تمرکز کنید که نه تنها جذاب باشد، بلکه مخاطبینی داشته باشد که دوست دارند آن را بازی کنند و به سرعت از آن خارج نشوند.منبع: motion-twinترجمه شده در شماره 26 بازینامه محمد علیزاده محمد علیزاده Wed, 13 May 2020 01:22:01 +0430