Отдельно интересующий вопрос касающийся мета даты у предметов инвентаря. Конкретно интересно, как сохранять данные модулей на оружие, если это пушка и подобное. Пример из майнкрафта - зачарования. Тоже хотелось бы увидеть на канале.
Метод RemoveItems я бы переименовал в RemoveItem, потому что неявный аргумент amount = 1, может запутать читающего, он подумает что удаляются все предметы с этим названием. а явное указание amount поможет домыслить смысл метода. Пишу не ради критики, а ради комментария хорошему видео.
Есть различные конвенции для нейминга всякого, обычно пользуются классикой от майкрософт: learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names
Все так, видимо, сработала привычка "на всякий случай", или для лучшего понимания. Я вообще часто создаю дополнительные переменные с норм неймингом, чтобы повысить читаемость. В данном случае ты прав, совсем не обязательно выносить в переменную значение remainingAmount
@@user-yw2ub8mb5b это не часть механики инвентаря, это часть механики экипировка. То есть в окошке, что ты видишь, когда перекладываешь из инвентаря в экипировку - ты взаимодействуешь с двумя механиками. И слот экипировки в свою очередь может проверять тип предмета, как ему это нравится
классная реализация, особенно понравился момент с возвращением результата в виде структуры) но есть вопрос на счет owner id. зачем его хранить внутри самой сущности инвентаря? ему ведь глобально пофиг чей инвентарь, у нас все равно принадлежность определяется и будет обрабатываться извне. айдишник, считай, в твоей архитектуре нужен чисто для возвращения результата добавления/удаления. и то он по моему там не нужен, как и amount, о котором ты говорил
и еще не совсем понимаю смысла от хранения всех инвентарей в одном сервисе. нам ведь понадобится прослойка, связывающая модель и ui и как ты тогда ее планируешь припихнуть?
Насчёт ownerId, тут вопрос того, как будет храниться данные. Если в виде профиля, то внутри данных Owner не нужен, если инвентари отдельным списком - то внутри ownerId нужен. Полный профиль не всегда удобно хранить и не всегда это полезно для оптимизации
Хочу отдельное видео про конфиги, чтобы все было по красоте
И такое будет
Видос по изменеиню сайзинга +, если можно. Слишком много полезной инфы. Хотелось бы по максимуму проработать
Спасибо огромное как раз ищу небольной инвентарь для пет проекта
Отдельно интересующий вопрос касающийся мета даты у предметов инвентаря.
Конкретно интересно, как сохранять данные модулей на оружие, если это пушка и подобное.
Пример из майнкрафта - зачарования.
Тоже хотелось бы увидеть на канале.
Ох, когда я сам писал эту модель с нуля я думал, что упоролся)
класне відео мені сподобалось, чекаю продовження з UI, о і таке питання, чи буде відео про те як ти це все грузиш через SO чи тому подібне
Будет видео о сохранении, могу приделать видео о конфигах. Не уверен, что конфиги прям к теме инвентаря приделаны будут, но сниму, да
💥💥💥
Метод RemoveItems я бы переименовал в RemoveItem, потому что неявный аргумент amount = 1, может запутать читающего, он подумает что удаляются все предметы с этим названием. а явное указание amount поможет домыслить смысл метода.
Пишу не ради критики, а ради комментария хорошему видео.
Почему переменные в начале класса с большой буквы, а в конструкторе с маленькой? Я все не могу понять синтаксис C#
Есть различные конвенции для нейминга всякого, обычно пользуются классикой от майкрософт:
learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names
0.0 🎉🎉🎉
коли пишеш ctor то в Rider повинна бути штука ctorf і ctorp що роблять конструктор для полів і для властивостей відповідно
звучит круто, надо затестить
Добавте пожплуйста в модель сохранение\чтение (где, когда, в каком формате?)
Да, это тоже сделаем)
Почему в 19:03 важно работать с копией? Что если написать такой код?
slot.ItemId = itemId;
int maxCapacity = GetItemMaxCapacity(itemId);
if (remainingAmount > maxCapacity)
{
slot.Amount = maxCapacity;
remainingAmount -= maxCapacity;
totalAmountAdded += maxCapacity;
}
else
{
slot.Amount = remainingAmount ;
totalAmountAdded += remainingAmount ;
remainingAmount = 0;
return totalAmountAdded;
}
Все так, видимо, сработала привычка "на всякий случай", или для лучшего понимания. Я вообще часто создаю дополнительные переменные с норм неймингом, чтобы повысить читаемость. В данном случае ты прав, совсем не обязательно выносить в переменную значение remainingAmount
@@gamedevlavka Спасибо за ответ, обязательно продолжу остальные части смотреть)
А как сделать слоты только для определенной группы предметов? Например, слоты только для шлемов, или только для оружия
Звучит как слоты для экипировки. Про это речь?
@@gamedevlavka да
@@user-yw2ub8mb5b это не часть механики инвентаря, это часть механики экипировка. То есть в окошке, что ты видишь, когда перекладываешь из инвентаря в экипировку - ты взаимодействуешь с двумя механиками. И слот экипировки в свою очередь может проверять тип предмета, как ему это нравится
@@gamedevlavka понял, спасибо
классная реализация, особенно понравился момент с возвращением результата в виде структуры)
но есть вопрос на счет owner id. зачем его хранить внутри самой сущности инвентаря? ему ведь глобально пофиг чей инвентарь, у нас все равно принадлежность определяется и будет обрабатываться извне. айдишник, считай, в твоей архитектуре нужен чисто для возвращения результата добавления/удаления. и то он по моему там не нужен, как и amount, о котором ты говорил
и еще не совсем понимаю смысла от хранения всех инвентарей в одном сервисе. нам ведь понадобится прослойка, связывающая модель и ui и как ты тогда ее планируешь припихнуть?
Насчёт ownerId, тут вопрос того, как будет храниться данные. Если в виде профиля, то внутри данных Owner не нужен, если инвентари отдельным списком - то внутри ownerId нужен. Полный профиль не всегда удобно хранить и не всегда это полезно для оптимизации
А прослойку в след видео будет