Pull to refresh

Comments 11

Годный туториал, если говорить о «игре, сделанной на коленке просто потренироваться и выкинуть».
Но если говорить о серьезных играх (даже мелочи типа TD) то это уроки о том как делать не нужно. И упомянутые в статье видео, к слову, тоже качеством не блещут.
Проблема подобных туториалов в том, что новички, насмотревшись на них, идут и делают так же, принимая все вышеказаное за «Best Practices».
Потому думают, почему у них долго инициализирется сцена (пустые методы, типа Start, Awake), почемуу них низки fps (обращение к компонентам без кеширования), и вообще, почему в годе происходит непноятная «магия» (потому что оставили поле public, только для того, чтобы оно было видно в инспекторе, всесто использования private + SerializeField, и кто-то из лени записал в это поле свое значение). Я уже молчу об общепринятых Style и Naming Conventions.
А разве компилятор не выбросит пустые методы?
Компилятор не сможет его выбросить, потому что Юнити на него ссылается. Когда скрипт добавляется в проект Юнити сохраняет список «этих самых» методов для каждого монобеха и потом их вызывает.
https://blogs.unity3d.com/2015/12/23/1k-update-calls/
Полезная статья, спасибо.
Многие заметили, что статья и видео похожи на уроки с этого канала. От части это так. Но я позаимствовал только лишь расстановку вэйпоинтов и построение уровня.

Это не так, повзаимствованы все косяки и нежелание их исправлять, т.е. статья просто перевод — так ее и надо оформлять. В комментах к прошлому переводу были ссылки на best practices. Что в итоге? На крипах опять колайдер без Rigidbody, двигаются они в Update, а спаунятся и умирают бесконтрольно (привет, фризы на GC).
Насчет коллайдера без риджитбади абсолютно согласен. Но не могли бы вы мне пояснить что именно в движении по апдейту не так? Как можно было бы сделать лучше?
Все, что связано с физикой — может двигаться только в FixedUpdate (частота вызовов FixedUpdate соответствует частоте симуляции физики). Цепочка проста: используем двигающиеся колайдеры -> используем rigidbody на них -> двигаем только в FixedUpdate. Если двигать в Update / LateUpdate — мы будем двигать чаще чем физика будет симулироваться и это приведет к дрожанию и протыканию колайдеров со всякими неопределенными поведениями.
Я извинюсь, а где они должны двигаться? В FixedUpdate? И что значит умирают безконтрольно? Как это лучше сделать?
Напишите если не сложно, хотелось бы узнать
Бесконтрольно — значит инстанцируются и уничтожаются без дополнительной обработки. По сути — это самые тяжелые операции (инстанцирование само по себе, уничтожение — в результате копится мусор, который однажды будет собран GarbageCollector-ом с фризом основного потока). Чтобы такого не было, применяют разные техники, например, пулинг: когда требуется много одинаковых объектов создавать / уничтожать, мы просто не уничтожаем их, а прячем и кладем в очередь на будущее использование; когда в следующий раз потребуется инстанцировать такой объект — сначала проверяем эту очередь и берем инстанс оттуда (настраиваем позицию, свойства и тп — все как для нового инстанса). В результате память через какое-то время перестает выделяться и течь в GC — инстансы будут переиспользоваться по кругу.
Пример реализации: PoolContainer
Пример использования (тут лучше смотреть в тестовую сцену — на префабе висит RecycleAfterTime): PoolingTest
А для чего на Spawner вообще висит компонента бокс коллайдер? Решение так себе, согласен с Tutanhomon И зачем вейпоинты искать файндом? Вообще юнитёвые файнды лучше юзать в крайних случаях, когда по-другому не обойтись, а тут и без него обойтись довольно просто.
Просто потому что он там висит по умолчанию, непонятно почему его отключают а не удаляют.
Sign up to leave a comment.

Articles