у меня есть свой код, и ассет со стора. В этом ассете есть ассет дифинишн. В своих скриптах я юзаю скрипты из ассета, но ассет подстроен под одичночую игру, мне нужно подключить его к своим скриптам, написанным для мультиплеера. Как я могу тут поступить?
@@gamedevlavka у меня ассет на игрока, с кодом в отдельных сборках кода(ассет дифинишн), и мне нужно в код этого ассета свои классы с методами указывать, которые находятся в сборке AssemblyCSharp. Как мне поступить то? Если мой код имеет ссылки на код из того ассета и на классы, которые я хочу использовать в скрипте этого ассета на игрока
Допустим у меня есть папка плагинов(зенжект/один/твин/аналитика и так далее), и папка скриптов своих. В скриптах используются эти плагины соответственно. Будет ли профит если сделать для папки скриптов Assembly Definition??? ведь мне придётся прокидывать ссылки в него всех плагинов используемых и перекомпиляция следовательно идентичная как без Assembly Definition. И помню как то делал и мне пришлось ещё референсы на юнитёвкие ассеты прокидывать(синемамашин, TMP, реклама). Как организовать чтобы мои скрипты компилировались отдельно от всего этого барахла стороннего и желательно чтобы не было 100500 ссылок в Assembly Definition папки скриптов
Так это же классический граф зависимостей. Компонент имеет ссылки на те компоненты, от которых зависит. Фокус в том, что твои компоненты должны быть максимально независимы. Эдакие черные ящики - вещи в себе. А все зависимости прокидываются через интерфейсы. А самый верхний уровень в любом случае будет иметь ссылки на всё и всех. Это в терминах DI корень композиции. Т.е. ответ на твой вопрос не в том, нужно или нет делать AD для папки скриптов, а в том, что нужно писать скрипты соответствующим образом, уменьшая зацепление. И тогда своим независимым модулям нужно назначить AD. Ну, я так понимаю ситуацию. Возможно, более знающие люди возразят. Вокруг такого подхода вертятся TDD, тесты, и DI.
Поддерживаю оратора выше, лучше и не скажешь. Профит от AD для тех участков кода, которые абсолютно самостоятельны и не зависят от проекта, в остальном можно пренебречь, т.к. неудобство использования может перекрыть скорость компиляции
Ничего против не имею и поддерживаю обучающие видео для новичков. Но как по мне большинство твоих видео бесполезные, потому что это гуглится за минуту и читается быстрее 12 минут, потому что много комментариев есть чаще не по теме (это неплохо). Тебе бы глубже тему разбирать и рассказывать, какие-то неочевидные вещи, тогда и статистика будет лучше и подписота придёт. Как один из примеров - видео про async, ты рассказал самые очевидные вещи +скорее всего скомуниздил текст у Tarodev, видео почти идентичные, но его вышло раньше. Если уж и затронул эту тему, то хотелось бы посмотреть разбор cancel token, о чём ты в конце сказал и намекнул на продолжение в дальнейших видео, но имеем, что имеем. Чисто критика без агрессии
Харош мужик, хачапури в радость!
Это канал заслуживает больше просмотров и подписчиков .
Спасибо за видео!
Запиши видос про алгоритмы, нужны ли они юнити разработчику, и если да то какие. Желательно с примерами задач)
Алгоритмы нужны любому разработчику
Лайк и коммент для поддержки
thx broooooooo!
у меня есть свой код, и ассет со стора. В этом ассете есть ассет дифинишн. В своих скриптах я юзаю скрипты из ассета, но ассет подстроен под одичночую игру, мне нужно подключить его к своим скриптам, написанным для мультиплеера. Как я могу тут поступить?
Писать также как и в одиночке. Ассет дифинишн не смотрит на мультиплеер это или нет. Это просто области видимости кода
@@gamedevlavka у меня ассет на игрока, с кодом в отдельных сборках кода(ассет дифинишн), и мне нужно в код этого ассета свои классы с методами указывать, которые находятся в сборке AssemblyCSharp. Как мне поступить то? Если мой код имеет ссылки на код из того ассета и на классы, которые я хочу использовать в скрипте этого ассета на игрока
@@gamedevlavka грубо говоря, код из того ассета не видит мой код,
Допустим у меня есть папка плагинов(зенжект/один/твин/аналитика и так далее), и папка скриптов своих. В скриптах используются эти плагины соответственно. Будет ли профит если сделать для папки скриптов Assembly Definition??? ведь мне придётся прокидывать ссылки в него всех плагинов используемых и перекомпиляция следовательно идентичная как без Assembly Definition. И помню как то делал и мне пришлось ещё референсы на юнитёвкие ассеты прокидывать(синемамашин, TMP, реклама). Как организовать чтобы мои скрипты компилировались отдельно от всего этого барахла стороннего и желательно чтобы не было 100500 ссылок в Assembly Definition папки скриптов
Так это же классический граф зависимостей. Компонент имеет ссылки на те компоненты, от которых зависит. Фокус в том, что твои компоненты должны быть максимально независимы. Эдакие черные ящики - вещи в себе. А все зависимости прокидываются через интерфейсы. А самый верхний уровень в любом случае будет иметь ссылки на всё и всех. Это в терминах DI корень композиции. Т.е. ответ на твой вопрос не в том, нужно или нет делать AD для папки скриптов, а в том, что нужно писать скрипты соответствующим образом, уменьшая зацепление. И тогда своим независимым модулям нужно назначить AD. Ну, я так понимаю ситуацию. Возможно, более знающие люди возразят. Вокруг такого подхода вертятся TDD, тесты, и DI.
Поддерживаю оратора выше, лучше и не скажешь. Профит от AD для тех участков кода, которые абсолютно самостоятельны и не зависят от проекта, в остальном можно пренебречь, т.к. неудобство использования может перекрыть скорость компиляции
А можно как-то ускорить загрузку проекта при первоначальном открытии. А то вроде маленький проект, а грузится долго.
Не совсем понятно, что имеется ввиду под первоначальным открытием проекта
@@gamedevlavka когда Unity hub нажимаешь на проект
Предлагаю тему: addressables/google play asset delivery - не?
Ничего против не имею и поддерживаю обучающие видео для новичков. Но как по мне большинство твоих видео бесполезные, потому что это гуглится за минуту и читается быстрее 12 минут, потому что много комментариев есть чаще не по теме (это неплохо). Тебе бы глубже тему разбирать и рассказывать, какие-то неочевидные вещи, тогда и статистика будет лучше и подписота придёт. Как один из примеров - видео про async, ты рассказал самые очевидные вещи +скорее всего скомуниздил текст у Tarodev, видео почти идентичные, но его вышло раньше. Если уж и затронул эту тему, то хотелось бы посмотреть разбор cancel token, о чём ты в конце сказал и намекнул на продолжение в дальнейших видео, но имеем, что имеем.
Чисто критика без агрессии