Войти
ПрограммированиеФорумОбщее

Unity (проблемы, решения, перспективы) (93 стр)

Страницы: 192 93 94 95119 Следующая »
#1380
14:43, 15 авг. 2018

Mira
> В юнити дико напрягает что устанавлеимые сторонние ассеты автоматом
> интегрируются в проект, хотя мне оттуда нужно иногда какую то мелочь.
а что мешает сторонние ассеты сначал интегрировать в новый пустой проект и перетаскивать в рабочий только то что действительно нужно ? (авторы большинства ассетов такие же разработчики как и мы и главная их задача - продать продукт своего творчества, а уж как оптимально интегрировать чужие наработки - это уже вопрос того кто использует :)


#1381
17:55, 15 авг. 2018

Что-то с окном проекта надо делать, потому что даже если в проект не совать ничего левого, со временем он сам себя засирает. Накапливается скриптов, текстур, моделей, ещё всякого, которое не понятно как лучше группировать:
- то ли по смыслу (модель + её текстуры и материалы + префаб + управляющие скрипты + аниматор какой-нибудь + ...),
- то ли по типам ассетов (модели отдельно, текстуры отдельно, скрипты отдельно, ...),
- то ли по подсистемам (отдельно ГУИ, отдельно ландшафт+кустики-деревья, отдельно постройки, отдельно персоонажи, ...)
- то ли ещё как-то.

Как ни группируй, потом всё равно оказывается неудобно и группы начинают перемешиваться.

#1382
(Правка: 19:38) 19:26, 15 авг. 2018

alexzzzz
> Накапливается скриптов, текстур, моделей, ещё всякого, которое не понятно как
> лучше группировать
Это извечное! В больших проектах например каждый чуть ли не свою папку делает и весь проект под себя переписывает. А когда один пишешь то многие например скрипты запихивают в один файл, потому что под папок со скриптами просто тьма и в каждом свой базовый класс с утилиткой.

Поскольку рефакторинг касается всего, даже ресурсов, я делаю корневую папку с версией и там все по новой организую. В результате получается боле менее удобная вариация. Но главное с самого начала не забывать назначение папок описывать, а то потом запутаешься и вся организация коту под хвост.

И такая дилемма: либо лабиринт из папок, либо мельтишня перед глазами из файлов.

А еще если начинаешь работать с любителем большого количества сторонних фреймворков организующих процесс разработки кода или еще чего либо, оооо.. Сразу куча папок с абстрактными классами для простого проекта. Жуткая жуть.

#1383
19:47, 15 авг. 2018

Чой-то вы сгущаете краски:
Screenshot_126 | Unity (проблемы, решения, перспективы)

Никаких проблем не испытываю - изначально все, что относится только к данному проекту, поместил в папку GameData. Любые сторонние ассеты туда не попадают никак. Свой порядок - ничем не нарушается, если соблюдать исходно определенную архитектуру объектов проекта.

#1384
(Правка: 19:59) 19:59, 15 авг. 2018

Homeship
Это понятно, но у меня уже в глазах рябит.

#1385
20:47, 15 авг. 2018

foxes
> в глазах рябит.

Глаза надо беречь.) Отдых им давать, упражнения делать, чернику кушать.))

#1386
23:30, 15 авг. 2018

Homeship
я так же в одну папку сложил, но проект походу все равно обрабатывает все кучей. и перекомпилирует всякий мусор чуть че)

#1387
(Правка: 0:32) 0:18, 16 авг. 2018

для любителей красивости есть неплохой ассет Rainbow Folders который позволяет на каждую папку назначить свою иконку

Изображение

ups ... два раза папка с анимациями - косяк :)

вот так лучше :)

+ Показать

#1388
0:34, 16 авг. 2018

Mira
> обрабатывает все кучей. и перекомпилирует всякий мусор чуть че)

Хм... Ну ведь он и должен обрабатывать все что лежит в Assets - логика движка такая, нет?
А насчет компиляции - тут либо сразу удалять что не нужно, либо - я не пойму почему он сам "перекомпилирует всякий мусор чуть че"... Под "компиляцией" понимается - перезагрузка скриптов в движок, при их изменении в среде (например Моно или Студия)?

Если так - то либо удалять, либо - не сохранять изменения, до "зачистки".

#1389
1:28, 16 авг. 2018

Mira

все равно обрабатывает все кучей

Используй assembly definitions
#1390
9:07, 16 авг. 2018

patsanchik3
> позволяет на каждую папку назначить свою иконку

На вкус и цвет конечно..
На мой - это все добавляет еще больше пестрящего хаоса )

#1391
9:27, 16 авг. 2018

Homeship
Да перезагрузка.
Так лежит , думаешь потом пригодится. И потом барахло кароче копится) а пригождается не все. Удобно иногда ченеть потестить , достаешь из свалки. В противном случа придется мудохаться с импортом пакетов а потом удалять

#1392
10:35, 16 авг. 2018

Mira
> думаешь потом пригодится.

Ну тут только самоорганизованность, иначе - никак. )) Я прошел уже через этот этап - "эту фичу сохранить, вдург найдется куда воткнуть", и "этот ассет - очень симпатичный, но пока не вписывается, но пускай полежит".
Все что "не вписывается", "пока не используется", "может пригодится" сразу - экспортируется в unitypackage-файл и удаляется из проекта.
Пока что из "понравившегося", обратно портировал в проект от силы 2% - показательно.

#1393
(Правка: 23:55) 23:54, 16 авг. 2018

Как известно CLR требует, чтобы методы, которые реализуют интерфейс были виртуальными, поэтому компилятор неявно их делает virtual и final.
Это меня натолкнуло на рассуждения, что будет, если метод будет объявлен в базовом классе, а интерфейс в дочернем. Или если базовый класс находится в другой сборке?!

И по какому-то случайному стечению обстоятельств я увидел твит одного из разработчиков Unity, который тоже сегодня об этом задумался: https://twitter.com/jon_cham/status/1030151715096547330

А будет следующие.
Когда метод в базовом классе, а интерфейс в дочернем классе, то компилятор добавляет virtual/final методу базового класса. Т.е. дочерний класс влияет на то как компилируется базовый класс.
А когда базовый класс находится в другой сборке, то компилятор создает новый виртуальный метод, который вызывает метод из базового класса.
В обсуждение твита приводятся и другие случаи, когда компилятор вынужден создать новый виртуальный метод. Я так понял модификатор In как-то влияет на это.
Вот такими хаками работает .Net)) Напрямую к Unity это никак не относится, но может кому-то будет интересно.

#1394
(Правка: 17:08) 16:06, 18 авг. 2018

Я в итоге вообще решил отказаться от сторонних ассетов.
Максимум могу посмотреть на реализацию нужных вещей что бы не тратить много времени на поиски и изучение требуемой функциональности.
Так что структура проекта полностью контролируется мной, да и можно использовать новейшие возможности Unity не боясь того, что один из сторонних ассетов сломается или ещё чего.:)

+ Показать

Да и структура кодовой базы тоже очень важна:

+ Показать

Хотя, мне и в UE4 нравится структура проекта.
Но в UE4 просто кошмар с поддержкой сторонних IDE для плюсов:(
Я уже задолбался с ними ругаться на эту тему.
Тут Unity вне конкуренции.

Страницы: 192 93 94 95119 Следующая »
ПрограммированиеФорумОбщее