среди ios разработчиков есть встроенные штуки для локализации в виде разных файликов <ключ=значение>, которое конвертируется в хэшмап. на юнити такое же сделать — дело одного дня максимум, даже с эдитором для непрограммистов. если лень, то можно купить за 20 баксов. Это будет работать быстрее и проще, чем грузить еще одну либу.
Две недели тому назад занимался оптимизацией сцены, уменьшил с 200dc до 95(мобильная разработка).
Когда прочитал о 40k dc, чуть не поперхнулся. И как 10 домов может занимать 4-5 тысяч dc? Почему не пользовались MeshBaker-ом?
Дык чем юнити программисты хуже? Присоединяйтесь ко мне — я как раз в свободное от работы время пилю для юнити мелкие плагины для себя. Как раз задумываюсь «а не сделать ли интересную игру- убивалку времени?
Ну вообще-то это не совсем верно. Доступ можно получить (более того, с помощью маршаллинга вполне уютно можно писать на плюсах).
Другая проблема заключается в том, что не всегда успеваешь сохранить ссылки на текстуры при паузе приложения — activity сбрасывает текстуры раньше, чем успеваешь их куда-либо записать.
Если не ошибаюсь, то про использование простого числа как основание хэша написал Дональд Кнут в третьем томе(про сортировку и поиск вроде как) и это не является какой-то магией.
У меня такое ощущение, что на первой странице Test your vocab вычисляется диапазон словарного запаса(там идут общие слова), а на второй странице уже этот диапазон уточняется. Если провально отметить первую страницу, вторая страница уже не поможет.
3) синглтон на то и синглтон, что у него ленивая инициализация и он всегда обязан существовать во время вызова. ну и синглтон все же отличается от статик класса
5) это я понял, даже так делал. пока не начал портировать все на android-ы. Во-первых, там размеры экранов могут быть совершенно разные, но самое фиговое — это разные пропорции. При вашем случае получается несколько проблем:
а) скейл вверх — портит картинку именно качество
б)пиксел-перфект тупо пропадет (из-за разных пропорций).
ща по поводу 2d: давайте определимся с тем, что нужно и как это делать.
1) 90% всех touchable элементов делается кругами или прямоугольниками — тут все просто.
2) 5 из 10% оставшихся элементов можно привести к кругам или прямоугольникам.
3) при остальных пяти процентах случаев(а это должно быть, реально тяжелый полигон, раз нельзя его привести к первым двум случаям) реально быстрее проверить через физику.
это во-первых, теор.часть. Во-вторых, Вас никто не заставляет писать это все руками, уже давно есть 2d фреймворки, где все уже давно сделано за Вас. К примеру, в NGUI проверка проходит через физику, если нужно сделать дополнительный рект, то просто увеличиваешь коллайдер.
В EZGUI же происходит сортировка по глубине.
И не надо писать собственный контроллер тачей, подписчиков событий.
Мне кажется, что наше обсуждение больше переходит в холливар. Предлагаю перейти в личку.
Да, про трансформы затупил, согласен. Но другие замечания кажутся вполне в тему.При этом почти не затронуты другие, мне кажется, более ресурсоемкие и важные, вопросы оптимизации(к примеру, рендеринг и вообще 3d). Если Вам кажется, что это не так, давайте обсудим.
Просто считаю некоторые пункты поста вредными для прочтения и выполнения новичкам(про разные разрешения экранов, про polygon crossing и т.д.).
[captain_mode]Нулевым правилом для начинающих я бы отметил умение гуглить и находить наилучшее готовое решение, а не бросаться писать все руками.[/captain_mode]
Я помню, как после полугода писания на Unity у меня была мания написания собственных крутых штук под все и вся. Как только появлялась какая-то объемная задача, я уже начинал пилить свою универсальную систему велосипеда. Уже только после нескольких таких систем осознал, что намного лучше по времени разработки и производительности найти/купить уже готовое решение, чем делать самому. Даже сожалею, что никто меня не одергивал и не говорил, что так делать не надо.
Замечания будут, причем их довольно много. Но основной смысл моего комментария - хватит писать собственные велосипеды и начать юзать готовые плагины/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 можно много чего интересного рассказать, может быть в будущем напишу топик, почему его стоит избегать или в каких случаях его можно применять, а в каких — нет.
Как-то длинно и сумбурно написал, извините. Прямо крик души.
А так, sqlite может использоваться как база данных внутри игрушки(если там сложная логика и нужно хранить кучу данных). Проверено, работает шустро.
Когда прочитал о 40k dc, чуть не поперхнулся. И как 10 домов может занимать 4-5 тысяч dc? Почему не пользовались MeshBaker-ом?
Другая проблема заключается в том, что не всегда успеваешь сохранить ссылки на текстуры при паузе приложения — activity сбрасывает текстуры раньше, чем успеваешь их куда-либо записать.
Проще было с помощью студ. билета: я просто отсканировал студенческий и отправил реквест — меня заапрувили.
Поскольку универскую почту система не приняла, я написал почту в реквест, и они — внезапно — прислали ключ в письме.
5) это я понял, даже так делал. пока не начал портировать все на android-ы. Во-первых, там размеры экранов могут быть совершенно разные, но самое фиговое — это разные пропорции. При вашем случае получается несколько проблем:
а) скейл вверх — портит картинку именно качество
б)пиксел-перфект тупо пропадет (из-за разных пропорций).
ща по поводу 2d: давайте определимся с тем, что нужно и как это делать.
1) 90% всех touchable элементов делается кругами или прямоугольниками — тут все просто.
2) 5 из 10% оставшихся элементов можно привести к кругам или прямоугольникам.
3) при остальных пяти процентах случаев(а это должно быть, реально тяжелый полигон, раз нельзя его привести к первым двум случаям) реально быстрее проверить через физику.
это во-первых, теор.часть. Во-вторых, Вас никто не заставляет писать это все руками, уже давно есть 2d фреймворки, где все уже давно сделано за Вас. К примеру, в NGUI проверка проходит через физику, если нужно сделать дополнительный рект, то просто увеличиваешь коллайдер.
В EZGUI же происходит сортировка по глубине.
И не надо писать собственный контроллер тачей, подписчиков событий.
Мне кажется, что наше обсуждение больше переходит в холливар. Предлагаю перейти в личку.
Просто считаю некоторые пункты поста вредными для прочтения и выполнения новичкам(про разные разрешения экранов, про polygon crossing и т.д.).
[captain_mode]Нулевым правилом для начинающих я бы отметил умение гуглить и находить наилучшее готовое решение, а не бросаться писать все руками.[/captain_mode]
Я помню, как после полугода писания на Unity у меня была мания написания собственных крутых штук под все и вся. Как только появлялась какая-то объемная задача, я уже начинал пилить свою универсальную систему велосипеда. Уже только после нескольких таких систем осознал, что намного лучше по времени разработки и производительности найти/купить уже готовое решение, чем делать самому. Даже сожалею, что никто меня не одергивал и не говорил, что так делать не надо.
А теперь по пунктам:
Основы: 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 можно много чего интересного рассказать, может быть в будущем напишу топик, почему его стоит избегать или в каких случаях его можно применять, а в каких — нет.
Как-то длинно и сумбурно написал, извините. Прямо крик души.