Хоть у нас тут и не dtf, но вот публикуем первый постмортем игры (историю разработки, то есть, с прологом и эпилогом). Евгений Орешин, руководитель небольшой студии Join Game, на примере «Волшебного королевства» рассказал о том, каково делать социальный проект на html5 – технологии для наших нужд довольно спорной, но, как показала практика, вполне рабочей.

Вступление

Пару недель назад в социальной сети «ВКонтакте» мы запустили наш новый проект – «Волшебное Королевство». Это социальная игра, но не совсем простая. Основной целью проекта было – показать возможности современных технологий. Игра построена полностью на своём движке с использованием таких передовых технологий, как HTML5, Canvas и CSS 3.0. При этом сам проект был полностью готов меньше чем через 3 месяца с момента начала разработки. Одним из ключевых факторов явилось то, что нам нет нужды компилировать проект, как если бы мы использовали технологию Flash. Также мы сразу хотим подчеркнуть следующий момент: благодаря использованию HTML5 игрокам не требуется никаких дополнительных установок плеера (-ов) в браузере, т.е. игра получается максимально общедоступной для конечного пользователя. В какой-то мере нам приходиться быть первопроходцами, поскольку социальных игр с применением и HTML5 и CANVAS на данный момент практически нет. По этой причине, в продолжение статьи хотелось бы ознакомить Вас с некоторыми техническими нюансами и особенностями, с которыми мы столкнулись при разработке игры «Волшебное Королевство», и ее интеграции в социальную сеть.

Серверная часть

Нами был использован JavaScript движок Google V8 совместно с Node.js (Javascript Framework).

Если Вы сталкивались с веб-разработкой, то клиентский JavaScript Вы скорее всего знаете. А так как V8 представляет собой движок, абстрагированный от браузера, то благодаря Node.js мы можем использовать его как угодно на стороне сервера. По причине простоты написания бинарных модулей и наличия своей системы пакетов Node.js вырос довольно быстро, что также «вооружает» разработчика целым арсеналом различных средств для написания какого-либо продукта.

Сам код фактически пишется на одном языке, и периодически мы можем копировать, и вставлять фрагменты кода из клиента в сервер, наоборот, для обеспечения единообразия. Хотелось бы отметить следующий важный момент: код, который используется на обеих сторонах, не привязан к GUI. Это является обязательным требованием, поскольку зачем серверу заниматься в памяти рендерингом? И так как язык один, то мы используем схожую логику на сервере/клиенте, и одному человеку из команды не составляет труда подключиться к написанию другой части. Этот аспект очень ускоряет разработку проекта, поскольку делает разработчиков взаимозаменяемыми.

При этом мы всегда следим за выходами новых версий JavaScript движка V8 и Framework Node.js по одной простой причине: с каждой новой версией HTTP-клиент/сервер становится всё стабильнее, а это является опорой проекта.

Графический движок и его производительность

Для того, чтобы CANVAS работал быстро, мы всячески избегали тяжелых операций, таких как заливка контура и попиксельный обход. Соответственно, чтобы игра не тормозила, нужно использовать только самые простые операции композинга без использования масштабирования и заливок контура. Все, что можно себе позволить – это drawImage. Придерживаясь этих правил, мы получили высокую производительность в игре на большинстве платформ.

Также хотим отметить следующие моменты:

Кросс-доменный Ajax не подошел Internet Explorer 9.0 из-за настроек его безопасности, и нам пришлось использовать JSONP (JSON with padding).

Google Chrome Frame бесполезен «ВКонтакте», так как приложение работает в iframe и наследует режим рендеринга от родительского окна (window), и мы не можем заставить «ВКонтакте» добавить в html родительского окна специальные инструкции для включения Google Chrome Frame.

Opera, этот браузер продемонстрировал странное поведение при использовании js-замыканий для эмуляции наследования классов; для решения этой проблемы нам пришлось дожидаться новой версии «Оперы», и в дальнейшем проблема исчезла сама собой.

Потребление минимум трафика. Для этого мы реализовали асинхронную загрузку спрайтов, т.е. спрайты у нас подгружаются по мере надобности.

Совместимость с Internet Explorer 8.0. Чтобы обеспечить обратную совместимость со «старым» IE 8.0, мы использовали excanvas (excanvas.js).

Производительность на мобильных платформах. Очевидно, что для мобильных платформ характерны самые разные размеры экранов, разнообразие ориентаций, и по этим причинам мы планируем делать resize спрайтов прямо на клиенте, причем по мере надобности.

Особенности работы с CSS, мобильными платформами

При разработке HTML5 приложения мы ориентировались на использование последнего драфта спецификации HTML5, стремились использовать новые тэги, новую семантику, обеспечивать поддержку мобильных браузеров. Мы отказались от костылей и стремились использовать новые технологии по полной, так как изначально ориентировались только на современные браузеры (Chrome5,  FF4, Opera11, IE9). Казалось бы такой набор условий – рай для веб-разработчика. В реальности все оказалось несколько сложнее.

Кросс-браузерная и кросс-платформенная верстка не вызвала трудностей. Тем не менее, нам  приходилось постоянно находить компромисс между красотой и эффектностью приложения и его производительностью на мобильных платформах. Для увеличения быстродействия на мобильных платформах нам пришлось отказаться от прозрачности (transparency), теней у шрифтов и блочных элементов (text-shadow, box-shadow), градиентных заливок. Аппаратное ускорение на мобильных устройствах пока тоже не удалось использовать из-за нестабильности и существующих известных багов.

На «настольных» браузерах мы развернулись в полный рост. Использовали закругленные углы (border-radius), тени шрифтов и блочных элементов, прозрачность, css-спрайты, градиентные заливки для кнопок и бэкграундов. Для обратной (gracefull degradation) совместимости нам пришлось использовать совместно с последними CSS правилами те правила, которые были бы поняты предыдущими версиями браузеров (-moz-border-radius, -webkit-border-radius и т.д.). Для определения возможностей браузеров и поддерживаемых ими технологий мы использовали библиотеку modernizr.

Большой проблемой для нас стало использование типографики. Так как игра у нас стилизованная, то и шрифты мы хотели использовать соответствующие. Однако, найти качественный кириллический стилизованный шрифт оказалось сложной задачей. Второй сложностью, с которой мы столкнулись, оказалось создание веб-шрифта из формата TrueType. Существуют генераторы веб-шрифтов, самый популярный из которых fontsquirrel.com. Тем не менее подобные сервисы не позволяют генерировать наборы веб-шрифтов на основе коммерческой гарнитуры, вне зависимости от того есть ли у нас права на ее использование.

Заключение

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

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

Эта запись была добавлена 22 Апр. 2011 в 16:10 под рубрикой полезное, про наших, статьи. Вы можете читать все комментарии в топике через ленту RSS 2.0. Вы можете написать комментарий, или сделать обратную ссылку с вашего сайта.