Как тестировать игры на Android

Привет!
Прошу прощения за долгое отсутствие — был занят делами насущными, но чтоб разбавить немного информационный вакуум, делюсь полезным гайдом.

Сегодня разберём, как удобно тестировать игры на Android, используя Unity Remote 5. Это приложение значительно ускоряет процесс проверки изменений в проекте. Оно транслирует изображение из редактора в смартфон и позволяет производить тест без сборки .apk. Инструмент мега полезный, но многие даже не подозревают о его существовании.

Подготовка

1. Активация режима разработчика и отладки по USB
Для начала нужно включить режим разработчика на смартфоне.

На Xiaomi:
- Откройте «Настройки» → «О телефоне».
- Тапайте 7 раз по пункту «Версия MIUI», пока не появится уведомление «Вы стали разработчиком».
- Вернитесь в настройки, зайдите в «Расширенные настройки» → «Для разработчиков».
- Активируйте «Режим разработчика» и ниже включите «Отладка по USB».

На других устройствах процесс похож: обычно нужно найти раздел «О телефоне», несколько раз нажать на «Номер сборки», затем включить отладку в меню разработчика.

2. Установка Unity Remote 5
Скачайте приложение из Google Play.

Если запустите его — увидите окно с подсказкой:
«Подключите устройство к ПК по USB и нажмите PLAY в Unity.
Выберите устройство в: Edit → Project Settings → Editor»

3. Подключение телефона к компьютеру
Соедините смартфон с ПК через USB-кабель.
Если появится запрос «Разрешить отладку по USB?», нажмите «Разрешить» (или выберите «Передача данных», если такого пункта нет).

4. Настройка Unity
- Откройте File → Build Settings и убедитесь, что выбрана платформа Android. Если нет - переключите.
- Перейдите в Edit → Project Settings → Editor. В выпадающем списке «Device» выберите «Any Android Device».

5. Запуск тестирования
Нажмите Play в Unity — изображение с редактора должно появиться на экране телефона.
Теперь можно тестировать управление через тачи, интерфейс и другие элементы без сборки APK.

Готово!

Для большинства случаев этого будет достаточно. Бываю более специфические проблемы, которые надо разбирать индивидуально.

Теперь у вас есть отличный инструмент для быстрой проверки изменений в проекте.

Кто спрашивал про сохранения)
https://dtf.ru/gamedev/3692700-sohraneniya-v-unity-podkhody-i-metody

Приходите на конференцию

Привет!
Давненько я тут не появлялся))

Но я не сидел сложа руки и возвращаюсь с горячим анонсом🔥

Уже в эту среду (18 июня) буду рассказывать про автоматизированное тестирование в юнити на онлайн конференции UnityConf. Приходите послушать меня и других спикеров. Ссылку завтра пришлю)

✏️Конференция длится 3 дня (17-19 июня), Начало в 19:00 мск и каждый день выступает несколько крутых докладчиков с разными темами:
• Работа с Git в рамках Unity-проектов.
• Эффективная разработка и публикация: что важно знать разработчику.
• Пайплайн и командная работа: создание веб-продуктов.
• Портирование игр: как войти в геймдев.
• Быстрый старт в Unity — от нуля до первых проектов.
• Почему именно Unity в 2025 году.

И это еще не всё! Во время конференции тебя ждут бонусы:

🎁 Ассеты, исходники, уроки по созданию шутера и многое другое!

Тема у меня обширная, но даже если не успею всё рассказать за отведённое на конференции время, продолжим тут развивать тему, если будет востребовано))

Выступаю первым)

Дублирую ссылки из презентации.

Видео:
- https://youtu.be/vLvA7ZkFGRo - теория по юнит тестам
- https://youtu.be/arzREy5zLVU - теория по tdd и пример кода
- https://youtu.be/TyxDg70hc3g - примеры кода
- https://youtu.be/6mkrxvyZp0Y - большой стрим от синдикатов

Статьи:
- Mastering Unit Testing in Unity 3D (https://kristobiasson.medium.com/mastering-unit-testing-in-unity-3d-8c8805accf1a)
- Unit Testing Best Practices (https://medium.com/@kaanfurkanc/unit-testing-best-practices-3a8b0ddd88b5)
- Документация Unity: Unity Test Framework (https://docs.unity3d.com/2022.1/Documentation/Manual/testing-editortestsrunner.html)
- Руководство для Unity-разработчика: Модульное тестирование (https://habr.com/ru/companies/otus/articles/913906/)
- Советы по тестированию и обеспечению качества для проектов Unity (https://unity.com/ru/how-to/testing-and-quality-assurance-tips-unity-projects?ysclid=mb9svd93b4232429255)

Запоздалая ссылка на стрим.
Был без интернета, так что сам в записи буду смотреть)

Assembly Definition

Привет!
Продолжая тему тестирования (а точнее предвосхищая ее) разберём мощный инструмент для организации кода в Unity - Assembly Definition.

❌По умолчанию все скрипты Unity компилирует в одну сборку (Assembly-CSharp.dll). Это вызывает проблемы:
* Медленная перекомпиляция (изменение любого скрипта пересобирает весь проект).
* Хаотичные зависимости (любой класс может обратиться к любому другому, даже если это не нужно).
* Сложность поддержки (в больших проектах трудно отслеживать связи между системами).

✅ Assembly Definition позволяет:
* Разделять код на независимые сборки (скрпиты одной сборки не "видят" скриптов другой, если между ними не настроена явная зависимость)
* Чётко контролировать зависимости между модулями
* Ускорять компиляцию (изменения затрагивают только нужные сборки)

⚠️ Для редакторских скриптов и тестов требуются отдельные .asmdef с настройками:
* Editor-скрипты: "Editor" в имени и включённая опция "Editor"
* Тесты: включить "Test Assemblies"

Assembly Definition и Namespace

Namespace – логическая группировка кода (защита от конфликтов имён)
Assembly Definition – физическое разделение на DLL

Можно ли обойтись без Namespace?

Технически — да, но крайне не рекомендуется тк:
* Риск конфликтов – если в разных сборках есть классы с одинаковыми именами
* Сложность навигации – без пространств имён труднее понимать структуру проекта
* Нарушение инкапсуляции – классы в глобальном пространстве видны везде

Представьте, например:
У вас есть сборка GameLogic и UI.
* В обеих есть класс Player (например, GameLogic.Player и UI.Player).
* Без namespace компилятор не поймёт, какой Player вы имеете в виду → ошибка.
С namespace конфликта нет, даже если классы в одной сборке.

Как использовать Assembly Definition

Базовая настройка:
1. Создаём .asmdef-файл
* в папке (подпапке) со скриптами: ПКМ → Create → Assembly Definition
* Даём понятное имя (например, GameLogic, UI, Network, обычно как имя подпапки или пространства имен)
2. Настраиваем зависимости, чтобы скрипты одной сборки могли работать со скриптами другой.
Например, если сборка UI использует классы из GameLogic:
* Выбираем в окне Project наш UI.asmdef
* В инспекторе в Assembly References добавляем GameLogic
3. Другие важные параметры сборки:
* Auto Referenced – разрешает доступ из стандартных сборок Unity
* Override References – ручное управление зависимостями
* No Engine References – полностью отключает доступ к Unity API (для чистого C# кода)

Структура папок

Scripts/
├── GameLogic/
│ ├── Gameplay/Player.cs (скрипт в namespace Gameplay)
│ └── GameLogic.asmdef (файл сбрки)
├── UI/
│ ├── Windows.cs (namespace UI)
│ └── UI.asmdef (зависит от GameLogic)
└── Tests/
├── Characters/HealthTest.cs (namespace Tests)
└── Tests.asmdef

✅ Рекомендации

1. Связывайте имена сборок, папок и namespace

// В сборке GameLogic.asmdef, лежащей в папке GameLogic
namespace GameLogic
{
    public class Player { ... }
}

2. (Не злоупотреблять) Используйте вложенные namespace для сложных систем

namespace GameLogic.AI 
{
    public class EnemyBehavior { ... }
}

3. Избегайте циклических зависимостей
Сборка A не должна зависеть от B, если B уже зависит от A

4. Избегайте глобального пространства имён (классов без namespace)

Итоги

Assembly Definition даёт:
✅ Быструю компиляцию
✅ Чёткую архитектуру
✅ Лёгкий рефакторинг
✅ Защиту от случайных зависимостей

#оптимизация #архитектура

Привет!
Тут Яковлев выкатил довольно неплохую дорожную карту, для Unity Джуна от 0 до устройства на работу. Можете использовать её как чек лист для проверки знаний.

В целом, с таким пулом знаний можно даже борзонуть и на мидловые позиции откликаться.

https://miro.com/app/board/uXjVJXnVs1s=/?share_link_id=197903878291