наконец-то кто-то делает нормальный видос по инвентарю. как раз с завода пришел, щас чаечек заварю будет круто, если покажешь как с инвентарем делается панель квик слотов и всякие хранилища
Ждем новый цикл по инвентарю, чтобы в каждом слоте хранилась реальная item, и у нее есть "прочность", кол-во патронов внутри, а ещё рюкзак внутри рюкзака внутри рюкзака
32:42 Интерфейс это не защита от злоумышленника, это защита от случайной ошибки программиста. Можно не только интерфейс привести к конкретному классу, можно в интерфейс дописать сеттер и вуаля, ты можешь писать туда, куда писать было нельзя. Но если хочется, чтобы приведение не работало, можно написать обертку над моделью, реализующий ReadOnly интерфейс, в обертку передавать в конструктор саму модель, тогда приведение уже работать не будет, но будет один дополнительный класс к каждому классу, который в твоём коде реализует интерфейс.
взаимодействие вьюшки и модели с помощью прослойки это что-то вроде MVVM паттерна, хорошая реализация! edit: но я думаю тут больше как MVP (model, view, presenter)
Спасибо. Старался примерно так же делать, но в вашем видео подчерпнул пару идей. Пока не понятно как решать некоторые проблемы, надеюсь они будут обсуждаться далее. Например, если это не инвентарь, а поле с клетками и юнитами на них, юнит - сложный объект и очень часто нужно получить данные клетки, имея данные юнита или наоборот. ну и вопрос о том какой класс должен иметь доступ для изменений, ведь игрок кликать должен и взаимодействовать с моделью.
Спасибо, отличный урок! Вы выбрали двумерный массив для инвентаря, таким образом мы сильно связано представление, не лучше ли сделать одномерным массивом или списком, где будет только порядковый индекс?
Вроде как инвентарь как раз таки и есть список, а метод GetSlots() всего лишь копирует этот список в двумерный массив и вызывается он во View, т.к. на выходе во View мы хотим получить сетку. Если я не ошибаюсь, то можно было бы возвращать из метода и список, а во View уже делать с ним что угодно, в том числе и отображать в виде сетки. Вот как вообще понять подобные тонкости? Где лучше преобразовывать список в двумерный массив? В данном методе GetSlots() или всё таки в методе класса View, просто для вывода в виде сетки?
Трудно найти такие видео как это, когда уже изучил уже язык, все инструменты и принципы архитектуры, но не получается нормально следовать этим принципам.
По сути, View не обязательно знать даже о ридонли инвентарных предметах, все что должен получать view, это даннве мостоящие из ади предмета его количества и процента прочности, при необходимости, все что нужно View, плюс он должен мочь ассоциировать айди предмета с UI спрайтом. Ну и там события, что бы прослойка которая представляет бизнес логику инвентаря в удобоваримом для View виде подписывалась на эти ивенты и уведомляла бизнес модель о вводе с ui, в таком случае, наше представление инвентаря в бизнес логике не зависит от того, как презентер интерпретирует его для UI, условно это даже может быть словарь с парой айдипредмета - его количество, или даже, если у нас предмет хранится в какой то базе данных, ключь айди и в значении пара, количество и ссылка на БД, откуда и будут подсасываться все данные о предмете.
Такой подход позволяет не заострять внимание в бизнес логике, в каком конкретно порчдке выложены в UI предметы, или как разделены стаки, и как пользователь с ними хочет взаимодействовать. В идее такую систему можно спокойно применять и с ивнвенатрём где предмет занимает несколько клеток.
Производительнее. 1. Если у тебя не мультиплеер с кучей интеракций с инвентарь, то плюсы от производительности сходят на нет, а отладка страдает, вывести в лог удобрчитаемые данные сложнее. На моем опыте ид в виде int встречается только в высоконагруженных местах мультиплеера. 2. Да, обучающий, и по причине неудобного логирования, в том числе выбрана строка. А так, без разницы, когда будешь работать с инвентарь, поменяй все на int - будет работать оптимизированнее
Любой пограммист ожидает увидеть "id" в виде целочисленного типа и это общепринято. Другие типы идентификации постоянно используются и string в особенности, но их называют "key", а не "id". Дело не в производительности, просто string крайне гибкий, в него можно трансформировать всё с помощью ToString, например тот-же enum и этим может одновременно пользоваться и программист не прибегающий к строковым литералам и дизайнер, свободно действующий, как ему вздумается. Почему изврат? потому, что автор неграмотный.
Вообще это здорово, что ты решил изменить форму обучения, порой очень сложно смотреть длинные ролики с динамикой динамикой
Боюсь представить что было до этого, если вот это - просто. Но написание кода в реальном времени с комментариями очень помогает пониманию
наконец-то кто-то делает нормальный видос по инвентарю. как раз с завода пришел, щас чаечек заварю
будет круто, если покажешь как с инвентарем делается панель квик слотов и всякие хранилища
Крик слоты это можно будет устроить, после
От простого к сложному, однозначно лайк)
Референс отличный, буду очень ждать всей серии роликов по инвентарю!
Like + Share не глядя. После рабочей смены обязательно наслажусь этим материалом♥
Безмерно благодарен, конструктивное видео с полезной информацией сегодня редкость 👍
Люблю страшные и долгие ролики... Придётся привыкать к красивым и долгим)
О наконец новый видос, класс👍
Как всгда топовый контент по Unity
Отличное видео. Жду продолжения.
Ой ну огнина же! как же ты хорош.
Очень ждем твой курс!😊
Красавчик, всё предельно понятно
Спасибо, жду продолжение!
Спасибо большое за труд!
Ждем новый цикл по инвентарю, чтобы в каждом слоте хранилась реальная item, и у нее есть "прочность", кол-во патронов внутри, а ещё рюкзак внутри рюкзака внутри рюкзака
Лайк этому герою
Ждем продолжение
Ждем Продолжение!!!!!!
Очень жду вторую часть)❤
Насчет сложности согласен, в некоторых ролика уследить за мыслью, любителю, очень сложно
32:42 Интерфейс это не защита от злоумышленника, это защита от случайной ошибки программиста. Можно не только интерфейс привести к конкретному классу, можно в интерфейс дописать сеттер и вуаля, ты можешь писать туда, куда писать было нельзя. Но если хочется, чтобы приведение не работало, можно написать обертку над моделью, реализующий ReadOnly интерфейс, в обертку передавать в конструктор саму модель, тогда приведение уже работать не будет, но будет один дополнительный класс к каждому классу, который в твоём коде реализует интерфейс.
взаимодействие вьюшки и модели с помощью прослойки это что-то вроде MVVM паттерна, хорошая реализация!
edit: но я думаю тут больше как MVP (model, view, presenter)
ролик про борьбу с читерами без "страшного кода" +
❤🔥
❤
Спасибо. Старался примерно так же делать, но в вашем видео подчерпнул пару идей. Пока не понятно как решать некоторые проблемы, надеюсь они будут обсуждаться далее. Например, если это не инвентарь, а поле с клетками и юнитами на них, юнит - сложный объект и очень часто нужно получить данные клетки, имея данные юнита или наоборот. ну и вопрос о том какой класс должен иметь доступ для изменений, ведь игрок кликать должен и взаимодействовать с моделью.
Спасибо, отличный урок! Вы выбрали двумерный массив для инвентаря, таким образом мы сильно связано представление, не лучше ли сделать одномерным массивом или списком, где будет только порядковый индекс?
Вроде как инвентарь как раз таки и есть список, а метод GetSlots() всего лишь копирует этот список в двумерный массив и вызывается он во View, т.к. на выходе во View мы хотим получить сетку. Если я не ошибаюсь, то можно было бы возвращать из метода и список, а во View уже делать с ним что угодно, в том числе и отображать в виде сетки. Вот как вообще понять подобные тонкости? Где лучше преобразовывать список в двумерный массив? В данном методе GetSlots() или всё таки в методе класса View, просто для вывода в виде сетки?
@@KerryBlackSun зависит от того, связана ли с этими клетками какая то механика. Если это просто для отрисовки - можно и во вью
Трудно найти такие видео как это, когда уже изучил уже язык, все инструменты и принципы архитектуры, но не получается нормально следовать этим принципам.
Подскажи плиз, что за ide используешь. VS чет не удобен мне 🥲
Я юзаю Rider, лучше пока не встречал
А если требуется прокачивать предмет? Ну например уровень у предмета есть, или предмет со вставками какими-то.
Прокачка предметов это другая система, инвентарь работает со списком идентификатор, ему без разницы что там за предметы и какой у них функционал
Видос топ, намного легче усваивается материал, отличное решение
По сути, View не обязательно знать даже о ридонли инвентарных предметах, все что должен получать view, это даннве мостоящие из ади предмета его количества и процента прочности, при необходимости, все что нужно View, плюс он должен мочь ассоциировать айди предмета с UI спрайтом. Ну и там события, что бы прослойка которая представляет бизнес логику инвентаря в удобоваримом для View виде подписывалась на эти ивенты и уведомляла бизнес модель о вводе с ui, в таком случае, наше представление инвентаря в бизнес логике не зависит от того, как презентер интерпретирует его для UI, условно это даже может быть словарь с парой айдипредмета - его количество, или даже, если у нас предмет хранится в какой то базе данных, ключь айди и в значении пара, количество и ссылка на БД, откуда и будут подсасываться все данные о предмете.
Такой подход позволяет не заострять внимание в бизнес логике, в каком конкретно порчдке выложены в UI предметы, или как разделены стаки, и как пользователь с ними хочет взаимодействовать. В идее такую систему можно спокойно применять и с ивнвенатрём где предмет занимает несколько клеток.
А почему int в айдишнике для извщ? Производительнее же должно быть. Или это чисто для понятности, т.к. обучающий проект?
Производительнее.
1. Если у тебя не мультиплеер с кучей интеракций с инвентарь, то плюсы от производительности сходят на нет, а отладка страдает, вывести в лог удобрчитаемые данные сложнее. На моем опыте ид в виде int встречается только в высоконагруженных местах мультиплеера.
2. Да, обучающий, и по причине неудобного логирования, в том числе выбрана строка.
А так, без разницы, когда будешь работать с инвентарь, поменяй все на int - будет работать оптимизированнее
Любой пограммист ожидает увидеть "id" в виде целочисленного типа и это общепринято. Другие типы идентификации постоянно используются и string в особенности, но их называют "key", а не "id". Дело не в производительности, просто string крайне гибкий, в него можно трансформировать всё с помощью ToString, например тот-же enum и этим может одновременно пользоваться и программист не прибегающий к строковым литералам и дизайнер, свободно действующий, как ему вздумается. Почему изврат? потому, что автор неграмотный.
Это точно для джунов?😢
Нет, не для, а от джуна, который не понимает что и зачем он делает)😅
@@EvilYarik где можно посмотреть обучающие ролики от вас,сенсей,блин?
Когда вторая часть?
Полагаю на следующей неделе будет
eeeeee😀
ппц каша
... в голове автора