Перевірка відповідності ігор вимогам платформ (Compliance)

Rejection від Sony, Microsoft або Apple зриває маркетинг і знищує рекламні бюджети. За статистикою, 70% відмов викликані дрібницями, які команда пропустила через «так завжди працювало». Один rejection може коштувати вам від 1000 до 5000 доларів на повторну сертифікацію та доопрацювання. Завдання compliance-аудиту — знайти ці дрібниці та підготувати гру до успішної публікації.

Що таке compliance-перевірка і чому вона критична?

У кожної платформи свій набір вимог: PlayStation TRC, Xbox TCR, App Review Guidelines для Apple, політики Google Play. Вони регулярно оновлюються — те, що раніше проходило, сьогодні може дати rejection. Наші інженери стежать за всіма змінами та адаптують чек-листи під актуальні версії SDK.

PlayStation (TRC). Типові причини відмови: невірна обробка системних подій — suspend/resume, вихід через PS Button, втрата геймпада. TRC вимагає призупинення геймплею при втраті контролера (не просто UI-повідомлення). Багато хто ставить Time.timeScale = 0, але забувають про NetworkEvent у мультиплеєрі. Також критична trophy unlock — виклик має бути лише при реальному досягненні, без тестових тригерів у релізі.

Xbox (TCR). Achievement unlock без справжнього тригера — автоматична відмова. Плюс xinput-сумісність, коректна робота Quick Resume (відновлення без перезапуску сесії), дотримання Xbox Accessibility Guidelines. Останнє часто ігнорують як «необов'язкове», але Microsoft все активніше перевіряє базові вимоги.

iOS App Store. Серед частих проблем: private API (лізуть через сторонні плагіни), невірна обробка App Background Modes, помилки в IAP flow (Apple вимагає строгого UX згідно Human Interface Guidelines). Особливо актуальні некоректні privacy manifests починаючи з останніх версій iOS.

Google Play. Google перевіряє Target API Level (має бути актуальним), відповідність Data Safety section (якщо гра збирає дані — невідповідність коду та декларації веде до suspension), і compliance з Families Policy для ігор з рейтингом «для дітей».

Як підготуватися до submission без rejections?

Робота починається з читання актуальних вимог для конкретної платформи та версії SDK. Не документації річної давнини — актуальної на дату подачі. Sony, Microsoft і Apple оновлюють вимоги регулярно, а підписка на developer newsletters — обов'язкова практика.

Далі формуємо compliance checklist під кожну платформу. Він не універсальний: залежить від жанру, монетизації, онлайн-режимів, вікового рейтингу та цільових регіонів (GDPR для EU, COPPA для США).

Тестування охоплює:

• всі системні сценарії (suspend, resume, sign-out, controller disconnect, low battery);
• IAP flow від початку до кінця, включаючи restore purchases та обробку помилок;
• network interruption scenarios (втрата з'єднання в момент транзакції);
• віковий рейтинг (контент у грі vs заявлений);
• privacy та permissions (запитуються лише потрібні з правильними рядками обґрунтування);
• локалізацію системних повідомлень на всіх підтримуваних мовах.

Після тестування — pre-submission report з переліком невідповідностей, пріоритизованих за likelihood of rejection.

Кейс: дублювання achievement call у Game Center

На одному мобільному проєкті за тиждень до релізу ми виявили, що GKAchievement.reportAchievements викликався двічі за певного сценарію проходження рівня: один раз з gameplay-логіки, другий з analytics-події. Apple відстежує duplicate achievement calls і при частоті флагує як спробу накрутки. Виправили через дедуплікацію на рівні AchievementManager з кешем вже відправлених achievements у PlayerPrefs. Термін аудиту — 1 тиждень, вартість розраховується індивідуально.

Що входить у роботу

• Аналіз актуальних вимог для вашої платформи (TRC, TCR, App Review).
• Персоналізований чек-лист з урахуванням жанру, монетизації та онлайн-режимів.
• Повне тестування всіх системних сценаріїв, IAP, мережі, privacy.
• Pre-submission report з пріоритизованими порушеннями та рекомендаціями.
• Консультація щодо виправлення знайдених проблем.
• Опціонально: повторне тестування після доопрацювань.
• Доступ до документації та підтримка на всіх етапах.

Порівняння частих причин rejection

Орієнтовні терміни аудиту

Чому варто почати аудит заздалегідь?

Compliance-тестування — фінальний крок, але краще починати його паралельно з основною розробкою. Базові речі (обробка системних подій, IAP flow) можна верифікувати на ранніх білдах. Це знижує ризик дорогих переробок на останньому тижні, економлячи до 40% бюджету на виправленнях після rejection.

Наша команда має сертифікованих інженерів з 10+ років досвіду в геймдеві. Ми успішно провели аудит для 50+ проєктів на всіх великих платформах. Отримайте консультацію — оцінимо ваш проєкт і підготуємо індивідуальну пропозицію. Зв'яжіться з нами, щоб почати підготовку до публікації без rejections.

Фінальний submission checklist включає: перевірку всіх метаданих (скріншоти, опис, віковий рейтинг у кожному регіоні), верифікацію сертифікатів та provisioning profiles, тест на clean install без попередніх даних.

Тестування та QA

Ми не раз бачили, як проєкт на фінішній прямій перетворюється на кошмар: на машині розробника все літає, а на Samsung Galaxy A12 — 15 FPS і вильоти, на iPad Air — мильні текстури. Без вибудуваного QA-процесу тестування ігор стає лотереєю. Наша команда з 8-річним досвідом протестувала понад 30 мобільних ігор і в кожному проєкті знаходила критичні проблеми, які не виявили звичайні прогони. Тестування ігор під ключ — від функціонального до навантажувального — з гарантією якості та звітом, готовим до впровадження. Оцінимо ваш проєкт за 3 дні — зв'яжіться з нами.

Як автоматизувати тестування в Unity?

Найефективніший спосіб зловити регресію — автотести, які запускаються без людини. У Unity це Unity Test Framework (UTF) на базі NUnit. Два режими.

Edit Mode Tests працюють без ігрового циклу — швидкість виконання в мілісекундах. Підходять для формул урону, розрахунку економіки, валідації конфігів. Play Mode Tests запускають повний ігровий цикл — тестують логіку MonoBehaviour, корутини, переходи між сценами.

Приклад:

[UnityTest]
public IEnumerator PlayerTakeDamage_HealthReduces()
{
    var go = new GameObject();
    var health = go.AddComponent<HealthComponent>();
    health.Initialize(100);

    health.ApplyDamage(30);

    yield return null;

    Assert.AreEqual(70, health.CurrentHealth);
}

Покривайте те, що ламається найчастіше: система збережень, економіка, бойова логіка. 100% покриття не потрібне — достатньо критичних шляхів. UI (UGUI, UI Toolkit) автоматизувати складніше: для цього використовують InputSystem.QueueEvent або Appium на мобільних платформах. Автотести виконуються в 50 разів швидше ручних прогонів при регресії — це скорочує бюджет на регресійне тестування на 40%.

Чому профілювання на реальному пристрої критичне?

Тести не ловлять проблеми продуктивності. Для цього потрібен профілювальник на цільовій платформі. Unity Profiler — стартова точка. Ключові кроки:

1. Профілюйте на пристрої, а не в редакторі — Editor додає оверхед. Підключіть девайс через USB з Development Build і Autoconnect Profiler.
2. Дивіться Main Thread і Render Thread окремо. Типові проблеми:
   • Physics.FixedUpdate >2ms — складна фізика
   • Canvas.BuildBatch на кожному кадрі — зайві Dirty виклики UI
   • GC.Collect — виділення пам'яті в гарячому шляху (всередині Update)
3. Використовуйте ProfilerMarker для локалізації:

using Unity.Profiling;

static readonly ProfilerMarker k_PathfindMarker = new ProfilerMarker("Pathfinding.Calculate");

void UpdateAI()
{
    using (k_PathfindMarker.Auto())
    {
        // pathfinding code
    }
}

Memory Profiler (пакет com.unity.memoryprofiler) дає знімки пам'яті: знаходить витоки (об'єкти, не звільнені після зміни сцени), порівнює два знімки. Найчастіші причини проблем на мобайлі: текстури без правильного формату (ASTC для iOS, ETC2 для Android), аудіо в WAV замість Vorbis, об'єкти в DontDestroyOnLoad, які накопичуються.

Frame Debugger (Window → Analysis → Frame Debugger) дозволяє пройти по кожному draw call у кадрі. Для мобільних проєктів норма — 50–150 draw calls; якщо більше 300 — батчинг не працює або сцена перевантажена. Важливість профілювання на реальному обладнанні підкреслюється в літературі з тестування продуктивності.

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

Функціональне та регресійне тестування

Функціональне тестування будується на тест-планах: для кожної фічі — очікуваний результат, кроки відтворення, критерії проходження. Покриваємо smoke, sanity і acceptance-тести. Регресійне тестування — запуск накопичених кейсів перед кожним релізом, а не тільки перед мажорними.

Інструменти управління: TestRail, Qase, Zephyr. Для невеликих команд — Notion або Google Sheets зі структурованими чеклістами.

Тестування на реальних пристроях

Емулятори не відтворюють тепловий дросселінг, реальний GPU та обмеження пам'яті. Мінімальний набір — 20+ пристроїв усіх сегментів:

Для масштабного тестування — хмарні ферми: Firebase Test Lab, BrowserStack App Automate, AWS Device Farm. Вони дозволяють запускати сотні паралельних тестів на реальних пристроях.

Навантажувальне тестування (мультиплеєр)

Мета — знайти деградацію сервера до релізу. Інструменти: k6 (WebSocket/HTTP API), Gatling (складні сценарії зі станом). Для специфічних протоколів пишуть кастомний stress-клієнт на Go або C#.

Параметри перевірки:

• Поведінка при піковому CCU (concurrent users) — до 1000+ CCU
• Деградація латентності під навантаженням (p95 latency)
• Витоки пам'яті на сервері за 72+ години роботи
• Graceful degradation при відмові одного з вузлів

Краш-репортинг та моніторинг

Після релізу QA продовжується через моніторинг. Firebase Crashlytics — стандарт для мобільних ігор: автоматичний збір крашів із символізацією стектрейсів, real-time сповіщення. Sentry — для серверних компонентів і WebGL. ANR (Application Not Responding) налаштовується окремо — Play Console показує їх в окремому розділі. Інвестиції в тестування окупаються за 2–3 релізи, знижуючи витрати на виправлення багів після релізу на 60%.

Що входить у нашу роботу

• Детальний план тестування (чек-лист, сценарії, пріоритети)
• Набір автоматизованих тестів (економіка, збереження, критичні шляхи — покриття 70%)
• Профілювання CPU/GPU/пам'яті зі звітом по кожному багу
• Ручне тестування на 20+ реальних пристроях (low-end / mid-range / flagship)
• Навантажувальне тестування сервера (до 1000+ CCU протягом 12 годин)
• Дашборд з метриками та історією прогонів
• Навчання вашої команди основам автотестування та профілювання

Отримайте консультацію щодо вашого проєкту — ми оцінимо поточну збірку та запропонуємо план оптимізації.

Процес роботи

1. Аналіз — вивчаємо архітектуру, збираємо метрики поточної збірки, визначаємо цілі по FPS та стабільності.
2. План тестування — створюємо чек-лист, обираємо інструменти, узгоджуємо обсяг.
3. Автоматизація — пишемо тести для критичних шляхів, налаштовуємо CI-прогони.
4. Ручне тестування — проганяємо сценарії на пристроях, фіксуємо баги в трекері.
5. Звіт та рекомендації — надаємо документ зі знайденими проблемами, їх пріоритетом і конкретними правками (оптимізація шейдерів, налаштування батчингу, витоки).

Наші метрики

• 8+ років досвіду в геймдеві (Unity, Unreal, мобільні/PC/консолі)
• 30+ протестованих мобільних ігор
• Середнє підвищення FPS після оптимізації — 30%
• Скорочення часу регресійного тестування — 40%
• Гарантія: всі бази з Critical/High пріоритетом виправляються до релізу

Типові помилки в QA-процесі

• Тестування лише на флагманах — більшість гравців на mid-end і low-end.
• Відсутність автотестів для економіки та збережень — вони ламаються при будь-якому рефакторингу.
• Пропуск навантажувального тестування сервера — гра виходить, набирає 10k DAU і сервер лягає.
• Регресія тільки перед мажорними релізами — критично перед кожним публічним оновленням.

Замовте тестування ігор під ключ. Ми оцінимо ваш проєкт за 3 дні та запропонуємо план з гарантією результату. Пишіть — розберемо вашу збірку безкоштовно.