Comments 19
Эммм… «Автор статьи не претендует на… правильность предложенных решений.»
Зачем делать рекомендации другим людям, если сами вы некомпетентны?
Зачем делать рекомендации другим людям, если сами вы некомпетентны?
Хостить код на гугл докс — месье знает толк в извращениях.
Соглашусь 2D Toolkit — очень полезный плагин, за 65 баксов экономишь очень много времени.
Баги есть (я лично нашёл несколько), но автор (Dinesh Kumar) правит быстро. Саппорт очень хорош, отвечает быстро (автор живёт в UK, то есть по их времени работает).
Так же хочу отметить плагины Prime31 — тоже полезны, хотя ценник завышен.
Баги есть (я лично нашёл несколько), но автор (Dinesh Kumar) правит быстро. Саппорт очень хорош, отвечает быстро (автор живёт в UK, то есть по их времени работает).
Так же хочу отметить плагины Prime31 — тоже полезны, хотя ценник завышен.
Вопрос автору — а зачем 2 камеры в 2Д? Поясните 4-ый пункт, просто мы одной обошлись, не понятно зачем усложнять.
Что касается PlayerPrefs — он тормозной на планшетах, вот есть быстрый вариант:
www.previewlabs.com/writing-playerprefs-fast/
перевод статьи тут:
www.v4siliy.ru/2012/08/%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%B0%D1%8F-%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-playerprefs/
Что касается PlayerPrefs — он тормозной на планшетах, вот есть быстрый вариант:
www.previewlabs.com/writing-playerprefs-fast/
перевод статьи тут:
www.v4siliy.ru/2012/08/%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%B0%D1%8F-%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-playerprefs/
Конечно, если сцена всегда влезает в камеру, и камера относительно сцены не двигается, а всегда находится, например в (0,0,0), можно обойтись и одной камерой. Можно обойтись одной камерой, и если всё двигается, а Вы все элементы меню повесили на какой-то один GameObject, но неудобно, про это всегда надо помнить, при написании скриптов, как-то связанных с GUI. Но потом, если Вы захотите, чтобы камера, например тряслась, а элементы меню нет, у Вас сложные выпадающие меню и так далее, то возможно будет плохо. Лучше, когда всё для GUI висит где-то в пространстве само по себе, GUI-камера, например в (0,0,0), и с миром игры GUI никак не связано.
Замечания будут, причем их довольно много. Но основной смысл моего комментария - хватит писать собственные велосипеды и начать юзать готовые плагины/extensionы. Потому что это не только в разы ускоряет разработку, но и отдаляет от множества собственноручных костылей-подпорок.
А теперь по пунктам:
Основы: 1) да, нужно читать про оптимизацию, юнитеки плохого не напишут, но не нужно бросаться оптимизировать все и вся — юзаем профайлер. Все знают, что является root of all evil.
2) не понял, зачем? В чем смысл? Нафига нужен кешер для трансформа, если трансформ все время будет меняться? Если просто хочется написать wrapper, то почему бы не сделать что-то типаhttp://pastebin.com/k7FFsV60. Такие врапперы уже вбиты в более-менее достойные плагины и юзаются по умолчанию.
3) можно было проще: используйте синглтон.
4) Как-то очевидно. Зачем тогда нужно несколько камер?
5) А вот так вот не надо делать. Круто, если мы пишем только под iOS, там пропорции экрана не меняются, там все клево. А что делать с зоопарком андроидов? При портировании на андроиды схватим немало проблем.
Чтобы все выглядело одинаково, мы применяем следующую технику: мы делаем текстуры заведомо больше, чем нужно, а потом скейлим вниз пропорционально, по высоте. То есть на более мелких экранах это будет выглядеть четко, не будет размытия и т.д. А чтоб не попасть на проблемы со слабыми девайсами, используем HD и SD текстурные карты, которые переключаем в рантайме. Также не забываем про привязку к краям экрана(Anchor, Placement, их по разному называют). И соответственно, нужно забыть про pixel-perfect. У кого есть более удобные методы, поделитесь плиз.
по поводу шрифтов и вообще 2d: ни в коем случае не использовать стандартные средства. Пока в юнитях не появился человеческий gui, это неудобно, при этом это энергозатратно. А если используется много спрайтов, то прощай производительность мобильных игр. Используйте EZ GUI, NGUI. Мне лично больше понравился NGUI, просто потому, что он легче настраивается и многое у него работает корректно из коробки. В ЕZ мне пришлось много писать системных компонентов.
Про пул объектов сказано все абсолютно верно. Отмечу, что нужно по максимуму избегать операций типа GameObject.Find, Shader.Find, GetComponent, SendMessage и производных от них. Это ОЧЕНЬ медленно. Намного лучше кешировать и обращаться напрямую.
DontDestroyOnLoad нужно использовать с опаской, потому что
а) его включают и забывают. А потом не понимают, куда теряются связи и прочие элементы. Обоснованное использование — это синглтоны.
б) Объект должен быть нетяжеловесным. Оптимизировать производительность таких элементов невозможно, потому что он всегда есть и всегда нужен.
Про TouchDispatcher, AccelerometerDispatcher и иже с ними: посмотрите, что есть на unity store! Зачем писать собственный велосипед, когда есть уже готовые, 99% рабочие компоненты? Тот же самый finger gestures стоит 10 баксов, а на разработке по-любому спасет несколько человеко-часов, а может быть и дней.
Про проверку пересечений, 2D — смотрим выше про NGUI, EZGUI. Но если уж так хочется написать собственную систему, то тут несколько моментов:
1) если объекты круглые или прямоугольные, попадание нужно проверять через Rectы или просто по пересечению окружностей.
2) если у нас сложные объекты, то быстрее проверять коллайдерами. Проверено. Ну а избегать пересечения нужно с помощью z-глубины.
про www можно много чего интересного рассказать, может быть в будущем напишу топик, почему его стоит избегать или в каких случаях его можно применять, а в каких — нет.
Как-то длинно и сумбурно написал, извините. Прямо крик души.
А теперь по пунктам:
Основы: 1) да, нужно читать про оптимизацию, юнитеки плохого не напишут, но не нужно бросаться оптимизировать все и вся — юзаем профайлер. Все знают, что является root of all evil.
2) не понял, зачем? В чем смысл? Нафига нужен кешер для трансформа, если трансформ все время будет меняться? Если просто хочется написать wrapper, то почему бы не сделать что-то типаhttp://pastebin.com/k7FFsV60. Такие врапперы уже вбиты в более-менее достойные плагины и юзаются по умолчанию.
3) можно было проще: используйте синглтон.
4) Как-то очевидно. Зачем тогда нужно несколько камер?
5) А вот так вот не надо делать. Круто, если мы пишем только под iOS, там пропорции экрана не меняются, там все клево. А что делать с зоопарком андроидов? При портировании на андроиды схватим немало проблем.
Чтобы все выглядело одинаково, мы применяем следующую технику: мы делаем текстуры заведомо больше, чем нужно, а потом скейлим вниз пропорционально, по высоте. То есть на более мелких экранах это будет выглядеть четко, не будет размытия и т.д. А чтоб не попасть на проблемы со слабыми девайсами, используем HD и SD текстурные карты, которые переключаем в рантайме. Также не забываем про привязку к краям экрана(Anchor, Placement, их по разному называют). И соответственно, нужно забыть про pixel-perfect. У кого есть более удобные методы, поделитесь плиз.
по поводу шрифтов и вообще 2d: ни в коем случае не использовать стандартные средства. Пока в юнитях не появился человеческий gui, это неудобно, при этом это энергозатратно. А если используется много спрайтов, то прощай производительность мобильных игр. Используйте EZ GUI, NGUI. Мне лично больше понравился NGUI, просто потому, что он легче настраивается и многое у него работает корректно из коробки. В ЕZ мне пришлось много писать системных компонентов.
Про пул объектов сказано все абсолютно верно. Отмечу, что нужно по максимуму избегать операций типа GameObject.Find, Shader.Find, GetComponent, SendMessage и производных от них. Это ОЧЕНЬ медленно. Намного лучше кешировать и обращаться напрямую.
DontDestroyOnLoad нужно использовать с опаской, потому что
а) его включают и забывают. А потом не понимают, куда теряются связи и прочие элементы. Обоснованное использование — это синглтоны.
б) Объект должен быть нетяжеловесным. Оптимизировать производительность таких элементов невозможно, потому что он всегда есть и всегда нужен.
Про TouchDispatcher, AccelerometerDispatcher и иже с ними: посмотрите, что есть на unity store! Зачем писать собственный велосипед, когда есть уже готовые, 99% рабочие компоненты? Тот же самый finger gestures стоит 10 баксов, а на разработке по-любому спасет несколько человеко-часов, а может быть и дней.
Про проверку пересечений, 2D — смотрим выше про NGUI, EZGUI. Но если уж так хочется написать собственную систему, то тут несколько моментов:
1) если объекты круглые или прямоугольные, попадание нужно проверять через Rectы или просто по пересечению окружностей.
2) если у нас сложные объекты, то быстрее проверять коллайдерами. Проверено. Ну а избегать пересечения нужно с помощью z-глубины.
про www можно много чего интересного рассказать, может быть в будущем напишу топик, почему его стоит избегать или в каких случаях его можно применять, а в каких — нет.
Как-то длинно и сумбурно написал, извините. Прямо крик души.
Кешировать transform надо потому, что когда вы пишите
gameObject.transformgameObject.GetComponent<Transform>()Крик души, это очень хорошо, но Вы совершенно невнимательно прочитали статью, и привели очень много замечаний не соответсвующих её содержанию.
Мне не понятно, как прочитав рекоммендации по оптимизации скриптов Вы не поняли, зачем кешировать transform и т.п.
Мне не понятно, как прочитав рекоммендации по оптимизации скриптов Вы не поняли, зачем кешировать transform и т.п.
Да, про трансформы затупил, согласен. Но другие замечания кажутся вполне в тему.При этом почти не затронуты другие, мне кажется, более ресурсоемкие и важные, вопросы оптимизации(к примеру, рендеринг и вообще 3d). Если Вам кажется, что это не так, давайте обсудим.
Просто считаю некоторые пункты поста вредными для прочтения и выполнения новичкам(про разные разрешения экранов, про polygon crossing и т.д.).
[captain_mode]Нулевым правилом для начинающих я бы отметил умение гуглить и находить наилучшее готовое решение, а не бросаться писать все руками.[/captain_mode]
Я помню, как после полугода писания на Unity у меня была мания написания собственных крутых штук под все и вся. Как только появлялась какая-то объемная задача, я уже начинал пилить свою универсальную систему велосипеда. Уже только после нескольких таких систем осознал, что намного лучше по времени разработки и производительности найти/купить уже готовое решение, чем делать самому. Даже сожалею, что никто меня не одергивал и не говорил, что так делать не надо.
Просто считаю некоторые пункты поста вредными для прочтения и выполнения новичкам(про разные разрешения экранов, про polygon crossing и т.д.).
[captain_mode]Нулевым правилом для начинающих я бы отметил умение гуглить и находить наилучшее готовое решение, а не бросаться писать все руками.[/captain_mode]
Я помню, как после полугода писания на Unity у меня была мания написания собственных крутых штук под все и вся. Как только появлялась какая-то объемная задача, я уже начинал пилить свою универсальную систему велосипеда. Уже только после нескольких таких систем осознал, что намного лучше по времени разработки и производительности найти/купить уже готовое решение, чем делать самому. Даже сожалею, что никто меня не одергивал и не говорил, что так делать не надо.
На самом деле очень приятно, что Вы критикуете.
Сейчас прокомментирую Ваш ответ весь по пунктам:
3)Не совсем ясно, чем синглтон проще чем, статик класс, и потом или он уничтожится при смене сцены, или надо делать его DontDestroyOnLoad.
4)Это неочевидно.
5)Под iOS пропорции экрана ещё как меняются от 4x3 до 16x9. Предлагается верстать всё PixelPerfect для iPad, для всех же других разрешений всё отмасштабируется, как нужно, само. Конечно, расположение объектов надо привязывать к краям экрана. Резиновую вёрстку никто не отменял. Т.е. поясню ещё раз: всё верстаем под размер 1024x768 полученные элементы будут PixelPerfect на iPad, на других же экранах всё отмасштабируется, но положение элементов надо вычислять.
Очень много трудоёмких операций) Например ActiveRecursively() (в unity 3). А ещё распаковка музыки в память.
Насчёт 2д, смотря какие задачи.
Во-первых, Вы всё же невнимательно прочитали, и да, простые объекты хорошо проверять по кругу, или прямоугольнику.
Во-вторых. Интересно, а как вы добьётесь без контроллера захвата тач события(swallow) и зададите используя только z-index, чтобы объект спереди перехватывал событие раньше, того, что сзади? А ещё: коллайдер у объекта маленький, а мы хотим дополнительный масштаб для тач событий, чтобы можно было пальцем попасть?
Ну и моё личное мнение с 2д, всё таки, надо работать как с 2д. Да и физика с обработкой тач никак не связана.
Для простых задач и лучи с коллайдерами сгодятся.
Про www, действительно, было бы интересно почитать.
Сейчас прокомментирую Ваш ответ весь по пунктам:
3)Не совсем ясно, чем синглтон проще чем, статик класс, и потом или он уничтожится при смене сцены, или надо делать его DontDestroyOnLoad.
4)Это неочевидно.
5)Под iOS пропорции экрана ещё как меняются от 4x3 до 16x9. Предлагается верстать всё PixelPerfect для iPad, для всех же других разрешений всё отмасштабируется, как нужно, само. Конечно, расположение объектов надо привязывать к краям экрана. Резиновую вёрстку никто не отменял. Т.е. поясню ещё раз: всё верстаем под размер 1024x768 полученные элементы будут PixelPerfect на iPad, на других же экранах всё отмасштабируется, но положение элементов надо вычислять.
Очень много трудоёмких операций) Например ActiveRecursively() (в unity 3). А ещё распаковка музыки в память.
Насчёт 2д, смотря какие задачи.
Во-первых, Вы всё же невнимательно прочитали, и да, простые объекты хорошо проверять по кругу, или прямоугольнику.
Во-вторых. Интересно, а как вы добьётесь без контроллера захвата тач события(swallow) и зададите используя только z-index, чтобы объект спереди перехватывал событие раньше, того, что сзади? А ещё: коллайдер у объекта маленький, а мы хотим дополнительный масштаб для тач событий, чтобы можно было пальцем попасть?
Ну и моё личное мнение с 2д, всё таки, надо работать как с 2д. Да и физика с обработкой тач никак не связана.
Для простых задач и лучи с коллайдерами сгодятся.
Про www, действительно, было бы интересно почитать.
3) синглтон на то и синглтон, что у него ленивая инициализация и он всегда обязан существовать во время вызова. ну и синглтон все же отличается от статик класса
5) это я понял, даже так делал. пока не начал портировать все на android-ы. Во-первых, там размеры экранов могут быть совершенно разные, но самое фиговое — это разные пропорции. При вашем случае получается несколько проблем:
а) скейл вверх — портит картинку именно качество
б)пиксел-перфект тупо пропадет (из-за разных пропорций).
ща по поводу 2d: давайте определимся с тем, что нужно и как это делать.
1) 90% всех touchable элементов делается кругами или прямоугольниками — тут все просто.
2) 5 из 10% оставшихся элементов можно привести к кругам или прямоугольникам.
3) при остальных пяти процентах случаев(а это должно быть, реально тяжелый полигон, раз нельзя его привести к первым двум случаям) реально быстрее проверить через физику.
это во-первых, теор.часть. Во-вторых, Вас никто не заставляет писать это все руками, уже давно есть 2d фреймворки, где все уже давно сделано за Вас. К примеру, в NGUI проверка проходит через физику, если нужно сделать дополнительный рект, то просто увеличиваешь коллайдер.
В EZGUI же происходит сортировка по глубине.
И не надо писать собственный контроллер тачей, подписчиков событий.
Мне кажется, что наше обсуждение больше переходит в холливар. Предлагаю перейти в личку.
5) это я понял, даже так делал. пока не начал портировать все на android-ы. Во-первых, там размеры экранов могут быть совершенно разные, но самое фиговое — это разные пропорции. При вашем случае получается несколько проблем:
а) скейл вверх — портит картинку именно качество
б)пиксел-перфект тупо пропадет (из-за разных пропорций).
ща по поводу 2d: давайте определимся с тем, что нужно и как это делать.
1) 90% всех touchable элементов делается кругами или прямоугольниками — тут все просто.
2) 5 из 10% оставшихся элементов можно привести к кругам или прямоугольникам.
3) при остальных пяти процентах случаев(а это должно быть, реально тяжелый полигон, раз нельзя его привести к первым двум случаям) реально быстрее проверить через физику.
это во-первых, теор.часть. Во-вторых, Вас никто не заставляет писать это все руками, уже давно есть 2d фреймворки, где все уже давно сделано за Вас. К примеру, в NGUI проверка проходит через физику, если нужно сделать дополнительный рект, то просто увеличиваешь коллайдер.
В EZGUI же происходит сортировка по глубине.
И не надо писать собственный контроллер тачей, подписчиков событий.
Мне кажется, что наше обсуждение больше переходит в холливар. Предлагаю перейти в личку.
посмотрите, что есть на unity store!
а как же спортивный интерес? ) бывает и самому хочется что-нибудь эдакое сделать
Думаю стоит добавить немного информации про плагины от Prime31, для реализации таких вещей как внутренние покупки а также быстрой интеграции социальных функций/рекламы/gamecenter и тд. очень упрощают жизнь и экономят уйму времени.
Отличная документация, поддержка, регулярные обновления. Используем уже в 3ем проекте и очень довольны.
Правда цены дороговаты но того стоят.
Отличная документация, поддержка, регулярные обновления. Используем уже в 3ем проекте и очень довольны.
Правда цены дороговаты но того стоят.
Какое-то слабо связанное множество советов.
Взяли что вспомнили и запихали в статью. Возможно, сами по себе они имеют смысл, но так как статья без цели, то и советы эти ни у кого в голове не отложатся.
И почему вдруг лишь tk2d? В Asset Store еще много хороших движков для 2d. И все они умеют все, что вы описали в статье.
Взяли что вспомнили и запихали в статью. Возможно, сами по себе они имеют смысл, но так как статья без цели, то и советы эти ни у кого в голове не отложатся.
И почему вдруг лишь tk2d? В Asset Store еще много хороших движков для 2d. И все они умеют все, что вы описали в статье.
Спасибо интересная статья! Небольшой комментарий, всё же от синглтонов я отказался бы, стоит использовать статические классы. Доступ к ним понятнее и храниться будет стеке, а не в куче. И ко всем господа, рекомендация Unity — страйтесь создавать значимые типы, а не классы.
Sign up to leave a comment.
Unity3d, в помощь начинающим