ВНИМАНИЕ: Уже после выкладки обнаружил, что генерик интерфейс там нафиг не нужен, нужен просто интерфейс без генерика и без Amount, а то подумал одно, начал говорить правильно, и сделал непонятно что. Для хранения удобного всех ресурсов, нужен просто IResource.
Как в таком случае изменять количество ресурсов для разных типов? Допустим, нужно изменить в Idle игре количество количество Hard валюты, которой может быть не более, чем 100 000 000 (подходит int), а обычной валюты может быть до 10^100 (double ?)
@@ChimpanzeeUltra нужно два списка. Это то, о чем я говорил, генерик сложно обрабатывать, иы его все равно не сможешь в один список запихнуть если не кастовать потом. А каст - дорого, поэтому проще на каждый тип данный свой список ресурсов сделать и размножить методы под каждый тип данных. Это будет быстрее для процессора и лучше для памяти
Самое крутое что я узнал с видео, BigInteger.. Ни где не мог найти инфу как сделать такое бесконечное число, а тут оказывается все готово... А видосы у тебя крутые
Это довольно хороший подход, но есть ещё 1. Минусы данного подхода, когда нужно добавить набор ресурсов, например за награду, придётся писать свич кейс по типу ресурса, и если в награде есть первый тип, вызвать addResource(soft, amount) и т. д. для остальных, если бы у тебя всё ресурсы были имплементация от baseResource а в resource Storage ты бы их хранил так: dictionary то мог бы передавать list.
Не нужно делать свич, если где-то будет храниться "применитель" наград, который имеет обработчики для каждого типа ресурсов и они находятся в словаре. Для многих проектов это оверинжиниринг, поэтому не стал расписывать. Минус подхода с типами - даункаст, довольно тяжёлая операция, при часто использовании не очень хороший приём. Но если игра вроде героев, где ресурсов куча, но меняются они не часто - подход со словарём по типу - отличное решение без оверинжиниринга и достаточно гибкое
Не очевидная связь: ResourcesFeature должен хранить данные для всех ResourceType (иначе исключения при вытаскивании по отсутствующим типам), а в конструктор обязательно передавать массив только с уникальным RecourceType (иначе не создаться dictionary), что не проверяется компилятором. Это ошибка, или предполагается, что тот, кто заполняет ResourcesFeature знает об этой особенности?
Так задумано. Некоторые ошибки должны быть явными, чтобы их вовремя можно было исправить. Это достаточно эффективный подход в некоторых местах. Но не всегда он нужен, иногда нужно смягчить вылетание ошибки. При работе с ресурсами я ничего бы не смягчал
Отличный канай, отличный видос, спасибо тебе) Можно про работу с SQL что-то снимать? Там много вариантов есть, хотелось бы узнать что лучше, как лучше.
К сожалению, с частью про отписку от события не соглашусь. Очень часто встречаюсь с тем, что если без прямой отписки завершить приложение, то при повторном запуске игра иногда работает не корректно. Так же, реже, но бывает такое что при IL2CPP билдах игра не может корректно завершиться.
блин - очень прошу тебя = не снимай обучающий материал в 60fps - давайте заботиться об окружающей природе и понапрасну не тратить электроэнергию - ведь сервер выдающий видео обрабатывает в два раза больше данных - а умножив это на кол-во просмотров = объем лишней затраты на электроэнергию как на стороне серверов ютуб так и на стороне каждого клиента огромный. и большинство смотрит видео на скорости 2х - поэтому профитно писать обучающий материал в 30fps(для плавной картинки) - и даже разумно использовать 24fps. а еще = некоторые (как я) юзают старый macbook - и на скорости 2х 1080p@60fps = нотик просто взвывает от нагрузки=( оч прошу давайте будем разумными и не будем снимать 60fps там где нет в этом необходимости
Слушай, никогда не задумывался об этом, хотя сам стараюсь следить за своими действиями по отношению к экологии (сортирую мусор, нет пакетам, металлические бутылки и все такое). Полностью согласен, спасибо за совет, 60фпс в принципе ни к чему для таких видео
ВНИМАНИЕ:
Уже после выкладки обнаружил, что генерик интерфейс там нафиг не нужен, нужен просто интерфейс без генерика и без Amount, а то подумал одно, начал говорить правильно, и сделал непонятно что. Для хранения удобного всех ресурсов, нужен просто IResource.
Как в таком случае изменять количество ресурсов для разных типов?
Допустим, нужно изменить в Idle игре количество количество Hard валюты, которой может быть не более, чем 100 000 000 (подходит int), а обычной валюты может быть до 10^100 (double ?)
@@ChimpanzeeUltra нужно два списка. Это то, о чем я говорил, генерик сложно обрабатывать, иы его все равно не сможешь в один список запихнуть если не кастовать потом. А каст - дорого, поэтому проще на каждый тип данный свой список ресурсов сделать и размножить методы под каждый тип данных. Это будет быстрее для процессора и лучше для памяти
Мне кажется мне нереально повезло, что я нашёл эти видосы. То, что искал, то и нашёл, даже круче.
One of the most unity qualitative videos I have ever seen
Ура! Мы будем делать РПГ!)
(но это не точно)
Очень классно!
Самое крутое что я узнал с видео, BigInteger.. Ни где не мог найти инфу как сделать такое бесконечное число, а тут оказывается все готово... А видосы у тебя крутые
Это довольно хороший подход, но есть ещё 1. Минусы данного подхода, когда нужно добавить набор ресурсов, например за награду, придётся писать свич кейс по типу ресурса, и если в награде есть первый тип, вызвать addResource(soft, amount) и т. д. для остальных, если бы у тебя всё ресурсы были имплементация от baseResource а в resource Storage ты бы их хранил так: dictionary то мог бы передавать list.
Не нужно делать свич, если где-то будет храниться "применитель" наград, который имеет обработчики для каждого типа ресурсов и они находятся в словаре. Для многих проектов это оверинжиниринг, поэтому не стал расписывать. Минус подхода с типами - даункаст, довольно тяжёлая операция, при часто использовании не очень хороший приём. Но если игра вроде героев, где ресурсов куча, но меняются они не часто - подход со словарём по типу - отличное решение без оверинжиниринга и достаточно гибкое
я Согласен круто
Не очевидная связь: ResourcesFeature должен хранить данные для всех ResourceType (иначе исключения при вытаскивании по отсутствующим типам), а в конструктор обязательно передавать массив только с уникальным RecourceType (иначе не создаться dictionary), что не проверяется компилятором. Это ошибка, или предполагается, что тот, кто заполняет ResourcesFeature знает об этой особенности?
Так задумано. Некоторые ошибки должны быть явными, чтобы их вовремя можно было исправить. Это достаточно эффективный подход в некоторых местах. Но не всегда он нужен, иногда нужно смягчить вылетание ошибки. При работе с ресурсами я ничего бы не смягчал
Отличный канай, отличный видос, спасибо тебе)
Можно про работу с SQL что-то снимать? Там много вариантов есть, хотелось бы узнать что лучше, как лучше.
А что конкретно интересует, то?
Ну типо как правильно использовать SQL (я использую Sqlite), как использовать Rest api, как получить и использовать response, и тд
Это паттерн стратегия сколько я понял не досмотрел до конца😁 мне больше нравится шаблонный метод)
К сожалению, с частью про отписку от события не соглашусь. Очень часто встречаюсь с тем, что если без прямой отписки завершить приложение, то при повторном запуске игра иногда работает не корректно. Так же, реже, но бывает такое что при IL2CPP билдах игра не может корректно завершиться.
а почему не использовать анонимный метод в ResourcesFuture вместо delegate?
Когда увидел в начале интерфейс для ресурса- захотел выключать, потом ты сказал про enum и я передумал)
13:17 Зачем дробить на Add и Spend, если можно сделать один ModifyResource()? Иногда неизвестно, положительная или отрицательная дельта ресурса
Практика показывает, что отлавливать баги проще с раздельными изменением
Когда я начну немного понимать о чем тут речь, мне прийдёт приглашение от Яндекс на должность Мидла?
Неа
Первый
Дикий оверинжениеринг
блин - очень прошу тебя = не снимай обучающий материал в 60fps - давайте заботиться об окружающей природе и понапрасну не тратить электроэнергию - ведь сервер выдающий видео обрабатывает в два раза больше данных - а умножив это на кол-во просмотров = объем лишней затраты на электроэнергию как на стороне серверов ютуб так и на стороне каждого клиента огромный. и большинство смотрит видео на скорости 2х - поэтому профитно писать обучающий материал в 30fps(для плавной картинки) - и даже разумно использовать 24fps. а еще = некоторые (как я) юзают старый macbook - и на скорости 2х 1080p@60fps = нотик просто взвывает от нагрузки=( оч прошу давайте будем разумными и не будем снимать 60fps там где нет в этом необходимости
😂
@@artem-nf6fh 😐
Слушай, никогда не задумывался об этом, хотя сам стараюсь следить за своими действиями по отношению к экологии (сортирую мусор, нет пакетам, металлические бутылки и все такое). Полностью согласен, спасибо за совет, 60фпс в принципе ни к чему для таких видео
@@gamedevlavka РЕСПЕКТ!!!
грета тунберг разлогинься