Продукти

Як провести гравця через гаманець і не втратити його на першому екрані

Гравця не «проводять» через гаманець — гаманець або стає невидимою частиною першої хвилини в грі, або блокує її. Різниця між цими двома сценаріями визначається не технологією як такою, а тим, де саме в потоці з’являється

Опубліковано 24.09.2026Оновлено 11.08.20268 хв читанняРедакція солана.укр
Редакційна ілюстрація до матеріалу про продукти та щоденний досвід Solana
editorial illustrationПродукти
Авторство Редакція солана.укрАктуальність оновлено 11.08.2026Формат редакційний матеріал

Коротко: що має значення для користувача

Гравця не «проводять» через гаманець — гаманець або стає невидимою частиною першої хвилини в грі, або блокує її. Різниця між цими двома сценаріями визначається не технологією як такою, а тим, де саме в потоці з’являється запит на підключення, що бачить людина на екрані й які рішення від неї вимагають до першої ігрової дії. Є кілька архітектурних підходів, кожен із яких переміщує тертя в різне місце. Жоден не усуває його повністю — але вони суттєво відрізняються за тим, хто цим тертям керує: розробник гри чи гравець.

Практичний сценарій

Усі існуючі підходи до онбордингу через гаманець у контексті ігор на Solana можна згрупувати у чотири сценарії. Кожен має власну логіку, власну точку відмови й власний набір компромісів.

Сценарій 1: Зовнішній гаманець — класичний потік

Гравець бачить кнопку «Connect Wallet», натискає її, потрапляє на екран вибору гаманця, встановлює розширення (якщо його немає), створює або імпортує гаманець, зберігає фразу відновлення, повертається в гру, підтверджує підключення. Перший екран гри в цьому сценарії — це не гра, а інструкція з налаштування інструмента.

Критерій перевірки: скільки екранів і переключень між вкладками розділяють момент «гравець відкрив гру» і момент «гравець робить першу ігрову дію». Якщо більше трьох — це класичний потік із високим ризиком відтоку.

Спостереження: цей підхід максимально прозорий щодо контролю: гравець володіє ключами з першої секунди. Але він же створює найвищій бар’єр входу для людини, яка прийшла грати, а не налаштовувати криптогаманець.

Сценарій 2: Вбудований гаманець усередині інтерфейсу гри

Гравець не залишає сторінку гри. Створення гаманця відбувається в модальному вікні або вбудованому блоці: вводить пароль, отримує адресу, продовжує грати. Фраза відновлення може показуватися пізніше або пропонуватися до збереження у вигляді файлу.

Критерій перевірки: чи залишається гравець на тому самому домені протягом усього процесу. Якщо так — це вбудований підхід. Додатково перевірити: де генеруються ключі (на клієнті чи на сервері) і чи має гравець експорт приватного ключа або фрази відновлення.

Ризик: якщо ключі генеруються на стороні сервера, гравець де-факто не контролює свій гаманець, навіть якщо інтерфейс здається «його». Це потрібно перевіряти технічно, а не за дизайном екрану.

Сценарій 3: Соціальний вхід із прихованим гаманцем

Гравець обирає «Увійти через Google» або «Увійти через Discord». Гаманець створюється в фоновому режимі на основі облікового запису. Гравець може навіть не знати, що у нього є гаманець у мережі Solana, поки не захоче вивести активи.

Критерій перевірки: що саме відбувається після натискання «Увійти через Google» — чи створюється налаштований гаманець у мережі Solana, чи це просто авторизація на сервері гри без блокчейн-ідентичності. Друге не є гаманцем, хоча інтерфейс може виглядати однаково.

Спостереження: цей підхід мінімізує тертя на вході, але максимізує непрозорість. Гравець не знає, де його ключі, як їх відновити без доступу до Google-акаунта й чи взагалі можливо їх відновити.

Сценарій 4: Кастодіальний старт із опцією експорту

Гравець реєструється як у звичайній грі: email, пароль. Гра створює гаманець на своєму сервері й керує ним від імені гравця. Пізніше, за бажанням, гравець може «забрати» свій гаманець — експортувати ключі й перейти на самостійне управління.

Критерій перевірки: чи існує реальний, технічно працюючий механізм експорту гаманця на момент перевірки, чи це лише заявлений у документації функціонал. Перевірити можна лише спробувавши експорт — або знайшовши підтвердження від незалежних джерел.

Сценарій Де тертя Хто контролює ключі з першої секунди Що перевірити
Зовнішній гаманець На вході: встановлення, переключення, фраза Гравець Кількість кроків до першої дії
Вбудований гаманець Усередині гри: пароль, фраза Залежить від реалізації Де генеруються ключі
Соціальний вхід Невидиме: перенесене на етап виводу Сервер гри (ймовірно) Чи створюється гаманець взагалі
Кастодіальний старт На виході: експорт, перевірка ключів Сервер гри Чи працює експорт реально

Кому потрібен цей контекст

Розробникам ігор на Solana — якщо гра орієнтована на широку аудиторію, а не лише на людей, які вже мають гаманець. Вибір сценарію онбордингу безпосередньо визначає, яка частка трафіку перетвориться на реальних гравців. Детальніше про загальний контекст ігор на Solana можна прочитати у матеріалі «Ігри на Solana: геймплей, економіка й користувацький досвід».

Продакт-менеджерам — щоб розуміти, що метрика «кількість підключених гаманців» не дорівнює метриці «кількість гравців, які зробили першу дію в грі». Між цими двома точками може лежати прірва, яку різні сценарії перекривають по-різному.

Гравцям — щоб розуміти, що відбувається, коли гра просить підключити гаманець або увійти через Google. Чи отримуєте ви контроль над своїми активами чи делегуєте його? Цей вибір не очевидний з інтерфейсу.

Цей матеріал не замінює сусідній — «Чи потрібен цій грі блокчейн: п’ять чесних критеріїв». Тут ми припускаємо, що рішення про використання блокчейну вже прийняте, і фокусуємося виключно на механіці проведення гравця через гаманець.

Що легко зрозуміти неправильно

Ризик: ілюзія контролю

Найнебезпечніша помилка — вважати, що якщо гравець бачить адресу свого гаманця в інтерфейсі гри, він цим гаманцем володіє. Візуальна наявність адреси не гарантує наявності приватного ключа на стороні клієнта. Це потрібно перевіряти архітектурно, а не візуально.

Спосіб перевірки: відкрити інструменти розробника в браузері, перевірити мережеві запити при створенні гаманця. Якщо ключі або зашифрована фраза відновлення генеруються локально — це клієнтський гаманець. Якщо сервер повертає готову адресу у відповідь на запит із email — це серверний гаманець.

Ризик: фраза відновлення як точка відмови

Навіть у вбудованих гаманцях, де ключі генеруються на клієнті, момент показу фрази відновлення часто стає точкою відтоку. Людина, яка прийшла грати, не готова до когнітивного навантаження «запиши дванадцять слів і сховай їх у безпечне місце». Деякі продукти відкладають цей крок — але тоді виникає ризик втрати доступу, якщо гравець забуде пароль до гри до того, як збереже фразу.

Критерій оцінки: чи пропонує продукт проміжне рішення — наприклад, зашифроване резервне копіювання в хмару з паролем від гри як ключем розшифрування. Це не ідеально з точки зору безпеки, але знижує відтоку на онбордингу.

Обмеження: немає універсального рішення

Кожен сценарій мінімізує одне тертя за рахунок створення іншого. Зовнішній гаманець дає контроль, але створює бар’єр входу. Соціальний вхід знімає бар’єр, але приховує контроль. Кастодіальний старт дає зручність, але створює залежність від сервера гри. Питання не в тому, який підхід «правильний», а в тому, який компроміс відповідає конкретному продукту й конкретній аудиторії.

Типова помилка: не розрізняти аудиторії

Гравець, який прийшов з DeFi-контексту й уже має Phantom, не потребує соціального входу. Гравець, який прийшов з App Store й ніколи не стикався з криптою, не готовий до фрази відновлення на першому екрані. Один продукт може пропонувати різні шляхи входу — але це ускладнює інфраструктуру. Перевірити, чи продукт пропонує різні потоки для різних сегментів, можна просто пройшовши онбординг із різних точок входу.

Який наступний крок має сенс

Якщо ви оцінюєте конкретну гру або продукт, скористайтеся цим переліком як чек-листом перевірки. Жоден пункт не вимагає спеціального обладнання — достатньо браузера й уважності.

  • Кількість екранів до першої ігрової дії. Відкрийте гру з чистого профілю браузера. Рахуйте кожен екран, модальне вікно й переключення вкладки до моменту, коли ви можете зробити щось ігрове. Фіксуйте результат.
  • Місце генерації ключів. Відкрийте мережеву панель браузера. Створіть гаманець у процесі онбордингу. Подивіться, чи генеруються ключі локально, чи сервер повертає готовий результат.
  • Наявність експорту.
  • Що показують дозволи гаманця. Якщо використовується зовнішній гаманець, перевірте, які саме дозволи запитує гра при підключенні. Чи запитує вона лише читання адреси, чи також доступ до підпису транзакцій і відправки коштів. Це критично для безпеки — детальніше у розділі «Безпека Solana: спокійно, конкретно, перевірено».
  • Що відбувається при втраті пароля. Спробуйте зрозуміти з інтерфейсу й документації, як відновити доступ, якщо гравець забув пароль до гри, але зберіг фразу відновлення — і навпаки.

Якщо ви розробник і плануєте реалізувати один із цих сценаріїв, корисний контекст є у матеріалі «Будувати на Solana: від ідеї до працюючого продукту». А якщо ви ще на етапі визначення, чи потрібен вашій грі блокчейн взагалі, почніть із п’яти чесних критеріїв.

Наступний логічний крок у цьому кластері — зрозуміти, що саме гравець отримує в результаті онбордингу: «Ігрові активи: коли право власності має сенс для гравця».

Усі продукти, про які йдеться в матеріалах кластера, зібрані на сторінці «Продукти Solana: що працює для людей».

Редакція солана.укр