Логи в Unity: как использовать Debug.Log и найти причину ошибки

Сообщение «не работает» не показывает, дошёл ли код до нужного метода. Лог помогает увидеть событие и данные в конкретной точке. Но если писать одинаковую строку каждый кадр, важная информация быстро потеряется в потоке.

Разберём вывод сообщений, привязку к объекту, чтение Console и поиск журналов готовой игры. Цель — получить короткую цепочку наблюдений, которая объясняет причину сбоя.

ТОП-5 курсов обучения Unity:

Debug.Log подходит для обычного диагностического сообщения. Debug.LogWarning отмечает ситуацию, на которую нужно обратить внимание. Debug.LogError сообщает о существенной ошибке, обнаруженной вашим кодом. Выбор уровня должен помогать чтению журнала.

Например, начало уровня — обычное событие. Необязательный звук не назначен — возможное предупреждение. Нет обязательной модели данных, без которой операция невозможна, — ошибка. Не превращайте любое штатное действие в LogError.

Сигнатуры и контекст сообщения описаны в справочнике Debug.Log.

Строка «Coin» мало объясняет. Полезнее увидеть имя объекта, старое и новое значение счёта и нужный этап операции. Второй параметр сообщения связывает запись с объектом Unity.

Добавьте скрипт на объект и в Play вызовите Test → Add point из контекстного меню компонента. Каждое действие должно дать одно сообщение. После диагностики подробный вывод можно отключить через Verbose.

В Console проверьте фильтры обычных сообщений, предупреждений и ошибок. Отсутствие строки может означать, что её категория скрыта. Затем посмотрите Collapse: объединённые одинаковые сообщения показывают счётчик повторений.

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

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

Допустим, монета не увеличивает счёт. Добавьте сообщение в начало обработчика, затем после проверки игрока и перед изменением счёта. Запустите один подбор.

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

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

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

Проверьте Inspector, получение компонента и момент инициализации. Проверка null может предотвратить падение, но если ссылка обязательна, её отсутствие всё равно нужно объяснить и исправить. Тихий return способен скрыть сломанную конфигурацию.

Получение ссылок разобрано в статье о поиске объектов.

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

Ошибка выполнения появляется после запуска определённого действия. Для неё полезны состояние сцены, данные, порядок событий и шаги воспроизведения. Записывайте, что вы сделали непосредственно перед сообщением.

Console Editor не является единственным журналом. У Editor, Hub и Player есть свои log files. На Windows типовой журнал Player находится по пути %USERPROFILE%\AppData\LocalLow\CompanyName\ProductName\Player.log; названия зависят от параметров продукта.

Пути других платформ и ограничения описаны в справочнике журналов Unity. Для Web вывод смотрят также в консоли браузера. Для платформенных сбоев используйте инструменты соответствующей платформы.

Если ошибка возникает только в сборке, воспроизведите её там и прочитайте этот журнал. Сообщения успешного запуска внутри Editor не объясняют автоматически ситуацию на другом устройстве.

Логирование каждый кадр создаёт шум и может влиять на работу приложения. Сообщайте об изменении состояния: переходе уровня, принятом действии, загрузке данных. Для повторяющейся диагностики используйте флаг, счётчик или ограничение частоты.

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

Сохраните версию Unity, версию пакета, платформу, шаги, ожидаемый результат и небольшой фрагмент журнала со стеком. Укажите, воспроизводится ли проблема в отдельной сцене и в сборке.

Затем повторите сценарий после исправления. Исчезновение красной строки — лишь часть проверки; нужное действие игры тоже должно работать. Такой подход превращает лог из списка тревожных сообщений в инструмент объяснения поведения.