Насчёт интерфейса: за ним не получится или точнее это будет плохим вариантом, пытаться за ним прятать контроллер управления птицей или машиной. Так как это будет нарушением принципа подстановки Барбары Лисков. То есть, класс, использующий базовый класс, не должен знать о наследниках. Если расшифровать, то суть в том, что производные классы, должны полностью соответствовать контракту без всяких там заглушек. То есть управляя контроллером, подразумевающим прыжок, при его вызове должен произойти прыжок. Тут скорее нужно будет выделять интерфейс взаимодействия не с игровым персонажем, а с транспортом.
Согласен, лучший вариант - раздробить контролируемые объекты на IMovable, IJumpable и т.д. и в инпуте передавать команды в соответствующие интерфейсы, если они существуют. Спасибо за поправку.
Благодарю за труды. Люблю смотреть ваши видео. Хотелось бы добавить, что для новичков вся эта S.O.L.I.D тема довольно сложная. По этому было бы неплохо добавлять чуть больше примеров. К примеру, если бы в этом видео вы продемонстрировали ту самую подстановку управления, я более чем уверен что большинство новичков прозрело) Хотя возможно оно и не надо) Мой небольшой опыт менторинга показал, что на синтетических или маленьких примерах новичок быстро забывает суть. Объясняешь ученику как работают делегаты и события, и для чего они нужны/какую проблему решают. Ученик все понял. Но из за недостаточного кол-ва примеров, и опыта использования все же через неделю забывает как этим пользоваться ХD То же отснял 3 месяца назад урок о том как с помощью интерфейсов по типу IOpenable IInteractable открывать ящики, двери, сундуки, чемоданы, окна, витрины и все что может открыться. Но к сожалению у военкомата были на меня свои проблемы поэтому свой блог пришлось на время заморозить. 😁 Но да это все не важно. Продолжайте в том же духе🔥 Годный контент, всем советую. ❤️
Полностью солидарен насчёт SOLID, стоит уплмянать такие вещи прямо в видео) А насчёт подмены - это будет в видео про новую инпут систему, там и покажу, как легко подменяется) Спасибо за столь развёрнутый комментарий)
это потрясающе братан, жду новых уроков) недавно наткнулся на твой канал и просто кайфую с твоего качественного кода и объяснений. а качество контента такое, словно ты миллионник) впрочем, продолжая в таком духе, все так и будет
По поводу птицы и прыжка- оставлять метод пустым при имплементации интерфейса или переопределения абстрактного метода класса - нарушение принципа солид Барбары Л. Данная проблема решается путем применения паттерна стратегия.
Окей, ждём видео про Input system. Единственное, что я не предполагал, что скрипт с InputController, может лежать на Игроке, всегда думал, что это некий менеджер, к которому скрипт игрока получает доступ.
Удобнее командовать контроллируемым объектом, чем из объекта подписываться на инпут. Так, ты легко можешь воткнуть ИИ, который управляет объектом, или наоборот, дать управление игроку
Спасибо за видео маленько разобрался, но всё же некоторые моменты остались не понятными. Если в игре надо реализовать разных персонажей которые также ходят и прыгают, но с небольшими какими-то нововведениями это надо для каждого объекта создавать новый скрипт с реализацией тех же интерфейсов? Если делать так то мы копируем постоянно код один и тот же. Можно этого как-то избежать или это неотъемлемая часть реализации таким способом, или я что-то не правильно понял?
Смотря какие дополнения. Если это разные способности, то ничего копировать не нудно, способности также делаются абстрактно и добавляются персонажу независимо от его управления. Если же речь не про способности, то я нужно больше информации. В любом случае копирование кола это фу, и есть куча способов избежать дублирования
а что если пешек на сцене несколько? (пешки по аналогии с pawn из анриала, я привык) то надо реализовывать менеджер IsUnderControl? который будет держать все пешки в виду и писать логику передачи управления с условием (только один за раз) ? right?) я просто в интерфейсках полный ноль и почему то мне эта тема очень сложно даётся.
Все дуже круто, але можна будь ласка, щоб ти показав створення гри від початку до кінця (RPG по можливості), де ти вирішуєш проблеми "на ходу"(зразу) . P.s. Дякую що прочитав
Спасибо! RPG - это гигантский жанр, над которым в одиночку не работают, а если и работают, то это растягивается на годы разработки) так что, именно RPG жанр не подходит для такого формата видео, но я подумаю, что модно сделать)
Приветствую! У меня по какой-то причине в "throw new Exception", сам " Exception" не находит тип или имя в пространстве имён... Делал всё по твоему коду. В чём может быть проблема?
Привет спасибо за видео, но тема кажется пока не раскрытой, думаю кто-то не заметит особых изменений, ибо убрав интерфейсы все будет работать так же, возможно дальше будет больше примеров и раскрытия преимуществ. Понятно что видео не об этом, но зачем использовать GameManager/Controller под названием Character, почему не сделать CharacterMovement(у которого тоже можно cделать интерфейс IMovable) отдельный класс и другую логику которая возможно и дальше будет запихиваться в этот класс тоже отделить. Тот же Input вынесен в отдельный класс. И еще такой момент почему Input должен управлять передвижением и всеми другими логиками связанными с инпутом, а не другие классы, кому нужна информация о вводе, должны иметь ссылку на Input и отслеживать был ли произведен нужный им ввод?
Все постепенно, мой друг) Если я буду выдавать слишком много информации в одном видео, то оно разрастется, а усваиваемость уменьшится. В следующем видео, я расскажу про New Input System, и мы прекрасно применим полученные знания к тому, о чем говорится в этом видео. По поводу последнего вопроса про Input. Никто не должен знать про инпут, это лишняя обязанность, это во-первых. А во вторых, управляя чем-то извне, можно легко заменить инпут например на ИИ.
Спасибо за видео. Будем ждать следующие! И стримы. По резиденту. Там дополнение вышло как раз.
Насчёт интерфейса: за ним не получится или точнее это будет плохим вариантом, пытаться за ним прятать контроллер управления птицей или машиной. Так как это будет нарушением принципа подстановки Барбары Лисков. То есть, класс, использующий базовый класс, не должен знать о наследниках. Если расшифровать, то суть в том, что производные классы, должны полностью соответствовать контракту без всяких там заглушек. То есть управляя контроллером, подразумевающим прыжок, при его вызове должен произойти прыжок. Тут скорее нужно будет выделять интерфейс взаимодействия не с игровым персонажем, а с транспортом.
Согласен, лучший вариант - раздробить контролируемые объекты на IMovable, IJumpable и т.д. и в инпуте передавать команды в соответствующие интерфейсы, если они существуют. Спасибо за поправку.
Спасибо за урок :)
Благодарю за труды. Люблю смотреть ваши видео.
Хотелось бы добавить, что для новичков вся эта S.O.L.I.D тема довольно сложная. По этому было бы неплохо добавлять чуть больше примеров. К примеру, если бы в этом видео вы продемонстрировали ту самую подстановку управления, я более чем уверен что большинство новичков прозрело) Хотя возможно оно и не надо)
Мой небольшой опыт менторинга показал, что на синтетических или маленьких примерах новичок быстро забывает суть. Объясняешь ученику как работают делегаты и события, и для чего они нужны/какую проблему решают. Ученик все понял. Но из за недостаточного кол-ва примеров, и опыта использования все же через неделю забывает как этим пользоваться ХD
То же отснял 3 месяца назад урок о том как с помощью интерфейсов по типу IOpenable IInteractable открывать ящики, двери, сундуки, чемоданы, окна, витрины и все что может открыться. Но к сожалению у военкомата были на меня свои проблемы поэтому свой блог пришлось на время заморозить.
😁 Но да это все не важно. Продолжайте в том же духе🔥 Годный контент, всем советую. ❤️
Полностью солидарен насчёт SOLID, стоит уплмянать такие вещи прямо в видео)
А насчёт подмены - это будет в видео про новую инпут систему, там и покажу, как легко подменяется)
Спасибо за столь развёрнутый комментарий)
это потрясающе братан, жду новых уроков) недавно наткнулся на твой канал и просто кайфую с твоего качественного кода и объяснений. а качество контента такое, словно ты миллионник) впрочем, продолжая в таком духе, все так и будет
Замечательный пример применения интерфейсов! 👍
Побольше примеров с интерфейсами если не сложно
Да было бы не плохо если бы он показал реализацию разного поведения персов, типа полет, езда, ходьба
Очень круто! Спасибо.
По поводу птицы и прыжка- оставлять метод пустым при имплементации интерфейса или переопределения абстрактного метода класса - нарушение принципа солид Барбары Л. Данная проблема решается путем применения паттерна стратегия.
Отличный урок, спасибо! Но когда декоратор?)
Скоро)
@@gamedevlavka стратегия?)
Ну да, паттерн стратегия
Его кстати часто спрашивают на собеседованиях не понятно почему
Отличный урок))
Спасибо!
Все ясно, Вилла у моря у него)
Это длинная история о том, что мне надоело имя Vasya))
@@gamedevlavka Можно было взять Vasilevs
Окей, ждём видео про Input system. Единственное, что я не предполагал, что скрипт с InputController, может лежать на Игроке, всегда думал, что это некий менеджер, к которому скрипт игрока получает доступ.
Удобнее командовать контроллируемым объектом, чем из объекта подписываться на инпут. Так, ты легко можешь воткнуть ИИ, который управляет объектом, или наоборот, дать управление игроку
Спасибо за видео маленько разобрался, но всё же некоторые моменты остались не понятными. Если в игре надо реализовать разных персонажей которые также ходят и прыгают, но с небольшими какими-то нововведениями это надо для каждого объекта создавать новый скрипт с реализацией тех же интерфейсов? Если делать так то мы копируем постоянно код один и тот же. Можно этого как-то избежать или это неотъемлемая часть реализации таким способом, или я что-то не правильно понял?
Смотря какие дополнения. Если это разные способности, то ничего копировать не нудно, способности также делаются абстрактно и добавляются персонажу независимо от его управления. Если же речь не про способности, то я нужно больше информации.
В любом случае копирование кола это фу, и есть куча способов избежать дублирования
а если этот CharacterInputController вынести на empty object в сцену? он же будет брать и передавать input значения пешке? верно?
а что если пешек на сцене несколько? (пешки по аналогии с pawn из анриала, я привык) то надо реализовывать менеджер IsUnderControl? который будет держать все пешки в виду и писать логику передачи управления с условием (только один за раз) ? right?) я просто в интерфейсках полный ноль и почему то мне эта тема очень сложно даётся.
Все дуже круто, але можна будь ласка, щоб ти показав створення гри від початку до кінця (RPG по можливості), де ти вирішуєш проблеми "на ходу"(зразу) .
P.s. Дякую що прочитав
Спасибо!
RPG - это гигантский жанр, над которым в одиночку не работают, а если и работают, то это растягивается на годы разработки) так что, именно RPG жанр не подходит для такого формата видео, но я подумаю, что модно сделать)
@@gamedevlavka Будемо чекати)
Добрый день. А кто ловит исключение в Awake?
Всё круто, но одно не понятно, а для чего вообще компонент CharacterController, что он делает, за что отвечают его параметры? ))
Как говорил кто то из великих, думайте об интерфейсах, а не о реализации.
А как к этой системе добавить возможность управления через UI кнопки?
Приветствую! У меня по какой-то причине в "throw new Exception", сам " Exception" не находит тип или имя в пространстве имён... Делал всё по твоему коду. В чём может быть проблема?
using System;...
Привет, можешь пожалуйста затронуть тему архитектуры UI? очень интересно было бы послушать.
Обязательно! Уже пришёл к инетесному решению, которое и удобно и функционально. Нужно протестировать хорошо и потом расскажу
Я правильно понял, что если в проекте управлятся будет только персонаж то смысла от такой реализации нет?
А можешь рассказать, как правильно сделать андроид управление?
Привет спасибо за видео, но тема кажется пока не раскрытой, думаю кто-то не заметит особых изменений, ибо убрав интерфейсы все будет работать так же, возможно дальше будет больше примеров и раскрытия преимуществ. Понятно что видео не об этом, но зачем использовать GameManager/Controller под названием Character, почему не сделать CharacterMovement(у которого тоже можно cделать интерфейс IMovable) отдельный класс и другую логику которая возможно и дальше будет запихиваться в этот класс тоже отделить. Тот же Input вынесен в отдельный класс. И еще такой момент почему Input должен управлять передвижением и всеми другими логиками связанными с инпутом, а не другие классы, кому нужна информация о вводе, должны иметь ссылку на Input и отслеживать был ли произведен нужный им ввод?
Все постепенно, мой друг) Если я буду выдавать слишком много информации в одном видео, то оно разрастется, а усваиваемость уменьшится. В следующем видео, я расскажу про New Input System, и мы прекрасно применим полученные знания к тому, о чем говорится в этом видео.
По поводу последнего вопроса про Input. Никто не должен знать про инпут, это лишняя обязанность, это во-первых. А во вторых, управляя чем-то извне, можно легко заменить инпут например на ИИ.
Привет, давай про addresables)
Я в них не до конца разобрался, так что это позднее)