Cronvid Blog

Смотрю я на возможности новых 3D движков для мобильных устройств, на последние релизы игр от EAMobile и Gameloft, на спецификации анонсированного вчера HTC Flyer с процессором, работающим на частоте 1.5 ГГц и видеоускорителем Adreno 205 и прихожу к выводу, что 2011 год станет последним годом, когда команда из нескольких человек сможет сделать популярную мобильную игру.
По аналогии с Xbox Live Arcade и PC какие-то успешные игры инди разработчиков безусловно будут выходить, но задавать тон будут явно не они.

Читать далее…

Опасаюсь, что эта реклама – это лучшее, что можно ожидать от «Sony Ericsson Xperia Play». Читать далее…

Есть некоторый дуализм в работе с игровой графикой. С одной стороны почти все художники используют для своей работы хорошие мониторы с IPS матрицей или хотя бы с MVA/PVA. У мониторов отличная цветопередача, они откалиброваны и отправив изображение на печать на выходе получается та же самая картинка, что и на экране. И это логично. С другой стороны большая часть пользователей играют в игры на мониторах с TN матрицей. Они дешевые, более быстрые (!), у них часто интересный дизайн и классный голубой светодиодик, как индикатор питания. И это тоже логично.
Но есть и пострадавшие в этом царстве логики. Красивая кнопка с плавным градиентом вдруг становиться двухцветной, ненавязчивая подсветка выделенной строки становится совсем не навязчивой и сливается с фоном, разделительная линия между группами элементов исчезает за компанию с подсветкой, а игровой участок с безопасной водой притворяется коварной кислотной ловушкой.

HP ZR30W (IPS) и LG Flatron W1943SS (TN). Разница $1200

Как поступать в данной ситуации каждый разработчик решает сам. Я прогнулся под игроков. Часть графики я проверил на обычном мониторе у своих знакомых и переделал ее так, чтобы она выглядела у них максимально хорошо. Теперь, заканчивая очередной элемент, я выкладываю его в общую композицию, вижу его «бледность» и добавляю 10-15 процентов контраста. Но не все такие слабохарактерны как я, не все. Часть разработчиков явно считает, что красота требует жертв и жертвы – это пользователи с дешевыми мониторами.

Пользователь Focus проделал отличную работу и опубликовал на сайте Хабрахабр статью «Способы «защиты» flash-приложений». Статья суммирует все, что относиться к данной теме: в ней очень детально, с примерами, рассказывается обо всех возможных способах защиты вашей игры и даны ссылки на другие материалы по рассматриваемому вопросу.
Вывод из всего сказанного не меняется давно и справедлив не только для Flash приложений: «Если за исследование вашего SWF файла возьмётся профессионал, то, вероятно, он не остановится перед препятствиями и доведёт дело до конца [...]. Поэтому всегда здраво оценивайте свой вклад в защиту своих проектов – не тратьте на это слишком много времени и средств, если это того не стоит.»

MochiMedia опубликовала хорошую вводную статью о переносе Flash игр на платформу Android. Tips and Tricks When Developing Your Flash Game on Android. Статья, естественно, на аглийском языке.
Для более глубокого изучения вопроса стоит обратить внимание на блог автора статьи Terry Paton.

Не все можно масштабировать. Если игра сделана для разрешения 640×480, то сжав графику в два раза ее легко можно перенести на разрешение 320×240 используемое в смартфонах в 2009 году. Но вот перенести ее на современные устройства Nokia с разрешением 640×360 будет уже сложно. Решений два: уменьшить графику на 75%, получить разрешение 480×360 и появившиеся пустое место (160×360) закрыть заглушкой. Или же полностью переработать уровень и размещение элементов интерфейса, чтобы занять все пространство экрана.
Первый способ приводит к появлению “недоигр” и не имеет никакого смысла: при таком половинчатом портировании игра не получит популярности и есть риск не окупить затраты при достаточной насыщенности рынка. Второй способ забирает больше времени и денег.
Выбирая разрешение для игры я рассчитывал на возможность портировать ее на мобильную платформу, поэтому смотрел в первую очередь на разрешение популярных смартфонов. Закончив прототип игры я решил, что сделать его играбельным на экране размеров в 3-4 дюйма (не важно какое там при этом будет разрешение) будет очень сложно, поэтому переключил свое внимание со смартофнов на планшеты и вновь занялся выбором размера игрового поля.
Как видно из первоначально приведенного примера основная сложность не в разрешении экрана, а в соотношение его сторон. Наиболее часто используются соотношения 5:3 и 16:9. 5:3 используется в большинстве топовых смартфоноы, как уже продающихся, так и только анонсированных (разрешение 800×480). Это же соотношение используется в большинстве планшетов на операционной системе Android 2.x (разрешение 1024×600).
16:9 в основном продвигают Nokia и Motorola. Nokia пока не выбирается за разрешение 360×640, а вот Motorola экспериментирует с увеличением разрешения. Большая часть ее устройств имеют разрешение 480×854, но анонсированный на CES 2011 флагман Motorola Atrix 4G подымает разрешение до 960×540.
Пока непонятно, что будет с соотношением 16:10, которое будет использоваться в анонсированных планшетах на операционной системе Android 3.0. С одной стороны это соотношение становится все более популярным в телевизорах и мониторах, а с другой стороны, если на планшете нужно не только смотреть HDTV видео, то это соотношение менее удобно чем 4:3 у iPad.
Под катом таблица основных используемых сейчас пропорций экрана и разрешений.
Читать далее…

Рынок мобильных приложений быстро растет. В этом году он оценивается в 4 миллиарда долларов, и через два года предположительно вырастет до 27 миллиардов (оригинал на английском, русский перевод). Доход со среднего приложения при этом все равно падают, но речь не об этом. Читать далее…

Когда операционная система выглядит лучше чем многие коммерческие игры и тем более лучше чем большинство flash игр, то вера в светлое будущее как-то теряется.

Вот пара инструментов, которые я выбрал для себя и использую во время отладки игры.
Первое, это «Actionscript Performance Monitor» проект с открытым исходным кодом, который показывает в удобной форме FPS и расход памяти. В нем нет никакой магии, тот же подсчет FPS можно реализовать в пять строк, но со «Stats» это сделать еще проще. Достаточно добавить в проект строчку:

addChild( new Stats() );

Второе, инструмент для вывода отладочной информации. Какое-то простое событие, например, заход в функцию, можно отследить и с помощью стандартной команды AS trace(), но если нужно показывать постоянно обновляемую информацию, такую как координаты объекта, то тут нужно организовать вывод данных на экран.
Это опять же можно сделать массой различных способов, но мне больше всего понравился небольшой класс, написанный Джосем Хертом (Jos Hirth). Класс подключает маленький и контрастный, пиксельный шрифт. Если вывести им нужную информацию, то она не займет много места и будет отлично читаться не зависимо от того какой фон находится под ней.
Исходный код класса можно скачать в блоге автора.

Вместе с выходом SDK для iPhone OS 4.0 Apple внесла изменения в соглашение разработчика. Самым обсуждаемым пунктом там оказался пункт 3.3.1 в котором добавили список языков на котором может быть написана программа для iPhone. Это C, C++, и Objective-C.
Этот пункт в очередной раз останавливает быстрое портирование flash приложений на iPhone. Все текущие разработки, такие как Open-Plug, о котором я писал раньше, или Packager for iPhone, который должен был войти в релиз будущего Flash Professional CS5, теперь представляют не более чем академический интерес: они есть, они работают, но вот использовать их нельзя. Разработчки Open-Plug сейчас общаются с Apple, но надежды на успешный исход не много.
Вместе с тем для разработчиков middleware и, в первую очередь, для Adobe остается еще один путь для переноса flash приложений на iPhone – это препроцессор, когда AS код будет вначале переводиться в код Objective-C, а затем компилироваться стандартным компилятором Apple.
Это сложная задача, но вполне решаемая. И что хорошо – это то, что текущие наработки по кросс-компиляторам позволят ускорить ее решение.