С другой стороны Яндекс могут интерпертировать, как компанию, сотрудничающую с Крымом и запретить американским компаниям пользоваться Яндексом, как площадкой.
Т.е. запрет не со стороны Яндекса, но со стороны правительства США по отношению к американским же компаниям
Поясните, каким образом вы сделали данный скриншот.
Я до сих пор вижу такую картинку и на maps.yandex.ru и на maps.yandex.com yadi.sk/i/jxlnLknNe3rbF
Если Яндекс выдает разную версию карты в зависимости от каких-то параметров, то это естественно меняет все дело. Но я бы хотел сперва сам в этом убедиться.
Это будет странно, потому что Яндекс единственный (из тех кого я знаю), кто отметил на карте спорные территории во время грузинского и крымского конфликов именно в соответствии с законами РФ
Пункт про предварительную оптимизацию очень неочевидный и больше зависит от опыта и квалификации.
Например, мы когда делали Shadow Snake, затачивали его строго под iPad и натянули игру на другие разрешения перед релизом за 2 дня. Вин!
Когда делали анимации — заводили под каждый анимированый спрайт отдельную текстуру (один или несколько стрипов анимации) — так было проще. В результате получили ощутимое количество нерационально использованного места в текстурах. По Draw Calls мы вписались в 20-30, но вот по размеру дистрибутива вышли в районе 70 Мб. Сейчас возникли проблемы с публикованием в Google Play, т.к. там свыше 50 Мб приходится гемороиться. Чудом вписались в 48 Мб путем сжатия всего чего только можно было сжать и ухудшения качества некоторых текстур, т.к. переделопачивать всю графику — слишком много работы. Теперь уже знаю, что это оптимизировать надо с самого начала. Фэйл!
Это описано где-то в доках Unity — такое вот странное поведение.
По второму пункту — Unity кроссплатформенный, С# — очень комфортный язык. Плюс, в Unity есть редактор.
Без базовых знаний 3D графики не обойтись в любом случае. Если сомневаетесь, какой движок выбрать, выберите любой и что-нибудь на нем сделайте — после этого будет проще движки выбирать :)
Я имею в виду всякие векторные анимации — все таки 3D дает возможность создавать любые, формы не зависимо от количества реально задействованных измерений.
Не, я не про стоимость движков, я про стоимость контента — трудозатрат очень много. В 2D «дешевле» идею выразить.
А еще в Unity удобно, конструировать сцены и настраивать параметры. Особенно, если не ты это делаешь :)
А у вас есть на Starling какие-нибудь проекты под iOS или Android. Мне интересно, как AIR шагнул в плане производительности. Почему-то в моем информационном поле AIR не попадаются упоминания как средство для разработки под телефоны. Помню, Corona мелькала, как хорошее решение для флешеров.
На Unity тоже были нюансы, например, для слабых девайсов ( iPhone 4 в их числе :) ) мы отключили один партикл-эффект, который просто в ноль убивал производительность.
Сейчас, я думаю, я бы так и поступил. 25$ — это небольшие деньги.
На момент написания проекта я знал об атласах и draw calls лишь в теории.
С другой стороны, я получил хороший опыт, и знаю теперь, как правильно организовать работу с ассетами. В следующих проектах я рассчитываю выйти за пределы использования обычных квадратных спрайтов — так можно создать более эффектную визуалку. Но такие возможности, как я знаю, никакие готовые движки не предлагают.
Изначально был взят курс на Unity. Как на зарекомендовавшую себя кроссплатформенную технологию. Примеры быстрых приложений на мобильниках под Unity были. Примеров на AIR не было, а наш опыт с запуском проекта, написанного на Flixel оказался негативным. Решение использовать Unity обосновано именно этим.
Кроме того, в C# у меня опыта на порядок больше, чем в ActionScript.
В 3D не целимся, т.к. дорого.
Т.е. изначально посыл был именно влезть в Юнити с использованием текущих ассетов.
AIR пробовали, когда он еще вроде версии 2 был. Не очень хорошо — на векторе вообще тормоза дикие, на растре лучше но не настолько. Брали проект на Flixel (ссылку не дам, гуглите по Star Navigator) и один в один его переводили — на iPhone 4 тормозило адово.
Сейчас вроде в AIR какие-то некст-ген компиляторы появились, может ситуация стала лучше :)
Изначально курс был взят на Unity, т.к. востребованная технология, и точится под платформы хорошо. Да и я по основному роду деятельности уже 5 лет с C# вожусь.
И мне очень нравится редактор в Unity, вернее то, что я могу заниматься кодом, а дизайном уровней, балансировкой, графикой — другие люди. Первый опыт на Flash у меня был с PushButton Engine — это как Юнити, но без редактора — просто ад какой-то.
ScriptableObject — он полегче чем MonoBehaviour и его можно сохранить в отдельный ассет. Т.е. не надо создавать префабы для этого дела, можно просто ссылаться на этот ассет.
Другими словами ScriptableObject — это свой тип ресурса.
Все равно у каждого проекта своя специфика. Я вот сам не люблю посты с простынями кода и код не читаю. Поэтому я хотел лишь дать направление — показать, что это возможно, куда копать и что использовать.
В Unity 4 напрочь развалился код, который создавал префабы — его надо переписывать. Кроме того после конвертации в Unity 4 внезапно появились глюки Mono, но правда они не исчезли, при откате на 3.5, поэтому тут вроде Unity 4 не виноват.
На деле работа со строками очень может даже стать узким местом, особенно при разборе текста — например парсером.
Из своего опыта скажу, разительно помогло «не создавать новых строк», т.е. везде где можно использовалась ссылка на оригинальный текст и передавались индексы начала и конца фрагмента.
Благо в .NET есть порядочно методов, которые работают именно с подстроками.
Дело в том, что такие подходы, особенно если это касается небольших Flash игр не выживают. Особенно когда дело касается игр. Игра, даже небольшая — это очень живой проект с динамичными изменениями и очень неопределенными требованиями — при дальнейшем развитии проекта и внедрении фич весь паттерн MVC начнет трещать по швам, т.к. фичи вдруг перестанут на него «натягиваться». Так зачем что-то сейчас проектировать. если оно в конечном итоге превратится в кашу.
Если все-таки хотите проектировать — обратите внимание на компонентный подход — обычно именно его используют при разработке игр, например, Unity 3D, PushButton Engine, да те же Аллоды: Онлайн.
Но компонентый подход не работает (да и любой абстрактный подход, тот же MVC) без редактора — инструмента, в котором можно быстро собрать запчасти в целое и настроить их — в этом офигенный плюс Unity 3D и провальный недостаток PushButton Engine — они обещали редактор, но так его и не сделали.
А еще лучше — взять обычный flixel и не заморачиваться
С другой стороны Яндекс могут интерпертировать, как компанию, сотрудничающую с Крымом и запретить американским компаниям пользоваться Яндексом, как площадкой.
Т.е. запрет не со стороны Яндекса, но со стороны правительства США по отношению к американским же компаниям
Я до сих пор вижу такую картинку и на maps.yandex.ru и на maps.yandex.com
yadi.sk/i/jxlnLknNe3rbF
Если Яндекс выдает разную версию карты в зависимости от каких-то параметров, то это естественно меняет все дело. Но я бы хотел сперва сам в этом убедиться.
Например, мы когда делали Shadow Snake, затачивали его строго под iPad и натянули игру на другие разрешения перед релизом за 2 дня. Вин!
Когда делали анимации — заводили под каждый анимированый спрайт отдельную текстуру (один или несколько стрипов анимации) — так было проще. В результате получили ощутимое количество нерационально использованного места в текстурах. По Draw Calls мы вписались в 20-30, но вот по размеру дистрибутива вышли в районе 70 Мб. Сейчас возникли проблемы с публикованием в Google Play, т.к. там свыше 50 Мб приходится гемороиться. Чудом вписались в 48 Мб путем сжатия всего чего только можно было сжать и ухудшения качества некоторых текстур, т.к. переделопачивать всю графику — слишком много работы. Теперь уже знаю, что это оптимизировать надо с самого начала. Фэйл!
По второму пункту — Unity кроссплатформенный, С# — очень комфортный язык. Плюс, в Unity есть редактор.
Без базовых знаний 3D графики не обойтись в любом случае. Если сомневаетесь, какой движок выбрать, выберите любой и что-нибудь на нем сделайте — после этого будет проще движки выбирать :)
А еще в Unity удобно, конструировать сцены и настраивать параметры. Особенно, если не ты это делаешь :)
А у вас есть на Starling какие-нибудь проекты под iOS или Android. Мне интересно, как AIR шагнул в плане производительности. Почему-то в моем информационном поле AIR не попадаются упоминания как средство для разработки под телефоны. Помню, Corona мелькала, как хорошее решение для флешеров.
На Unity тоже были нюансы, например, для слабых девайсов ( iPhone 4 в их числе :) ) мы отключили один партикл-эффект, который просто в ноль убивал производительность.
На момент написания проекта я знал об атласах и draw calls лишь в теории.
С другой стороны, я получил хороший опыт, и знаю теперь, как правильно организовать работу с ассетами. В следующих проектах я рассчитываю выйти за пределы использования обычных квадратных спрайтов — так можно создать более эффектную визуалку. Но такие возможности, как я знаю, никакие готовые движки не предлагают.
Кроме того, в C# у меня опыта на порядок больше, чем в ActionScript.
В 3D не целимся, т.к. дорого.
Т.е. изначально посыл был именно влезть в Юнити с использованием текущих ассетов.
Сейчас вроде в AIR какие-то некст-ген компиляторы появились, может ситуация стала лучше :)
Изначально курс был взят на Unity, т.к. востребованная технология, и точится под платформы хорошо. Да и я по основному роду деятельности уже 5 лет с C# вожусь.
И мне очень нравится редактор в Unity, вернее то, что я могу заниматься кодом, а дизайном уровней, балансировкой, графикой — другие люди. Первый опыт на Flash у меня был с PushButton Engine — это как Юнити, но без редактора — просто ад какой-то.
Другими словами ScriptableObject — это свой тип ресурса.
В Unity 4 напрочь развалился код, который создавал префабы — его надо переписывать. Кроме того после конвертации в Unity 4 внезапно появились глюки Mono, но правда они не исчезли, при откате на 3.5, поэтому тут вроде Unity 4 не виноват.
Из своего опыта скажу, разительно помогло «не создавать новых строк», т.е. везде где можно использовалась ссылка на оригинальный текст и передавались индексы начала и конца фрагмента.
Благо в .NET есть порядочно методов, которые работают именно с подстроками.
Дело в том, что такие подходы, особенно если это касается небольших Flash игр не выживают. Особенно когда дело касается игр. Игра, даже небольшая — это очень живой проект с динамичными изменениями и очень неопределенными требованиями — при дальнейшем развитии проекта и внедрении фич весь паттерн MVC начнет трещать по швам, т.к. фичи вдруг перестанут на него «натягиваться». Так зачем что-то сейчас проектировать. если оно в конечном итоге превратится в кашу.
Если все-таки хотите проектировать — обратите внимание на компонентный подход — обычно именно его используют при разработке игр, например, Unity 3D, PushButton Engine, да те же Аллоды: Онлайн.
Но компонентый подход не работает (да и любой абстрактный подход, тот же MVC) без редактора — инструмента, в котором можно быстро собрать запчасти в целое и настроить их — в этом офигенный плюс Unity 3D и провальный недостаток PushButton Engine — они обещали редактор, но так его и не сделали.
А еще лучше — взять обычный flixel и не заморачиваться
P.S.
Сорри, накипело
И обычно CompareAndExchange оказывается производительнее.
Т.е. никаких летящих пуль и т.д.