Как сделать инвентарь в Unity. Часть 1: Модель, абстракция
HTML-код
- Опубликовано: 1 июн 2024
- Понравилось видео? Поддержи Лавку Разработчика!
www.donationalerts.com/r/game...
boosty.to/gamedevlavka
paypal.me/gamedevlavka
Стыдно признать, но я решил переделать серию видео про инвентарь. Снова. Прошу прощения за это! Теперь я проработал полный цикл, знаю, что в каждом рассказать, чтобы это стало органичным и хорошо легло в голову не только как фича, а как подход к разработке, о котором я рассказывал в предыдущем видео (Зачем разделять модель и визуал игры: • Зачем разделять модель... )
В этом видео мы начнем разработку инвентаря с разделением на модель и представление, как это сделать и почему это делается так - в новом видео из Лавки Разработчика!
Отсылки:
t.me/gamedevlavka - телеграм канал Лавки Разработчика
t.me/gamedevtavern - ламповый чат
/ discord - дискорд
__________
0:00 Предисловие (ною)
1:29 Описываем техническое задание на инвентарь
3:30 Определяем данные (что будем сохранять)
6:48 Пишем интерфейсы
12:12 Пишем реализации
23:48 Пишем вью (только для теста)
26:26 Пишем точку входа (для теста)
31:43 Пару слов о разделении модели и представления
![Darren Waller - Who Knew (Her Perspective) [Official Video]](http://i.ytimg.com/vi/GytDjB8u6bM/mqdefault.jpg)
Боюсь представить что было до этого, если вот это - просто. Но написание кода в реальном времени с комментариями очень помогает пониманию
32:42 Интерфейс это не защита от злоумышленника, это защита от случайной ошибки программиста. Можно не только интерфейс привести к конкретному классу, можно в интерфейс дописать сеттер и вуаля, ты можешь писать туда, куда писать было нельзя. Но если хочется, чтобы приведение не работало, можно написать обертку над моделью, реализующий ReadOnly интерфейс, в обертку передавать в конструктор саму модель, тогда приведение уже работать не будет, но будет один дополнительный класс к каждому классу, который в твоём коде реализует интерфейс.
Вообще это здорово, что ты решил изменить форму обучения, порой очень сложно смотреть длинные ролики с динамикой динамикой
наконец-то кто-то делает нормальный видос по инвентарю. как раз с завода пришел, щас чаечек заварю
будет круто, если покажешь как с инвентарем делается панель квик слотов и всякие хранилища
Крик слоты это можно будет устроить, после
От простого к сложному, однозначно лайк)
Like + Share не глядя. После рабочей смены обязательно наслажусь этим материалом♥
Референс отличный, буду очень ждать всей серии роликов по инвентарю!
взаимодействие вьюшки и модели с помощью прослойки это что-то вроде MVVM паттерна, хорошая реализация!
edit: но я думаю тут больше как MVP (model, view, presenter)
Люблю страшные и долгие ролики... Придётся привыкать к красивым и долгим)
Ждем новый цикл по инвентарю, чтобы в каждом слоте хранилась реальная item, и у нее есть "прочность", кол-во патронов внутри, а ещё рюкзак внутри рюкзака внутри рюкзака
О наконец новый видос, класс👍
Безмерно благодарен, конструктивное видео с полезной информацией сегодня редкость 👍
Очень ждем твой курс!😊
Отличное видео. Жду продолжения.
Спасибо, жду продолжение!
Насчет сложности согласен, в некоторых ролика уследить за мыслью, любителю, очень сложно
Очень жду вторую часть)❤
Спасибо большое за труд!
Красавчик, всё предельно понятно
Как всгда топовый контент по Unity
Ой ну огнина же! как же ты хорош.
Ждем Продолжение!!!!!!
Ждем продолжение
Лайк этому герою
ролик про борьбу с читерами без "страшного кода" +
Спасибо. Старался примерно так же делать, но в вашем видео подчерпнул пару идей. Пока не понятно как решать некоторые проблемы, надеюсь они будут обсуждаться далее. Например, если это не инвентарь, а поле с клетками и юнитами на них, юнит - сложный объект и очень часто нужно получить данные клетки, имея данные юнита или наоборот. ну и вопрос о том какой класс должен иметь доступ для изменений, ведь игрок кликать должен и взаимодействовать с моделью.
❤🔥
❤
Спасибо, отличный урок! Вы выбрали двумерный массив для инвентаря, таким образом мы сильно связано представление, не лучше ли сделать одномерным массивом или списком, где будет только порядковый индекс?
Вроде как инвентарь как раз таки и есть список, а метод GetSlots() всего лишь копирует этот список в двумерный массив и вызывается он во View, т.к. на выходе во View мы хотим получить сетку. Если я не ошибаюсь, то можно было бы возвращать из метода и список, а во View уже делать с ним что угодно, в том числе и отображать в виде сетки. Вот как вообще понять подобные тонкости? Где лучше преобразовывать список в двумерный массив? В данном методе GetSlots() или всё таки в методе класса View, просто для вывода в виде сетки?
@@KerryBlackSun зависит от того, связана ли с этими клетками какая то механика. Если это просто для отрисовки - можно и во вью
Подскажи плиз, что за ide используешь. VS чет не удобен мне 🥲
Я юзаю Rider, лучше пока не встречал
По сути, View не обязательно знать даже о ридонли инвентарных предметах, все что должен получать view, это даннве мостоящие из ади предмета его количества и процента прочности, при необходимости, все что нужно View, плюс он должен мочь ассоциировать айди предмета с UI спрайтом. Ну и там события, что бы прослойка которая представляет бизнес логику инвентаря в удобоваримом для View виде подписывалась на эти ивенты и уведомляла бизнес модель о вводе с ui, в таком случае, наше представление инвентаря в бизнес логике не зависит от того, как презентер интерпретирует его для UI, условно это даже может быть словарь с парой айдипредмета - его количество, или даже, если у нас предмет хранится в какой то базе данных, ключь айди и в значении пара, количество и ссылка на БД, откуда и будут подсасываться все данные о предмете.
Такой подход позволяет не заострять внимание в бизнес логике, в каком конкретно порчдке выложены в UI предметы, или как разделены стаки, и как пользователь с ними хочет взаимодействовать. В идее такую систему можно спокойно применять и с ивнвенатрём где предмет занимает несколько клеток.
Трудно найти такие видео как это, когда уже изучил уже язык, все инструменты и принципы архитектуры, но не получается нормально следовать этим принципам.
А если требуется прокачивать предмет? Ну например уровень у предмета есть, или предмет со вставками какими-то.
Прокачка предметов это другая система, инвентарь работает со списком идентификатор, ему без разницы что там за предметы и какой у них функционал
А почему int в айдишнике для извщ? Производительнее же должно быть. Или это чисто для понятности, т.к. обучающий проект?
Производительнее.
1. Если у тебя не мультиплеер с кучей интеракций с инвентарь, то плюсы от производительности сходят на нет, а отладка страдает, вывести в лог удобрчитаемые данные сложнее. На моем опыте ид в виде int встречается только в высоконагруженных местах мультиплеера.
2. Да, обучающий, и по причине неудобного логирования, в том числе выбрана строка.
А так, без разницы, когда будешь работать с инвентарь, поменяй все на int - будет работать оптимизированнее
Когда вторая часть?
Полагаю на следующей неделе будет
eeeeee😀
Видос топ, намного легче усваивается материал, отличное решение