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

Там написано P.S : Автору 13 лет :)

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

Давай разбор этого типа ukposts.info/have/v-deo/bKp4qJiqr6Bmp5c.html

@@jakepomg317 У него проблемы с абстрактным мышлением.

Завел канал для того, чтобы Роман сделал бесплатное ревью на твой код - это гениально, пойду траить.

._. Я что в стране адекватов которые не бомбят?

Человек, здраво воспринимающий конструктивную критику, всегда развивается

Я так и знал что тут будешь ты

Респект таким пацанам

А ведь правда, рожа бандитская

ПРОФЕССИОНАЛЬНЫЙ программист и просто программист это разное Ну а так то да, у Романа Сакутина названия роликов странные

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

Скоро будет

очень скучно смотреть за пассивной агрессией в этом ролике. Даже когда для данного конкретного случая код является приемлемым, как случай с PlayerPrefs - автор всё равно пытается унизить ice cream чтобы возвыситься за его счет.

@@user-uk9pv6bx7z ну они не льют желчь на ютубе как автор канала.

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

Полностью согласен

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

@@const1988 но написание публичного поля и свойства занимают разное время -а у них разные нотации - отсюда и эта вечная проблема маленькой/большой буквы

@@asisu2877 ну я в данном случае писал про поле, которое обсуждалось в самом начале видео.

Не то слово

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

@@1pampers13aby7 мой комментарий удалили, который я тебе писал, в общем, Graphic Design распространяет плохие идеи, вспомни хотя бы видео про переключение персонажей, а потом людям приходится объяснять чем плох такой код.

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

На расте можно сторонним макросом сделать SoA, с которым можно будет работать и как с AoS, и как с SoA.

Если это не шутка: 1. Чаще используют FixedUpdate. 2. Можешь почитать в справке про Time. deltaTime.

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

@@xezdx Вопрос был про движение, так как часто делают через физику, написал про fixed. Дальше уже человек может сам покопаться.

Уже есть на канале

@@user-ey7rd9ih4g зачем мне это?)

Так экстримкод изначально на серьёзных щах ничего не подают

Никогда. Зачем ему деньги терять?

Так у него вроде нету кода никакого

чё за негатив?

камшот

В гейдеве все такие.

Я её съел

Здравствуйте, относительно не давно я бы с вами согласился, а вот сейчас совсем нет. Советую прочитать прекрасные книги Роберта Мартина "Чистый Agile", "Чистый код", а также книгу Кента Бека "Разработка через тестирование" (Test-driven development). Обещаю, после изучения книг эти вопросы у вас испарятся.

Да, но раньше все просто всегда делали публичные поля

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

@@asisu2877 идеальный - согласен, не пишут. Но есть вещи, которые ты НИКОГДА не напишешь, потому что они в корне не правильные. У нас даже джуны такого не творят. Есть базовые правила, которым ты сделаешь по умолчанию. Вы же никогда не будете лить чай, не в рот, а в нос например? Даже идеи такой не возникнет. А по 7 минутам - вообще странно. Все во первых, лечится склейками, а во вторых - автор должен же продумать изначально, что он будет делать.

Ну вы же делаете и не переживаете.

@@aammssaamm Ну так я и не выкладываю обучающие видео по русскому языку))

@@TheMerklar И не переживаете.

@@user-ey7rd9ih4g Про базу данных знаю, про базу языка не слышал.

Я не разбираюсь в Unity, но могу примерно объяснить в чем отличие. Краткое объяснение: это хорошая практика Более долгое объяснение: Дело совсем не в аттрибуте [SerializedField], а в модификаторе доступа "private", который используется совместно с этим аттрибутом, и его отличия от "public" в контексте ООП В ООП один из фундаментальных принципов - это инкапсуляция. Инкапсуляция - это защита инварианта класса (по определению Романа, которое мне нравится). Она и есть объяснение Вашему вопросу. Рассмотрим ее на примере: допустим, у Вас есть задача создать пользовательский интерфейс для таймера. Скорее всего, Вы начнёте писать что-нибудь типа: public class Timer { ... } Вы, скорее всего, понимаете, что время в таймере не может быть отрицательным - это и объявим инвариантом класса (то есть это условие, которое ни при каких условиях не должно нарушаться) (Даже сам класс не может нарушать это условие) Далее объявляем поле публичное поле Time, которое отвечает за время в таймере: public class Timer { public int Time = 0 ... } В клиентском коде кто-то напишет: Timer timer = new Timer() timer.Time = -100000 // Всё сработало! Поскольку мы напрямую ставим значение в публичное поле объекста класса, то мы не можем провести проверку полученного значения, следовательно не можем гарантировать, что время в таймере (значение в поле Time) - это неотрицательное число, следовательно мы нарушили инвариант класса. (то есть нарушили инкапсуляцию) Таких проблем с приватным полем нет, поскольку никто не может к нему обращаться извне и мы можем сами сделать все нужные проверки, тем самым гарантируя, что мы защитили инвариант класса: public class Timer { private int _time = 0 } Пользовательский код: var timer = new Timer() timer._time = -100000 // Ошибка! Не думаете, что инкапсуляция - это про модификаторы доступа. Если Вы можете защитить инвариант своего класса другим способом, то пожалуйста. Просто один из самых лёгких способов её соблюсти - это скрыть поля от внешнего доступа с помощью модификатора доступа "private" В этом и есть основное различие [SerializeField] от public. На него и жалуется Роман и советует пользоваться [SerializeField] вместе с private P. S. Я написал свое понимание этой проблемы, поэтому советую провести собственные изыскания

@@user-ey5xw2nx9s кароче: [сералайзфиед] private var ksj; >>показывается в инспекторе private var ksj; >>не показывается public var ksj; >> всем эта переменная доступна как шл... Я так понимаю, и пока что хватает, я новичек