Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Ссылку на игру можно? Например в личку, чтобы не сочли за рекламу. Интересно все же.
А как с производительностью по сравнению с нативной разработкой на плюсах? Каких хоть порядков различия?
Коротко ответить на этот вопрос невозможно, слишком много различных факторов надо принимать во внимание.
Это зависит от того что меряете, относительно чего, как построена архитектура приложения, как используется скриптовый движок, как сделан биндинг, какие технологии используется в игре и как они используются итд итп. Если всё сделать грамотно, то просадки производительности заметно не будет.
Такие вопросы часто возникают при обсуждении скриптования в геймдеве и показывают, к сожалению, что до всеобщего понимания целей и задач скриптования ещё довольно далеко. Начать хотя бы с того, что при использовании скриптов никто не ставит цель рассчитывать в них сложные и тяжелые алгоритмы (понятно что это глупость), соответственно классическое влобное сравнение производительности теряет смысл в виду множества факторов (более важных).
Собственно вопрос уже давно нужно ставить не как «падает производительность или не падает», а «как мне использовать правильно встраиваемые скриптовые языки так, чтобы не падала производительность».
Понятно, что здесь я произнес общие слова и в каждой конкретной игре есть свои особенности. Может, в некой игре X скрипты не нужны совсем и можно обойтись грамотно спроектированными данными.
Сравнивать (может быть) имеет смысл два скриптовых языка, например Lua и Javascript, но и то не по скорости, а скорее по удобству биндинга, управлению памятью, гарантированному объему памяти которую потребляет интерпретатор и всему такому.
Это зависит от того что меряете, относительно чего, как построена архитектура приложения, как используется скриптовый движок, как сделан биндинг, какие технологии используется в игре и как они используются итд итп. Если всё сделать грамотно, то просадки производительности заметно не будет.
Такие вопросы часто возникают при обсуждении скриптования в геймдеве и показывают, к сожалению, что до всеобщего понимания целей и задач скриптования ещё довольно далеко. Начать хотя бы с того, что при использовании скриптов никто не ставит цель рассчитывать в них сложные и тяжелые алгоритмы (понятно что это глупость), соответственно классическое влобное сравнение производительности теряет смысл в виду множества факторов (более важных).
Собственно вопрос уже давно нужно ставить не как «падает производительность или не падает», а «как мне использовать правильно встраиваемые скриптовые языки так, чтобы не падала производительность».
Понятно, что здесь я произнес общие слова и в каждой конкретной игре есть свои особенности. Может, в некой игре X скрипты не нужны совсем и можно обойтись грамотно спроектированными данными.
Сравнивать (может быть) имеет смысл два скриптовых языка, например Lua и Javascript, но и то не по скорости, а скорее по удобству биндинга, управлению памятью, гарантированному объему памяти которую потребляет интерпретатор и всему такому.
Остальная часть рекламной компании прошла без затрат денежных средств и заключалась в рассылке пресс-релизов к редакторам интернет-изданий про iOS/Android
Можно ли как-то получить mail list редакторов изданий?
Можно в личку.
А Вы не сталкивались с механизмом как защититься от LocallAPStore и т.п.?
Поздравляю с релизом! А как осуществлялась поддержка разных aspect ratios?
В cocos'e при разработке используются свои единицы измерения, задаваемые разработчиком — designResolutionSize. В нашем случае мы выставили размер по умолчанию 1024х768 (под ipad), и определили что ширина может варьироваться в зависимости от соотношения сторон девайсов (FIXED_HEIGHT). Таким образом, на «длинных» девайсах мы могли получить размер 1400х768. Также при дизайне интерфейсов в CocosBuilder'е есть возможность позиционировать элементы относительно различных углов (отступ от правого края 100, сверху 50). Подробнее можно почитать здесь.
А не поделитесь конкретными данными по Facebook Mobile Ads? Какой был таргетинг (конкретные «интересы», возраст, пол, версия ОС, и т.д.)? Какая в итоге получалась «потенциальная аудитория»? Какая получилась самая лучшая цена за инсталл (и на каком таргетинге)? А CTR? Оплату ставили Optimized CPM или колдовали с bid'ом вручную? Были ли какие-то технические проблемы, зависания? И про бюджеты конкретные было бы очень интересно узнать, но не настаиваю, конечно.
Просто мы сейчас активно экспериментируем с этим добром и иногда получаются очень хорошие результаты, но обычно их не удается повторить.
Просто мы сейчас активно экспериментируем с этим добром и иногда получаются очень хорошие результаты, но обычно их не удается повторить.
Конкретно по таргетингу: возраст аудитории 18 — 37 лет, пол любой, из глобальных категорий мы выделили людей, пользователей iOS устройств начиная с iOS 5 версии, (не затрагивая Android), интересующихся играми, соц.играми, в частности мобильными играми, apple store, головломками, аркадами итд. Из языков только анлийский. Всегда выбирали Optimized CPM. Технических проблем не наблюдалось, компания запускалась и работала строго по времени. При этом охват аудитории получился где-то 6млн. человек, что, подводя итоги, мы считаем крайне большой цифрой при выбранном нами бюджете. Действительно много зависит от тонкости настроек. К примеру, для нашего прерыдущего проекта, использование такого же бюджета, но для аудитории примерно в 10 раз меньше (для России) полностью себя оправдало.
общем, конечно, интересно… но по сути пост ни о чем — кроме перечня использованных инструментов собственно и читать не о чем, увы.
Понятное дело, но не будет же автор писать здесь все подробности разработки… На изучение всего этого, лично у меня, ушло около 2х лет. Тут одной статьёй не обойдешься… Но перечень инструментов — очень полезная штука, новичкам будет полезно знать в какую сторону «копать». И при этом примерно оценить время на изучение и практический опыт…
Интересно, какое планируемое соотношение бюджета проекта — разработка/маркетинг? Есть ли у вас метрика «успешности» или точки безубыточности проекта?
Расскажите, сталкивались ли вы с какими-то трудностями при портации в Eclipse? С помощью каких инструментов отлаживали и как проверяли на утечки? Недавно тоже озадачилась проблемой портации, Eclipse показался мне очень криворукой системой. Отсутствие встроенного дебагинга для cpp-кода меня вообще поставило в тупик. Может это я как-то не разобралась с системой? Очень бы хотелось узнать ваше мнение насчет связки Eclipse+Cocos2dX, насколько там удобна и возможна отладка проектов? Может вы рассматривали какие-то альтернативы типа VisualGDB.
Вообще лучше отлаживать в XCode. Там есть инструменты для отладки по поиску утечек и еще много интересного и полезного… Но я сталкивался с некоторыми проблемами во время поиска багов, а именно: некоторые баги никак не проявляются когда проект собран и работает под iOS, вплоть до выхода за границы массива… Естественно когда собираешь этот проект в Eclipse, после запуска приложение падает. Если при этом она успевает выдать дамп, и стек вызовов, где произошло исключение, то это еще пол беды… Но иногда программа тихо падает и в ANT ничего полезного не выдает… В этом случае мне очень помогла сборка проекта под Windows Phone, все баги в коде были найдены и успешно устранены… Во время запуска приложения в среде Visual Studio, если оно падает, то очень хорошо видно где это произошло и есть много шансов найти причину…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт создания кроссплатформенной игры (iOS/Android)