مسئله‌ای که باید حل می‌کردم
اضافه‌شدن پاسور باید هم حالت انتخاب‌شده را درست منتقل کنه و هم رویداد عمومی معتبر بسازد. من ورود پرداخت‌شده و تله‌متری را ادامهٔ ساختار مشترک دیدم، با حفظ اعتبار کار هم‌تیمی‌ام.
پیاده‌سازی در نسخهٔ فعلی
PasurMatchLaunch.Set فقط دو یا چهار نفر و مقصد معتبر می‌گیرد. TryConsume داده را یک بار مصرف می‌کنه و نام صحنه را تطبیق می‌دهد؛ انتخاب باقی‌مانده نباید بی‌صدا وارد مقصد اشتباه بشه.
تصمیم و هزینهٔ طراحی
PasurGameplayTelemetry برای deal، move و round مجموعهٔ dedup نگه می‌دارد. TrackAcceptedPlay فقط حرکت pending معتبر را می‌شمارد و Emit استثنا را می‌گیرد تا آنالیتیکس جریان بازی را متوقف نکند.
مرزهای فعلی
جلوگیری از تکرار در عمر همان نمونه برقرار هست و یکتایی پایدار سمت سرور را به تنهایی ثابت نمی‌کنه. سورس PHP اکنون موجود هست، اما شکست ارسال را نباید شکست عمل بازی یا مدرک تحویل آینده شمرد.
سناریوهای بررسی و معنای قرارداد
انتخاب تعداد نفرات یک دادهٔ گذرای ورود هست و اگر بی‌قاعده باقی بماند، ورود بعدی ممکنه انتخاب قبلی را ناخواسته مصرف کنه. Set تنها دو یا چهار نفر را می‌پذیرد و مقصد معتبر می‌خواهد؛ TryConsume این تحویل را یک‌بار مصرف می‌کنه و نام صحنهٔ واقعی را هم می‌سنجد. این جزئیات کمک می‌کنه منوی مشترک و runner پاسور روی یک قرارداد کوچک توافق کنن. در روایت همکاری، قانون بازی همچنان کار هم‌تیمی‌ام هست و این مرز دربارهٔ وصل کردن آن به جریان محصول هست. هزینهٔ ورود با سکهٔ داخلی را نیز با خرید واقعی پولی یا پرداخت تولیدی یکی نمی‌گیرم.
تله‌متری باید از عمل پذیرفته‌شده ساخته بشه. نگه داشتن مجموعه‌های جلوگیری از تکرار برای پخش، حرکت و دور کمک می‌کنه فراخوانی دوباره در همان نمونه لزوماً رویداد دوباره نسازد. با این حال این حافظه به معنای یکتایی پایدار در همهٔ اجراها نیست. Catch کردن خطای ارسال نیز فقط جریان بازی را از خطای گزارش جدا می‌کنه؛ شکست گزارش نه شکست جمع کارت هست و نه تضمین تحویل بعدی. اکنون کد سرور Bunny Circus Analytics نیز در منبع موجود هست و می‌شود قرارداد ذخیره و گزارش را جدا بررسی کرد. وجود آن کد به خودی خود ادعای حجم ترافیک زنده یا کیفیت عملیاتی نمی‌سازد.
اگر مقصد با انتخاب ذخیره‌شده هماهنگ نباشد، مصرف نکردن بی‌قاعدهٔ داده از اجرای حالت اشتباه بهتر قابل توضیح هست. قرارداد یک‌بارمصرف به runner اجازه می‌دهد تشخیص دهد ورودی از کدوم جریان آمده هست. در گزارش نیز تعداد رویدادهای پذیرفته‌شده را به تعداد لمس تبدیل نمی‌کنم؛ یک درخواست نامعتبر نباید به عنوان حرکت معتبر ثبت بشه. این دقت مرز اتصال محصول و قوانین نوشته‌شدهٔ هم‌تیمی‌ام را روشن نگه می‌دارد.
چیزی که از این مرحله یاد گرفتم
برای من، ادغام موفق قراردادهای کوچک می‌خواهد: مقصد درست، حالت درست و رویداد برآمده از عمل عمومی واقعی. این روایت دربارهٔ اتصال کار هم‌تیمی‌ام هست و کیفیت زندهٔ سرور را از کد Unity ادعا نمی‌کنه.
مثال عملی تله‌متری ورود پاسور
اگر بخواهی تله‌متری ورود پاسور را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. مسیر ورود به پاسور، آغاز دست و پایان نتیجه را با رویدادهای جدا دنبال کن. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
نام‌های مشترک بدون مشخص کردن حالت بازی، دادهٔ حکم و پاسور را مخلوط می‌کنند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. اعداد معرفی محصول با دادهٔ آزمایشی یا پیش از عرضه نباید آمار عمومی کاربران معرفی شوند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
نام حالت، نسخهٔ بازی و نتیجهٔ رویداد را در یک نشست آزمایشی تطبیق بده. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | مسیر ورود به پاسور، آغاز دست و پایان نتیجه را با رویدادهای جدا دنبال کن. |
| ریسک اصلی | نام‌های مشترک بدون مشخص کردن حالت بازی، دادهٔ حکم و پاسور را مخلوط می‌کنند. |
| روش بررسی | نام حالت، نسخهٔ بازی و نتیجهٔ رویداد را در یک نشست آزمایشی تطبیق بده. |
| مرز نتیجه‌گیری | اعداد معرفی محصول با دادهٔ آزمایشی یا پیش از عرضه نباید آمار عمومی کاربران معرفی شوند. |
پرسش‌های کاربردی دربارهٔ تله‌متری ورود پاسور
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: مسیر ورود به پاسور، آغاز دست و پایان نتیجه را با رویدادهای جدا دنبال کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. نام حالت، نسخهٔ بازی و نتیجهٔ رویداد را در یک نشست آزمایشی تطبیق بده. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. اعداد معرفی محصول با دادهٔ آزمایشی یا پیش از عرضه نباید آمار عمومی کاربران معرفی شوند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
