Впервые произошла такая ситуация, когда 20-минутный урок смотришь будто он от силы идет 5-7 минут. Очень интересный урок, без воды, с нормальной речью и без растягиваний. За 20 минут рассказано то что некоторые умудряются растянуть на час. Объяснение очень понятное. Нет ничего лишнего, только код нужный для урока. Никакого копирования из других скриптов и т.д. Это один из немногих уроков где с 1-2 просмотра ты понимаешь о чём идет речь и без проблем ориентируешься в коде, который написан в примере. Плюс ко всему, с таким примером, его можно без проблем повторить, даже если видео уже закрыто. Очень печально что такие качественные уроки набирают так мало просмотров. Думаю канал стоит развивать, и делать что-то вроде рекламы. Потому что урок действительно хороший. А с таким уровнем качества, канал ждёт светлое будущее.
Я только начал делать уроки (относительно), поэтому все еще впереди). Пока уроки выходят редко, т.к. нет времени на монтаж, но когда канал начнет приносить какие-никакие деньги - то первое, что будет сделано - монтаж уйдет на аутсорс, и количество видео увеличится :) ПОДДЕРЖАТЬ проект можно здесь ➔ www.tinkoff.ru/sl/44cyJfImuhT
Спасибо большое. Урок что нужно. Потратил неделю на изучение данной темы. Много где смотрел. Здесь раза 3-4 нужно посмотреть, вникнуть и уже будет понятна логика. Вообщем за неделю изучения материала, именно данное видео позволило мне сдвинуться с мертвой точки, спасибо.
Большое тебе спасибо за урок. Ты - талантище, умеешь обьяснять так понятно и так быстро... ну без воды, после ролика, у меня такое ощущение будто я в своем познании настолько преисполнился.... да и дикция у тебя отличная, даже если поставить ролик на 2х скорость то все прекрасно понятно. Знай ты получил от меня заслуженый лайк, хоть их я ставлю не часто, в основном дабы потом можно было найти видео, но тут чисто в знак благодарности. Еще раз спасибо!
Смеюсь и плачу, когда вижу комментарии где люди каждую строчку критикуют. Вы не забывайте, что программирование придумано людьми для того, чтобы оно приносило пользу, а не эстетический оргазм, который нужен только людям с окр и/или перфекционизмом
Наткнулся на ваше видео и с первого раза все понял, спасибо. Хотя до этого сколько бы не вчитывался в принципы ООП до конца не мог нормально все понять.
На обучающем ресурсе от разработчиков Юнити, как пример инкапсуляции приводят использование свойств. Что позволяет использовать приватные поля вместо публичных с контролем доступа к этим полям. В принципе логично, потому что инкапсуляция подразумевает не только "сокрытие" реализации, но и защиту "содержимого" объекта от непредусмотренного внешнего воздействия.
Можно и подробнее - связываться с 3D начинающий разраб не станет, если он в своем уме, а вот начинать с 2D - это то что доктор прописал. Поэтому тематика 2D - востребована начинашками. Не зря всякие Флатинго/ХаудиХо и пр. Гоши Дудари активно снимали на эту тему. движения персов/камеры, свет, партиклы, цвет, бесплатные ассеты с магазина Юнити - я б рыл в ту сторону. И да, я имею шкурный интерес в таком материале.
@@gamedevlavka проще всего на диване лежать. Ждем новых видео. Ну и сахара в видосы добавить, мемчиковой херни - начинающие разрабы это молодежь ± 20 лет. Удачи!
Нет принцип инкапсуляции,это когда в одном классе присутствуют свойства,или поля, методы,и когда они взаимодействуют с друг другом ,при этом они не зависят друг от друга,и даже не знают о существования друг друга,но при этом они могут взаимодействовать с друг другам,но при этом,их свойства,не как не пересекаются между собой,это один из очень сильных Паттернов.Но реализовать его могут единицы. А то что вы нам показал,не как даже близко не может назваться таким принципом . Помню смотрел одну лекцию,по php,там было написано,то что получает из вне,не коем образом не является инкапсуляции,даже если написаны в объектно ориентированном стиле ,я эти слова запомнил))
Спасибо за урок. Сейчас пытаюсь понять, как лучше связывать не связанные напрямую компоненты, через gameManager или через ближайших родителей, непонятно пока короче.
Отличный вопрос! И это вопрос архитектуры игры! Если вкратце, то существуют конечные элементы геймплея (игрок, враги, объекты и др) и элементы контроля, которые следят за геймплеем и знают о них. Соответственно контроллеры регистрируются где-то в общем месте, которое имеет глобальный доступ. Соответственно через подобное место можно доставать контроллеры и из них уже нужные элементы геймплея.
Видео классное но остался момент, в SpyCar мы унаследовали BaseCar, и непереопределив метод Drive добавили метод на невидимость, который так и не использовали, в каком месте согласно парадигме ооп мы должны его вызывать(брать инпут с клавиатуры, вызывать метод стать невидимым). Это реализуется в InputController или инпут конкретно этого экземпляра мы будем брать в классе SpyCar?
@@Anton-ny6tx а можно просто вместо конкретного действия (Move), передавать массив нажатых кнопок(или массив игровых действий, которые мы получаем от системы биндов, чтобы была возможность менять значения кнопок, нам ведь не важно какая кнопка нажата, важно само значение кнопки) через метод интерфейса например: OnPlayerInput, а реализация пусть сама разбирается какие методы вызывать (Fly, Drive и т.д) исходя из массива действий. Это делает нашу систему гибкой, и позволяет в производную от Car, добавить действия хоть для всех кнопок на клавиатуре, при этом базовые классы вообще не надо менять. И ещё позволяет нам в производных классах блокировать вызов базовых методов, изменяя массив игровых действий в производных классах до вызова base.OnPlayerInput.
летающую машину логичнее отнести к воздушному транспорту, т.е. наследоваться от лучше какого-нибудь AirVehicle с методом Fly(). BrokenCar вообще мем какой-то, здесь лучше добавить булевое значения isBroken и соответственно проверить условие в Drive() в базовом классе
Это все понятно, у меня задача была показать вещи на примитивных примерах, чтобы был понятен механизм. А то, что он не лучшее решение - это здесь вообще роли не играет. Тем не менее AirVehicle должен быть унаследован от некоего Vehicle и иметь переопределенный метод Move(), а не Fly, иначе будет жесткая зависимость от того, летающее транспортное средство или нет. Булевое значение тоже не всегда подойдет, пример - несколько типов раздолбанных машин, одна без колес, но мотор работает и можно газовать, другая совсем сломана и мотор не работает, третья вроде едет, но с очень медленной скоростью, рывками, как-нибудь еще. Под разные задачи - разные решения
@@gamedevlavka да, под разные задачи - разные решения. я же не писал, что Move() вовсе не будет, это же реализация интерфейса, я имел в виду странность содержания двух по сути взаимоисключающих методов Fly() и Drive(), разве только если у машины не 2 мода - воздушное и наземное перемещение, однако тут уже возникают другие вопросы.. насчёт примитивных примеров, тогда лучше было бы взять в качестве них что-то имеющее больше смысл. если это видео совсем для новичков, мало ли, как их воспримут
как можно проверить, стоит ли деталька в механизме на своём месте? (в игре типа надо собрать механизм) У меня есть абстрактный класс BaseDetail и разные детальки типа винты, шестерёнки, крышки они наследуются от BaseDetail, у которого есть булевая переменная, показывающая состояние детальки(уже на месте или нет), но я хз как к ней обратиться, потому что деталей много и у всех разные скрипты и названия
Не ..не... Никто не заметил неправильного наследования? BrokenCar? Точно? Это же состояние) Грубая ошибка! У тебя в base классе должен быть enum работающая машина, сломанная машина и т.д. "А, во все остальные ты наследуешь этот enum" через паблик или протект. Лучше через паблик!😀 Учишь наследовать от болды. Это мина, которая уничтожит архитектуру проекта.
Копец у тебя структура. У меня PlayerMovement, PlayerRotation, PlayerShooting, LivingEntity и это всё я вешаю на Player. Unity изучаю 20 дней. Я так понял у меня плохая структура? И мне нужно всё переделать?
Если я правильно представил, то да. Но ты не расстраивайся, через подобное проходит каждый, и вот ты уже прошел, а значит стал опытнее. Путь улучшения кода, он бесконечный
У тебя структура разделяющая все ответственности игрока, вместо того что бы реализовывать Год класс и запихиватть в него все подряд, как показано в видео.
-> Интерфейс - это такая штука -> Исключение - это отдельная тема для изучения -> И вот, мы работаем как бы с абстракцией Кого? Куда? Зачем? Ни одного нормального объяснения. Весь урок сводится к "Ээ, ну тут вот так делаем, а тут вот так и всё работает". Классно. Урок подойдёт только тем, кто уже хорошо знаком с ООП. Тогда в чём его смысл?
Урок для тех, кто изучал программирование где-либо, знает теорию. Но не доконца понимает, как работает на практике. Поэтому сухая теория опущена и на пальцах рассказывается, как работает на практике
Если ты смотришь ролик, чтобы узнать как правильней всего говорить, то да, для тебя нет смысла. А тем, кто хочет научиться писать код, видео может помочь
@@alexwinston3635 я бы посоветовал почитать какую-нибудь книгу на эту тему, так как принципы ООП не меняются. К сожалению, не могу посоветовать книгу именно по изучению с нуля, т.к. я проходил это в универе, а не учил самостоятельно, но очень советую почитать "паттерны проектирования", когда появится небольшое понимание. Именно от авторов Фримен, Робсон, Сьерра, Бейтс. Читается легко и помимо паттернов там хорошо раскрывается тема и принципы ООП подхода. Но опять же, рекомендую читать уже после того, как появится понимание ООП
Впервые произошла такая ситуация, когда 20-минутный урок смотришь будто он от силы идет 5-7 минут. Очень интересный урок, без воды, с нормальной речью и без растягиваний. За 20 минут рассказано то что некоторые умудряются растянуть на час. Объяснение очень понятное. Нет ничего лишнего, только код нужный для урока. Никакого копирования из других скриптов и т.д. Это один из немногих уроков где с 1-2 просмотра ты понимаешь о чём идет речь и без проблем ориентируешься в коде, который написан в примере. Плюс ко всему, с таким примером, его можно без проблем повторить, даже если видео уже закрыто.
Очень печально что такие качественные уроки набирают так мало просмотров. Думаю канал стоит развивать, и делать что-то вроде рекламы. Потому что урок действительно хороший. А с таким уровнем качества, канал ждёт светлое будущее.
Я только начал делать уроки (относительно), поэтому все еще впереди). Пока уроки выходят редко, т.к. нет времени на монтаж, но когда канал начнет приносить какие-никакие деньги - то первое, что будет сделано - монтаж уйдет на аутсорс, и количество видео увеличится :)
ПОДДЕРЖАТЬ проект можно здесь ➔ www.tinkoff.ru/sl/44cyJfImuhT
Ходит легенда что если посмотреть все видео этого автора, можно стать middle unity c# разработчиком
Впервые пишу комментарий под образовательным контентом, твои обьяснения безупречны
Самое понятное объяснение всех этих ООП-штук, которое я когда-либо встречала. Спасибо! Лайк, подписка, теперь смотрю все твои ролики.
Я так рад, что этот видос мне выскочил в реках. Спасибо огромное
Спасибо большое. Урок что нужно. Потратил неделю на изучение данной темы. Много где смотрел. Здесь раза 3-4 нужно посмотреть, вникнуть и уже будет понятна логика. Вообщем за неделю изучения материала, именно данное видео позволило мне сдвинуться с мертвой точки, спасибо.
Здраствуйте можно спрлсить вы уже стали програмистом и сколько лет уже работаете?😮
Огромное спасибо за объяснение простым языком абстрактных тем) лайк, подписка
Ощущение, будто в куче компоста нашёл рабочие ролексы, офигенные уроки, спасибо
Самое толковое и простое объяснение интерфейсов, которое я встречал. Спасибо тебе большое за такой классный материал!)
Большое тебе спасибо за урок. Ты - талантище, умеешь обьяснять так понятно и так быстро... ну без воды, после ролика, у меня такое ощущение будто я в своем познании настолько преисполнился.... да и дикция у тебя отличная, даже если поставить ролик на 2х скорость то все прекрасно понятно. Знай ты получил от меня заслуженый лайк, хоть их я ставлю не часто, в основном дабы потом можно было найти видео, но тут чисто в знак благодарности. Еще раз спасибо!
Топовое видео по объяснению ООП
Пробігся по каналу і зрозумів, що це те що треба перед співбесідою юніті, дякую за працю. Такий контент заслуговує на більше
Спасибо, умный и добрый человек!
Крайне рад что есть такой годный контент, не представляю как можно жить без такого :3
Почему это видео так поздно мне попалось... Классная подача материала!
Смеюсь и плачу, когда вижу комментарии где люди каждую строчку критикуют. Вы не забывайте, что программирование придумано людьми для того, чтобы оно приносило пользу, а не эстетический оргазм, который нужен только людям с окр и/или перфекционизмом
Спасибо большое за урок, очень поднял свой навык в ооп, следовательно буду щас практиковаться на оружии
Ютуб подкинул видео про корутины. Просмотрел заголовки всех видео Вашего канала - похоже придется смотреть их все)
Боже, идеальный канал, все нах, бессонные ночи поехали. Ты лучший!
очень помог, спасибо большое!
Наткнулся на ваше видео и с первого раза все понял, спасибо. Хотя до этого сколько бы не вчитывался в принципы ООП до конца не мог нормально все понять.
ты просто сокровище для начинающих программистов
Автор, спасибо вам большое за ваш труд. С удовольствием послушал и даже разобрался! Теперь начинаю "крестовый" поход на все ваши ролики)))+подписался
Это видео помогло мне выучить ООП! Спасибо.
Мужик красава. Расти. Все будет окей скоро
Лучший, спасибо большое ❤
Спасибо дружище! Полезные уроки!
Спасибо за урок, очень полезное видео! 👍👍👍
Спасибо, это очень нужный контент
Спасибо за урок, без скучной теории, на живых примерах. Классно!
Очень нравятся твои видео, жду новых с нетерпением
Большое спасибо!
Каждый раз при запуске редактора Unity разливается одна банка зелёнки) XD
На обучающем ресурсе от разработчиков Юнити, как пример инкапсуляции приводят использование свойств. Что позволяет использовать приватные поля вместо публичных с контролем доступа к этим полям. В принципе логично, потому что инкапсуляция подразумевает не только "сокрытие" реализации, но и защиту "содержимого" объекта от непредусмотренного внешнего воздействия.
Вот хороший формат подачи материала. Дополнить 2D и ему цены не будет.
Можно подробнее? Актуальные темы для уроков - это очень важно!
Можно и подробнее - связываться с 3D начинающий разраб не станет, если он в своем уме, а вот начинать с 2D - это то что доктор прописал. Поэтому тематика 2D - востребована начинашками. Не зря всякие Флатинго/ХаудиХо и пр. Гоши Дудари активно снимали на эту тему. движения персов/камеры, свет, партиклы, цвет, бесплатные ассеты с магазина Юнити - я б рыл в ту сторону. И да, я имею шкурный интерес в таком материале.
@@dmitriypermyakov5402 спасибо за пожелания, хорошие темы, есть что рассказать. Правда от себя добавлю, что порой 2D сложнее, чем 3D
@@gamedevlavka проще всего на диване лежать. Ждем новых видео. Ну и сахара в видосы добавить, мемчиковой херни - начинающие разрабы это молодежь ± 20 лет. Удачи!
@@dmitriypermyakov5402 Мне 20 лет и никакие мемчики мне не нужны, спасибо откажусь. Хочу получать информацию, а не приколы.
Бомба вообще
Нет принцип инкапсуляции,это когда в одном классе присутствуют свойства,или поля, методы,и когда они взаимодействуют с друг другом ,при этом они не зависят друг от друга,и даже не знают о существования друг друга,но при этом они могут взаимодействовать с друг другам,но при этом,их свойства,не как не пересекаются между собой,это один из очень сильных Паттернов.Но реализовать его могут единицы.
А то что вы нам показал,не как даже близко не может назваться таким принципом .
Помню смотрел одну лекцию,по php,там было написано,то что получает из вне,не коем образом не является инкапсуляции,даже если написаны в объектно ориентированном стиле ,я эти слова запомнил))
Спасибо за урок.
Сейчас пытаюсь понять, как лучше связывать не связанные напрямую компоненты, через gameManager или через ближайших родителей, непонятно пока короче.
Отличный вопрос! И это вопрос архитектуры игры! Если вкратце, то существуют конечные элементы геймплея (игрок, враги, объекты и др) и элементы контроля, которые следят за геймплеем и знают о них. Соответственно контроллеры регистрируются где-то в общем месте, которое имеет глобальный доступ. Соответственно через подобное место можно доставать контроллеры и из них уже нужные элементы геймплея.
10:09 или слон летающий🤣
Респект, только у меня появился вопрос. Можно ли реализовать свойства? Если да было бы круто у видеть такое видео.
А часто используется в коммерческих проектах c# такой способ переноса фигурных скобок как в java? То есть в той же строке объявления метода.
Не часто. Я сам уже пересел на классическую нотацию. Вообще все зависит от заказчика, или тех лида, который устанавливает код стиль
Видео классное но остался момент, в SpyCar мы унаследовали BaseCar, и непереопределив метод Drive добавили метод на невидимость, который так и не использовали, в каком месте согласно парадигме ооп мы должны его вызывать(брать инпут с клавиатуры, вызывать метод стать невидимым). Это реализуется в InputController или инпут конкретно этого экземпляра мы будем брать в классе SpyCar?
Нужен еще один слой абстракции именно для машин с супер способностями.
@@Anton-ny6tx а можно просто вместо конкретного действия (Move), передавать массив нажатых кнопок(или массив игровых действий, которые мы получаем от системы биндов, чтобы была возможность менять значения кнопок, нам ведь не важно какая кнопка нажата, важно само значение кнопки) через метод интерфейса например: OnPlayerInput, а реализация пусть сама разбирается какие методы вызывать (Fly, Drive и т.д) исходя из массива действий.
Это делает нашу систему гибкой, и позволяет в производную от Car, добавить действия хоть для всех кнопок на клавиатуре, при этом базовые классы вообще не надо менять. И ещё позволяет нам в производных классах блокировать вызов базовых методов, изменяя массив игровых действий в производных классах до вызова base.OnPlayerInput.
У меня в Inputcontroller нет ячейки для добавления ссылки на Character.Как исправить?
Возможно, нужно дописать [SerializedField] перед приватным полем
@@gamedevlavka спасибо за ответ ,все было гораздо проще ,нужно было сохранить код в VS 😂
летающую машину логичнее отнести к воздушному транспорту, т.е. наследоваться от лучше какого-нибудь AirVehicle с методом Fly(). BrokenCar вообще мем какой-то, здесь лучше добавить булевое значения isBroken и соответственно проверить условие в Drive() в базовом классе
Это все понятно, у меня задача была показать вещи на примитивных примерах, чтобы был понятен механизм. А то, что он не лучшее решение - это здесь вообще роли не играет.
Тем не менее AirVehicle должен быть унаследован от некоего Vehicle и иметь переопределенный метод Move(), а не Fly, иначе будет жесткая зависимость от того, летающее транспортное средство или нет. Булевое значение тоже не всегда подойдет, пример - несколько типов раздолбанных машин, одна без колес, но мотор работает и можно газовать, другая совсем сломана и мотор не работает, третья вроде едет, но с очень медленной скоростью, рывками, как-нибудь еще. Под разные задачи - разные решения
@@gamedevlavka да, под разные задачи - разные решения.
я же не писал, что Move() вовсе не будет, это же реализация интерфейса, я имел в виду странность содержания двух по сути взаимоисключающих методов Fly() и Drive(), разве только если у машины не 2 мода - воздушное и наземное перемещение, однако тут уже возникают другие вопросы..
насчёт примитивных примеров, тогда лучше было бы взять в качестве них что-то имеющее больше смысл. если это видео совсем для новичков, мало ли, как их воспримут
Лично я, пока не пойму смысл каждого действия, то дальше объяснять бесполезно.
Это сложно понять когда все абстрактно, но когда будешь делать свой проект тогда понимание придет)
как можно проверить, стоит ли деталька в механизме на своём месте?
(в игре типа надо собрать механизм)
У меня есть абстрактный класс BaseDetail
и разные детальки типа винты, шестерёнки, крышки
они наследуются от BaseDetail, у которого есть булевая переменная, показывающая состояние детальки(уже на месте или нет), но я хз как к ней обратиться, потому что деталей много и у всех разные скрипты и названия
вав, клёво, не академично но доступно и главное на примерах. а S.O.L.I.D. так же сможешь)?
Я не академик, а практик) SOLID, кстати, важная тема. Поставлю на очередь)
Посоветуйте кто-нибудь серию уроков тут на ютубе, где такую реализацию ООП делают на реальной игре что бы лучше понять суть
в теме с абстракцией после трех скритов в unity выбивает ошибку NullReferenceException, Что это значит?
Бро можешь провести обучалку с# unity
Не ..не... Никто не заметил неправильного наследования? BrokenCar? Точно? Это же состояние) Грубая ошибка! У тебя в base классе должен быть enum работающая машина, сломанная машина и т.д. "А, во все остальные ты наследуешь этот enum" через паблик или протект. Лучше через паблик!😀 Учишь наследовать от болды. Это мина, которая уничтожит архитектуру проекта.
Ну это как пример, ты описываешь что сломанной может быть и SpyCar и FlyingCar, а у него это отдельный вид машины, а не состояние
И лучше через протектед
Ввод и управление кем-то это не одно и тоже, почему тогда InputController вместо того что бы отвечать за информаицю о вводе управляет кем-то?
Я раскрыл тебя все ФСБ ТУТ
Копец у тебя структура. У меня PlayerMovement, PlayerRotation, PlayerShooting, LivingEntity и это всё я вешаю на Player. Unity изучаю 20 дней. Я так понял у меня плохая структура? И мне нужно всё переделать?
Если я правильно представил, то да. Но ты не расстраивайся, через подобное проходит каждый, и вот ты уже прошел, а значит стал опытнее. Путь улучшения кода, он бесконечный
У тебя структура разделяющая все ответственности игрока, вместо того что бы реализовывать Год класс и запихиватть в него все подряд, как показано в видео.
Классы ненаследуют интерфейсы, а реализуют их
-> Интерфейс - это такая штука
-> Исключение - это отдельная тема для изучения
-> И вот, мы работаем как бы с абстракцией
Кого? Куда? Зачем? Ни одного нормального объяснения. Весь урок сводится к "Ээ, ну тут вот так делаем, а тут вот так и всё работает". Классно. Урок подойдёт только тем, кто уже хорошо знаком с ООП. Тогда в чём его смысл?
Урок для тех, кто изучал программирование где-либо, знает теорию. Но не доконца понимает, как работает на практике. Поэтому сухая теория опущена и на пальцах рассказывается, как работает на практике
На словах "унаследуемся от интерфейса" становится понятно, что ролик смотреть нет смысла)
Если ты смотришь ролик, чтобы узнать как правильней всего говорить, то да, для тебя нет смысла. А тем, кто хочет научиться писать код, видео может помочь
Где вас таких рожают, которые говорят Чарактер?
Специально для тебя: КэРэКтЕр
@@ichbinschlange ай спс))
Тупейшее и неверное объяснение. В комментах либо боты либо люди с очень-очень поверхностными знаниями
тоже смутил brokencar ?)
@@Michael_Sh я не дошёл до туда)
Уже на инкапсуляции и на том, что input controller почему-то двигает персонажа всё стало ясно
@@андрейракчеев-ы2н Как тогда, где инфу найти?
@@alexwinston3635 я бы посоветовал почитать какую-нибудь книгу на эту тему, так как принципы ООП не меняются. К сожалению, не могу посоветовать книгу именно по изучению с нуля, т.к. я проходил это в универе, а не учил самостоятельно, но очень советую почитать "паттерны проектирования", когда появится небольшое понимание. Именно от авторов Фримен, Робсон, Сьерра, Бейтс. Читается легко и помимо паттернов там хорошо раскрывается тема и принципы ООП подхода. Но опять же, рекомендую читать уже после того, как появится понимание ООП
@@андрейракчеев-ы2н спс за совет!