🤓С чего начать работу в Unity🥸

Привет!

Недавно читал лекцию для новичков в разработке. Рассказал из чего состоит игра, какие задачи решает игровой движок и, главное, показал процесс создания первой игры.

Думаю "Чего добру зря пропадать" и решил поделиться с вами презентацией.

Для вас, скорее всего, нового там ничего не будет, но, может, вы знаете кому это отправить))

Гришаков вернулся, пришлось ехать в Москву)

Пока жду фото с Гришаковым покажу моего первого наставника в клубе и просто большого человека. Гроза Яндекс игр - Инди Алёша😁

Вот и фото с виновником подоспело)

Путь масштабирования студии

Привет!
Хочу поделиться с вами, на мой взгляд, одним из самых крутых слайдов из презентации.

С одной стороны, "секретного ингредиента нет", а с другой - почему-то самые простые вещи оказываются самыми сложными для понимания и поэтому их надо проговаривать.

Когда стартуем свой путь на рынке, имеет смысл держать в голове такую схему:

1. Сначала спамите простенькими проектами, как из пулемёта и смотрите статистику. Как только появился явный лидер - доводим его до ума.
2. Выкладываем ±завершённый продукт везде, до куда можем дотянуться
3. Сколько можем, улучшаем его путём бесконечных А/Б тестов.
4. Когда упираемся в потолок - начинаем закупать рекламу с горизонтом окупаемости ~ 2 месяцев.
5. Ну, и когда доход позволяет - расширяем штат, чтоб вести больше проектов одновременно.

Естественно, в жизни всё чуть сложнее, чем на бумаге, но как ориентир - схема очень крутая.

Следующая статья идет тяжеловато из-за нехватки времени, но лучшей подводки к ней вы не увидите🤣🤣🤣

Был программистом, стал (техническим) должником

Привет!
Сегодня хочу обсудить причину, из-за которой любой проект рано или поздно станет неподдерживаемым куском говнокода и его будет проще переписать с нуля чем продолжать поддерживать.

Технический долг — это метафора, которая описывает последствия принятия краткосрочных решений в разработке, которые упрощают или ускоряют процесс в краткосрочной перспективе, но приводят к дополнительным затратам в будущем. Часто такие решения принимаются из-за отсутствия опыта (не понимаете в чем проблема или не знаете как лучше).

Это как "долг", который нужно "погасить", чтобы поддерживать и развивать проект, пока не накапали проценты (а капают они с каждым комитом).

По сути, добрую половину замечаний к домашкам можно свести к этой теме (а из-за отсутствия опыта и понимания долгосрочных последствий у ученика часто появляется обида и ощущение, что менторы просто докопались).

Что ведёт к накоплению технического долга?

1. Сжатые сроки
Когда разработчики вынуждены быстро выпускать игру или её части, они могут пропускать важные этапы, такие как рефакторинг, тестирование или оптимизацию.

2. Отсутствие документации (в основном автодокументирования и соблюдения нотации)
Другим разработчикам (или даже самому автору) часто сложно понять, как работает код, если он написан не по нотации. Это замедляет дальнейшую разработку и увеличивает риск ошибок. Кроме того, другие разработчики могут повторно реализовать тот же функционал, тк не знают/не понимают, что кто-то уже это сделал или не могут найти.

3. Использование "костылей" (нет ничего более постоянного, чем временное)
Временные решения, которые быстро решают проблему, но не являются оптимальными, часто становятся частью кода. Со временем такие "костыли" накапливаются и усложняют поддержку.

4. Недостаточное тестирование
Если не писать unit-тесты или не проводить достаточное тестирование, ошибки могут оставаться незамеченными. Это приводит к тому, что их приходится исправлять позже, что увеличивает затраты (тк за проблемный код могут цепляться будущие решения).

5. Игнорирование архитектуры
Если не уделять внимание проектированию архитектуры игры, код может стать запутанным и сложным для поддержки. Например, сильная связанность компонентов или отсутствие модульности.

6. Частые изменения требований
Если требования к игре часто меняются, разработчики могут вносить изменения в код "на скорую руку", что приводит к накоплению долга.

7. Неоптимизированные ассеты
Использование тяжелых ассетов (например, высокополигональных моделей или текстур высокого разрешения) без оптимизации может привести к проблемам с производительностью, которые придется решать позже.

8. Отсутствие рефакторинга
Если код не рефакторить (не улучшать его структуру и читаемость), он становится всё более сложным для понимания и поддержки. Написание идеального кода сразу (особенно в коменде) - утопия.

9. Использование устаревших подходов
Unity постоянно развивается, и некоторые методы или API могут устаревать. Если не обновлять код, это может привести к проблемам совместимости и производительности.

10. Недостаток опыта команды
Если разработчики недостаточно опытны, они могут принимать неоптимальные решения, которые в будущем придется переделывать.

Неутешительный итог

Технический долг коварен, многолик и неотвратим. Победить его полностью в реальном проекте невозможно. Все что нам остается - сдерживать эту критическую массу костылей как можно дольше, пока проект не развалится под их тяжестью. Но это не повод не пытаться. При должном усердии и дисциплине проект может существовать десятки лет (правда, на втором десятке он, скорее всего, уже будет напоминать паралитика на ИВЛ, зато живой 😅)

В будущих статьях рассмотрим несколько примеров (в том числе тот, с которым я недавно столкнулся и который побудил меня написать этот цикл).

Привет!
По классике, живой и в запаре)
Времени на статью небыло, поэтому буду хвалиться репетициями в театре😁

Как тестировать игры на 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