Класс! Как раз изучаю написание инвентарей. Ждём продолжения, особенно интересно отпочковывание в сторону айтемов, занимающих несколько слотов. Есть на ютубе двухчасовой подробный тутор, но там нет разделения на дату и вью, айтемы хранятся непосредственно в геймобжектах
9:11 чтобы не было необходимости так переименовывать параметры в сгенерированом методе-обработчике события - нужно писать свои делегаты с именованными параметрами, тогда автоматически сгенерированный метод будет иметь параметры с названиями из своего кастомного делегата, а не так как сейчас string obj из Action.
Спасибо, такого хорошего материала очень мало. Возник вопрос вопрос: а почему добавление в инвентарь делается не через контроллер? Судя по схеме это событие генерирует View, которое логически связано только с контроллером и ничего не должно знать о сервисе
в конце было слегка эротишно...🥴 предположу, что многим будет интересна всякая вьюшная движуха типо - разделение элемента на 2 слота, передача (драгндроп мб) между инвентарями и тп
8:38 но ведь тогда будет утечка памяти, если контроллер будет уничтожен, а слот продолжит существовать (это следует держать в голове на всякий случай). Нужно отписываться от обрабочика события. Как я понимаю, Слот будет держать ссылку на Контроллер, так как ему нужно откуда-то брать ссылку на Контроллер, чтобы вызвать его метод (не важно где именно будет ссылка, через делегат или нет).
Хах, для новичков видео хорошее. Но когда ты уже проф. разработчик, то тебя будут просить делать инвентарь либо через Unity Cloud-сервисы (тот же Economy), либо что-то другое, тот же PlayFab с которым я сейчас мучаюсь. Кстати, вот тебе идея для следующих видео: хотелось бы какой-то подробный гайд по сервисам :)
Ну тут вопрос как с базой данных, твоя реализация инвентаря не должна зависеть от технологии, которую ты используешь. Unity-Cloud, PlayFab или что-то другое. Она должна быть автономна и работать с любой подключаемой системой. Ей должно быть без разницы, где ты хранишь данные где-то на сервере или локально. Что в дальнейшем упростит тебе тестирование или перенос на другой сервис. Поэтому реализация инвентаря остается плюс минус одинаковой, вопрос только в изоляции подключения и вытягивания данных.
@@user-sx7vo6kg8t все верно сказано. Дабы сделать инвентарь с состоянием на сервере, достаточно прикрутить сверху систему команд и все будет работать точно также
Мені сподобалось, все клас, на своєму проекті скоріш за все таки бахну. Є питання, ти казав що там події самі відписуються при знищенні, для чого тоді деструктор?
Верно сказано. Деструктор работает, когда Сборщик мусора (GC) уничтожает объект. Когда это произойдет - неизвестно. Поэтому для полного контроля принято использовать реализацию интерфейса IDisposable
привет) а как сделать так чтобы при очистке слота, когда в нем 0 остается, весь инвентарь сдвигался влево к началу(чтобы пустого окошка не оставалось где пустая ячейка осталась)?
Пушка, спасибо!❤
Очень классная реализация
Класс! Как раз изучаю написание инвентарей. Ждём продолжения, особенно интересно отпочковывание в сторону айтемов, занимающих несколько слотов. Есть на ютубе двухчасовой подробный тутор, но там нет разделения на дату и вью, айтемы хранятся непосредственно в геймобжектах
Изменение размера + 😄
Хотелось б увидеть систему екипировки, а так вроде все топ)
Спасибо! Очень хорошие уроки по инвентарю и главное - архитектуре!
Классные видео! Подробно и без воды. Спасибо
Ай спасибо! :3
9:11 чтобы не было необходимости так переименовывать параметры в сгенерированом методе-обработчике события - нужно писать свои делегаты с именованными параметрами, тогда автоматически сгенерированный метод будет иметь параметры с названиями из своего кастомного делегата, а не так как сейчас string obj из Action.
Я уже пишу inventory на клавиатуре быстрее чем hesoyam в юности
Спасибо, такого хорошего материала очень мало. Возник вопрос вопрос: а почему добавление в инвентарь делается не через контроллер? Судя по схеме это событие генерирует View, которое логически связано только с контроллером и ничего не должно знать о сервисе
в конце было слегка эротишно...🥴
предположу, что многим будет интересна всякая вьюшная движуха типо - разделение элемента на 2 слота, передача (драгндроп мб) между инвентарями и тп
8:38 но ведь тогда будет утечка памяти, если контроллер будет уничтожен, а слот продолжит существовать (это следует держать в голове на всякий случай). Нужно отписываться от обрабочика события. Как я понимаю, Слот будет держать ссылку на Контроллер, так как ему нужно откуда-то брать ссылку на Контроллер, чтобы вызвать его метод (не важно где именно будет ссылка, через делегат или нет).
Как всегда я не досмотрев написал. В видео автор говорит про эту проблему. В данном случае её нет.
Хах, для новичков видео хорошее. Но когда ты уже проф. разработчик, то тебя будут просить делать инвентарь либо через Unity Cloud-сервисы (тот же Economy), либо что-то другое, тот же PlayFab с которым я сейчас мучаюсь. Кстати, вот тебе идея для следующих видео: хотелось бы какой-то подробный гайд по сервисам :)
Так быстрее, но сложнее?
Ну тут вопрос как с базой данных, твоя реализация инвентаря не должна зависеть от технологии, которую ты используешь. Unity-Cloud, PlayFab или что-то другое. Она должна быть автономна и работать с любой подключаемой системой. Ей должно быть без разницы, где ты хранишь данные где-то на сервере или локально. Что в дальнейшем упростит тебе тестирование или перенос на другой сервис. Поэтому реализация инвентаря остается плюс минус одинаковой, вопрос только в изоляции подключения и вытягивания данных.
@@user-sx7vo6kg8t все верно сказано. Дабы сделать инвентарь с состоянием на сервере, достаточно прикрутить сверху систему команд и все будет работать точно также
Мені сподобалось, все клас, на своєму проекті скоріш за все таки бахну.
Є питання, ти казав що там події самі відписуються при знищенні, для чого тоді деструктор?
Имхо деструктор не нужен. Его вызов сложно проконтролировать.
По этому обычно используется IDisposoble и реализация метода Dispose.
Верно сказано. Деструктор работает, когда Сборщик мусора (GC) уничтожает объект. Когда это произойдет - неизвестно. Поэтому для полного контроля принято использовать реализацию интерфейса IDisposable
привет) а как сделать так чтобы при очистке слота, когда в нем 0 остается, весь инвентарь сдвигался влево к началу(чтобы пустого окошка не оставалось где пустая ячейка осталась)?
Ребят кто понял как добавить инвентарь на сцену что бы можно было его открывать \ закрывать по нажатию кнопки ?