В этой статье разберём, что такое Coroutine, как они работают, когда их стоит использовать и каких ошибок лучше избегать.

Что такое Coroutine

Coroutine (корутина) - это специальный метод, который может приостанавливать своё выполнение и продолжать его позже.

Проще говоря, корутина позволяет выполнять код поэтапно, не блокируя основной поток игры.

Простейший пример:

using System.Collections; using UnityEngine; public class Example : MonoBehaviour { private void Start() { StartCoroutine(PrintMessage()); } private IEnumerator PrintMessage() { Debug.Log("Начало"); yield return new WaitForSeconds(2); Debug.Log("Прошло две секунды"); } }

После запуска игры первое сообщение появится сразу, а второе - через две секунды.

Почему не использовать Update

Многие начинающие разработчики делают подобные проверки:

private float timer; private void Update() { timer += Time.deltaTime; if (timer >= 2) { Debug.Log("Прошло две секунды"); timer = 0; } }

Такой код работает, но быстро становится сложным, если подобных таймеров становится несколько.

Coroutine позволяют писать подобную логику значительно проще.

Как запустить Coroutine

Для запуска используется метод:

StartCoroutine(MyCoroutine());

Сама корутина должна возвращать IEnumerator.

private IEnumerator MyCoroutine() { yield return null; }

Что делает yield return

Ключевое слово yield return сообщает Unity, когда нужно продолжить выполнение метода.

Например:

yield return null;

Означает:

Продолжить выполнение на следующем кадре.

WaitForSeconds

Самый популярный вариант использования.

yield return new WaitForSeconds(3f);

Корутина приостановится на три секунды.

Это удобно для:

• задержек;
• перезарядки оружия;
• анимаций;
• появления врагов;
• игровых эффектов.

WaitForSecondsRealtime

Обычный WaitForSeconds зависит от Time.timeScale.

Если игра поставлена на паузу:

Time.timeScale = 0;

ожидание тоже остановится.

Если нужно ждать независимо от времени игры:

yield return new WaitForSecondsRealtime(3f);

WaitUntil

Иногда нужно дождаться выполнения условия.

Например:

yield return new WaitUntil(() => player.IsDead);

После смерти игрока выполнение продолжится автоматически.

WaitWhile

Работает наоборот.

yield return new WaitWhile(() => loading);

Корутина будет ждать, пока переменная loading остаётся равной true.

WaitForEndOfFrame

Позволяет выполнить код после завершения текущего кадра.

yield return new WaitForEndOfFrame();

Часто используется:

• при создании скриншотов;
• работе с UI;
• чтении RenderTexture.

Запуск нескольких Coroutine

Можно запускать сразу несколько корутин.

StartCoroutine(SpawnEnemies()); StartCoroutine(UpdateScore()); StartCoroutine(PlayMusic());

Они будут выполняться независимо друг от друга.

Остановка Coroutine

Иногда необходимо остановить выполнение.

Например:

Coroutine reload; private void Start() { reload = StartCoroutine(Reload()); } private void CancelReload() { StopCoroutine(reload); }

Также можно остановить сразу все корутины объекта:

StopAllCoroutines();

Использовать этот метод стоит осторожно.

Практический пример

Представим систему перезарядки.

private bool isReloading; public void Reload() { if (!isReloading) StartCoroutine(ReloadRoutine()); } private IEnumerator ReloadRoutine() { isReloading = true; yield return new WaitForSeconds(2); ammo = maxAmmo; isReloading = false; }

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

Когда использовать Coroutine

Coroutine отлично подходят для:

• задержек;
• постепенных изменений;
• появления волн врагов;
• загрузки данных;
• анимаций;
• перезарядки;
• кат-сцен;
• диалогов.

Когда Coroutine использовать не стоит

Не стоит применять корутины:

• для сложной игровой логики;
• для постоянных вычислений;
• вместо полноценной системы состояний.

В таких случаях лучше использовать отдельные классы или архитектурные решения.

Частые ошибки новичков

Запускать Coroutine каждый кадр

Плохо:

private void Update() { StartCoroutine(MyCoroutine()); }

В результате каждую секунду создаются десятки новых корутин.

Забывать о завершении объекта

Если объект уничтожается:

Destroy(gameObject);

все его Coroutine автоматически прекращают работу.

Это важно учитывать при работе с загрузкой данных и сетевыми запросами.

Использовать Coroutine вместо любой логики

Coroutine - это инструмент для последовательного выполнения действий.

Они не заменяют архитектуру проекта.

Практический вывод

Coroutine позволяют писать более чистый и понятный код.

Вместо множества таймеров и проверок в Update() вы получаете последовательное выполнение действий, которое легче читать и поддерживать.

Именно поэтому корутины используются практически в каждом Unity-проекте.

Заключение

Coroutine - один из самых полезных инструментов Unity.

Освоив их, вы сможете проще реализовывать задержки, анимации, загрузку данных и множество игровых механик без лишнего усложнения кода.

Главное - использовать их по назначению и не пытаться заменить ими всю игровую логику.

Для решения этой проблемы используется Object Pooling — один из самых важных паттернов оптимизации в Unity.

В этой статье разберём, как работает Object Pooling, зачем он нужен и как реализовать собственный пул объектов.

Что такое Object Pooling

Обычно объекты создаются через:

Instantiate(prefab);

А удаляются через:

Destroy(gameObject);

Для небольшого количества объектов это нормально.

Но если игра каждую секунду создаёт десятки или сотни объектов, начинают появляться проблемы:

• лишние выделения памяти
• работа сборщика мусора (GC)
• просадки FPS
• микрофризы

Object Pooling решает эту проблему за счёт повторного использования объектов.

Как работает Object Pool

Вместо создания нового объекта:

1. Объект создаётся заранее.
2. Отключается.
3. Когда нужен — активируется.
4. После использования снова отключается.

Получается своеобразный склад готовых объектов.

Пример без пула

Представим систему стрельбы:

Instantiate(bulletPrefab, spawnPoint.position, spawnPoint.rotation);

После попадания:

Destroy(gameObject);

Если игрок выпускает 500–1000 пуль в минуту, производительность начнёт ухудшаться.

Создаём простой пул объектов

Создадим класс пула:

using System.Collections.Generic; using UnityEngine; public class ObjectPool : MonoBehaviour { public GameObject prefab; public int poolSize = 20; private Queue<GameObject> pool = new(); private void Awake() { for (int i = 0; i < poolSize; i++) { GameObject obj = Instantiate(prefab); obj.SetActive(false); pool.Enqueue(obj); } } }

Теперь у нас есть набор заранее созданных объектов.

Получение объекта из пула

Добавим метод:

public GameObject Get() { GameObject obj = pool.Dequeue(); obj.SetActive(true); return obj; }

Теперь вместо Instantiate():

GameObject bullet = pool.Get();

Возврат объекта в пул

Добавим метод:

public void Return(GameObject obj) { obj.SetActive(false); pool.Enqueue(obj); }

После использования объект возвращается обратно.

Где применяется Object Pooling

Пул объектов особенно полезен для:

• пуль
• врагов
• частиц
• всплывающего урона
• эффектов взрывов
• временных UI-элементов

Практически любой объект, который часто создаётся и уничтожается, является кандидатом для пула.

Unity ObjectPool

Начиная с новых версий Unity появилась встроенная система пулов.

Пример:

using UnityEngine.Pool;

Создание пула:

private ObjectPool<Bullet> bulletPool;

Инициализация:

bulletPool = new ObjectPool<Bullet>( CreateBullet, OnGetBullet, OnReleaseBullet );

Для большинства проектов встроенного решения достаточно.

Частые ошибки новичков

Пулить вообще всё

Не каждый объект нуждается в пуле.

Если объект создаётся один раз за игру — пул не нужен.

Забывать сбрасывать состояние

Перед возвратом объекта важно очищать данные:

health = maxHealth; velocity = Vector3.zero;

Иначе появляются трудноуловимые баги.

Слишком маленький пул

Если объектов не хватает, система может начать создавать новые экземпляры во время игры.

Это сводит пользу пула к минимуму.

Когда использовать Object Pooling

Используйте пулы, если:

• объект создаётся десятки раз в секунду
• игра работает на мобильных устройствах
• появляются GC Alloc и лаги

Практический вывод

Object Pooling — одна из первых оптимизаций, которую стоит освоить каждому Unity-разработчику.

Он позволяет:

• уменьшить количество аллокаций
• сократить работу сборщика мусора
• повысить стабильность FPS
• сделать игру более отзывчивой

Поэтому почти во всех коммерческих проектах используются различные виды пулов объектов.

Заключение

Object Pooling — простой, но крайне эффективный инструмент оптимизации.

Даже небольшая система пулов способна заметно улучшить производительность проекта, особенно на мобильных устройствах и в играх с большим количеством объектов.

Это одна из тех технологий Unity, которую стоит изучить каждому разработчику.

В этой статье разберём полный жизненный цикл MonoBehaviour и выясним, когда использовать Awake, Start, Update, FixedUpdate и другие важные методы.

Что такое MonoBehaviour

MonoBehaviour — это базовый класс Unity, который позволяет скрипту взаимодействовать с движком.

Благодаря ему становятся доступны:

• Start()
• Update()
• FixedUpdate()
• OnEnable()
• OnDisable()
• OnDestroy()

и многие другие события.

Пример простого скрипта:

using UnityEngine; public class Player : MonoBehaviour { private void Start() { Debug.Log("Игра началась"); } }

Жизненный цикл MonoBehaviour

Упрощённо порядок вызова выглядит так:

Awake ↓ OnEnable ↓ Start ↓ Update ↓ LateUpdate ↓ OnDisable ↓ OnDestroy

Если используется физика, между кадрами также вызывается FixedUpdate.

Awake()

Awake вызывается сразу после создания объекта.

Он запускается ещё до первого кадра и до вызова Start.

Пример:

private void Awake() { Debug.Log("Awake"); }

Когда использовать Awake

Подходит для:

• получения ссылок на компоненты
• базовой инициализации
• подготовки объекта к работе

Например:

private Rigidbody rb; private void Awake() { rb = GetComponent<Rigidbody>(); }

Главное правило:

Awake используется для подготовки самого объекта.

OnEnable()

Метод вызывается каждый раз, когда объект становится активным.

private void OnEnable() { Debug.Log("Объект включён"); }

Он сработает:

• при запуске сцены
• после SetActive(true)
• после включения компонента

Когда использовать

Часто применяется для подписки на события:

private void OnEnable() { GameEvents.OnGameOver += HandleGameOver; }

Start()

Start вызывается перед первым кадром.

Но только один раз.

private void Start() { Debug.Log("Start"); }

Отличие от Awake:

• Awake вызывается сразу после создания объекта
• Start вызывается перед первым кадром

Когда использовать

Подходит для логики, которая зависит от других объектов сцены.

Например:

private void Start() { enemy = FindObjectOfType<Enemy>(); }

К моменту вызова Start все объекты уже успели выполнить Awake.

Update()

Самый известный метод Unity.

Вызывается каждый кадр.

private void Update() { transform.Rotate(Vector3.up * 100 * Time.deltaTime); }

Если игра работает в 60 FPS, Update будет вызываться примерно 60 раз в секунду.

Когда использовать

Подходит для:

• обработки ввода
• движения
• проверки условий
• игровой логики

Пример:

private void Update() { if (Input.GetKeyDown(KeyCode.Space)) { Jump(); } }

FixedUpdate()

Используется для физики.

Вызывается через фиксированные интервалы времени.

По умолчанию:

0.02 секунды

или примерно 50 раз в секунду.

Пример:

private void FixedUpdate() { rb.AddForce(Vector3.forward); }

Когда использовать

Только для работы с Rigidbody:

• AddForce()
• Velocity
• физическое движение

Типичная ошибка новичков — выполнять физику в Update.

LateUpdate()

Вызывается после всех Update текущего кадра.

private void LateUpdate() { Debug.Log("LateUpdate"); }

Когда использовать

Идеально подходит для камеры.

Пример:

private void LateUpdate() { transform.position = player.position + offset; }

Сначала игрок двигается в Update, затем камера догоняет его в LateUpdate.

Так движение получается плавным.

OnDisable()

Вызывается, когда объект или компонент отключается.

private void OnDisable() { Debug.Log("Объект отключён"); }

Когда использовать

Чаще всего для отписки от событий:

private void OnDisable() { GameEvents.OnGameOver -= HandleGameOver; }

Это помогает избежать утечек памяти и ошибок.

OnDestroy()

Вызывается перед уничтожением объекта.

private void OnDestroy() { Debug.Log("Объект уничтожен"); }

Срабатывает при:

Destroy(gameObject);

или выгрузке сцены.

Когда использовать

Подходит для:

• очистки ресурсов
• сохранения данных
• отписки от глобальных событий

Частые ошибки новичков

Использовать Start вместо Awake

Если нужно получить компонент:

rb = GetComponent<Rigidbody>();

лучше делать это в Awake.

Использовать физику в Update

Плохо:

void Update() { rb.AddForce(Vector3.forward); }

Правильно:

void FixedUpdate() { rb.AddForce(Vector3.forward); }

Забывать отписываться от событий

Если подписка происходит в OnEnable, то отписка должна происходить в OnDisable.

Практический вывод

Можно запомнить простое правило:

• Awake — подготовка объекта
• OnEnable — подписка на события
• Start — работа с другими объектами
• Update — игровая логика
• FixedUpdate — физика
• LateUpdate — камера и постобработка
• OnDisable — отписка от событий
• OnDestroy — очистка ресурсов

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

Заключение

Жизненный цикл MonoBehaviour — одна из фундаментальных тем в Unity.

Понимание порядка вызова методов помогает избежать множества ошибок и писать более предсказуемый код.

Освоив Awake, Start, Update и остальные методы, вы сможете гораздо увереннее работать с любыми игровыми системами.

Dependency Injection (внедрение зависимостей) — это подход, при котором объект не создаёт свои зависимости самостоятельно, а получает их извне.

Без DI код часто выглядит так:

public class Player : MonoBehaviour { private AudioManager audioManager; private void Start() { audioManager = FindObjectOfType<AudioManager>(); } }

На первый взгляд всё работает.

Но со временем появляются проблемы:

• много поисков через сцену
• скрытые зависимости
• сложное тестирование
• трудности с поддержкой

Как выглядит Dependency Injection

С DI зависимости передаются извне:

public class Player { private readonly AudioManager audioManager; public Player(AudioManager audioManager) { this.audioManager = audioManager; } }

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

Это делает код более понятным и предсказуемым.

Зачем нужен DI в Unity

На маленьких проектах можно спокойно жить без него.

Но в средних и крупных играх появляются преимущества:

• меньше связности между системами
• проще тестировать код
• удобнее заменять реализации
• легче поддерживать проект

Особенно полезно для:

• UI-систем
• сервисов
• экономики
• сохранений
• мультиплеера

Zenject

Zenject долгое время был самым популярным DI-фреймворком для Unity.

Он позволяет автоматически создавать объекты и связывать зависимости.

Пример установки зависимости:

public class GameInstaller : MonoInstaller { public override void InstallBindings() { Container.Bind<AudioManager>() .AsSingle(); } }

Получение зависимости:

public class Player : MonoBehaviour { [Inject] private AudioManager audioManager; }

Плюсы Zenject

• Огромное количество материалов
• Большое сообщество
• Поддержка Signals
• Хорошая документация

Минусы Zenject

• Довольно сложный для новичков
• Большое количество абстракций
• Более тяжёлый по производительности

VContainer

VContainer появился позже и быстро стал популярным благодаря производительности и простоте.

Основная идея осталась той же, но реализация стала легче.

Регистрация сервиса:

builder.Register<AudioManager>(Lifetime.Singleton);

Внедрение зависимости:

public class Player { private readonly AudioManager audioManager; public Player(AudioManager audioManager) { this.audioManager = audioManager; } }

Плюсы VContainer

Высокая производительность

По результатам тестов VContainer работает быстрее большинства DI-контейнеров для Unity.

Простота

Код получается более чистым и понятным.

Активная разработка

Проект активно развивается и поддерживается.

Минусы VContainer

• Меньше обучающих материалов
• Меньше готовых решений
• Сообщество меньше, чем у Zenject

Когда использовать DI

Dependency Injection имеет смысл, если:

• проект растёт
• много систем взаимодействуют друг с другом
• важна тестируемость
• работает несколько разработчиков

Когда DI не нужен

Для небольших проектов часто достаточно:

• ссылок через Inspector
• ScriptableObject
• простых сервисов

Если игра состоит из нескольких сцен и десятка скриптов, DI может только усложнить разработку.

Частые ошибки новичков

Использовать DI слишком рано

Многие начинают внедрять Zenject ещё до появления реальной проблемы.

В результате архитектура становится сложнее самой игры.

Внедрять всё подряд

Не каждая переменная должна становиться сервисом.

Игнорировать жизненный цикл объектов

Важно понимать, когда использовать:

• Singleton
• Scoped
• Transient

Что выбрать сегодня

Если вы начинаете новый проект в 2026 году:

VContainer чаще всего выглядит предпочтительным вариантом благодаря производительности и простоте.

Если вы работаете в существующем проекте на Zenject — причин для миграции обычно нет.

Заключение

Dependency Injection помогает создавать более чистую и масштабируемую архитектуру в Unity.

Однако это инструмент для решения конкретных проблем, а не обязательная часть любого проекта.

Для большинства современных проектов стоит обратить внимание на VContainer, а для поддержки старых решений и изучения концепций по-прежнему полезно знать Zenject.

• настройки
• прогресс игрока
• инвентарь
• статистику
• сохранения уровней

В Unity для этого существует несколько популярных подходов:

• PlayerPrefs
• JSON
• ScriptableObject

У каждого варианта есть свои плюсы, минусы и сценарии использования.

В этой статье разберёмся, что и когда лучше применять.

PlayerPrefs

PlayerPrefs — самый простой способ хранения данных в Unity.

Он позволяет сохранять:

• int
• float
• string

Пример:

PlayerPrefs.SetInt("Coins", 100); PlayerPrefs.SetFloat("Volume", 0.8f); PlayerPrefs.SetString("PlayerName", "Alex"); PlayerPrefs.Save();

Получение данных:

int coins = PlayerPrefs.GetInt("Coins", 0);

Плюсы PlayerPrefs

• Очень просто использовать
• Подходит новичкам
• Отлично подходит для настроек

Минусы PlayerPrefs

• Не подходит для сложных данных
• Данные легко изменить вручную
• Нет структуры
• Плохая масштабируемость

Когда использовать PlayerPrefs

Подходит для:

• громкости
• графических настроек
• языка игры
• небольших числовых значений

Не стоит использовать для полноценной системы сохранений.

JSON-сохранения

JSON — один из самых популярных способов сохранения данных.

Суть простая:

• объект переводится в JSON-строку
• строка сохраняется в файл

Пример JSON-сохранения

Класс данных:

[System.Serializable] public class SaveData { public int coins; public int level; public float health; }

Сохранение:

SaveData data = new SaveData(); data.coins = 150; data.level = 3; data.health = 75f; string json = JsonUtility.ToJson(data); System.IO.File.WriteAllText(path, json);

Загрузка:

string json = System.IO.File.ReadAllText(path); SaveData data = JsonUtility.FromJson<SaveData>(json);

Плюсы JSON

• Гибкость
• Удобная структура
• Подходит для сложных сохранений
• Легко расширять

Минусы JSON

• Нужно самостоятельно работать с файлами
• Нет защиты данных
• Можно случайно сломать совместимость сохранений

Когда использовать JSON

Подходит для:

• RPG
• survival-игр
• сохранения прогресса
• инвентаря
• сложных игровых данных

ScriptableObject

ScriptableObject — это специальный тип объекта в Unity для хранения данных.

Главная идея:

• данные существуют отдельно от сцены
• их можно переиспользовать

Пример ScriptableObject

using UnityEngine; [CreateAssetMenu(menuName = "Game/Player Config")] public class PlayerConfig : ScriptableObject { public int maxHealth; public float speed; }

После этого можно создать asset прямо в Project.

Плюсы ScriptableObject

• Удобно хранить конфиги
• Отличная интеграция с Inspector
• Переиспользование данных
• Уменьшает дублирование

Минусы ScriptableObject

• Не подходит для пользовательских сохранений
• Не предназначен для runtime-save системы

Когда использовать ScriptableObject

Подходит для:

• настроек оружия
• конфигов персонажей
• баланса
• данных предметов
• статических игровых данных

Частая ошибка новичков

Новички часто пытаются хранить всё в PlayerPrefs.

Это быстро приводит к:

• хаосу
• сложному коду
• проблемам масштабирования

Лучше сразу разделять типы данных.

Практический подход

В реальных проектах обычно используют комбинацию:

• PlayerPrefs → настройки
• JSON → сохранения
• ScriptableObject → игровые конфиги

Это наиболее удобная и масштабируемая схема.

Заключение

В Unity нет одного универсального способа хранения данных.

Каждый инструмент решает свою задачу:

• PlayerPrefs — простота
• JSON — гибкость
• ScriptableObject — удобство работы с конфигами

Главное — использовать их по назначению.

Если вы только начинаете изучать multiplayer в Unity, скорее всего вы уже слышали про:

• Netcode for GameObjects
• Photon

В этой статье разберём, чем они отличаются, что выбрать и с чего вообще начинать.

Почему multiplayer — это сложно

В одиночной игре всё происходит локально:

• игрок нажал кнопку
• объект переместился
• игра сразу показала результат

В multiplayer всё иначе:

• действия нужно отправлять по сети
• данные синхронизируются между игроками
• появляются задержки (latency)

Из-за этого даже простое движение персонажа становится сложнее.

Основные понятия

Перед началом важно понимать базовые термины.

Client

Игрок, который подключается к игре.

Server

Сервер, который хранит состояние игры.

Host

Игрок одновременно является и сервером, и клиентом.

RPC (Remote Procedure Call)

Метод, который вызывается по сети.

Netcode for GameObjects

Netcode — официальное multiplayer-решение от Unity.

Оно хорошо интегрировано с движком и подходит для:

• кооперативных игр
• небольших multiplayer-проектов
• обучения сетевой разработке

Преимущества Netcode

Простая интеграция

Netcode работает прямо внутри Unity.

Не нужно подключать внешние сервисы.

Хорошо подходит новичкам

API достаточно понятный.

Пример сетевого объекта:

using Unity.Netcode; public class PlayerMovement : NetworkBehaviour { void Update() { if (!IsOwner) return; float h = Input.GetAxis("Horizontal"); transform.Translate(Vector3.right * h * Time.deltaTime); } }

Здесь:

• объект наследуется от NetworkBehaviour
• движение выполняется только для владельца объекта

Официальная поддержка

Unity активно развивает Netcode.

Недостатки Netcode

• Меньше готовой инфраструктуры
• Нужно самостоятельно решать часть сетевых задач
• Менее зрелая экосистема по сравнению с Photon

Photon

Photon — одно из самых популярных решений для multiplayer в Unity.

Чаще всего используют:

• Photon PUN
• Photon Fusion
• Photon Quantum

Для новичков обычно начинают с PUN или Fusion.

Преимущества Photon

Готовая инфраструктура

Photon предоставляет:

• серверы
• matchmaking
• комнаты
• подключение игроков

Это сильно упрощает старт.

Хорошая документация

У Photon огромное сообщество и много примеров.

Масштабируемость

Photon подходит даже для крупных проектов.

Пример Photon RPC

[PunRPC] void TakeDamage(int damage) { health -= damage; }

RPC позволяет вызывать методы у других клиентов.

Недостатки Photon

• Многие функции платные
• Нужно изучать отдельную экосистему
• Зависимость от внешнего сервиса

Что лучше для новичка

Если вы только изучаете multiplayer:

Выбирайте Netcode, если:

• хотите понять основы
• делаете небольшой проект
• нужен простой coop

Выбирайте Photon, если:

• нужен matchmaking
• хотите быстрый старт онлайн-игры
• планируете масштабирование

С чего начать обучение

Лучший подход:

1. Сделать локальный multiplayer
2. Изучить синхронизацию объектов
3. Разобраться с RPC
4. Только потом переходить к полноценному онлайну

Частые ошибки новичков

• Попытка сразу сделать MMO
• Игнорирование сетевых задержек
• Синхронизация всего подряд
• Отсутствие серверной логики

Практический вывод

Multiplayer — это отдельная специализация.

Не пытайтесь сразу построить сложную систему.

Начните с:

• движения игроков
• синхронизации объектов
• простых RPC

И постепенно усложняйте проект.

Заключение

Netcode и Photon — оба хороших инструмента.

Главное различие:

• Netcode ближе к "чистому" Unity
• Photon даёт готовую инфраструктуру

Для первых проектов лучше сосредоточиться на понимании основ сетевой логики, а не на выборе идеального фреймворка.

Для решения этой проблемы Unity предлагает систему Addressables.

В этой статье разберём, что это такое, как работает и как начать использовать на практике.

Что такое Addressables

Addressables — это система управления ресурсами, которая позволяет загружать ассеты по "адресу" (ключу), а не через прямые ссылки.

Вместо этого:

public GameObject prefab;

Вы используете:

Addressables.LoadAssetAsync<GameObject>("Enemy");

Это даёт больше гибкости и контроля.

Зачем нужны Addressables

Основные проблемы классического подхода:

• Жёсткие зависимости между объектами
• Загрузка всех ресурсов сразу
• Сложность управления памятью

Addressables решают это за счёт:

• ленивой загрузки (on demand)
• освобождения памяти
• удобной организации ассетов

Как работает система

Основные элементы:

• Address — строковый ключ (например "Enemy")
• Asset — сам ресурс (префаб, текстура и т.д.)
• Group — группа ресурсов с настройками сборки

Вы связываете ассет с адресом, а потом загружаете его по этому адресу.

Установка Addressables

1. Откройте Package Manager
2. Найдите "Addressables"
3. Установите пакет
4. Window → Asset Management → Addressables → Groups

После этого можно настраивать ресурсы.

Простой пример загрузки

using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class SpawnEnemy : MonoBehaviour { public string enemyAddress = "Enemy"; void Start() { Addressables.LoadAssetAsync<GameObject>(enemyAddress).Completed += onloaded; } void onloaded(AsyncOperationHandle<GameObject> handle) { if (handle.Status == AsyncOperationStatus.Succeeded) { Instantiate(handle.Result); } } }

Освобождение памяти

Очень важный момент — ресурсы нужно освобождать.

Addressables.Release(handle);

Если этого не делать — будет утечка памяти.

Загрузка сцен

Addressables также поддерживают загрузку сцен:

Addressables.LoadSceneAsync("GameScene");

Это удобно для:

• уровней
• DLC
• динамической подгрузки контента

Преимущества Addressables

• Гибкое управление ресурсами
• Экономия памяти
• Поддержка удалённых ассетов (CDN)
• Удобная система сборки

Недостатки

• Более сложная настройка
• Нужно следить за освобождением памяти
• Требует понимания асинхронности

Когда использовать Addressables

Подходит, если у вас:

• Средний или крупный проект
• Много ассетов
• Нужна загрузка по требованию

Когда можно не использовать

Можно обойтись без Addressables, если:

• Маленький проект
• Все ресурсы загружаются сразу
• Нет проблем с памятью

Практический вывод

Addressables — мощный инструмент для управления ресурсами.

Он усложняет архитектуру, но даёт:

• контроль
• гибкость
• масштабируемость

Если вы делаете серьёзный проект — стоит освоить эту систему.

Заключение

Addressables — это стандарт для современных Unity-проектов, особенно на мобильных устройствах и больших играх.

Начните с простых кейсов, постепенно внедряйте систему — и вы получите полный контроль над ресурсами.

В этой статье разберём всё максимально просто и на примерах.

GameObject — основа всего

В Unity практически всё является GameObject.

Это может быть:

• персонаж
• камера
• свет
• UI-элемент

GameObject — это контейнер, который сам по себе почти ничего не делает.

Важно: GameObject — это не поведение, а «пустая оболочка».

Transform — положение в мире

Каждый GameObject автоматически имеет компонент Transform.

Он отвечает за:

• Position (позиция)
• Rotation (вращение)
• Scale (размер)

Именно благодаря Transform объект появляется в сцене и имеет координаты.

Пример:

• Position (0,0,0) — центр сцены
• Scale (2,2,2) — объект увеличен в 2 раза

Компоненты — добавляют поведение

Компоненты — это то, что делает GameObject «живым».

Примеры компонентов:

• Mesh Renderer — отображение модели
• Collider — физика столкновений
• Rigidbody — физическое поведение
• Script (MonoBehaviour) — ваша логика

GameObject может иметь сколько угодно компонентов.

Как это работает вместе

Связка выглядит так:

GameObject = контейнер Transform = положение Компоненты = функциональность

Пример:

Вы создаёте куб:

• GameObject: Cube
• Transform: определяет где он находится
• Mesh Renderer: делает его видимым
• Box Collider: позволяет сталкиваться

Без компонентов это был бы просто «пустой объект».

Важный принцип: композиция

Unity использует композицию, а не наследование.

Это значит:

• вы добавляете поведение через компоненты
• вместо создания сложной иерархии классов

Преимущества:

• гибкость
• переиспользование
• простота изменений

Частая ошибка новичков

Новички думают, что GameObject = объект с логикой.

Но на самом деле:

• логика находится в компонентах
• GameObject только объединяет их

Практический пример

Представим врага в игре:

GameObject: Enemy

Компоненты:

• Transform
• Mesh Renderer
• Collider
• EnemyAI (скрипт)
• Health (скрипт)

Каждый компонент отвечает за свою часть.

Практический вывод

Чтобы эффективно работать в Unity, нужно помнить:

• GameObject — это контейнер
• Transform — всегда есть и отвечает за положение
• компоненты — добавляют поведение

Как только вы поймёте эту модель — работа в Unity станет гораздо понятнее.

Заключение

GameObject, Transform и компоненты — это фундамент Unity.

Освоив эти три вещи, вы сможете уверенно двигаться дальше и понимать, как устроены более сложные системы.

В этой статье разберём самые распространённые ошибки и как их избежать.

1. Смешивание логики и данных

Новички часто пишут всё в одном MonoBehaviour:

• логика
• данные
• ссылки

Это приводит к запутанному коду.

Как правильно:

• разделяйте ответственность
• используйте несколько компонентов
• держите классы маленькими

2. Жёсткие ссылки (Hard references)

Прямые ссылки через Inspector — удобно, но:

• сложно масштабировать
• ломается при изменениях

Решение:

• использовать Find только временно
• переходить на события / DI / ScriptableObject

3. Перегрузка Update()

Одна из самых частых ошибок:

void Update() { // куча логики }

Это быстро убивает производительность.

Как лучше:

• выносить логику в события
• использовать FixedUpdate / Coroutines
• проверять, нужно ли выполнять код каждый кадр

4. Игнорирование оптимизации

Новички думают:

«Сначала сделаю, потом оптимизирую»

Но потом проект уже сложно исправить.

Что важно:

• следить за количеством объектов
• использовать Object Pooling
• проверять Profiler

5. Плохая структура проекта

Типичная картина:

• Scripts
• Scripts2
• ScriptsNew

Через месяц в проекте невозможно ориентироваться.

Решение:

• логическая структура папок
• разделение по системам (UI, Gameplay, Core)

6. Магические числа в коде

speed = 5.37f;

Непонятно, откуда число и зачем.

Лучше:

• использовать переменные
• выносить в ScriptableObject или настройки

7. Отсутствие системы сохранения

Новички часто откладывают это «на потом».

В итоге приходится переделывать архитектуру.

Совет:

• продумайте сохранение заранее
• хотя бы базовый вариант (PlayerPrefs / JSON)

8. Непонимание жизненного цикла Unity

• Awake
• Start
• Update

Если не понимать порядок — появляются баги.

Решение:

• изучить lifecycle
• не инициализировать всё в одном месте

9. Копипаст вместо архитектуры

Новички часто копируют код:

Получается дублирование и баги.

Как избежать:

• выносить общий код
• использовать наследование или композицию

10. Отсутствие контроля версий

Работа без Git — частая ошибка.

Один баг — и всё потеряно.

Решение:

• использовать Git
• делать коммиты регулярно

Практический вывод

Ошибки — это нормально. Главное — не застревать в них.

Если вы:

• структурируете код
• думаете об архитектуре
• следите за производительностью

→ вы уже на шаг впереди большинства новичков.

Заключение

Unity — мощный инструмент, но без правильных привычек он быстро превращается в хаос.

Избегайте этих ошибок — и ваш путь в геймдеве будет намного проще и быстрее.

Разберёмся, что это такое, зачем оно нужно и стоит ли использовать ECS в реальных проектах.

Что такое ECS простыми словами

ECS — это архитектурный подход, в котором данные и логика строго разделены.

В отличие от привычного Unity-подхода:

• GameObject + MonoBehaviour → объект содержит и данные, и логику

В ECS всё разделено на три части:

• Entity (сущность) — просто идентификатор
• Component (компонент) — только данные
• System (система) — логика, которая обрабатывает данные

💡 Ключевая идея: компоненты не содержат логики, а системы не хранят состояние.

Почему вообще появился ECS

Классическая модель Unity удобна, но у неё есть ограничения:

• Много лишних аллокаций
• Плохая производительность при большом количестве объектов
• Сложность масштабирования

ECS решает эти проблемы за счёт:

• Data-Oriented подхода
• Линейного хранения данных в памяти
• Отличной работы с многопоточностью

Преимущества ECS

🚀 Производительность

ECS отлично подходит для проектов с тысячами объектов:

• RTS
• симуляции
• игры с большим количеством NPC

Благодаря DOTS (Data-Oriented Tech Stack) Unity может обрабатывать огромные массивы данных значительно быстрее.

🧠 Чистая архитектура

• Чёткое разделение данных и логики
• Меньше связности
• Проще тестировать

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

⚡ Параллелизм

Системы можно легко выполнять в несколько потоков.

Это критично для современных CPU.

Недостатки ECS

🤯 Высокий порог входа

Если вы привыкли к MonoBehaviour — ECS сначала кажется странным:

• Нет привычных Update()
• Нет прямых ссылок на объекты
• Нужно мыслить данными, а не объектами

🧩 Сложность отладки

• Труднее дебажить
• Меньше визуальных инструментов
• Ошибки сложнее локализовать

⚠️ Не для всех проектов

ECS — не универсальное решение.

Для небольших игр он может быть избыточным.

Когда стоит использовать ECS

Используйте ECS, если у вас:

• Много однотипных объектов (сотни/тысячи)
• Требования к высокой производительности
• Сложные симуляции

Примеры:

• RTS
• city-builder
• sandbox-игры

Когда лучше НЕ использовать ECS

Лучше остаться на классическом подходе, если:

• Маленький или средний проект
• Вы делаете UI-heavy игру
• Быстрая разработка важнее оптимизации

💡 Правило: если не уверены — не используйте ECS.

Практический вывод

ECS — это мощный инструмент, но не «волшебная таблетка».

Он даёт огромный прирост производительности, но требует:

• переучивания
• изменения мышления
• времени на внедрение

Если вы делаете сложный, масштабируемый проект — стоит изучить ECS.

Если вы делаете первую или небольшую игру — лучше сосредоточиться на классическом подходе.

Заключение

ECS — это будущее высокопроизводительных игр, но не обязательный инструмент для каждого проекта.

Используйте его осознанно и только тогда, когда он действительно решает ваши задачи.