معرفی Bunny Circus Analytics
Bunny Circus Analytics ابزار تحلیل بازی هست که من، کیان پاک نعمت، برای داشتن مسیر سبک و قابل کنترل گزارش‌گیری ساخته‌ام. دلو از این ابزار استفاده می‌کنه، اما ساختار آن فقط برای یک بازی کارت نیست. می‌شود بازی دیگری تعریف کرد و رویدادها، تب‌ها و گزارش‌های خودش را به آن داد. منظور از سبک بودن، شروع با امکانات روشن و نگهداری قابل فهم هست؛ نه وعدهٔ ظرفیت نامحدود. اگر دنبال ابزاری هستی که سؤال‌های پروژهٔ کوچک خودت را به گزارش تبدیل کنه، این محصول نقطهٔ شروعی برای بررسی هست.
از یونیتی تا پنل خودمیزبان
ابزار دو بخش اصلی داره: بخشی که در بازی یونیتی رویدادها را می‌فرسته و پنلی که روی هاست خودت نصب می‌شود. نسخهٔ فعلی سرور با PHP کار می‌کنه و اطلاعات را در فایل‌های JSON نگه می‌دارد؛ برای اجرا به راه‌اندازی دیتابیس نیاز نداره. در پنل، هر بازی تنظیمات و کلید دریافت جدا داره. قالب کارت گیم، قالب تاور دیفنس و شروع خالی کمک می‌کنند از نمونه‌ای متناسب شروع کن. انتخاب قالب به معنی تولید خودکار رفتار بازی نیست؛ باید مشخص کن چه اتفاقی در خود بازی ثبت بشه.
گزارش را دور سؤال بساز
بخش جذاب برای من، ساخت گزارش متناسب با سؤال هست. می‌شود رویدادی مثل پایان مرحله را تعریف کرد، دادهٔ لازم آن را مشخص کرد و گزارش تعداد یا میانگین زمان ساخت. نمایش به شکل عدد، نمودار مقایسه‌ای، گزارش روزانه یا جدول در دسترس هست. فیلترها کمک می‌کنند مثلاً فقط نتیجه‌های برد را بررسی کن. تعریف گزارش‌ها نیز قابل خروجی‌گرفتن و استفاده در بازی دیگر هست، به شرط اینکه نام و معنای داده‌ها هماهنگ باشند. این روش اجازه می‌دهد سؤال تازه را بدون تغییر همهٔ صفحه‌های پنل دنبال کنیم.
قابلیت‌ها همراه با تعریف روشن
کلاینت یونیتی برای مشکل موقت اتصال صف محلی و تلاش مجدد داره. با این حال، صف و اندازهٔ رویدادها محدود هستند و رسیدن همهٔ داده‌ها تضمین نمی‌شود. در پنل نیز گزارش بازگشت روزهای یک، هفت و سی وجود داره که از نخستین مشاهدهٔ بازیکن حساب می‌شود. اطلاعات دستگاه فقط وقتی قابل نمایش هست که بازی آن را بفرستد. این مرزها کمک می‌کنند ابزار را درست به کار ببریم: گزارش رفتار، جای اندازه‌گیری عملکرد یا تأیید نتیجهٔ واقعی بازی را نمی‌گیرد و عددها باید در زمینهٔ خودشان خوانده بشن.
شروع کوچک و نگهداری مسئولانه
خودمیزبانی کنترل و مسئولیت را با هم می‌آورد. باید نصب مناسب، دسترسی پنل، پشتیبان‌گیری و آرشیو تاریخچه را جدی گرفت. نسخهٔ فعلی برای هاست کوچک و تاریخچهٔ محدود طراحی شده؛ رشد زیاد داده ممکنه به راهکار دیگری نیاز داشته باشد. برای شروع، یک رویداد آزمایشی بفرستید و گزارش همان را بررسی کن، سپس سراغ پرسش بعدی بروید. معرفی کامل در صفحهٔ محصول هست. سورس و راهنمای نصب را از GitHub بگیر و برای پیگیری یا تماس از تلگرام استفاده کن. این مسیر با یک سؤال کوچک، زودتر قابل ارزیابی می‌شود.
مثال عملی آنالیتیکس سبک یونیتی
اگر بخواهی آنالیتیکس سبک یونیتی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. رویداد پایان مسابقه با نتیجه و مدت ارسال می‌شود و در سرور فایل‌محور نگهداری می‌شود. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
ارسال همهٔ وضعیت بازی در هر رویداد، حجم و نگهداری را بی‌دلیل افزایش می‌دهد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. سبک بودن به تعریف داده، دفعات ارسال و نگهداری بستگی دارد، نه صرفاً نام ابزار. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
فقط دادهٔ لازم برای سؤال گزارش را بفرست و صف آفلاین و دریافت سرور را آزمایش کن. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | رویداد پایان مسابقه با نتیجه و مدت ارسال می‌شود و در سرور فایل‌محور نگهداری می‌شود. |
| ریسک اصلی | ارسال همهٔ وضعیت بازی در هر رویداد، حجم و نگهداری را بی‌دلیل افزایش می‌دهد. |
| روش بررسی | فقط دادهٔ لازم برای سؤال گزارش را بفرست و صف آفلاین و دریافت سرور را آزمایش کن. |
| مرز نتیجه‌گیری | سبک بودن به تعریف داده، دفعات ارسال و نگهداری بستگی دارد، نه صرفاً نام ابزار. |
پرسش‌های کاربردی دربارهٔ آنالیتیکس سبک یونیتی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: رویداد پایان مسابقه با نتیجه و مدت ارسال می‌شود و در سرور فایل‌محور نگهداری می‌شود. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. فقط دادهٔ لازم برای سؤال گزارش را بفرست و صف آفلاین و دریافت سرور را آزمایش کن. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. سبک بودن به تعریف داده، دفعات ارسال و نگهداری بستگی دارد، نه صرفاً نام ابزار.
برای ادامهٔ همین موضوع، آنالیتیکس چیست؟ از شمارش رویداد تا فهم مسیر بازیکن و Bunny Circus Analytics را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
