По моим ощущениям, UGUI проигрывает, NGUI из коробки работает хорошо. С UGUI через какое-то время начинаются адовые тормоза, и не понятно почему так происходит. Потом ты набредаешь на статьи и видео где рассказывают что всё это время ты проектировал интерфейс неправильно. И что все те оптимизации которые по идее должны были срабатывать, не работали вовсе. Т.е. он сделан контринтуитивно в этом плане. Например все объекты на Canvas считаются будто-бы с прозрачностью, любое перемещение или изменение элемента на экране это практически всегда перестройка всего меша до Canvas (а он обычно один, никто не говорит что их надо делать побольше). Деактивированные объекты участвуют в создании меша (по крайней мере я об этом слышал из видео юнити разраба, может я его неправильно понял) и т.д. и т.п.
В этом плане NGUI хорош, делаешь как нибудь, а оно будет работать нормально, даже если ты специально об этом не заботишься. Хочешь сделать лучше, можно сделать понятные и очевидные оптимизации.
Ну и как бы оба движка, условно говоря, поставляются с исходниками. Но разобраться в логике работы UGUI весьма и весьма затруднительно. Всё это лишь, конечно же, мое мнение, основанное на довольно обширном опыте работы с обоими движками. Мой выбор NGUI.
Ага… бесит когда на телефоне открываешь сайт, а он вбок уехал, пытаешь вернуться а он скроллится сверхбыстро, постоянно что-то подгружает. Очень удобно. Запустите свой же пример на маке с тачпадом и почувствуйте боль.
Кстати, было бы интересно почитать статью об организации подобного проекта, как у вас в комментарии.
Я сейчас занимаюсь разработкой чего-то подобного, и, похоже, собираю грабли ;( от чего проект движется как-то медленно.
В этой цитате показывается неосведомленность о том, как Unity собирает проект на самом деле. Если коротко, то из папки Assets в проект попадает только то, что используется на сцене, которая попадает в проект (в настройках билда), либо через префабы которые используются на сцене попадающей в проект — т.е если есть прямая ссылка на asset со сцены тем или иным образом.
100% в билд попадает только содержимое папки Resources и папки Streaming Assets. В первом случае к ресурсам можно обратится через Resource, во втором через File.
Простой способ увеличить скорость компилирования проекта, засунуть библиотечный (не ссылающийся на код игры) код в папку Plugins. Вообще я видел проект на гитхабе который с помощью симлинков тюнил скорость компиляции и гибкий шаринг скриптов между проектами.
В школе был английский, оценка у меня отлично, переводил я всегда хорошо. С подросткового возраста смотрел аниму на японском с субтитрами, потом английские мультики с субтитрами (Adventure Time, Futurama, etc). Потом начал и фильмы с субтитрами смотреть. В какой-то момент (когда поехал в Германию в командировку) понял что мне субтитры не очень то и нужны. Вообще живых людей понимать проще чем в записи. Речь хорошо понимаю на слух. Некоторое время занимался через Lingualeo не очень усердствуя, набрал словарный запас, а потом начал читать литературу на английском. Сперва получалось тяжело, потом когда я забил кучу слов в Lingualeo и повторил их пару раз, стало нормально.
На данный момент смотрю ютуб без субтитров на английском и понимаю достаточно. Хочу научиться говорить и писать, но не знаю как это практиковать. С этим реальная проблема.
Ещё корутины сродни анонимным колбекам в js, можно запутаться в их работе с полпинка и получить свежие спагетти. Корутины нужно использовать, но с умом.
7-й пункт как раз полезный. Нужно прятать все свойства от изменения их программистом. Потому что чаще всего это и не требуется. Вообще максимально закрытый класс это хорошо. Изменение переменных либо через геттеры, либо через метод с понятным названием. Десять раз стоит подумать прежде что-то объявить публичным, либо виртуальным.
Этот пункт должен звучать как: объявляй все поля и функции публичными вдруг тебе нужно будет поменять значение или вызвать функцию.
Стоит дополнить, что весь код который не изменяется и который не ссылается на игровые классы, лучше перенести в Plugins, так он попадёт в другую DLL (Assembly-Firstpass.dll) и будет компилироваться намного реже. Это ускорит компиляцию при изменении кода в проекте. В некоторых случаях в разы.
Ощущение что главу из реферата прочитал. При чём не первую. А оно вообще зачем надо? Где применение на практике? Что такое коллиматор вообще такое? Я об этом только в шутерах слышал.
На шлеме разместить приёмники прямо на креплении к голове + на макушке, а передатчики разместить в датчиках передвижения, которые висят по комнате и так следят за перемещением игрока(например у Vive). Вуаля.
Никто и не говорит что это просто и правильно — это плохо и аморально. Но один два раза сделать можно во имя благой цели. Как в лифте, первый этаж нажимают чаще всего как и поиск через первый уровень дерева в иерархии.
А неопределённое поведение, конкретно в этом случае, потому что конструируется пути внутри скрипта из различных констант. При этом частенько вместо того чтобы использовать уже объявленную константу, скрипт конструирует путь из двух других констант не связанных между собой. В общем это сложно отследить, и не стоит на это время тратить. Папка Plugins — в этом конкретном случае не причем (учитывая что её путь поменять нельзя). Вообще папка Plugins и как её содержать в чистоте и уюте — отдельный разговор.
Я написал об этом. Обычно после обновления нахожу переменную ответственную за путь и меняю на соответствующий (это легко правится в google ads например). Но Soomla, как видно, грешит тем что исправление этой переменной не помогает, и вызывает неопределённое поведение иногда, потому лежит в корне. В общем, рекомендация, скорее звучит держать папку Assets как можно чище.
2. Делай каждую сцену запускаемой: Не всегда возможно, к этому стоит стремиться, но в реальности проще сделать объект Persistent запихнуть его в префаб а потом скидывать на все сцены, а сам объект инициализировать в первой сцене с логотипом. 5. Обновляйся одновременно с командой: Выполняйте обновление юнити со страхом, а лучше прочитайте что это вам даст, оцените стоит ли это того, может и текущая версия неплоха. Обязательно читайте release notes и исправления на странице выпуски патчей. Возможно та неуловимая проблема на каком-нибудь редком устройстве которое вы уже пару месяцев не можете поймать, уже исправлена в патче для вашей версии? Но и обновляйтесь со страхом, получить ещё много новых занимательных неуловимых проблем, которые будут исправлены следующим патчем. 6. Импортируй ассеты в чистый проект: Хорошая практика, плюс заведите папку addons или extensions и все-все-все сторонние дополнения старайтесь сохранить в ней. Это уменьшит путаницу в иерархии папок. 9. Используй пространство имён с умом: Пространство имён, штука классная, но и с ними бывают коллизии, избегайте имён типа Utils каждое второе дополнение имеет его, лучше начинать пространство имён с, например, названия компании, WeslomPo.Utils — имеет меньше шансов столкнуться с другим пространством (так принято называть классы в других языках программирования, например Java или AS3, только ещё более жёстко: ru.weslompo.projectname.etc). Папки в должны следовать пространству имён. Т.е. файл лежащий в корне «Scripts» не имеет пространства имён, а файл «Scripts\Puzzle\Pieces\PieceOfCake.cs» должен иметь пространство имён «Puzzle.Pieces». 25. Инспектируемые поля только private + [SerializeField]: Я бы был более настойчивым в утверждении что следует использовать только private поля + [SerializeField] для всего что можно, кроме того что нужно вызывать снаружи класса. Не смотря на то что юнитеки этот метод не пропагандируют (я думаю им просто лень писать это в примерах). Это делает классы чуть более защищенным от нежелательных изменений, и помогает меньше заглядывать внутрь кода чтобы определить что можно с ним делать а что нельзя. Плюс это просто хорошая практика (good practice). 29. Запечатывай MonoBehaviour: Стоит дополнить, что sealed классы работают чуть быстрее чем не sealed, особенно когда проект компилируется в il2cpp, недавно была статья по этой теме. 43. Используй префабы для всего: Стандартные префабы в юнити это пи… ужас-ужас. Постоянно с ними какие-нибудь гадости творятся (например нет поддержки вложенности, встроили префаб в префаб — потерял ссылку, обещают исправить… но пока ещё нету стабильной версии с этой фичей). Поэтому используйте префабы на свой страх и риск, и лучшее только для объектов которые используются ОДИН раз, тогда вы избежите нежелательного поведения. 46-50. Советы по работе со ScriptableObject: «скриптуемые объекты» — я думаю это, как переводчик любит выражаться, «более сильно непонятно» чем ScriptableObject, особенно для тех кто никогда не трогал его ни разу в жизни, и даже не может понять что гуглить чтобы пояснить этот момент. Без нумерации: Структура папок, имхо излишне усложнённая, на первом уровне иерархии нужно иметь как можно меньше папок, и всё что является assets (Props, Prefabs, Texures, Meshes, Materials etc) на самом деле лучше засунуть куда-нибудь ниже, например, в папку «Data\», и там уже делать разветвлённую иерархию (DarkVampire, LightVampire, Plants etc.). Близкая к идеалу структура:
(Addons, Data, Editor, Plugins, Resources, Scenes, Scripts).
Но и тут заметно что Soomla вылезла в коернь, потому что пути у неё захардкожены (их исправление приводит к неопределённому поведению).
Еще стоит добавить обязательную установку расширения RainbowFolders. Прям вот начал проект, первым делом установил. Сидит в редакторе, в билд не попадает, а наглядность папок возрастает.
Структура сцены излишне оптимистичная, ибо большая часть экстеншенов любит «срать» на сцену своими компонентами, либо хотят быть самыми близкими к корню (из-за метода DontDestroyOnLoad). Возможно меня закидают палками, но я обычно выпиливаю этот метод из всех нужных мне компонентов-дополнений. Просто завёл один объект Persistent который в единственном экземпляре использует метод DontDestroyOnLoad и самоудаляется если находит ещё один такой компонент на сцене. А все компоненты запихиваю в него ниже по иерархии с группировкой по типа (Advertise, Shop, Analytics etc.). Так получается чище сцена. А то посмотришь на неё как-нибудь, и ужаснёшься какой там кошмар устроили сторонние разработчики своими объектами без спросу.
В этом плане NGUI хорош, делаешь как нибудь, а оно будет работать нормально, даже если ты специально об этом не заботишься. Хочешь сделать лучше, можно сделать понятные и очевидные оптимизации.
Ну и как бы оба движка, условно говоря, поставляются с исходниками. Но разобраться в логике работы UGUI весьма и весьма затруднительно. Всё это лишь, конечно же, мое мнение, основанное на довольно обширном опыте работы с обоими движками. Мой выбор NGUI.
Я сейчас занимаюсь разработкой чего-то подобного, и, похоже, собираю грабли ;( от чего проект движется как-то медленно.
100% в билд попадает только содержимое папки Resources и папки Streaming Assets. В первом случае к ресурсам можно обратится через Resource, во втором через File.
Простой способ увеличить скорость компилирования проекта, засунуть библиотечный (не ссылающийся на код игры) код в папку Plugins. Вообще я видел проект на гитхабе который с помощью симлинков тюнил скорость компиляции и гибкий шаринг скриптов между проектами.
На данный момент смотрю ютуб без субтитров на английском и понимаю достаточно. Хочу научиться говорить и писать, но не знаю как это практиковать. С этим реальная проблема.
Этот пункт должен звучать как: объявляй все поля и функции публичными вдруг тебе нужно будет поменять значение или вызвать функцию.
А неопределённое поведение, конкретно в этом случае, потому что конструируется пути внутри скрипта из различных констант. При этом частенько вместо того чтобы использовать уже объявленную константу, скрипт конструирует путь из двух других констант не связанных между собой. В общем это сложно отследить, и не стоит на это время тратить. Папка Plugins — в этом конкретном случае не причем (учитывая что её путь поменять нельзя). Вообще папка Plugins и как её содержать в чистоте и уюте — отдельный разговор.
5. Обновляйся одновременно с командой: Выполняйте обновление юнити со страхом, а лучше прочитайте что это вам даст, оцените стоит ли это того, может и текущая версия неплоха. Обязательно читайте release notes и исправления на странице выпуски патчей. Возможно та неуловимая проблема на каком-нибудь редком устройстве которое вы уже пару месяцев не можете поймать, уже исправлена в патче для вашей версии? Но и обновляйтесь со страхом, получить ещё много новых занимательных неуловимых проблем, которые будут исправлены следующим патчем.
6. Импортируй ассеты в чистый проект: Хорошая практика, плюс заведите папку addons или extensions и все-все-все сторонние дополнения старайтесь сохранить в ней. Это уменьшит путаницу в иерархии папок.
9. Используй пространство имён с умом: Пространство имён, штука классная, но и с ними бывают коллизии, избегайте имён типа Utils каждое второе дополнение имеет его, лучше начинать пространство имён с, например, названия компании, WeslomPo.Utils — имеет меньше шансов столкнуться с другим пространством (так принято называть классы в других языках программирования, например Java или AS3, только ещё более жёстко: ru.weslompo.projectname.etc). Папки в должны следовать пространству имён. Т.е. файл лежащий в корне «Scripts» не имеет пространства имён, а файл «Scripts\Puzzle\Pieces\PieceOfCake.cs» должен иметь пространство имён «Puzzle.Pieces».
25. Инспектируемые поля только private + [SerializeField]: Я бы был более настойчивым в утверждении что следует использовать только private поля + [SerializeField] для всего что можно, кроме того что нужно вызывать снаружи класса. Не смотря на то что юнитеки этот метод не пропагандируют (я думаю им просто лень писать это в примерах). Это делает классы чуть более защищенным от нежелательных изменений, и помогает меньше заглядывать внутрь кода чтобы определить что можно с ним делать а что нельзя. Плюс это просто хорошая практика (good practice).
29. Запечатывай MonoBehaviour: Стоит дополнить, что sealed классы работают чуть быстрее чем не sealed, особенно когда проект компилируется в il2cpp, недавно была статья по этой теме.
43. Используй префабы для всего: Стандартные префабы в юнити это пи… ужас-ужас. Постоянно с ними какие-нибудь гадости творятся (например нет поддержки вложенности, встроили префаб в префаб — потерял ссылку, обещают исправить… но пока ещё нету стабильной версии с этой фичей). Поэтому используйте префабы на свой страх и риск, и лучшее только для объектов которые используются ОДИН раз, тогда вы избежите нежелательного поведения.
46-50. Советы по работе со ScriptableObject: «скриптуемые объекты» — я думаю это, как переводчик любит выражаться, «более сильно непонятно» чем ScriptableObject, особенно для тех кто никогда не трогал его ни разу в жизни, и даже не может понять что гуглить чтобы пояснить этот момент.
Без нумерации: Структура папок, имхо излишне усложнённая, на первом уровне иерархии нужно иметь как можно меньше папок, и всё что является assets (Props, Prefabs, Texures, Meshes, Materials etc) на самом деле лучше засунуть куда-нибудь ниже, например, в папку «Data\», и там уже делать разветвлённую иерархию (DarkVampire, LightVampire, Plants etc.). Близкая к идеалу структура:
(Addons, Data, Editor, Plugins, Resources, Scenes, Scripts).
Но и тут заметно что Soomla вылезла в коернь, потому что пути у неё захардкожены (их исправление приводит к неопределённому поведению).
Еще стоит добавить обязательную установку расширения RainbowFolders. Прям вот начал проект, первым делом установил. Сидит в редакторе, в билд не попадает, а наглядность папок возрастает.
Структура сцены излишне оптимистичная, ибо большая часть экстеншенов любит «срать» на сцену своими компонентами, либо хотят быть самыми близкими к корню (из-за метода DontDestroyOnLoad). Возможно меня закидают палками, но я обычно выпиливаю этот метод из всех нужных мне компонентов-дополнений. Просто завёл один объект Persistent который в единственном экземпляре использует метод DontDestroyOnLoad и самоудаляется если находит ещё один такой компонент на сцене. А все компоненты запихиваю в него ниже по иерархии с группировкой по типа (Advertise, Shop, Analytics etc.). Так получается чище сцена. А то посмотришь на неё как-нибудь, и ужаснёшься какой там кошмар устроили сторонние разработчики своими объектами без спросу.