Основные требования:

- уверенное владение ActionScript 3.0
- опыт разработки клиент-серверных приложений
- опыт разработки игр
- опыт командной разработки
- навыки проектирования архитектуры приложений

Будет плюсом:
- опыт работы с API социальных сетей
- опыт работы с физическими движками во flash
- опыт работы с Flex

Зарплата - от 60 до 90 тыс. р (по результатам собеседования)

Контакты:

e-mail: ilya[собака]digitalizm[точка]ru
тел.: +7 (916) 612 67 38
Илья

Еще в феврале ходили слухи о будущем jabber-мессенджере на AIR от Rambler, и сегодня началось его открытое тестирование. Поддержка самых различных сервисов общения - от Gtalk до MSN, делает Virtus универсальным средством общения, а кроссплатформенность и удобные сервисы, такие как переводчик и функционал по отправке электронной почты прямо из мессенджера придают еще большое очарование.

P. S. А еще есть надежда на увеличение благодаря этому install base у Adobe AIR, что совсем не лишне для RIA-разработчиков

I. Flash

Alternativa3D обосновалась на приличных размеров стенде:

Народ проявлял интерес, в беседах с участниками ярмарки проектов выяснилось, что потенциальные клиенты здесь имеются. Например, разработчики Города Дорог.

Интерес к flash играм у казуальщиков есть, но выражен не слишком ярко. Такие проекты, как Город Игр (НевоСофт), служат скорее экспериментальными площадками. Но опять же, это означает готовность игроков не-flash казуального рынка быстро перестроиться.

Но не PC единым силен flash, и проявил он свою силу на Xbox 360. Тот факт, что с помощью специального middleware(стоимостью порядка 10 000 долларов) можно заставить работать AS2 на Xbox, стал для меня новостью. Работе с “чудесным” ActionScript/C++ гибридом Interpol, а точнее переносу его на Wii и PSN был посвящен соответствующий доклад. Классическая point-and-click игра на 33 локации. Как ее можно растянуть на 600 классов и 160 тысяч строк кода, трудно представить, но создателям это удалось. Кроме того, в наличии имелось 80 000 строк дублированного кода, множество неявных связей (”мы немного изменили длину эффекта - и у нас отвалилась отправка очков в интернет”), завязанность на несколько нижележащих движков…

Отладка происходила только трейсами, распиханными повсюду и генерирующими логи в сотню мегабайт, а для распечатки диаграммы классов, по словам докладчика, подошли бы “только обои”. Кстати, флешер был отделен в списке команды как “скриптер”, отдельно от “программистов”, хотя, на мой взгляд, вполне можно было объединить. Вывод для себя я сделал простой: не нужно пытаться везде и всюду портировать flash “as is”, даже если это в теории возможно.

II. Silverlight

По сильверлайту был один с небольшим доклад: немного в докладе про монетизацию и отдельный доклад о разработке казуалок. В докладе про монетизацию порадовало, что, в отличие от Flash Gamm, про Miniclip как место, где есть silverlight контент, было упомянуто. Ну и все тот же SilverArcade как хостинг Silverlight игр. Хотя, не упомянутый в докладе Mashooo на мой взгляд даже поинтереснее для разработчика. Доклад про игры на Silverlight был, к счастью, намного интереснее своего Flash Gamm аналога, так как о всеми любимом Бибигоше рассказывал сам разработчик, а потому упоминались не только положительные аспекты разработки:) Кстати, я либо пропустил, либо не слышал о факте аутсорсинга части игр, что означает, что российское комьюнити разработчиков игр на Silverlight будет расти как минимум засчет этого. Единственная очень странная вещь: были жирно выделены новые фичи 3го сильверлайт, а о среде разработки (Expression Blend) говорилось только о 2ой, хотя Blend 3 Preview появился вместе с бетой третьего сильверлайта и также содержит серьезные улучшения.

III. XNA

Всем приводится в пример Shizoid (приятная действительно игрушка, кстати) как XNA-разработка, но то что миграций XNA->XBLA  нет, не радует (хотя, судя по описаниям в блогах, процесс приема в XBLA долгий и мучительный, и ничего удивительного в этом факте нет). Так как сравнение статистики скачиваний и прибылей показывает существенную разницу доходов. Хотя, возможно, это и не так страшно, так как на XBLCG (Xbox Live Community Games) пускают такой треш, что выделиться там легче. Ничего нового на тему нормальной поддержки в России нет, как обычно предлагается регистрировать аккаунт в США или другой поддерживаемой стране. Но засчет того, что некоторые из Community игр за последний год оказались довольно успешными, инди-разработчик под XNA стал реальным явлением

Кроме того, опять же упоминалась о планах мнедрения маркетинговых возможностей для XNA-игр за дополнительный %, опять же было сказано о выборке Community игр от IGN. Из интересного относительно путей маркетинга не был упомянут XNplay, куда можно предложить игру на рецензирование. Ресурс кстати позволяет оценить качество XNA игр в общем. А самое странное - полное отсутствие каких-либо упоминаний о DreamBuildPlay, где еще вполне можно успеть поучаствовать, и заодно получить бесплатный trial-аккаунт, дающий возможность запускать игры на xbox 360. И Россия там допускается к участию вполне легально:)

Техническая часть доклада про программирование на XNA произвела странное впечатление. С одной стороны, с учетом отсутствия нормальной литературы по XNA на русском языке о компонентной архитектуре, возможностях матекатики и т п в принципе полезно рассказать, с другой радостные слайды с перечисленными полями/методами классов Vector и Matrix и бодро-радостным озвучиванием их количестве - это странно. Меня не волнует, у кого 48 методов, а у кого 32, ни капельки:) В принципе я надеялся на большее, но кучу кубиков показали, изику показали, модель приложения и принцип пайплайна обьяснили - для вводного доклада это вполне приемлимо, а для большего все равно без литературы не обойтись (кстати, есть очень хорошая книга от O-Reilly (на английском)).

Для полного счастья нужна команда российских разработчиков, сделавшая полноценный XNA-продукт, так как именно такие люди могут рассказать больше всего интересного. Пока таковой, судя по всему, не имеется, поэтому то, что было - лучшее, что можно было сделать/рассказать. И получилось вполне неплохо.

Сравнения. В виде скринов BubbleMark годичной давности, актуальных для Flash 9 и Silverlight 2. Искренне хочется верить, что Microsoft так занят улучшением своих технологий и поддержкой разработчиков, что даже времени снять свежие скриншоты не остается:) И, собственно, все. Серьезных сравнений больше никаких не было, хотя по 3ему (и даже 2ому) сильверлайту есть что сказать, и именно в геймдеве некоторый перекос его возможностей срабатывает лучше всего. Это было бы нормально для доклада начального уровня, ориентированного на неспециализированную аудиторию, однако на Flash Gamm большинство - люди, уже определившиеся с платформой и активно ее использующие, и им надо не просто показывать простейшие вещи, но и рассказать о вкусностях, которые дадут стимул хотя бы попробовать применить технологию в реальной жизни.

Приятным аспектом был учет вопроса “а куда потом созданное девать”, но и тут дело ограничилось упоминанием SilverArcade, работающему недавно и имеющему низкую посещаемость (ура, за неделю с моего последнего посещения одна игрушка все-таки перевалила за 1000 игр), и, что важно, низкое качество большинства игр в графической части. И это при наличии достойных примеров и поддержки сильверлайта miniclip-ом (где, например, есть вполне приличная игрушка про бобров в стиле Portal).

Показ Blend-а большей частью свелся к издевательствам над растровым изображением божьей коровки, но это и к лучшему, так как ковыряние и попытка сделать что-то в программе обычно относительно скучно - для такого есть скринкасты и туториалы.

Закончилось все рассказом про BizSpark,  но опять же обобщенным. Большинство софта там не представляет интереса для разработки игр, кроме Visual Studio и Blend. Про бету 3его Blend-а кстати не сказали ничего, а между тем наличие редактора кода делает его “вещью в себе”, вполне приемлимой для разработки приложения целиком.

В итоге впечатление двоякое. С одной стороны, Microsoft проявляет активность, и обращается к правильной аудитории. Однако содержимое этого обращения до сих пор направлено непонятно на кого, особенности аудитории не были использованы в полной мере, часть данных несколько устарело, преимущества не раскрыты. Надеюсь, на следующей подобной конференции эта тема станет больше и глубже, и статистика и позитивный опыт в сфере геймдева будут ярче освещены.

P. S. А то сколько же можно показывать Бибигошу как единственный пример большого проекта игровой направленности…

В случае массивов стандарт документирования имеется официально:

var myArray:Array/*of String*/;

Эта форма также поддерживается FlashDevelop (при ее использовании получаем автокомплит для элементов массива, что удобно). Кроме того, для mxml во Flex имеется метатег ArrayElementType, однако в чистых AS3 проектах без использования mxml он все равно не работает.

Однако массивами дело далеко не исчерпывается: для комфортной работы с кодом требуется информация о типах для Responder-ов, коллекций, в некоторых случаях  - информации о точном контракте у Function и т. п. В соответствии с этим при написании кода я проставляю дополнительные типы комментариев, характеризующих типы данных.

1) Коллекции, Dictionary

var features:ArrayCollection/*<String>*/;

var settings:Dictionary/*<String,XML>*/;

Для случая коллекций использование of выглядит неоправданным, так как массив и коллекция являются различными сущностями. Описание же в стиле дженериков Java выглядит очевидно, а также логично, в свете появления Vector с использующим угловые скобки синтаксисом.

2) тип Function

var mouseDownHandler:Function/*MouseEvent->void*/;

Функциональный тип описан по аналогии с haXe, где описание функций более полноценно. Для функций с одним входным аргументом такой вариант выглядит предельно логично, для случая нескольких входных аргументов вопрос усложняется (однако случаи, когда приходится подробно специфицировать функции с несколькими аргументами относительно редки). В этом случае можно следовать описанию типов в haXe (все аргументы и возвращаемый тип разделяются стрелками), либо использовать что-то свое. Вариант haXe для 2-3 аргументов все еще читаем, а в случае большего числа уже логичнее выносить описание функции в отдельный раздел в asDoc, так как inline комментарий станет слишком длинным, вне зависимости от используемого синтаксиса описания.

3) Уточнение типа

override public function doSomething(arg1:Object/*(MyType)*/,arg2:int):void{…}

В некоторых случаях приходится использовать в контракте функции более общий тип, несмотря на то, что в любом случае передаются объекты совершенно определенного типа. Такая ситуация часто возникает, например, когда производится override методов библиотеки, не подлежащей/не поддающейся изменению. В этом случае дополнительный комментарий позволит разработчику быстрее ориентироваться в коде.

4) Responder-ы

var sqlResponder:Responder/*<SQLResult->void,SQLError->void>*/;

Прямое следствие пунктов 1-2. Подобное описание responder-а позволяет избежать использования типа Object для обработки результатов выполнения асинхронных задач, что делает код более четким и читаемым.

Может показаться, что дополнительное комментирование  является лишней и ненужной работой, однако при работе с большим количеством кода наличие подобных уточнений позволяет получить необходимую информацию максимально быстро, что снижает количество отвлечений, и, соответственно, положительно сказывается на производительности.

Проще говоря, теперь as2/as3 разработчику нет необходимости знакомиться с haXe (хотя в случае с as3 языки крайне близки), так как наличествует готовый API. Из вкусного: работа с реестром, экспериментальная возможность записи видео(с использованием локально запущенного haxeVideo - медиасервера на соответствующем языке) и запуск сторонних приложений, организация API частично по аналогии с AIR. И, соответственно, расширяемость haXe-модулями под neko. С учетом того, что haXe, neko, ScreenWeaverHX и HippoHX являются опенсорсными решениями, свобода действий достаточно велика.

Минусы, конечно, тоже есть. Нет поддержки Linux, которая уже есть у AIR и, в ограниченном виде, у Zinc. Работа с буфером обмена и drag-n-drop представлена слабее AIR-ной, нет поддержки отображения HTML и PDF. Ну и традиционный для всех оболочек вопрос о правомерности редистрибьюции flash player-а, конечно.

Таким образом, в лице HippoHX имеем в наличии вполне пригодную для работы бесплатную оболочку, с режимом командной строки и GUI, которая может пригодиться flash-разработчику, в особенности из-за сочетания достаточного базового API и расширяемости на синтаксически близком к ActionScript языке.

1. Охват аудитории

Flash Lite в том или ином виде установлен на большинстве мобильных телефонов, выпущенных в последние годы. Собственно, как о чем-то серьезном можно говорить о Flash Lite 2.0/2.1/3.0/3.1, так как версии 1.x были малопригодны для сколько-нибудь серьезной разработки. Открытое распространение Flash Lite позволит Adobe еще больше расширить аудиторию, тем более что Flash Lite 3.1 наконец-то работает под Windows Mobile, а это серьезная доля рынка. JavaFX же на данный момент признаков свободного распространения не проявляет, а поддержка Windows Mobile только обещается. Кроме того, на данный момент устройств с поддержкой JavaFX Mobile, собственно говоря, нет.

2. Особенности языка, среда разработки

В процессе развития до версии 1.0 у JavaFX существенно менялся синтаксис, но итоговый результат стал довольно приятным для использования. Типизация через “:” делает JavaFX Script сильно похожим на ActionScript, так что перейти на использование этого языка флешерам будет нетрудно. Язык интересен отсутствием интерфейсов и поддержкой множественного наследования, которое реализовано, на мой взгляд, просто идеально. Если у наследуемых классов есть одноименные методы с разными сигнатурами - работает перегрузка метода. Если сигнатуры одинаковые и метод не вызывается - все нормально, а попытка его вызвать приведет к ошибке, если в явном виде - код даже не скомпилируется. Наличествует встроенный биндинг и синтаксический сахар в виде linq-подобных запросов (select и т п для объектов). Радости кончаются, когда приходится описывать графический интерфейс - нагромождение из вложенных описаний объектов довольно слабочитаемо. Тем более, что набросать компоненты на формочку пока нельзя - работает только отображение написанного вручную интерфейса. Единственной работающей средой разработки является NetBeans 6.5. В принципе, достаточно для кодирования. А более удобные средства для работы с графикой обещаны в середине 2009.

В стане Flash тоже не все идеально - хотя AS3 является мейнстримом, для разработки под мобильные устройства приходится переключаться на AS1/2. Правда. ситуация обещает исправиться к началу 2010 с появлением Flash Player 10 Mobile. Среда разработки опять же одна - Flash, которая хоть и отстает в сфере написания кода(что легко компенсируется использованием внешнего редактора при работе с FlashLite 2.1+), но значительно удобнее с точки зрения работы с графикой. Кроме того, хелп по мобильной версии выделен отдельно, в отличии от JavaFX, где даже в версии 1.1 не появилось профиля “mobile” в хелпе, а именно он используется при запуске на эмуляторе мобильника. Приходится использовать common. Таким образом, на стороне Flash преимущество, хотя и не подавляющее.

3. Интеграция с платформой

На данный момент, JavaFX не предоставляет по сути средств интеграции с телефоном. Flash Lite в этом смысле впереди: имеются средства для управления вибросигналом, получения информации о системе и т п.

Выводы: на данный момент, даже не учитывая выход Flash 10 для мобильных устройств в будущем, детище Macromedia/Adobe далеко впереди. Более того, скорость развития у Flash как минимум не меньше, чем у JavaFX - анонсирована поддержка Android и iPhone, запускается редистрибьюция плеера с приложениями и т п. Комьюнити разработчиков под Flash Lite достаточно велико, а число поддерживающих Adobe производителей больше, чем имеется у Sun. Таким образом, именно Flash, как мне видится, претендует на роль кроссплатформенной среды для мобильных RIA приложений, а JavaFX претендует скорее на более скромную нишу десктопно-мобильных виджетов с небогатым функционалом. Но жизнь покажет, и за развитием конкурирующей технологии нужно следить;)

Напомню, что Flash Lite 3 близок по функционалу к Flash Player 8, а версия 3.1 поддерживает новые форматы видео, совместимые с Flash Player 9.0.115.0+ на десктопном плеере.