4 ошибки в Unity которые совершают начинающие программисты | Часть 1

Если показываете своё произношение английского, то имейте в виду, что будет правильно "компОнент".

Я так и не понял, почему нельзя обращаться к transform

Совершенно бесполезное видео.

Хотел бы уточнить, т.к. ребята по первому пункту путаются. Как я понял.
transform.SameMethod такая запись это аналог записи GetComponent<Transform>.SameMethod. Т.е. вызов метода гетКомпонент идёт каждый кадр. Вместо этого гетКомпонент вызывается один раз на старте (или раньше) и дальше уже юзается ссылка соответствующего типа.

У МЕНЯ В НОВОМ ПРОЕКТЕ 27 ОШИБОК, А Я ДАЖЕ НИЧЕГО НЕ МЕНЯЛ!!!!!!

так а как использовать transform если не в update если менять его постоянно собираемся ?

В 4ом пункте ButtonPrefab должен быть не GameObject в таком случае, а ItemPresenter и тогда произойдет магия и не нужно будет использовать после инстантиейта GetComponent...

Что вместо трансформа тогда использовать?

2.) Зачем вообще эти проверки и ивенты если при получения урона вы по любому будете менять Health там же строчкой меняете Display.text =health;

На счет 4 проблемы не понял - что она исправляет/решает? У нас так же есть дочерний объект с компонентом Text, поле которого вообще не меняется.

1. А как тогда сделать передвижение объекта?

Слово "однерка" не существует!

консультации ведете?

Спасибо за видео. Header произносится как "хэда" или "хэдр", а не как "хизр"

Слышишь, классический антипатинг, как тебе там живется? Ты там гонишь, что кто-то пишет говно код? СУКА КАК МЖНО СПИЗДАНУТЬ КЛАССИЧЕСКИЙ АНТИПАТИНГ? Гуглил бы хоть что такое. Невозможно, если человек занимается программированием, когда он попросту не знает названий банальнейших вещей, не бывает так. Кто вам пишет код, текст для видео? Этим явно занимаешься не ты, Роман

походу видос поутратил в актуальности.. да и кого не посмотри- того же Brackeys - всьо там с трансформом хорошо и официально Юнити говорит вот смотрите этого парня.

Ну ну, смотреть советы от дауна, который и сам нихера не умеет

Отлично
Но мало
Еще

Почему бы во втором примере не обращаться к здоровью через свойство, где и будет реализованы проверки и вызов события? Очевидно же, то при обращении к Set здоровье будет меняться в 99% случаев

С чего вдруг get_transform вызывает GetComponent<Transform>() загляни-ка в dnSpy

А что делать если все курсы гавно, а миллиардов долларов на курсы этого чувака у меня нет? Как обучиться c# на юнити?

PyGame убьет Unity

В первом примере ты был против использования transform в Update, в третьем уже за, при этом не предложив никакой альтернативы. Лишь бы что сморозить?

Ошибки скорей в использовании самого языка программирования C# и актуальны не только для Unity, но видео хорошее в любом случае)

Использование transform это в первую очередь удобно и кратко, заниматься кэшированием и ленивой загрузкой это лишний код который должен быть оправдан.
Потом если и будут проблемы с производительностью то совсем не факт что получение transform`a будет узким горлышком, возможно все манипуляции с трансформацией объекта будут в разы дороже чем получение transfrom`a. Да и где тесты подтверждающие это? Насколько медленнее? GetComponent просто ищет компонент линейным поиском. Transform всегда в списке компонентов первый искать то особо и не надо, я лично сомневаюсь что GetComponent<Transform> и получение компонента через свойство transform будут отрабатывать за одно и тоже время.

Непонятно, как без апдейта жить. Дождавшись события вызывать нужный метод через InvokeRepeating("MethodName",Time.deltaTime)? Это уже байтодрочерством попахивает. А если ты каждый кадр проверяешь всего то навсего несколько булеанов, это что сильно скажется на производительности?

Не понял, почему нельзя создать Observable, который будет триггерить на _health, у нас range будет 100 max, и магии никакой, каждый фрейм считать не надо, и вроде производительность не падает?Если что я правда не знаю, хочу послушать ваше мнение, спасибо!)

С каких это пор сравнение двух флоатов, пусть даже в апдейте, стало тяжёлой операцией?))

На i7 шестилетней давности: луп на миллион итераций дает такие результаты: обращение к кэшированному трансформу: 55мс. Обращение к не кэшированному трансформу: 104мс. Объявление локального инта и проверка его на «меньше или равно»: 6 мс.
Луп на 100к итераций - 5мс, 10мс, 0мс.
Луп на 25к итераций - 1мс, 2мс, 0 мс.
Луп на 10к итераций - 0мс, 0мс, 0мс.

Если объектов до 25-50 тысяч, то имхо смысла с кэшем трансформа запариваться нет. Проверка значений практически не сказывается на производительности.

А что делать, если после установки unity, в Unity Hub при нажатии на проект ничего не происходит, ничего не открывается. А когда создаёшь новый проект он запускается и всё работает, но при выходе и входе в него он также перестаёт запускаться.

Пробовал переустанавливать unity - ничего не изменилось. Ставил все версии.

Самая главная ошибка, которую может допустить новичок юнити, это смотреть видео с этого канала

И что использовать вместо transform?

Годно, грешил сильно проверкой в update

Я вообще андроид разработчик, что я тут делаю

Ролик небольшой, но полезный, спасибо.

Не сказал бы что трансформы в апдейтах пускай даже каждый кадр едят там что-то сверхестественное) По оптимизации таких вещей впринципе даже можно недумать)
Игра даже на самом убогом телефоне ~за 2к рублей ,нормально будет работать с трансформами в апдейте.. Смысл этой оптимизации 0))
Если ищете оптимизацию, лучше копайте в сторону шейдеров, там можно значительно оптимизировать игру, к примеру игра с неправильными шейдерами выдает 20 фпс, сделайте нужные вам шейдеры и получите 60-100 фпс из 20, вот это оптимизация) Лучше про такое пишите уроки)
Оптимизируйте модели,эффекты.

Почему о секретах unity мне рассказывает человек, который читает header как "хидер"? Или документация юньки не на инглише написана?

1. Использование свойства transform
2. Постоянные проверки в Update
3. Использование непонятных чисел, вместо полей с понятным названием
4. Поиск дочерних объектов

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

заместо слова нет, есть вместо

1. Когда что-либо кому-либо разъясняете за Unity необходимо всегда вести ликбез в контексте версии Unity, т.к. то что справедливо в одной версии не всегда справедливо для другой.
2. По поводу 4ого пункта: ItemPresenter не гетнуть как компонент т.к. он не унаследован от Component, и уж тем более не накинуть на геймобжект т.к. он не унаследован от MonoBehaviour (не говоря уже о том что имя наследника MonoBehaviour должно совпадать с именем файла в котором он описан).

Почти вовремя, аудио в финале, с голосом сработали)

6 лайков до нового видосика)

))))

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

2. Проверки в Update. Хм, а вы все еще думаете, что создавая события вы тем самым что можете ждать? События также имеют свой стак и также апдейтятся. Проверки здоровья, на столько ничтожно мелкие операции, что не каких тут нагрузок неощутимы. Update неопасен такими операциями, но если вы туда будете засовывать медленные функции (которые долго работают), например какой нибудь find то конечно это уже перебор.

Ну и самая главная ошибка новичков, изначально многополигональные модели в огромном числе. Это самое уязвимое место в любых играх, не оптимизированные модели, злоупотребление высоким полигонажем особенно с кучей постэффектов, динамическим светом и тому подобное. А кодом, просадить оптимизацию в целом нужно постараться и быть совсем мало осведомленным.

Роман, если возможно, снимите видео с советами по организации структуры проекта в Unity. Это было бы очень здорово!

Надо было дорисовать слово в сцене. xD

кеширование transform встроили еще в 2017 юню, так что можно спокойно к нему обращаться на прямую. Я сам не проверял, кому не лень потестируйте

Давай курс для продвинутых )