Чому прототип мобільної гри потрібен до старту розробки
Механіка перевіряється лише в живій взаємодії. Відчуття керування складається із затримки між натисканням і реакцією, вікна введення, інерції персонажа та того, як камера слідує за дією — ні в описі, ні на папері це не відтворюється.
Поки ключову механіку не зібрано й не запущено в руках, команда сперечається про припущення, а не про гру.
Ранній прототип навмисно відмовляється від графіки, звуку та мета-шару: залишаються грубі блоки, фізика й керування. Це дає перевірку механік до релізу — на живих гравцях, а не на думці авторів, — і кожна ітерація коштує години правки замість тижнів переробки. Прототип мобільної гри в такому вигляді збирається за один-три тижні.
Пізні правки дорогі не самі по собі, а зв’язками. Коли механіка обросла анімаціями, балансом, інтерфейсом, прогресією та монетизацією, зміна одного параметра тягне перезбирання суміжних систем: заново налаштовується темп, перераховуються нагороди, розходиться крива складності.
Ризики пізніх правок у тому, що на момент перших реальних цифр утримання половина проєкту вже спирається на неперевірене рішення.
Ігрові гіпотези формулюємо як перевірювані твердження: чи зрозуміле керування без навчання, чи тримає цикл перших хвилин, чи відчувається нагорода.
Три-п’ять таких гіпотез ранній прототип закриває або відкидає до того, як у них вкладено місяці виробництва, — далі розбираємо, як це влаштовано.
Що дає рання перевірка гіпотез: строки, ризики, обсяг переробок
Правка в прототипі займає години, та сама правка в релізній збірці — тижні: спочатку міграція даних, потім перезбирання, потім регрес на десятку пристроїв.
Ранній етап стискає цикл правок із тижнів до днів, тому до продакшену доходить не перша придумана версія, а десята перевірена.
Основні механіки розкладаємо за рамкою MDA — правило та його відгук перевіряємо окремо від оформлення й мета-прогресії. Петля взаємодії збирається в найпростішому вигляді: дія, відгук, нагорода.
Якщо гравець не розуміє, навіщо натискати вдруге, це видно на першому ж тесті, а не через місяць за просілим утриманням.
Метрики прототипу — проксі для утримання гравців: час до першої осмисленої дії, частка тих, хто кинув на першому випробуванні, кількість замкнених петель за одну сесію.
Гіпотеза, що провалилася за цими числами, відсікається до того, як під неї написано інтерфейси, прогресію та економіку.
Відсікання гіпотез напряму ріже обсяг переробок: контент, який робили б під непідтверджене ядро, не йде в кошик — його просто не починають. За нашими проєктами частка таких робіт падає приблизно вдвічі, а час команди йде на те, що гравець уже підтвердив своєю поведінкою.
Формати перевірки: настільний тест, сірий блок, робоча збірка
Формати відрізняються глибиною достовірності: настільний тест перевіряє правило гри без жодного рядка коду, інтерактивний макет — реакцію на екрани та жести, а збірка без графіки — реальну логіку.
Чим ближчий формат до готової гри, тим дорожча правка: змінити правило на папері — година роботи, у вертикальному зрізі — тиждень переробок.
Порядок зазвичай такий: гіпотеза перевіряється настільним тестом, найризикованіші місця — сірим блоком, і лише потім збирається вертикальний зріз одного ігрового циклу. Так ми не витрачаємо час на малювання того, що може не вижити після першого тесту.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Настільний тест | Перевірити правило й баланс до розробки — картки, кубики, схема циклу | Немає відчуття від керування й темпу, складно зрозуміти, чи «залипає» гравець |
| Інтерактивний макет | Перевірити навігацію та потік екранів до коду | Реакція на дії умовна, баланс і економіка не перевіряються |
| Сірий блок (збірка без графіки) | Перевірити живу логіку й прогресію на людях | Візуал — заглушки, частина тестувальників відвалюється, не дійшовши до суті |
| Вертикальний зріз | Один ігровий цикл цілком: керування, графіка, звук, прогресія | Дорожчий і довший за інших, правки механік після збірки найзатратніші |
Формат обираємо під питання, на яке потрібна відповідь: незрозуміле правило — настільний тест, незрозуміла реакція на керування — вертикальний зріз.
Етапи роботи: від постановки гіпотези до передачі збірки
Прототип мобільної гри потрібен не для показу, а для відповіді на одне питання: чи працює ключова механіка. Тому маршрут будується навколо гіпотези та замірів, а не навколо обсягу контенту. Нижче — шість етапів, за якими ми ведемо роботу від ідеї до передачі збірки.
- Постановка гіпотези. Фіксуємо перевірюване твердження й метрику, яка його підтвердить: наприклад, частка гравців, які завершують перший цикл і запускають другий. Без критерію прототип перетворюється на набір екранів.
- Схема механік. Розкладаємо цикл на стани й переходи: що гравець робить, що отримує у відповідь, що повертає його після провалу. Правки на схемі дешевші за правки у збірці.
- Налаштування збірки. Один сценарій збірки під цільові платформи: версія ставиться на пристрої тестувальників без ручних правок і оновлюється за командою.
- Тестування механік. Знімаємо заміри на живих гравцях: час до першої осмисленої дії, частка покинутих сесій, повторні запуски. Окремо відзначаємо, де учасники діють навмання, — це ознака незрозумілого правила.
- Доопрацювання за замірами. Змінюємо один-два параметри за ітерацію та звіряємо з попередніми цифрами — так видно, що саме вплинуло на поведінку. Гіпотеза підтверджується або замінюється.
- Передача результату. Віддаємо збірку, схему механік, заміри та висновки: що підтвердилося, що відкинули. Команда розробки стартує від перевіреного ядра, не перепридумуючи правила.
Кожен етап закінчується артефактом, який можна подивитися й оспорити, — спірні рішення не спливають у середині розробки.
Комплект передачі: збірка, схема механік, звіт за замірами
Прототип потрібен не заради факту запуску на пристрої, а заради зафіксованих рішень. Тому етап закривається не показом збірки, а комплектом передачі: робочою збіркою, описом механік, замірами та регламентом запуску. Усе лежить у репозиторії замовника, щоб команді не довелося відновлювати логіку з листування.
- Вихідники збірки — проєкт цілком із профілями збірки та інструкцією розгортання на чистій машині: зібрати й запустити можна без нас.
- Схема механік — потік станів від введення до нарахування прогресу та умов виходу. Окремо позначено, що підтверджено заміром, а що залишилося гіпотезою.
- Звіт за замірами — час відгуку на слабкому пристрої, частка пройдених циклів, кроки, де гравці кидали. Сирі дані додані, висновки можна переперевірити.
- Регламент запуску — які параметри середовища потрібні, де зберігаються ключі, що вважається справним станом стенда.
- Конфігурації середовищ — окремі набори налаштувань під розробку, тестовий стенд і демонстрацію; балансні параметри винесені назовні й змінюються без перезбирання.
- Матриця перевірок — перелік сценаріїв приймання: що прогнано, на яких класах пристроїв і з яким результатом.
- Журнал рішень — чому вибрано такий темп циклу й спосіб введення. Саме це найчастіше губиться під час передачі.
Регламент запуску та схему механік ми розбираємо разом із командою замовника: показуємо, де що лежить, і відповідаємо щодо коду. Так прототип залишається робочою основою розробки, а не архівом.
Кейс: як ранній прогін петлі прибрав ризик перезапуску
Де стояла петля до
Проєкт — аркада з однією кнопкою: тап задає імпульс, далі поведінку визначає фізика. На закритому тесті до першої очкової дії доходили 34% гравців, а середній час до першого натискання становив 19 секунд, із яких 11 ішло на екрани навчання. Інструкцію проходили, але не пов’язували її з результатом — петля не замикалася.
Заміри ставили на кожен крок: показ екрана, перше натискання, перше очко, перший програш, вихід. Агрегована статистика Google Play не дає таких зрізів, тому події збирали в клієнті — це дало воронку за окремим гравцем, а не середні за застосунком.
Що змінили і чим підтвердили
Прибрали проміжний екран навчання, перший програш зробили без покарання — перезапуск в одну дію, а перший успіх зсунули на п’яту-сьому секунду. Криву складності перезібрали так, щоб перша перемога була майже гарантована, а друга вже вимагала точного ритму. Події після правок залишили в проді — ті самі метрики видно на живій аудиторії, а не лише на тесті.
За три тижні вхід у петлю зріс із 34% до 71%, утримання першого дня — у 1,8 раза, частка сесій із трьома й більше забігами — із 26% до 58%. Ризик перезапуску проєкту знявся: керування й темп виявилися робочими, далі можна нарощувати контент, а не переробляти основу.
Чим прототип відрізняється від вертикального зрізу
Прототип відповідає на одне питання: чи цікаво повторювати ключову дію знову й знову. Тому його збирають із сірих примітивів, без фінальної графіки та звуку — уся цінність етапу в перевірці ігрового циклу, керування й темпу. Якщо ядро не тримає гравця тут, графіка цього не виправить, а отже, вкладатися в неї рано.
Вертикальний зріз — одна ділянка гри, доведена до цільової якості: одна локація, один бій, один екран магазину, але зі справжньою графікою, анімацією, звуком та інтерфейсом, як у релізі.
Тут перевіряють інші ризики — як механіка відчувається у фінальному виконанні, скільки часу йде на виробництво такої ділянки й чи витримує вона слабкі пристрої.
Обсяг робіт різниться в рази. Прототип — це тижні та мінімальна команда: програміст і дизайнер механік закривають перевірку гіпотез і закінчують етап, коли механіку підтверджено або відкинуто.
Зріз потребує художників, аніматорів, звуку та збирача збірок, а будь-яка правка ядра на цьому етапі дорожча — вона тягне за собою переробку готових матеріалів. Далі за обсягом іде альфа: весь контент гри зібрано цілком, але ще не відполіровано.
Звідси правило переходу між етапами: поки прототип не дає стійкого сигналу — частки гравців, які повертаються наступного дня, і числа сесій підряд, — переходити до зрізу рано.
Коли сигнал є, керування, темп і економіку фіксують, готовність механік вважається підтвердженою, і лише потім починається виробництво в якості.
Технічні сумніви перед стартом: доступи, дані, приймання
Перед стартом прототипу в технічної команди замовника зазвичай той самий набір питань: що потрібно з вашого боку, за якими критеріями приймається результат і що залишиться в коді після здачі. Відповідаємо по суті, а розбіжності з вашим процесом проговорюємо до початку робіт.
Що потрібно від вас на старті?
Доступи до репозиторію та системи збірки, обліковий запис розробника, макети або референси, список пристроїв для перевірки. Якщо акаунта немає — заводимо свій і передаємо володіння разом із проєктом.
Як приймається результат?
Критерії фіксуємо письмово до старту: збірка ставиться на цільовий пристрій, ігровий цикл проходиться від запуску до кінця раунду, механіка відтворюється стабільно на серії прогонів. Приймання йде за списком, не за відчуттями.
Що з правками після прототипу?
В обсяг входять один-два кола уточнень за узгодженими механіками: баланс, відзивчивість керування, порядок екранів. Нові механіки та зміна ідеї — окрема задача з оцінкою.
Код прототипу викидається?
Ні. Пишемо його як основу продукту: шари розділені, ігрові системи ізольовані, збірка налаштована під релізи. Далі переносяться архітектура, збереження, введення та конфігурація рівнів.
Як будується робота за строками?
Ітерації по тижню: в кінці кожної — робоча збірка за посиланням і короткий звіт, що перевірено. Прототип ключової механіки вкладається в один-три тижні, точний строк називаємо після розбору задачі.
Обговоримо задачу: що потрібно від вас для швидкого старту
Щоб повернутися з оцінкою та планом, а не з уточнювальними питаннями, нам потрібен мінімум вхідних даних. Чим конкретніше описано задум і обмеження, тим точніший склад робіт і строк до першого іграбельного білда.
- Ключова механіка, яку перевіряємо: одне-два речення — що гравець робить і що отримує у відповідь.
- Референси: 2-3 гри зі схожою механікою і що саме в них беремо, а що свідомо не беремо.
- Платформи та пристрої: одна платформа на старті або відразу дві, включно з найслабшими моделями, на яких прототип зобов’язаний працювати.
- Керування: жести, екранні елементи, нахил — як гравець взаємодіє з ігровим полем.
- Що зафіксовано: сетинг, персонаж, стиль графіки — і де ми вільні в рішеннях.
- Матеріали: напрацювання, начерки інтерфейсів, файли графіки, якщо вони вже є.
- Зв’язок із командою: хто з вашого боку ухвалює рішення і в якому каналі обговорюємо правки.
Цього достатньо, щоб обговорити задачу предметно й зафіксувати рамки: що входить у прототип, що перевіряємо на кожній ітерації та за якою ознакою вважаємо механіку підтвердженою.
Далі надсилаємо оцінку та план робіт з етапами й датою старту проєкту — після узгодження одразу починаємо.
