Согласен, но это вопрос того, как именно визуализировать лабиринт. Так как лабиринт — это граф, и в целом его можно визуализировать по разному — это самая простая трёхмерная визуализация (ну точнеее технически не самая простая — самая простая из кубиков, но там будет куча проблем в стиле артефактов освещения на стыках, кривой тайлинг материалов и как следствие невозможность использовать один материал и т.п.) Вообще если говорить о использовании в играх, то удобнее всего сделать определённый набор готовых ячеек, и подставлять их. В целом сгенерированная структура данных W4Maze позволяет это сделать без особого труда.
А по поводу скриншотов и замкнутых квадратов (особенно если речь о 3д) Там их не должно быть и это скорее всего оптическая иллюзия благодаря тому, что у стен нет «верха» — я его не визуализировал. Поэтому если у вас есть юнити, то можете скачать проект с гитхаба и посмотреть на результат.
Ну я сейчас всё-таки специализируюсь на разработке, так что не сказать, что я хорошо и внимательно слежу за трендами и являюсь профессионалом в этой области.
Просто периодически для мониторинга и анализирую графики премьер фильмов и сериалов, поисковые запросы, тренды приложений, ютуба, просто тот контент который выходит на популярных каналов.
Ну и yandex wordstat, google trends и инструмент в adword для просмотра популярности поисковых запросов.
Ну я просто ничего в этом не вижу плохого. В нашем мире для того, чтобы даже что-то крутое делать, нужны деньги. И если есть возможность их заработать, и после этого потратить на крутой и интересный проект — то почему нет. Команду разработки ведь надо кормить.
Ну, я беру нормальные аппы под хайповую тему, а не всякий чистый мусор. Искусство — это конечно прекрасно, но кушать тоже надо. Тем более, что именно зарабатывать на хайпе тоже надо уметь. Это не так просто, как может показаться.
«Неправильно», на мой взгляд, не следить за трендами и их игнорировать. Всё зависит конечно же от конечной цели, но тем не менее это странно.
Прикольная штука. И судя по google trends начала набирать в России популярность только в мае этого года (там ярковыраженный пик) Я думаю, что скорее всего пару месяцев будет в тренде, как те же покемоны, а потом все про неё забудут.
Ну вот с проблемой префабов (по крайней мере в UI) тут я бы поспорил, ведь руками создавать второй префаб панели, чтобы поменять текст кнопки, или добавлять новый функционал, звучит как костыль. Она решается может не слишком удобно, и решается скриптингом. События, инстанцирование и правильные использование всего этого, позволяют собирать окна, как в конструкторе, но скриптингом (я уверен, что визуальное программирование в анреале лучше), но учитывая особенности юнити, не особо оптимально делать второй префаб стола, да и просто в ручную раскидывать однотипные объекты на сцене.
Дело в том, что так как юнити не определяет дубликаты в сцене, то с точки зрения скорости загрузки сцены и т.п. все однотипные объекты лучше инстанцировать при загрузке. Поэтому, по сути, в моём понимании, префаб стола один, а внутри него есть скрипт, берущий префаб ноутбука и создающий необходимый ноутбук, с необходимым цветом экрана. По крайней мере в UI — это точно самая адекватная практика. С 3д, тут соглашусь, если требуется baked освещение и т.п. начинаются пляски с бубном, да и редактировать такое может не очень удобно. Это тожно можно хитро обойти малой кровью, но это уже нужно знать как (да и писать что-то для движка, чтобы с ним было просто удобно работать, звучит странно)
В анреале (по рассказам, сам я с ним пока не работал) проще работать с помощью визуального программироваиня, а в юнити всё проще делать скриптами. И описанное выше делается достаточно тривиальным скриптингом. Но если вы повторяете изменения вручную, создаёте новые префабы на старом скелете, перенося скелет целиком — вы делаете что-то не так. Так как в моём понимании префаб — это по сути минимальная логическая единица, которая потом инстанцируется с параметрами. Если придерживаться этой логики, то таких проблем особо не возникает.
Со скриншотами есть способ удобнее. Просто через LateUpdate не так удобно это всё делать, лучше, на мой взгляд делать это корутиной c yield return new WaitForEndOfFrame();
Там уже зависит от того, как работать, но к примеру, я сейчас написал для Texture такой экстеншн метод GetTexture2D, и как пример использования, небольшой класс, который позволяет делать скриншоты с вебки.
Я не претендую на инновационность, так как решение не особо сложное. Цель статьи показать какой эффект можно создать. Возможно, можно добиться того же эффекта инструментами назваными вами. Но я сейчас попробовал и у меня не получилось. С декалями я не совсем понял идею (или особую разницу). Моя задача не рендерить такой эффект в приложении, а получить результат искажения для того, чтобы распечатать и использовать. Может этого можно добиться проектором или декалями в линейном случае.
Но скажем с отражающими поверхностями такого решения достичь этими средствами уже не получится (либо это будет сложнее). Хотя в целом сейчас для обработки отражения нужно определять, какая поверхность отражает, и проецировать по отражённому лучу на неотражающую поверхность. Что опять таки, не такая сложная доработка.
Зачем, если все остальные инстансы просто сами по себе умрут при проверке, являются ли они настоящим синглтоном.
В плане умрут в той реализации, которая в статье? Если в сцене по какой-то причине будет два синглтона, то как определить какой из них правильный? И какой из них удалится? Просто реализацию из статьи я видел в майкрософтовской библиотеке Holotoolkit (если его не обновили) и ничего там не удаляется, просто второй инстанс бесцельно висит, так как он никогда не вызывается.
Если нужна реакция на события жизненного цикла юнити — без этого не обойтись.
Может быть в некоторых случаях соглашусь, хотя у меня получалось выстраивать архитектуру так, чтобы синглтоны по сути вызывались в монобехах, но сами монобехами не являлись. Просто по сути получалось вроде того, что синглтоны у меня выполняли роль «модели» (правильнее сказать они управляли моделью), а монобехи — это «отображение+контроллер», и в них синглтоны как-то не требовались.
Об особенностях юнити нужно думать не только в foreach, но и вообще.
Я и имел ввиду, что знание особенностей платформы — это главное. Фанатизм — это плохо что в одну, что в другую сторону. Использовать хорошую практику для конкретной платформы/технологии — понятное дело лучше, чем не использовать. Просто не надо уходить в крайности «ради идеи». Конечная цель всё-таки в любом случае получить стабильно и хорошо работающую программу, и хороший поддерживаемый код. Если при этом там будет плохой приём, который не влияет на производительность и читаемость, то не надо с пеной у рта избивать программистов за их незнание особенностей платформы. Программисты вообще не любят когда их бьют :)
Это наверное один из самых длинных споров про foreach на который я натыкался в последнее время. Мне конечно даже немного страшно влезать в вашу перепалку, но там где без foreach легко обойтись, лучше обойтись без foreach. При этом вы не сказали, в каких случаях foreach всё-таки необходим, и в чём его плюс то собственно. Его можно и нужно юзать в двух случаях, когда мы работаем с коллекцией, с которой без foreach работать нельзя (скажем с хешсетом) или передаём параметром скажем просто класс, который реализует интерфейс IEnumerable, если не ошибаюсь.
Если проходить форичем на эвейке какого-то одного объекта, то в целом конечно же +- плевать, но если мы работаем с коллекцией по которой можно пройтись через for, то почему бы не юзать его? Можно вообще охотится на бесов, и так как мы в юнити чаще всего живём в однопоточном мире, если мы знаем, что внутри цикла не меняется количество элементов коллекции, кешировать заранее Count, так как насколько мы помним у нас в пропертях ничего не инлайнится.
Я просто уже, если честно, потерял цель вашего спора. Излишняя оптимизация — это плохо, так как чаще всего её придётся переделывать, но если мы знаем, что в юнити на данный момент for работает лучше, чем foreach, то зачем использовать foreach? Конечно же никто не запрещает, и если очень хочется — пользуйтесь. Просто это не лучшая практика, при этом решение через for занимает всего на несколько символов больше.
Просто не надо уходить в крайности. Ещё можно похоливарить на тему того, что по хорошему можно обойтись без List, и он работает медленнее, чем массивы, так что давайте везде юзать массивы. Ребята — давайте жить дружно. Есть места где та или иная вещь критична, есть где в целом всё равно, а есть где по-другому нельзя. Зачем что-то выводить в уровень абсолюта?
Не юзать foreach там, где он не обязателен с тем, как это работает в юнити — в сущности неплохой совет. Просто ещё стоит уточнить, что не надо его избегать, как огня, и если скажем поиск по коллекции вы вызываете в апдейте, а проходите по каждому элементу коллекции в эвейке (я думаю, что можно придумать такую ситуацию, где в начале мы скажем очищаем состояние элементов, а после ищем особенные), то не нужно городить костыли, а нужно взять хешсет и ходить по нему форичем, так как хешсет на поиск нам даст О(1).
Просто если вы знаете, что форичи аллоцируют лишнего в юнити и заставляют GC запускаться чаще — вот это уже хорошо. Так как если возникнет проблема, что игра по какой-то причине фризится, то вы знаете где это можно искать, а это главное.
Соглашусь по этому пункту, но добавлю, что в ряде ооооочень специфичных случаев — это бывает полезно из-за того, что с полями удобнее работать в плане рефлексии. Рефлексия — это конечно вообще очень медленно и т. п., но бывает полезно (как минимум для написания тестов).
Ахинея — использование автосвойств без ограничения доступа. По сути — просто увеличение вычислительной нагрузки без логического обоснования. Свойства нужны исключительно для вычисляемых полей и ограничения доступа.
Ну это я скостил на добавку автора, что оптимизировать надо по необходимости. Я согласен, что фраза «не юзать строки» тоже звучит слишком громко, так как я юзаю строки для айдишников объектов и это никогда не вызывало проблем. Так же можно было бы сказать «храните всё в бинарниках, так как это быстрее, чем читать текстовые файлы, что позволяет уменьшать время загрузки», но с сериализацией в текстовые файлы банально удобнее работать при разработке продукта. Так как если скажем делать всё через поля в префабах, то с этим невозможно работать в команде, так как вы будете решать мержконфликты львиную долю времени.
Ну скажем кешировать GetComponent(), а не вызывать его в Update или боже упаси FixedUpdate — это тоже здраво. Да, и аллоцировать лишнее учитывая фрагментацию и то, как устроен GC в .NET тоже такое, так как это может вызывать просто периодические просады CPU засчёт фрагментации, если бездумно аллоцировать кучу мелких объектов. А так да, во многих случаях про это даже особо думать не надо.
Спасибо за замеры с 1. На самом деле было интересно, есть ли разница. Автосвойствами я не пользуюсь, так как пока не возникало кейсов, где они были бы нужны. В некоторых случаях можно кешировать проперти (чтобы не дёргать лишний раз), но согласен, что не всегда.
А про комменты тоже не соглашусь, в они часто бывают полезны, так как если скажем в коде реализован сложный алгоритм (тот же волновой алгоритм поиска пути или же алгоритм триангуляции невыпуклого контура), то не каждый с ходу их сможет узнать, и был бы полезен коммент, что тут именно происходит, чтобы не лезть в документацию лишний раз. Да, и в ряде случаев люди мыслят немного по разному и нейминг, который одному человеку кажется очевидным для другого не так очевиден.
Спасибо. Статья хорошая, но реализация шаблонного синглтона, которая тут описана — плохая. Если я не ошибаюсь, она мне не запрещает иметь два синглтона в одной сцене (первый найденный файндом и будет прав) Тут должна быть ещё проверка на то, что если объект существует, то его нельзя прицепить. Хотя я бы вообще не советовал делать монобехи синглтонами.
1. В каком смысле не использовать свойства? Какие свойства? Если имеется ввиду в своих классах, то допустим нам нужна инкапсуляция. Вопрос, в чём отличие свойства от геттера и сеттера реализованных методами?
2. Про GetComponent<> вообще отдельный разговор, я не совсем понимаю зачем его использовать в принципе. Это конечно, наверное, ускоряет работу (хотя я считаю, что это банальная лень программистов), но в большинстве случаев можно обойтись вообще без него. Т.е. компоненты, которые висят на объекте всегда, можно просто сериализовать. А те объекты, которые цепляются динамически откуда-то можно хранить пуллом в скрипте, в котором они цепляются и обращаться с этим (точнее говоря это по разному можно решать)
4. Опасно, так как вроде Vector3 не иммутабелен (поэтому его геттер и сделан через new), и если кто-то случайно в коде натупит (случайно или по невнимательности), то такую ошибку очень тяжело найти (а точнее понять в чём именно ошибка). Соглашусь, что надо кешировать и т. п., и что случай редкий, но тем не менее я бы кешировал внутри класса, где это используется. (Допустим, кто-то вызовет метод Scale или уж совсем непонятно зачем — Set)
5. А как же StringBuilder?
С этим я просто не согласен, читабельность можно сохранить при правильных подходах если не торопиться. В крайнем случае решается это комментарием, что делает эта магическая строка.
«Самым плохим моментом оптимизаций является то, что ваш структурированный и „идеальный“ код растекается в местами не очень читабельное нечто. К сожалению, это неизбежно. Главное помнить о том, что это жертва в угоду производительности.»
Это не особо поможет с тайлингом. Можно в шейдере из мировых координат делать правильный тайлинг, но лучше правильно расставить Uv-шки
А по поводу скриншотов и замкнутых квадратов (особенно если речь о 3д) Там их не должно быть и это скорее всего оптическая иллюзия благодаря тому, что у стен нет «верха» — я его не визуализировал. Поэтому если у вас есть юнити, то можете скачать проект с гитхаба и посмотреть на результат.
Просто периодически для мониторинга и анализирую графики премьер фильмов и сериалов, поисковые запросы, тренды приложений, ютуба, просто тот контент который выходит на популярных каналов.
Ну и yandex wordstat, google trends и инструмент в adword для просмотра популярности поисковых запросов.
Ну, я беру нормальные аппы под хайповую тему, а не всякий чистый мусор. Искусство — это конечно прекрасно, но кушать тоже надо. Тем более, что именно зарабатывать на хайпе тоже надо уметь. Это не так просто, как может показаться.
«Неправильно», на мой взгляд, не следить за трендами и их игнорировать. Всё зависит конечно же от конечной цели, но тем не менее это странно.
Дело в том, что так как юнити не определяет дубликаты в сцене, то с точки зрения скорости загрузки сцены и т.п. все однотипные объекты лучше инстанцировать при загрузке. Поэтому, по сути, в моём понимании, префаб стола один, а внутри него есть скрипт, берущий префаб ноутбука и создающий необходимый ноутбук, с необходимым цветом экрана. По крайней мере в UI — это точно самая адекватная практика. С 3д, тут соглашусь, если требуется baked освещение и т.п. начинаются пляски с бубном, да и редактировать такое может не очень удобно. Это тожно можно хитро обойти малой кровью, но это уже нужно знать как (да и писать что-то для движка, чтобы с ним было просто удобно работать, звучит странно)
В анреале (по рассказам, сам я с ним пока не работал) проще работать с помощью визуального программироваиня, а в юнити всё проще делать скриптами. И описанное выше делается достаточно тривиальным скриптингом. Но если вы повторяете изменения вручную, создаёте новые префабы на старом скелете, перенося скелет целиком — вы делаете что-то не так. Так как в моём понимании префаб — это по сути минимальная логическая единица, которая потом инстанцируется с параметрами. Если придерживаться этой логики, то таких проблем особо не возникает.
Со скриншотами есть способ удобнее. Просто через LateUpdate не так удобно это всё делать, лучше, на мой взгляд делать это корутиной c yield return new WaitForEndOfFrame();
Там уже зависит от того, как работать, но к примеру, я сейчас написал для Texture такой экстеншн метод GetTexture2D, и как пример использования, небольшой класс, который позволяет делать скриншоты с вебки.
Но скажем с отражающими поверхностями такого решения достичь этими средствами уже не получится (либо это будет сложнее). Хотя в целом сейчас для обработки отражения нужно определять, какая поверхность отражает, и проецировать по отражённому лучу на неотражающую поверхность. Что опять таки, не такая сложная доработка.
В плане умрут в той реализации, которая в статье? Если в сцене по какой-то причине будет два синглтона, то как определить какой из них правильный? И какой из них удалится? Просто реализацию из статьи я видел в майкрософтовской библиотеке Holotoolkit (если его не обновили) и ничего там не удаляется, просто второй инстанс бесцельно висит, так как он никогда не вызывается.
Может быть в некоторых случаях соглашусь, хотя у меня получалось выстраивать архитектуру так, чтобы синглтоны по сути вызывались в монобехах, но сами монобехами не являлись. Просто по сути получалось вроде того, что синглтоны у меня выполняли роль «модели» (правильнее сказать они управляли моделью), а монобехи — это «отображение+контроллер», и в них синглтоны как-то не требовались.
Я и имел ввиду, что знание особенностей платформы — это главное. Фанатизм — это плохо что в одну, что в другую сторону. Использовать хорошую практику для конкретной платформы/технологии — понятное дело лучше, чем не использовать. Просто не надо уходить в крайности «ради идеи». Конечная цель всё-таки в любом случае получить стабильно и хорошо работающую программу, и хороший поддерживаемый код. Если при этом там будет плохой приём, который не влияет на производительность и читаемость, то не надо с пеной у рта избивать программистов за их незнание особенностей платформы. Программисты вообще не любят когда их бьют :)
А за статью спасибо — почитаю :)
Если проходить форичем на эвейке какого-то одного объекта, то в целом конечно же +- плевать, но если мы работаем с коллекцией по которой можно пройтись через for, то почему бы не юзать его? Можно вообще охотится на бесов, и так как мы в юнити чаще всего живём в однопоточном мире, если мы знаем, что внутри цикла не меняется количество элементов коллекции, кешировать заранее Count, так как насколько мы помним у нас в пропертях ничего не инлайнится.
Я просто уже, если честно, потерял цель вашего спора. Излишняя оптимизация — это плохо, так как чаще всего её придётся переделывать, но если мы знаем, что в юнити на данный момент for работает лучше, чем foreach, то зачем использовать foreach? Конечно же никто не запрещает, и если очень хочется — пользуйтесь. Просто это не лучшая практика, при этом решение через for занимает всего на несколько символов больше.
Просто не надо уходить в крайности. Ещё можно похоливарить на тему того, что по хорошему можно обойтись без List, и он работает медленнее, чем массивы, так что давайте везде юзать массивы. Ребята — давайте жить дружно. Есть места где та или иная вещь критична, есть где в целом всё равно, а есть где по-другому нельзя. Зачем что-то выводить в уровень абсолюта?
Не юзать foreach там, где он не обязателен с тем, как это работает в юнити — в сущности неплохой совет. Просто ещё стоит уточнить, что не надо его избегать, как огня, и если скажем поиск по коллекции вы вызываете в апдейте, а проходите по каждому элементу коллекции в эвейке (я думаю, что можно придумать такую ситуацию, где в начале мы скажем очищаем состояние элементов, а после ищем особенные), то не нужно городить костыли, а нужно взять хешсет и ходить по нему форичем, так как хешсет на поиск нам даст О(1).
Просто если вы знаете, что форичи аллоцируют лишнего в юнити и заставляют GC запускаться чаще — вот это уже хорошо. Так как если возникнет проблема, что игра по какой-то причине фризится, то вы знаете где это можно искать, а это главное.
А про комменты тоже не соглашусь, в они часто бывают полезны, так как если скажем в коде реализован сложный алгоритм (тот же волновой алгоритм поиска пути или же алгоритм триангуляции невыпуклого контура), то не каждый с ходу их сможет узнать, и был бы полезен коммент, что тут именно происходит, чтобы не лезть в документацию лишний раз. Да, и в ряде случаев люди мыслят немного по разному и нейминг, который одному человеку кажется очевидным для другого не так очевиден.
1. В каком смысле не использовать свойства? Какие свойства? Если имеется ввиду в своих классах, то допустим нам нужна инкапсуляция. Вопрос, в чём отличие свойства от геттера и сеттера реализованных методами?
2. Про GetComponent<> вообще отдельный разговор, я не совсем понимаю зачем его использовать в принципе. Это конечно, наверное, ускоряет работу (хотя я считаю, что это банальная лень программистов), но в большинстве случаев можно обойтись вообще без него. Т.е. компоненты, которые висят на объекте всегда, можно просто сериализовать. А те объекты, которые цепляются динамически откуда-то можно хранить пуллом в скрипте, в котором они цепляются и обращаться с этим (точнее говоря это по разному можно решать)
4. Опасно, так как вроде Vector3 не иммутабелен (поэтому его геттер и сделан через new), и если кто-то случайно в коде натупит (случайно или по невнимательности), то такую ошибку очень тяжело найти (а точнее понять в чём именно ошибка). Соглашусь, что надо кешировать и т. п., и что случай редкий, но тем не менее я бы кешировал внутри класса, где это используется. (Допустим, кто-то вызовет метод Scale или уж совсем непонятно зачем — Set)
5. А как же StringBuilder?
С этим я просто не согласен, читабельность можно сохранить при правильных подходах если не торопиться. В крайнем случае решается это комментарием, что делает эта магическая строка.
И очень не хватает картинок