مسئله‌ای که باید حل می‌کردم
دکمه باید سریع پاسخ لمس را نشان بدهد، ولی حرکت کوچک آن نباید اجرای خرید یا شروع بازی را در اختیار بگیرد. من این دو مسئولیت را جدا کردم.
پیاده‌سازی در نسخهٔ فعلی
ButtonPressFeedback رویدادهای PointerDown، PointerUp و PointerExit را برای تغییر مقیاس می‌گیرد. PointerClick فقط صدای بازخورد را اجرا می‌کنه؛ کار اصلی دکمه در listener خودش باقی می‌ماند.
تصمیم و هزینهٔ طراحی
اگر USE_DOTWEEN فعال باشد از tween استفاده می‌شود و در غیر این صورت coroutine مسیر جایگزین هست. گزینهٔ زمان مستقل اجازه می‌دهد توقف زمان بازی بازخورد رابط را منجمد نکند.
مرزهای فعلی
OnDisable حرکت فعال را متوقف و مقیاس اصلی را برمی‌گرداند. با این حال حس لمس، overlap و صدا در دستگاه واقعی نیاز به بررسی دارن؛ دو مسیر اجرا خودکار هم‌کیفیت بودن را ثابت نمی‌کنند.
سناریوهای بررسی و معنای قرارداد
سناریوی ساده برای بررسی این جزء، فشردن دکمه و بیرون بردن انگشت پیش از رها کردن آن هست. در چنین حالتی بازیکن انتظار داره دکمه به اندازهٔ عادی برگردد، حتی اگر کلیک نهایی اتفاق نیفتد. جدا کردن PointerExit از PointerClick همین تفاوت را قابل توضیح می‌کنه. سناریوی دیگر بستن پنل در میانهٔ حرکت هست: اگر مقیاس کوچک در شیء باقی بماند، باز کردن دوبارهٔ پنل ظاهر خراب ایجاد می‌کنه. بازگرداندن مقدار اولیه در OnDisable برای همین چرخه اهمیت داره؛ این رفتار دربارهٔ ظاهر دکمه هست و مجوز اجرای عمل اقتصادی یا تغییر صحنه را صادر نمی‌کنه.
وجود دو مسیر حرکت، یک انتخاب وابسته به پروژه هست. پروژه‌ای که DOTween داره می‌تواند از همان ابزار استفاده کنه؛ پروژه‌ای بدون آن همچنان مسیر coroutine را در اختیار داره. در عوض، هر تغییر در زمان، منحنی حرکت یا توقف باید در هر دو مسیر بررسی بشه. برای ارزیابی رابط، فقط دیدن یک کلیک با ماوس کافی نیست: لمس سریع پشت سر هم، تغییر پنل، توقف بازی و خروج انگشت از محدوده هر کدوم پرسش متفاوتی دارن. معیار من در این مرحله این هست که بازخورد به لمس پاسخ بدهد و پایان مشخص داشته باشد، بدون آنکه شنوندهٔ اصلی دکمه به زمان انیمیشن وابسته بشه.
از نگاه طراحی، اندازهٔ حرکت باید با فضای واقعی اطراف دکمه بررسی بشه. کوچک شدن کارت تعاملی کنار دکمهٔ دیگر ممکنه حس خوبی داشته باشد، ولی ترتیب لایه‌ها و محدودهٔ لمس همچنان مسائل جدا هستند. من در مرور این جزء، صدای کلیک را نیز از انجام عمل اصلی جدا نگه می‌دارم تا خاموش کردن صدا یا نبودن جزء صوتی معنای دکمه را تغییر ندهد.
چیزی که از این مرحله یاد گرفتم
برای من، یک جزء کوچک و قابل استفادهٔ مجدد بهتر از کپی انیمیشن در هر صفحه بود. رابط می‌تواند زنده‌تر بشه و قانون خرید یا بازی همچنان در جای خودش بماند.
مثال عملی بازخورد دکمهٔ بازی
اگر بخواهی بازخورد دکمهٔ بازی را در یک پروژهٔ کوچک بررسی کنی، بهتر است از یک موقعیت محدود شروع کنی. یک دکمهٔ غیرفعال، در حال پردازش و آمادهٔ کلیک را کنار هم بررسی کن. ورودی را ثابت نگه دار و نتیجهٔ مورد انتظار را پیش از اجرای نسخه بنویس. این کار کمک می‌کند تفاوت میان رفتار منطقی و چیزی که صرفاً روی صفحه دیده می‌شود روشن بماند. سناریوی این بخش آموزشی است و ادعای نتیجهٔ واقعی یک آزمایش روی کاربران دلو ندارد.
خطای رایج و علت آن
پخش صدا یا حرکت دکمه پیش از پذیرفته شدن عملیات، احساس موفقیت کاذب می‌سازد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. بازخورد بصری و صوتی باید وضعیت عمل را توضیح دهند. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
کلیک سریع تکراری نباید عملیات را چند بار اجرا کند و حالت پردازش باید دیده شود. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک دکمهٔ غیرفعال، در حال پردازش و آمادهٔ کلیک را کنار هم بررسی کن. |
| ریسک اصلی | پخش صدا یا حرکت دکمه پیش از پذیرفته شدن عملیات، احساس موفقیت کاذب می‌سازد. |
| روش بررسی | کلیک سریع تکراری نباید عملیات را چند بار اجرا کند و حالت پردازش باید دیده شود. |
| مرز نتیجه‌گیری | بازخورد بصری و صوتی باید وضعیت عمل را توضیح دهند. |
پرسش‌های کاربردی دربارهٔ بازخورد دکمهٔ بازی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک دکمهٔ غیرفعال، در حال پردازش و آمادهٔ کلیک را کنار هم بررسی کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. کلیک سریع تکراری نباید عملیات را چند بار اجرا کند و حالت پردازش باید دیده شود. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. بازخورد بصری و صوتی باید وضعیت عمل را توضیح دهند.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
