دستگاههای Android در شکلها و اندازههای مختلفی عرضه میشوند. با فعال کردن بازیکنان در هر جایی که میخواهند بازی کنند، چه تلفن، رایانه لوحی، رایانه، تلویزیون، خودرو، یا هدست واقعیت گسترده باشد، دسترسی بازیتان را گسترش دهید. در اینجا با این موارد آشنا میشوید:
- چگونه پشتیبانی از موشواره و صفحهکلید میتواند بازی شما را به بازیکنان در رایانه و ChromeOS برساند و همچنین قابلیت بازی در دستگاههای با صفحهنمایش بزرگ را بهبود بخشد.
- نحوه ملاقات با وفادارترین بازیکنان در جایی که هستند با ادغام کنترلگر بازی.
- نحوه افزودن پشتیبانی از قلم برای شیوه بازی دقیق و واکنشگرا درحال حرکت.
- نحوه پشتیبانی از کنترلر تلویزیون و باز کردن قفل بزرگترین صفحهنمایشی که بازیکنان شما دارند: تلویزیون آنها.
- ملاحظات طراحی درباره زمان جابهجایی بین روشهای ورودی.
- بازیهای چندضریب شکلی برای پشتیبانی از اولویتهای ورودی بازیکنان چه میکنند.
- و بسیار بیشتر.
سازگاری خودکار
Android درصورت امکان سازگاری خودکار بدون لمس دارد، برای مثال:
dispatchTouchEvent/onTouchEventحتی برای کلیکها یا ورودی قلم، با رویدادهای حرکتی پاسخ میدهد. این یعنی اگر نوع ابزار را بررسی نکنید، منطق مدیریت لمس شما باید با موشواره و قلم کار کند.- برخیاز رویدادهای دسته بازی و کنترلر تلویزیون که مدیریت نشدهاند، بهعنوان رویدادهای صفحهکلید دوباره منتشر میشوند.
ضریبهای شکل شبیه رایانه مانند «بازیهای Play» و ChromeOS بهطور پیشفرض از کلیکهای موشواره برای تولید لمس استفاده میکنند. ازآنجاییکه ممکن است صفحهنمایش لمسی برای استفاده وجود نداشته باشد، این ویژگی سطح پایه سازگاری را فراهم میکند.
رویدادهای دسته بازی و کنترلکننده تلویزیون که مدیریت نشدهاند دوباره بهعنوان رویدادهای صفحهکلید منتشر میشوند.
عوامل شکل شبیه رایانه مانند «بازیهای Play» و ChromeOS بهطور پیشفرض رویدادهای لمسی تولید میکنند تا سازگاری با بازیهایی که ورودی صفحهلمسی را انتظار دارند، به حداکثر برسانند.
برای ارائه بهترین تجربه کاربری، بهجای تکیه بر سازگاری خودکار، پشتیبانی مستقیم از ورودیهای غیرلمسی را پیادهسازی کنید.
پشتیبانی از همه ضرایب شکل
Android روی فهرست روبهرشدی از دستگاهها اجرا میشود. چه بازیکنان شما تلفنشان را باز کنند و به رایانه لوحی با صفحهنمایش بزرگ تبدیل کنند، چه تلویزیون سازگار با Android خود را روشن کنند، چه بازی Android را در Chromebook خود باز کنند، یا چه درحال انتظار برای شارژ شدن خودروشان بازی سریعی را در آن اجرا کنند، میتوانید بازیکنان خود را در مکانهای بیشتر و در نمایشگرهای بیشتری نسبتبه قبل جذب کنید. فقط باید مطمئن شوید که بازیتان در جایی که بازیکنان شما هستند قابل بازی کردن باشد:
| ضریب شکل | ورودی پیشفرض معمول | صفحه لمسی | موشواره و صفحهکلید | پد بازی | قلم۱ | پد کنترل ۵ جهته |
|---|---|---|---|---|---|---|
| تلفن | صفحه لمسی | بله | بله | بله | بله | بله |
| صفحهنمایش بزرگ | صفحه لمسی | بله | بله | بله | بله | بله |
| PC2 | موشواره و صفحهکلید | نه | بله | بله | نه | نه |
| ChromeOS۳ | صفحه لمسی، موشواره، و صفحهکلید | گاهی | بله | بله | بله | بله |
| تلویزیون | پد کنترل ۵ جهته | نه | بله | بله | نه | بله |
| خودرو۴ (سیستمعامل Automotive) |
صفحه لمسی | بله | بله | بله | نه | بله |
| تماشا۵ | صفحه لمسی | بله | نه | نه | نه | نه |
این جدول برای کمک به شما در اولویتبندی پشتیبانی از سازوکارهای ورودی جدید با برجسته کردن ورودی موردانتظار در هر ضریب شکل طراحی شده است. بهیاد داشته باشید که باید:
- از داشتن یک سازوکار ورودی پیشفرض اجتناب کنید. انجام این کار ممکن است بهطور ناخواسته دسترسی به تلاشهای غیرلمسی شما را محدود کند. برای مثال، اگرچه اکثر بازیکنان میخواهند بازیهای ChromeOS را با موشواره و صفحهکلید انجام دهند، برخیاز آنها ممکن است بسته به نمایه دستگاهشان همچنان به پشتیبانی از صفحه لمسی نیاز داشته باشند.
- از قفل کردن سازوکارهای ورودی به ضریبهای شکل خودداری کنید. Android با انواع مختلف لوازم جانبی کار میکند و دستگاههای ترکیبی محبوبتر میشوند. اگر بازیکن رایانه لوحیای داشته باشد که با صفحهکلید جداشدنی عرضه شده است، برداشتن پشتیبانی از صفحهکلید از نسخه تلفن ممکن است باعث شود بازی شما ناقص بهنظر برسد.
ورودی موشواره
بزرگترین و فراگیرترین صفحهنمایش بازیکن ممکن است Android را اجرا کند، خواه رایانه کیفی ChromeOS، رایانه لوحی Android، یا رایانه باشد. بازیکنان اغلب انتظار دارند که در این دستگاهها با موشواره بازی کنند و افزودن پشتیبانی میتواند تعامل بازیکنان را افزایش دهد. Android از ویژگیهای معمول سیستمعاملهای رایانه پشتیبانی میکند، ازجمله:
- پشتیبانی از کلیک چپ، راست، و وسط و همچنین دکمههای اضافی مثل عقب و جلو
- تشخیص چرخ پیمایش
- گزارش حرکت موشواره بهصورت مطلق یا نسبی (که بهعنوان ضبط اشارهگر نیز شناخته میشود)
- امکان تعریف نمادهای اشارهگر سفارشی
راهنماهای مختص ضریب شکل برای موارد زیر وجود دارد:
ورودی صفحه لمسی
ضبط ورودی صفحه لمسی در Android کمی با پشتیبانی از موشواره متفاوت است. هنگام فراخوانی requestPointerCapture()، درخواست دسترسی خام به لمسهای روی پد را دارید. این یعنی برای هر لمس رویداد دریافت میکنید، درست مثل اینکه رویدادهای چندلمسی را از صفحهنمایش لمسی دریافت میکنید، با این تفاوت که مختصات در فضای مختصات صفحه لمسی است نه در فضای مختصات نمایشگر. تشخیص اشاره صفحه لمسی داخلی Android و فیلتر کردن کف دست در این حالت غیرفعال است. برای مثال، اگر کاربر یک انگشت خود را روی پد حرکت میدهد و درعینحال انگشت شست خود را در گوشه پایین سمت چپ آماده کلیک کردن نگه داشته است، بازی شما باید تعیین کند که حرکت کدام انگشت باید در منطق شما استفاده شود (برای مثال، برای حرکت دادن دوربین).
این یعنی از دستههای بازی با صفحه لمسی داخلی میتوان مانند صفحه لمسی برای ورودی قوی مبتنی بر اشاره استفاده کرد.
برای تعیین اینکه بازیکن شما درطول ضبط اشارهگر از موشواره یا صفحه لمسی استفاده میکند، مقادیر منبع را از InputDevice#getSources() یا MotionEvent#getSource() برای InputDevice.SOURCE_TOUCHPAD بررسی کنید.
ورودی صفحهکلید
پشتیبانی از صفحهکلید تقریباً در همه دستگاههای Android وجود دارد. بسته به نوع بازیای که توسعه میدهید، مزایای افزودن آگاهی از صفحهکلید به بازیتان از افزایش پایگاه بازیکنان با دردسترستر کردن بازیتان تا فراگیرتر و شهودیتر کردن بازیتان برای بازی کردن متغیر است.
برخیاز روشهای رایج برای بهبود بازی با پشتیبانی از صفحهکلید:
- مکانیک چندلمسی باید به صفحهکلید دستگاههای غیرلمسی نگاشت شود. بازیهایی که به دو یا چند لمس همزمان نیاز دارند، مثل حرکت کردن و پریدن، از نگاشت این کنشها به فشردن کلیدهای صفحهکلید بهره میبرند تا قابلیت بازی کردن در صفحهنمایشهای بزرگ و صفحهنمایشهای غیرلمسی بهبود یابد.
- منوها با صفحهکلید پیمایشپذیر میشوند. افزودن پیمایش دکمهای، مانند کلیدهای جهتنما و Enter، به منوها و عناصر ثابت شیوه بازی، امکان بازی کردن در تلویزیون را فراهم میکند و دسترسپذیری را در همه ابعاد بهبود میبخشد.
- افزودن کلیدهای میانبر برای کنشهای روی صفحه. هر چیزی را که بازیکن میتواند روی صفحهنمایش لمس کند به کنش صفحهکلید تخصیص دهید. دسترسی سریع به کنشهایی مثل انتخاب واحدها در بازی استراتژیک یا فعال کردن جایگاههای انبار در بازی اکشن باعث میشود بازیکنان در بازی شما غرق شوند.
بهخاطر داشته باشید که اگرچه صفحهکلیدهای QWERTY نسبتاً رایج هستند، اما چیدمانهای محبوب مختلفی وجود دارد و برخیاز نویسههایی که در یک چیدمان با یکبار فشار دادن کلید تایپ میشوند، ممکن است در چیدمان دیگری نیاز به فشار دادن همزمان چند کلید داشته باشند.
اگر بازی شما از موقعیت نسبی کلیدها برای انجام کنشها استفاده میکند، مثلاً استفاده از W، A، S، و D مانند کلیدهای جهتنما برای حرکت، از InputDevice.getKeyCodeforKeyLocation() برای نگاشت مکان کلید QWERTY به کد کلید در KeyEvent.getKeyCode() استفاده کنید. اگر چیدمان پخشکننده تغییر کند، onInputDeviceChanged() فراخوانده میشود.
هنگام افزودن ورودی نوشتاری به بازی، TextInput in GameActivity سازوکاری برای مدیریت مطمئن ورودی IME، نشانههای سجاوندی، یا دیگر تغییرات خاص منطقه در چیدمان ارائه میدهد و درعینحال از موتور پردازش نوشتار درونبازی شما استفاده میکند. این کار از بسیاری از مشکلات مربوط به مدیریت مستقیم ورودی صفحهکلید یا استفاده از ابزاره EditText خارج از صفحه جلوگیری میکند.
ورودی دسته بازی
دستههای بازی بهطور رسمی در سراسر Android پشتیبانی میشوند، ازجمله رویدادهای اتصال و قطع اتصال، پشتیبانی لمسی، پشتیبانی ورودی پیشرفته ازجمله ژیروسکوپ، و پشتیبانی خروجی مانند رنگ روشن درصورت دردسترس بودن.
توسعهدهندگان نرمافزار میتوانند ازطریق View یا Activity پاسخبرگها به ورودیهای پد بازی گوش دهند، اما به توسعهدهندگان بازی توصیه میشود از کتابخانه کنترلکننده بازی استفاده کنند که:
- به زبان C++ نوشته شده است تا یکپارچهسازی در موتور بازی خودتان را تسهیل کند
- همه ویژگیهای دستهبازی را در یک API متمرکز میکند
- نمادهای روی دکمههای دسته بازی را ابهامزدایی میکند تا برچسبهای بازی شما با دسته بازی بازیکن مطابقت داشته باشد
- گزارش رویدادهای دسته بازی را در مواردی که دکمهها در برخیاز دستههای بازی ورودیهای آنالوگ و در برخی دیگر ورودیهای باینری هستند یکپارچه میکند
- سازگاری محدود با دستگاههای Android قدیمیتر برای دستههای بازی جدیدتر را فراهم میکند
ورودی قلم
Android در اکثر دستگاهها پشتیبانی پیشرفته از قلم دارد، ازجمله تشخیص فشار، جهت، کج کردن، نگه داشتن، و کف دست. رویدادهای قلم برای کمک به سازگاری به فراخوانهای لمسی ارسال میشوند، اما مهم است که با دستگاه قلم آزمایش کنید تا درصورتیکه منطق موتور شما این رویدادها را فیلتر میکند، متوجه شوید. ادغام کامل برای بازیهایی که هدفهای لمسی کوچک دارند یا بازیهایی که طراحی با قالب آزاد در آنها طبیعی بهنظر میرسد مفید است.
وقتی رندر کردن از حرکت قلم عقب میماند، تأخیر بیشتر از زمانی که با انگشت مسدود میشود یا از صفحهنمایش جدا میشود (مانند صفحهکلید، موشواره، یا دسته بازی) آشکار میشود. به همین دلیل، Android یک خط لوله با تأخیر کم برای رندر کردن خطوط با تأخیر بسیار کم (۴ میلیثانیه) از حرکت قلم تا نمایش روی صفحه ارائه میدهد. سه روش وجود دارد که بازی شما میتواند از این قابلیت بهره ببرد و باعث شود بازی شما مستقیماً به دنیای واقعی متصل شود:
- کتابخانه Jetpack Ink یک جعبهابزار مناسب برای افزودن رندرینگ قلمضربه واکنشگرا به هر پروژه Android ارائه میدهد.
- برای بازیهایی که نمیتوانند یا نمیخواهند برای پردازش ضربه به عنصر Kotlin تکیه کنند، کد منبع کامل C++ دردسترس است. این کار به توسعهدهندگان امکان میدهد آنچه را نیاز دارند مستقیماً در فناوری خود ادغام کنند.
- برای بازیهایی که به ادغام سفارشی کامل نیاز دارند، میتوان منطق پرداز سفارشی را مستقیماً روی میانگیر جلو اجرا کرد تا هم پاسخگویی و هم کنترل به حداکثر برسد.
کنترلکنندههای تلویزیون
دستگاههای Android TV با کنترل از راه دوری ارائه میشوند که شامل پد کنترل ۵ جهته است که از چهار جهت اصلی و دکمه تأیید تشکیل شده است. برنامههایی که از سیستم ابزارک داخلی Android استفاده میکنند بهطور پیشفرض از این ابزارکها پشتیبانی میکنند، اما توسعهدهندگان باید ابزارکهای سفارشی بازی خود را آزمایش کنند تا سازگاری آنها را در دستگاههای تلویزیون حفظ کنند.
برای کسب اطلاعات بیشتر، به اسناد Android TV مراجعه کنید.
سایر ملاحظات
برای ارائه بهترین تجربه به بازیکنان، بازی را براساس چندین شکل ورودی طراحی کنید و بهسرعت بین آنها جابهجا شوید. بهاینترتیب، بازیکن میتواند بهسرعت بین روشهای ورودی مختلف بسته به حالت بازیای که در آن قرار دارد جابهجا شود، یا بازی میتواند بهراحتی بین پیکربندیهای مختلف یک دستگاه Android جابهجا شود.
با درنظر گرفتن این موضوع، توجه داشته باشید که:
- بررسی وجود نوعی ورودی بهتر از فیلتر کردن براساس ضریب شکل است. برای مثال، اگر فقط پشتیبانی از موشواره و صفحهکلید را در ChromeOS فعال کنید، بازیکنانی که از رایانه لوحی با صفحهکلید جداشدنی استفاده میکنند از تلاشهای اضافی شما بهرهمند نخواهند شد.
- ملاحظاتی خارج از ضریب شکل وجود دارد که بر بهترین شکل ورودی تأثیر میگذارد. برای مثال، نیازهای دسترسپذیری بازیکن ممکن است استفاده از موشواره یا صفحه لمسی را دشوار یا دردناک کند، اما دسته بازی یا صفحهکلید برای او ایدهآل باشد.
- هر نوع حمایتی بهتر از عدم حمایت است. بهتر است به تغییرات ورودی در لحظه پاسخ دهید، اما بازیکنان تا زمانی که بتوانند به آن دسترسی داشته باشند، از پشتیبانی اندک هم استقبال میکنند.
- بهترین ورودی ممکن است بین اجراهای بازی شما تغییر کند. برای مثال، هنگام بازی کردن درحال حرکت، نمایشگر لمسی ترجیح داده میشود، هنگام وصل کردن تلفن به تلویزیون، دسته بازی، و هنگام نشستن پشت میز، موشواره و صفحهکلید.
نحوه پاسخ دادن به ورودی کاربر
بازیهای معمول تلفن همراه از یک بازیکن در هر دستگاه پشتیبانی میکنند. برای بهترین نتایج، بازی به همه ورودیهای ممکن پاسخ میدهد و واسط کاربر را براساس آنچه بازیکن بهطور فعال استفاده میکند تغییر میدهد. بهاینترتیب، یک نسخه از بازی بهطور خودکار در همه ابعاد کار میکند و بازیکنان حتی میتوانند ورودیها را باهم ترکیب کنند تا با نیازهایشان مطابقت داشته باشد.
اغلب توسعهدهندگان میخواهند روش ورودی پیشفرضی با تأخیرهای داخلی داشته باشند تا بعداز آن واسط کاربر را تغییر دهند. این یعنی چه؟
- ازآنجاییکه اکثر بازیکنان در صفحههای لمسی بازی میکنند، کنترلهای لمسی را هنگام راهاندازی نمایش دهید. اگر بازیکنی با صفحهکلید یا دسته بازی شروع به بازی کند و برای مدتی از صفحه لمسی استفاده نکند، لایه لمسی را محو کنید.
- اگر بازیکنی از پد بازی استفاده میکند و کلید صفحهکلید را فشار میدهد، راهنماییهای درون بازی را تغییر دهید تا بهجای دکمههای پد بازی، دکمههای صفحهکلید را نشان دهد.
- وقتی بازیکنی بهطور همزمان از صفحهکلید و دستهبازی استفاده میکند، قبلاز اینکه میانای کاربر از یک مجموعه راهنمایی به مجموعه دیگر تغییر کند، تأخیری ایجاد کنید تا از پرش نمایشگر جلوگیری شود.
- هنگام پردازش ورودیها، نوع منبع ورودی را بررسی کنید؛ کلیدهای صفحهکلید و دکمههای دسته بازی هر دو رویدادهای کلید پایین را منتشر میکنند.
- سعی کنید ورودی را بهعنوان مدیریتشده علامتگذاری نکنید، مگر اینکه بازی شما بتواند آن را مدیریت کند. Android برخیاز رویدادها را دوباره منتشر میکند تا سازگاری در عوامل شکل جدیدتر را تسهیل کند، برای مثال، تبدیل دکمه A دسته بازی به دکمه تأیید.
پشتیبانی ورودی را در مانیفست خود شرح دهید
اگرچه الزامی نیست، اما بهتر است با پرچمهای ویژگی مانیفست حاشیهنویسی کنید که چه نوع ورودیهایی را مدیریت میکنید. پرچمهای رایج عبارتاند از:
android.hardware.type.pc: لایههای سازگاری ورودی را هم در ChromeOS و هم در رایانه غیرفعال کنید تا توسعهدهندگان بتوانند مستقیماً رویدادهای موشواره را مدیریت کنند. android:required="false"را تنظیم کنید تا بازی همچنان به تلفنها ارائه شود.android.hardware.gamepad: برنامهها و بازیها رویدادهای دسته بازی را دریافت میکنند، چه از دسته بازی پشتیبانی کنند چه نکنند. با تعریف این پرچم مانیفست و تنظیمandroid:required="false"، بازی شما میتواند به دستگاههای Android TV که دسته بازی به آنها متصل است ارائه شود.
-
سازندگان میتوانند پشتیبانی از قلم را برای برخیاز دستگاهها تعبیه کنند، اما هیچ فرم فاکتوری وجود ندارد که پشتیبانی در آن تضمین شده باشد. میتوانید پد طراحی را به دستگاه Android متصل کنید و بهعنوان قلم نمایش داده میشود. ↩
-
اگرچه برخیاز رایانهها از صفحه لمسی و قلم پشتیبانی میکنند، اما کارخواه «بازیهای Google Play» فقط به رویدادهای موشواره از سیستمعامل میزبان پاسخ میدهد. برای به حداکثر رساندن سازگاری، رویدادهای موشواره بهطور پیشفرض بهعنوان رویدادهای لمسی در کارخواه ظاهر میشوند. برای اطلاعات بیشتر، بخش ورودی موشواره را ببینید. ↩
-
دستگاههای ChromeOS معمولاً از موشواره و صفحهکلید پشتیبانی میکنند، اما صفحهنمایش لمسی اختیاری است. بسیاری از دستگاههای دارای صفحه لمسی از ورودی قلم نیز پشتیبانی میکنند. ↩
-
سیستم عامل Android Automotive به خودروهایی اشاره دارد که Android در آنها تعبیه شده است و میتوانند بدون تلفن Android کار کنند. این نمودار به Automotive OS اشاره دارد. Android Auto برنامهای را از تلفن به خودرو فرافکنی میکند و دستگاههایی که از Android Auto (فرافکنی) پشتیبانی میکنند ممکن است صفحه لمسی نداشته باشند. ↩
-
دستگاههای Wear OS اتصالپذیری محدودی دارند. میتوانید دستگاههای جانبی بلوتوث را اسکن کنید، اما سیستمعامل اغلب نمیتواند متصل شود. ↩