قصد بازیکن را اسم‌گذاری کن
عمل ورودی قصدی مثل تأیید یا لغو را بیان می‌کنه؛ اتصال ورودی کنترل دستگاه را تعیین می‌کنه. سیستم ورودی یونیتی این جدایی را پشتیبانی می‌کنه. طراحی می‌تواند معنای یکسان را در لمس و صفحه‌کلید نگه داره، بدون پراکندن فرض دستگاه در قواعد بازی.
نام «تأیید» دربارهٔ قصد بازیکن هست، ولی Enter یا لمس یک دکمه دربارهٔ وسیلهٔ انجام آن هست. اگر همهٔ قانون‌های بازی مستقیم به یک کلید وابسته باشند، اضافه کردن کنترل دیگر تغییرهای زیادی می‌خواهد. در Input System یونیتی، action و binding برای جدا کردن این دو مفهوم به کار می‌روند. برای شروع فقط یک عمل مشخص انتخاب کن و ببین از دو مسیر چگونه به همان درخواست می‌رسی. لازم نیست از همان روز اول تمام دسته‌ها، وسیله‌ها و امکان شخصی‌سازی کلیدها را طراحی کنی؛ معنی یک عمل را درست و ثابت نگه دار.
یک تأیید روی دو وسیله
یک قصد تأیید را به صفحه‌کلید و کنترل لمس وصل کن. هر دو باید مسیر اعتبارسنجی یکسان داشته باشند. سپس با نگه داشتن کنترل یا لمس تکراری، تمرکز صفحه را تغییر دهید. هدف معنای ثابت هست، نه رفتار فیزیکی یکسان. بازیکن باید یک انتخاب پذیرفته‌شده بگیرد، نه حرکت اضافه ناشی از مدیریت مخصوص دستگاه.
ورودی بازی و رابط ممکنه در یک لحظه هر دو فعال باشند. وقتی پنجرهٔ تنظیمات باز هست، فشردن تأیید نباید ناخواسته کارت زیر آن را هم بازی کنه. برای هر زمینه مشخص کن کدوم مجموعهٔ عمل‌ها فعال هست و هنگام ورود و خروج از آن چه چیزی تغییر می‌کنه. همچنین دربارهٔ زمان واکنش دقیق باش: شروع فشار، نگه داشتن و رها کردن یک رویداد واحد نیستند. مستند Actions این مرحله‌های ورودی را شرح می‌دهد؛ انتخاب مرحله باید با معنی عمل هماهنگ باشد، وگرنه یک نگه داشتن ساده می‌تواند چند رفتار ناخواسته بسازد.
اجازهٔ حرکت بعد از ورودی بررسی می‌شود
بعد از دریافت تأیید، هنوز قانون باید تصمیم بگیرد حرکت مجاز هست یا نه. ورودی می‌گوید کسی خواسته کارت را بازی کنه، نه اینکه نوبتش هست و آن کارت قانونی هست. تمرین را با کلیک یا لمس در زمان اشتباه هم انجام بده و نتیجه را با کیبورد مقایسه کن. اگر دو مسیر پاسخ متفاوت می‌دهند، ببین یکی مستقیم امتیاز یا مالکیت را تغییر می‌دهد و دیگری از اعتبارسنجی می‌گذرد. پایان خوب این تمرین یک درخواست مشترک با نتیجهٔ یکسان هست؛ دستگاه ورودی عوض می‌شود، اما قانون پذیرفتن حرکت عوض نمی‌شود.
مطالعهٔ بیشتر: Unity Input System: Actions
برای یک مثال مرتبط، منوی دلو؛ راه کوتاه‌تر تا میز بازی را هم بخون.
مثال عملی قصد بازیکن در ورودی
یک روش کاربردی برای بررسی قصد بازیکن در ورودی این است که به جای چند تغییر هم‌زمان، تنها یک مسیر کوتاه بسازی. یک عمل انتخاب کارت را با ماوس، لمس و کلید اجرا کن. سپس وضعیت قبل و بعد را کنار هم قرار بده. چه بخشی از داده تغییر کرده و کدام بخش فقط ظاهر تازه‌ای پیدا کرده است؟ پاسخ باید از همان تعریف موضوع بیاید. این موقعیت یک مثال آموزشی است و آمار واقعی محصول یا وعدهٔ قابلیت جدید محسوب نمی‌شود.
خطای رایج و علت آن
وابسته شدن قانون به یک دکمهٔ فیزیکی، پشتیبانی دستگاه دیگر را پرهزینه می‌کند. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. تعریف action و binding در Input System به نسخهٔ پکیج و دستگاه هدف وابسته است. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
همهٔ ورودی‌ها باید یک قصد و یک نتیجهٔ معتبر بسازند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | یک عمل انتخاب کارت را با ماوس، لمس و کلید اجرا کن. |
| ریسک اصلی | وابسته شدن قانون به یک دکمهٔ فیزیکی، پشتیبانی دستگاه دیگر را پرهزینه می‌کند. |
| روش بررسی | همهٔ ورودی‌ها باید یک قصد و یک نتیجهٔ معتبر بسازند. |
| مرز نتیجه‌گیری | تعریف action و binding در Input System به نسخهٔ پکیج و دستگاه هدف وابسته است. |
پرسش‌های کاربردی دربارهٔ قصد بازیکن در ورودی
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: یک عمل انتخاب کارت را با ماوس، لمس و کلید اجرا کن. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. همهٔ ورودی‌ها باید یک قصد و یک نتیجهٔ معتبر بسازند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. تعریف action و binding در Input System به نسخهٔ پکیج و دستگاه هدف وابسته است.
برای ادامهٔ همین موضوع، نمونهٔ اولیهٔ بازی؛ چه چیزی را باید زود امتحان کنیم؟ را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
برای قرارداد action و binding به راهنمای رسمی Input System نسخهٔ ۱٫۱۱ مراجعه کن و مستندات را با نسخهٔ نصب‌شدهٔ پکیج تطبیق بده.
